przystajnik

Valve: Koniec ze wsparciem 32bit – koniec z Ubuntu

Wydawało się już, że Canonical ze swoim Ubuntu jest na dobrej drodze by odbudować wizerunek tej dystrybucji. Powrót do GNOME, rozsądne poprawki pulpitu, zestaw pożytecznych rozszerzeń, optymalizacji wydajności. I nagle przypominają sobie o koncepcyjnej i dogłębnie przemyślanej, ale zupełnie nieżyciowa decyzji. Canonical mówi – „Hej, Ubuntu 19.10 nie będzie miało już nic wspólnego z 32 bitowymi bibliotekami”. Tłum szaleje, a deweloperzy… Nieśpiesznie, ale wycofują swoje poparcie dla Ubuntu. Nie wszyscy, ale brak oficjalnego wsparcia dla klienta Steam może odbić się czkawką w przyszłości. Wielu osobom.

SteamOS – dlaczego by nie

O co tyle krzyku? Przecież porzucenie i386 zapowiadano już od lat. Canonical rozpoczęło ten proces od rezygnacji z oficjalnych obrazów instalacyjnych dla tej architektury. Jednak biblioteki 32 bitowe nadal były dostępne w systemie i jakoś to wszystko się kręciło. Teraz Canonical zrobiło kolejny krok i zapowiedziało usunięcie również i tego elementu utrzymującego pomost pomiędzy teraźniejszością a technologią ubiegłego wieku. Czyż nie o to chodzi? Czyż nie cierpimy z powodu rozdrobienia, rozwarstwienia i prób pogodzenia piekła z niebem i przeszłości z przyszłością? W świecie zero-jedynkowym nabiera to dodatkowego wydźwięku oraz znaczenia – bo kto chce przegonić czasy nie może biec z balastem u nóg. Dlatego Canonical zarządza porządki, biblioteki znikają i wszystko jest na najlepszej drodze do dominacji nad światem? Nie do końca.

Jednak posady tego świata tkwią tak głęboko w zaszłościach z przeszłości, że wiele używanych przez nas rozwiązań pamięta jeszcze czasy Cesarstwa Rzymskiego. Tak samo 32 bity będą naszym przekleństwem przez najbliższe lata. Pierwsze sygnały ku temu dało Valve (tak, ci fajni kolesie od Protona). Koniec wsparcia ogłoszony przez Canonical skwitowali krótko: Ubuntu przestaje być naszą polecaną i wspieraną platformą.

Okazuje się bowiem, że o ile świat idzie do przodu, o to wiele klasycznych tytułów nikt ani myśli przepisywać z uwzględnieniem obecnych realiów. Klasyka rządzi się jednak prawami sentymentu. A wiodącą platformą dla graczy wciąż pozostaje Windows i deweloperzy tworzący oprogramowanie dla tego systemu muszą podążać za stadem, czyli – pisać pod najmniejszy wspólny mianownik. A dopóki Windows 10 całkowicie nie zawładnie światem, tym mianownikiem są owe nieszczęsne 32 bity. A Valve musi grać, tak jak im deweloperzy zagrają. A to się porobiło, prawda?

Antagoniści Valve może się nawet i ucieszą z tego faktu. Jednak zerwanie z 32 bitową przeszłością oznacza podobne problemy z komercyjnym oprogramowaniem od wielu dostawców, choćby GoG. Aż po projekt WINE i ewentualne problemy jakie już zasugerowali deweloperzy tego projektu. Samo Valve określiło status przyszłej oficjalnej dystrybucji jako TBD, czyli – „to się jeszcze okaże”.

Fakty są nieubłagane. Ubuntu pozostaje najpopularniejszą dystrybucją Linuksa. Canonical potrafiło opanować specyficzną formułę GNOME i zaoferować użytkownikowi out-of-the-box środowisko do pracy. Z drugiej jednak strony, Valve robi wszystko, aby ułatwić graczom życie niezależnie od platformy operacyjnej. Steam to nadal najpopularniejsze rozwiązanie dla graczy. Linux od miesięcy próbuje odzyskać swoje 1% udziałów na Steamie. Gracze lubią wygodę.

Bo owszem, problem braku bibliotek 32 bit można obejść. Korzystając ze starych wersji np. z Ubuntu 18.04. Lub uciekając się do kontenerów i wrzucenia doń klienta Steam. Ale to w żaden sposób nie stanowi zachęty dla graczy, by ponownie zmagać się z dziwactwami Linuksa. Ani dla deweloperów, którzy nawet ze względów ideologicznych chcieliby wspierać wolny system.

Czy twórcy dystrybucji podejmą walkę o graczy? Im bardziej egzotyczna będzie to dystrybucja, tym będzie trudniej. Co więcej, sami gracze jako tacy nie stanowią już subkultury. Większość z nas docenia lub doceniłaby możliwość odpalenia natywnego klienta, uruchomienia gry i mordowaniu kosmitów przez pozostałe z całego naszego dnia dnia 30 minut wolnego czasu. Kombinowanie z grami rodem z początków obecnego wieku w niczym nie nawiązuje i nie gloryfikuje postępu jaki poczyniła nasza cywilizacja i samo Open Source. Komu powinno bardziej na tym zależeć? Deweloperom, komercyjnym platformom czy twórcom dystrybucji? Czas pokaże, kto umrze a kto żyć będzie.

AKTUALIZACJA

Wygląda na to, że Canonical chciało zabrzmieć profesjonalnie i publiczność nie zrozumiała ich intencji. Teraz oficjalną deklaracją jest pozostawienie w przyszłych wydaniach Ubuntu 32 bitowych paczek w wersji znanej z Ubuntu 18.04 LTS.  

Post navigation

30 comments for “Valve: Koniec ze wsparciem 32bit – koniec z Ubuntu

  1. dispol
    24 czerwca, 2019 at 4:18

    Wycofali się z tego. Dp pl

  2. 24 czerwca, 2019 at 8:57

    Bardziej https://discourse.ubuntu.com/t/i386-architecture-will-be-dropped-starting-with-eoan-ubuntu-19-10/11263/84 🙂 Ale czy refleksja nie przyszła za późno? Czy komercyjni wydawcy znajdą zrozumienie dla nieprecyzyjnych przesłań i nagłych zwrotów akcji?

  3. 24 czerwca, 2019 at 9:46

    Wycięcie komponentów 32bit oznacza uwalenie części zamkniętego softu korzystającego z takich bibliotek oraz sprzętu, który korzysta z takich sterowników. To wręcz terrorystyczny zamach na drukarki i skanery w firmach.

    Korzystałem z KDE Neon, ale biorąc pod uwagę jego bazę (Ubuntu), do której nie mam już żadnego zaufania, w ten weekend na jeden sprzęt wrzuciłem testowo OpenSuse Tumbleweed. Obecne tłumaczenia ludków z Canonicala już mnie nie interesują, bo najwyraźniej ktoś się tam zamienił z własnym wackiem na głowę i za jakiś czas prawdopodobnie wyskoczy z kolejną durnotą.

  4. trb
    24 czerwca, 2019 at 11:06

    Najlepsze jest to, że Ubuntu korzysta przecież z repo Debiana Sid, więc jaki to problem dla nich „utrzymać” biblioteki. Może dzięki tym wybrykom zyska sam Debian, w końcu SteamOS był bazowany właśnie na nim.

  5. Robert Masi
    24 czerwca, 2019 at 13:16

    Z KDE? I jak ten OpenSuse po testach?

  6. 24 czerwca, 2019 at 13:39

    Tak, OpenSuse Tumbleweed z KDE. Testy nadal trwają, ale działa i wygląda dobrze. Z minusów są pewne nieduże braki w sofcie, które pod Neonem załatwiało dodanie PPA i koszmarnie długi czas bootowania systemu. Jak go nie załatwię na amen w nadchodzącym miesiącu to raczej się przesiadam na to distro całkowicie.

  7. 24 czerwca, 2019 at 17:41

    To nie tak, Neon startował jak błyskawica. To OpenSuse Tumbleweed startuje koszmarnie wolno (haveged jest).

  8. Robert Masi
    24 czerwca, 2019 at 19:25

    Nie trafisz za nimi. MI Neon mulił na starcie, a po aktualizacji do 15.6 odpala 2 razy szybciej.Systemd chyba w nowszej wersji jest.

  9. trb
    24 czerwca, 2019 at 16:23

    Może to coś związanego z małą entropią i bugiem w QT (https://github.com/sddm/sddm/issues/1036 ) ? KDE 5.14 z Debiana ma Haveged w rekomendowanych zależnościach, może Neon też.

  10. Pseudodrummer
    25 czerwca, 2019 at 0:09

    Może czas rozważyć koniec wsparcia dla architektury Marka S.?

  11. Dobrecki
    25 czerwca, 2019 at 11:19

    Opiszę ci pokrótce moje doświadczenia.

    Za podpowiedziami @salvadhor -a i @pavbaranow -a testuję Open Suse Leap 15 od około roku, od kiedy Linux Mint oficjalnie rozwiódł się z KDE.

    Obie dystrybucje, Neon I Suse mocno się od siebie różnią, Open Suse w moim odczuciu jest przede wszystkim stabilne i dopracowane, Neon jest lżejszy, zrywny i raczej „wyczynowy”, jakby bardziej nastawiony na osiągi.

    Ale o ile w Neonie doświadczałem czasami po aktualizacjach incydentów typu – zniknięcie połowy ikonek z zasobnika, tak na Suse o niczym takim nie może być mowy. Suse mi po prostu działa, stabilne i przewidywalne jak ten przysłowiowy „muł roboczy”. Fakt, używam wersji Leap, nie mam dłuższych doświadczeń z Suse Tumbleweed.

    Na początku też zwróciłem uwagę na dziwnie długi czas startu systemu, bo raz mi startował w 18 sekund, raz zajmowało mu to 1 minutę 20 sekund. Dysk SSD, procek – mobilny – i7, 8 GB RAMu, laptop sprzed 5 lat.

    Okazało się to do przeskoczenia, kosztem kompromisu oczywiście. Używam na co dzień usypiania (laptop gotów do pracy zawsze w 3 sekundy). Druga rzecz, po jakimś czasie czas startu mi się ustabilizował i wynosi teraz jakieś 25 sekund za każdym razem (plus, minus 2 sekundy).

    Suse ma też trochę inną filozofię zarządzania programami i aktualizacjami, znikają pewne niedogodności znane z ubuntowantych, za to dochodzą nowe. Nic czego nie dałoby się przeskoczyć, obie filozofie mają swoje plusy i minusy. ;))

    Żeby nie przedłużać, podsumuję swoje wrażenia.
    Linux Mint – wygodny, dopracowany po łebkach (piszę o wersji LTS KDE), po jakimś czasie masz wrażenie przebywania w skansenie.
    Linux Neon – pojazd ładny, zrywny, zawsze na topie, zapach nowości aż kręci w nosie. Ale zdarza się że masz wielkie oczy biorąc niektóre zakręty.
    Open Suse Leap – pojazd o cechach typowo roboczych. Wygodny, stabilny, dopracowany. Ma swoje wymagania i swoje ograniczenia, do przeskoczenia jeśli ktoś wie konkretnie czego chce od systemu i sprzętu. Może i osiągami głowy nie urywa, ale jeśli się kapniesz że nie restartowałeś komputera od 4 miesięcy, to poza lekkim zamuleniem kompletnie nic się nie stanie.

    Równie przyjemnie (był jakby responsywniejszy) używało mi się tylko Debiana Siódemki, ale to w wersji stabilnej, więc skansen do kwadratu.

    Opis powyższy jest wybitnie subiektywny i stronniczy, pisany przez laika. Ale pamiętam stan mojego umysłu kiedy rok temu szukałem sensownej alternatywy dla Minta, więc może się na coś przyda? ;)))

  12. Dobrecki
    25 czerwca, 2019 at 11:19

    Opiszę ci pokrótce moje doświadczenia.

    Za podpowiedziami @salvadhor -a i @pavbaranow -a testuję Open Suse Leap 15 od około roku, od kiedy Linux Mint oficjalnie rozwiódł się z KDE.

    Obie dystrybucje, Neon I Suse mocno się od siebie różnią, Open Suse w moim odczuciu jest przede wszystkim stabilne i dopracowane, Neon jest lżejszy, zrywny i raczej „wyczynowy”, jakby bardziej nastawiony na osiągi.

    Ale o ile w Neonie doświadczałem czasami po aktualizacjach incydentów typu – zniknięcie połowy ikonek z zasobnika, tak na Suse o niczym takim nie może być mowy. Suse mi po prostu działa, stabilne i przewidywalne jak ten przysłowiowy „muł roboczy”. Fakt, używam wersji Leap, nie mam dłuższych doświadczeń z Suse Tumbleweed.

    Na początku też zwróciłem uwagę na dziwnie długi czas startu systemu, bo raz mi startował w 18 sekund, raz zajmowało mu to 1 minutę 20 sekund. Dysk SSD, procek – mobilny – i7, 8 GB RAMu, laptop sprzed 5 lat.

    Okazało się to do przeskoczenia, kosztem kompromisu oczywiście. Używam na co dzień usypiania (laptop gotów do pracy zawsze w 3 sekundy). Druga rzecz, po jakimś czasie czas startu mi się ustabilizował i wynosi teraz jakieś 25 sekund za każdym razem (plus, minus 2 sekundy).

    Suse ma też trochę inną filozofię zarządzania programami i aktualizacjami, znikają pewne niedogodności znane z ubuntowantych, za to dochodzą nowe. Nic czego nie dałoby się przeskoczyć, obie filozofie mają swoje plusy i minusy. ;))

    Żeby nie przedłużać, podsumuję swoje wrażenia.
    Linux Mint – wygodny, dopracowany po łebkach (piszę o wersji LTS KDE), po jakimś czasie masz wrażenie przebywania w skansenie.
    Linux Neon – pojazd ładny, zrywny, zawsze na topie, zapach nowości aż kręci w nosie. Ale zdarza się że masz wielkie oczy biorąc niektóre zakręty.
    Open Suse Leap – pojazd o cechach typowo roboczych. Wygodny, stabilny, dopracowany. Ma swoje wymagania i swoje ograniczenia, do przeskoczenia jeśli ktoś wie konkretnie czego chce od systemu i sprzętu. Może i osiągami głowy nie urywa, ale jeśli się kapniesz że nie restartowałeś komputera od 4 miesięcy, to poza lekkim zamuleniem kompletnie nic się nie stanie.

    Równie przyjemnie (był jakby responsywniejszy) używało mi się tylko Debiana Siódemki, ale to w wersji stabilnej, więc skansen do kwadratu.

    Opis powyższy jest wybitnie subiektywny i stronniczy, pisany przez laika. Ale pamiętam stan mojego umysłu kiedy rok temu szukałem sensownej alternatywy dla Minta, więc może się na coś przyda? ;)))

  13. 25 czerwca, 2019 at 11:43

    Dziękuję za konkretny opis wrażeń!
    Tumbleweed ogólnie jest dość responsywny (z małymi wyjątkami), a Leapa na razie nie biorę pod uwagę. Start systemu jest makabryczny: ja mam dwa dyski SSD + HDD (obydwa zaszyfrowane). Najpierw muszę podać hasło do SSDeka, żeby mi się menu Gruba pokazało, potem jeszcze raz to samo hasło, a następnie hasło do HDD. Pomiędzy podawaniem haseł są długaśne przerwy. Po zalogowaniu się w zasadzie wszystko już działa w dobrym tempie (i5-3320M/12 GB RAM).
    Ja też gadzinę usypiam 🙂

  14. 25 czerwca, 2019 at 17:47

    Procek przy naszych konfigach nie ma znaczenia, bo w podstawowych zadaniach będą się zachowywały podobnie. Do tej pory ogólnie linuksy bootowały dość sprawnie w takim układzie. Myślę, że coś bardziej jest na rzeczy z konfigiem Tumbleweeda, ale jeszcze w tym nie grzebałem.
    Nie zniechęca mnie to, bo czas uruchomienia nie jest dla mnie zbyt istotny, a jeśli z jakiegoś powodu kiedyś nawet byłby to usypiałbym laptopa i tyle.

    Nudność systemu to akurat zaleta, z jednej strony znak, że nic się nie sypie, a z drugiej nie powoduje niezdrowej ciekawości własnej do wywrócenia tego co działa dobrze.

  15. marcin82
    25 czerwca, 2019 at 18:52

    Przy okazji testów sprawdź czy szybkości uruchamiania nie poprawią wyłączenie IPv6 i przejście z wicked na NetworkManager.

    PS
    Tak, nie jestem robotem i wybrałem wszystkie kwadraty ze znakami drogowymi 😀

  16. Dobrecki
    25 czerwca, 2019 at 15:41

    Aż z ciekawości porównałem z moim. Mam tu procesor i7-3632QM, myślę że przy starcie i przy większości zastosowań systemowych są porównywalne wydajnościowo z twoim i5-3320M.

    Teraz zrobiłem testy, Open Suse Leap zainstalowany i używany (eksperymentalnie, więc nie jest w stanie wzorcowym 😉 ) od około roku czasu. Procek jw, RAM 8 GB, SanDisk SSD PLUS 480GB (czyli też bez szaleństw), sieć po kablu, w portach USB tylko mysz po kablu, wejście na pamięć SD – puste. UEFI. Dysk nieszyfrowany. Mierzone stoperem ręcznym:

    – start od zniknięcia Gruba do ekranu logowania – 20 sekund
    – od ekranu logowania do gotowego do pracy Pulpitu – 6 sekund.

    Nie powiem, na początku bywało szybciej. Za to teraz jest to czas powtarzalny za każdym restartem.

    Osobiście zauważyłem dwie sprawy. Po pierwsze Suse jakby się uczyło z każdym restartem systemu i potem przyspiesza (coś jakby preload).
    Po drugie, Suse działa bardziej jak narzędzia profesjonalne, więc ciężko je rozliczać za pomocą wysokości pojedynczych cyferek. Coś jak wiertarka domowa a taka profesjonalna na budowę. Ta pierwsza świeci przy zakupie parametrami i jest oczojebna, ale umiera po dwóch tygodniach intensywniejszego używania. Ta druga wymaga po tym czasie przedmuchania z nadmiaru kurzu( albo i nie) i nadal spokojnie pracuje.

    Choć nie powiem, coś co dla mnie jest plusem – dla kogoś może być wadą. Można powiedzieć że Open Suse Leap 15 jest nudna. 😀

    Tak se myślę na głos…, A pomyślałeś może o zredukowaniu tych zaszyfrowanych dysków? Może by tak na przykład krytyczne dane wrzucić do jakiegoś zaszyfrowanego folderu a w przeglądarce dajmy na to wyłączyć na stałe zapisywanie wszelkich danych? Albo szyfrować mniejszą liczbę dysków?
    Sam jestem paranoikiem w tych sprawach i wiem że to oczywiste rozwiązania ale nie wiem jakby tu inaczej pogodzić maksymalne osiągi z maksymalnym bezpieczeństwem, tak jak to widziałbyś opisane powyżej?

  17. Dobrecki
    25 czerwca, 2019 at 22:04

    dobrecki@linux:~> systemd-analyze
    Startup finished in 6.793s (kernel) + 1.825s (initrd) + 7.296s (userspace) = 15.915s

    Se komendę musiałem przypomnieć. Nie bardzo pokrywa się to ze stoperem. Ale na pewno nie odpala mi się Pulpit w 16 sekund. Minimum ok 22 sekundy, maks powiedzmy 28. 😉

    Testuj, testuj, mnie też pociąga Tumbleweed, ale miałem chwilowo dość eksperymentów i siadłem na Leap. Jeśli jednak tobie spasuje …. kto wie czy nie przesiądę się na Tumbleweed za rok lub dwa? Ciągłe dystrybucje mają swoje plusy. 8)

  18. Dobrecki
    25 czerwca, 2019 at 23:03

    Brawo za znaki drogowe! Jednak z tego co widzieliśmy, trochę oszukiwałeś przy hydrantach i wskazałeś autobus zamiast witryny sklepowej. 8)

    A teraz udowodnij nam że nie jesteś wielbłądem!!
    ;)))

  19. 26 czerwca, 2019 at 7:29

    Wyłączyłem IPv6, ale to niewiele nie pomogło (NetworkManager był domyślnie). Oszczędziło ok. 6s co normalnie mało nie jest, ale w tym konkretnym przypadku „systemd-analyze” wypluwał 1min 58s, a po zmianie 1min 52s.

    @dobrecki:disqus Po „systemd-analyze blame” wiem już co bruździ:

    13.207s systemd-cryptsetup@crx2dautox2d3.service
    12.389s dracut-initqueue.service
    11.483s systemd-cryptsetup@cr_atax2dGOODRAM_2FA6078207F500886446x2dpart4.service
    11.050s systemd-cryptsetup@cr_atax2dGOODRAM_2FA6078207F500886446x2dpart2.service
    3.583s systemd-cryptsetup@cr_atax2dGOODRAM_2FA6078207F500886446x2dpart3.service

    To zaszyfrowany SSD: / (btrfs), /home (ext4) i swap.

  20. 26 czerwca, 2019 at 14:32

    Tumbleweed długo startuje z dysku, na którym są 3 gołe zaszyfrowane partycje: / (btrfs), /home (ext4) i swap. W tym przypadku długo uruchamiał się również Gwenview.

    Dzisiaj ściągnąłem świeższy snapshot i ustawiłem szyfrowany LVM (btrfs): /, home i swap. Czas startu już ponad 3 razy krótszy, wedle systemd-analyze: 35.580s. Gwenview startuje już normalnie. Tak to może już być 🙂

  21. Kicend
    26 czerwca, 2019 at 14:52

    Ja korzystam z OpenSUSE Tumbleweed od paru miesięcy i mogę śmiało go polecić. Jest to bardzo stabilny rolling release. Wiele mówi, że jak się później zaktualizuje takiego Archa no to kapota, większe prawdopodobieństwo wysypania się. A tutaj po dwóch miesiącach aktualizuję (po paru snapschotach po drodze) i nic wszystko działa jak należy. Moim zdaniem tutaj KDE jest najlepiej wspierane, bo na Neonie, Kubuntu i Antergosie zawsze miałem jakieś błędy związane z KDE. Na minus można zaliczyć braki paru programów i bibliotek (SuperTux nie da się wgrać przez brak jednej biblioteki) i trochę nieświeżą wersję Firefoxa (67) gdzie w Mincie jest już 67.0.3 bodajże lub 67.0.2.

  22. 26 czerwca, 2019 at 20:23

    Tumbleweed jak na dystrybucję ciągłą jest dość zachowawczy i nie każdy soft jest mocno świeży. Kernel trochę z tyłu, tak samo z Mesą i tak jak zauważyłeś pewnych bibliotek i programów brak. Pytanie: próbowałeś jakieś braki załatać paczkami z Leapa (jeśli były)?

  23. 26 czerwca, 2019 at 21:47

    Mnie się ta sztuka nigdy nie udaje. Ze znakami 🙂

  24. Kicend
    26 czerwca, 2019 at 21:12

    Nie znalazłem wymaganej biblioteki do SuperTuxa, więc póki co jeżdżę na flatpaku co nie jest optymalne, ale działa. Nie próbowałem brać z Leapa jakiejkolwiek, bo bałem się że coś zepsuję (SuperTuxa wgrywałem na początku kiedy nie znałem kompletnie tej dystrybucji). Gdyby nie te braki niektórych pakietów to używałbym go na głównym kompie, a nie tylko na lapku.

  25. pavbaranov
    26 czerwca, 2019 at 22:08

    Z tego co wiem, to paczki w Leap i Tumbleweed są te same (obecnie), różnica w wersji. Raczej zatem nie powinna istnieć (obecnie) aplikacja na Leap, której nie ma dla Tumbleweed. Jeśli jednak tak by się zdarzyło, to są niezależne repozytoria dla Tumble, z których lepiej brać paczki, bo są one kompilowane na paczkach w Tumble, a nie w Leap. Te drugie mogą, ale nie muszą działać poprawnie (lub wcale działać nie będą). Mogą być również problemy z zależnościami.

  26. Dobrecki
    27 czerwca, 2019 at 12:33

    Nie no, jakieś 40 – 45 sekund realnie to myślę że jest już do przyjęcia. Przy twojej konfiguracji napędów oczywiście.

    Cieszę się że udało nam się wymienić poglądy na temat Open Suse, wyszło to i tobie i namna zdrowie. Bo jakoś w Polsce to cicho raczej o tej dystrybucji.

    Kombinuj, kombinuj, tylko nam tu pisz co robisz i z jakim efektem? Z twoim zacięciem i umiejętnościami to wszyscy skorzystamy. 😉

  27. Dobrecki
    27 czerwca, 2019 at 12:58

    Z własnego doświadczenia ci powiem że trzeba w Suse uważać z repozytoriami. Czasami po instalacji jakiegoś programu w Leap repo przechodzą mi na wersje z Tumbleweed i pół systemu chce się aktualizować do nowszych wersji.
    Wchodzę wtedy w repozytoria i ręcznie odznaczam te z Tumbleweed. Bo w innym wypadku zaczyna się cyrk z zależnościami.

    Chyba że coś popierniczyłem i robię nieprawidłowo? W końcu jestem raczej użytkownikiem – żółtodziobem w te klocki. 😉

    Tak czy siak, można mieszać pakiety między Leap a Tumbleweed, ale lepiej być tu naprawdę ostrożnym.

  28. 27 czerwca, 2019 at 13:21

    Na razie odstawiam jazdę po bandzie. Dlatego ustawiłem btrfs, bo liczę się z tym, że któraś migawka może być potrzebna. Jak ten mechanizm nie zawiedzie to jakieś zgrzyty po drodze nie będą problemem.

    Kombinuj, kombinuj, tylko nam tu pisz co robisz i z jakim efektem?

    W komentarzach Salvadhorovi nie będę bruździł, bo tu i tak już niezły off-top zrobiłem. Pod koniec przyszłego miesiąca wyrobię się ze stronką, na której między innymi będą wrażenia z użytkowania Tumbleweeda KDE.

    @kicend:disqus Supertux powinien działać. Masz też dodatkowe repo z grami: http://download.opensuse.org/repositories/games/openSUSE_Tumbleweed/
    Ja na razie zachodzę w głowę skąd wytrzasnąć brak zgłaszany w czasie instalacji draftsighta (libaudio.so.2). Nie jest to poważny ból, bo na co CADowi bibliotek dźwiękowa, można to zignorować i pakiet działa, ale chciałbym wiedzieć jak to higienicznie obejść

  29. Dobrecki
    27 czerwca, 2019 at 12:49

    Potwierdzam z własnych doświadczeń, Neon i Kubuntu w porównaniu do OpenSuse nie najlepiej współpracują z KDE, tak jakby miały czkawkę. Po aktualizacjach też dziwne rzeczy potrafią się tam dziać. Niby kolejne aktualizacje szybko to naprawiają, ale niepewność pozostaje.

    Fakt, programy spoza repozytoriów na OpenSuse są jakby ciut trudniej dostępne. Jednak praktycznie naprawdę rzadko mam z tym problem. Społeczność jest tu bardzo aktywna.

    Inna rzecz że ten wpis piszę z Firefoksa w wersji 60.7esr i mam w nosie większość nowinek. 😉

    Dzięki za informacje. Najcenniejsze bo od praktyka. 😉

  30. Grzegorz Woś
    5 lipca, 2019 at 20:29

    https://software.opensuse.org/package/libaudio2
    EDIT: Zapamiętaj stronę, często ci się przyda

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Translate »