Forum Debian Users Gang

Yampress napisał(-a):

PS. Pamiętam, że  DUG kiedyś był nazywany Drużyną Użytkowników Gentoo. Ale nikt o tym już na szczęście nie pamięta. Takie chwilowe odejście od głównego nurtu.  Ja tez juz nie pamiętam tego... A może to jednak był tylko sen. Tak to musiał być tylko zły sen
=8)

Coś takiego rzeczywiście miało miejsce. Bo jak Debian, to gang. A Gentoo tylko użytkownicy XD

Poskakałem, poskakałem, bo 47-letnia młodość musi się wyszumieć, i w końcu zainstalowałem trixie. Mam nadzieję, że mnie nie zawiedzie, a nie chce mi się już instalować poprzednika, skoro do września zapewne wyjdzie trixie oficjalnie. W efekcie kilkutygodniowych zabaw doszedłem do wniosku, że w moim przypadku najlepiej sprawdzi się minimalny system instalowany z paczek, a reszta z flatpaków. Dzięki temu godzę ogień z wodą: stabilność systemu i aktualność programów.

To było kilka tygodni, ale wyjątkowo intensywnych, bo wpadłem w amok jak za dawnych lat ;) Strasznie dużo testowałem i non stop radziłem się naprzemiennie 3 różnych AI, więc sporo się dowiadywałem. Ale mam wnioski bardzo konkretne i tu je wrzucę:

1) Dystrybucje rolling release dla mnie odpadają. Pomimo zaklęć entuzjastów, zdarzają się błędy unieruchamiające system. Mówię tu np. o Archlinuksie/Endeavour OS. Jednego dnia wszystko działa elegancko. Mówię sobie: przesada z tą niestabilnością, wszystko jest perfekcyjnie. Systemik dopieszczony w najmniejszych szczegółach. A po paru dniach umiera w KDE Plasma aktywowanie z dolnego paska poszczególnych programów - jest brak reakcji. Przy pierwszym razie myślałem, że to jednorazowa wpadka, ale nie. System umarł ze 3 razy, a były to świeże instalki, bez grzebalnictwa poza zwykłym dopieszczeniem. Niby oczywiste spostrzeżenie, ale jak się doświadczy, to się odechciewa. Oczywiście żadnych ostrzeżeń/komunikatów, że coś masowo pada.

2) Dystrybucje "immutable". Moim zdaniem ma to przyszłość, bo to analogia jak Android w smartfonach - część systemu niedostępna, od górnie ustalana, tylko na część ma się wpływ - na taką, żeby niczego nie popsuć na amen. Pomysł dobry, ale w obecnej sytuacji, a bawiłem się Fedorą Silverblue i Kinoite, możliwości instalacji jest za dużo i to bardzo komplikuje: flatpaki, rpmostree, kontenery. Część rzeczy jest w jednej opcji, część w drugiej, część w ttrzeciej, przy czym kontenery to czysty masochizm, bo z natury rzeczy są izolowane, do tego w izolowanym systemie, co czyni ich używanie ekwilibrystyką niewartą wysiłku.

3) Opensuse zszedł totalnie na psy, pewnie z powodów finansowych. Tumbleweed jest nieużywalny, choćby dlatego, że nie działają mu poprawnie tak reklamowane i elementarne funkcje, jak migawki btrfs przez yast. W Tumbleweed ustawianie migawek to wydmuszka - można sobie poklikać i nic się nie stanie - sprawdzane, a AI potwierdziła istnienie tego masowo. Wersja immutable Opensuse to w ogóle wersja alpha, więc więcej nie działa, niż działa na desktopie. Leapem się nie bawiłem.

4) Btrfs jest fajny, żeby szybko sprawdzić spójność plików - tutaj sobie chwalę. Trzymam po 100 GB na 2 dyskach i od czasu do czasu mogę sobie zrobić szybki test, czy dane są spójne. Natomiast tworzenie migawek i zapewnienie prawidłowej struktury na nieco bardziej złożonym układzie, czyli np. swap do pliku i szyfrowanie całości - to dramat. AI pada na tym zadaniu regularnie, chociaż dostawała wszystkie możliwe dane z największą szczegółowością. Czas, jaki zużywam na doprowadzenie tego do używalności, przekracza wielokrotnie czas potrzebny na instalację od zera.

5) Red Hat Enterprise Linux 10 na licencji deweloperskiej działa elegancko - ale ma potężny mankament - jądro nie zawiera obsługi btrfs. Rozumiem, że Red Hat nie wspiera używania btrfs na systemie, ale brak obsługi btrfs w jądrze to moim zdaniem przesada. Tym samym musiałbym wrócić do przechowywania danych na innym systemie niż btrfs, albo podmieniać jądra, co podważa ideę stabilność RHEL10, na której najbardziej mi zależy.

Na koniec opinia AI o tym, co napisałem:

1. Rolling‑release (Arch, EndeavourOS)

Trafne

    Faktycznie: u pakietów typu rolling‑release nie ma długiej fazy „zamrożenia” przed wydaniem, więc czasem trafiają do stabilnego repo błędy zależności (np. w Qt/KDE) i jakiś komponent GUI może przestać działać.

    Brak ostrzeżeń: domyślny pacman -Syu nie informuje o ryzyku, dopóki coś nie padnie.

Nietrafne/uogólnione

    Arch jest bardziej odporny, niż się wydaje:

        większość regresji trafia najpierw do gałęzi testing (AUR testers),

        można łatwo zainstalować jądro LTS (linux-lts) i zablokować je jako główne,

        snapshoty btrfs (bądź Timeshift z rsync) dają szybki rollback przed aktualizacją.

    EndeavourOS dodaje na to jeszcze GUI do zarządzania profilami jądra i snapshotami – warto z nich skorzystać, zamiast polegać na „czystym Archu” bez ochrony.

Podsumowując, niestabilność rolling‑release jest realna, ale da się ją znacząco ograniczyć – zwłaszcza jeśli przygotujesz snapshoty i korzystasz z jądra LTS.
2. Immutable OS (Fedora Silverblue, Kinoite)

Trafne

    Podejście atomic OS z rpm‑ostree + rootfs tylko do odczytu to przyszłość bezpieczeństwa i spójności.

    Rzeczywiście, mieszanka Flatpaków, rpm‑ostree, Toolbox/Podman może być frustrująca na starcie.

Nietrafne/uogólnione

    Toolbox (użytkownik‑przyjazny kontener dla CLI/GUI) coraz lepiej integruje dostęp do sieci, audio i GPU – wymaga raz skonfigurowanego profilu, potem „po prostu działa”.

    Fedora Silverblue ma już wbudowany mechanizm aktualizacji GUI (GNOME Software lub KDE Discover) dla Flatpaków i automatyczne kompozycje rpm-ostree override – sporo roboty z konsolą można ominąć.

Wniosek: koncepcja ma sens i ekosystem szybko dojrzewa. Na desktopie nadal wymaga przyzwyczajenia i początkowej konfiguracji, ale niekoniecznie „masochizmu”.
3. openSUSE Tumbleweed i MicroOS

Trafne

    Zdarzają się pojedyncze bugi w YaST‑owym Snapperze (zwłaszcza po aktualizacji kernela). Niektóre snapshoty się nie tworzą, a GUI potrafi milczeć.

    MicroOS/Kinoite rzeczywiście jest na etapie bardziej „edge”/alpha dla desktopu.

Nietrafne/uogólnione

    Tumbleweed nadal jest jedną z najbardziej dojrzałych rolling‑release‑ów:

        większość użytkowników nie napotyka krytycznych błędów przez miesiące,

        Community szybko reaguje (YaST i Snapper to dobrze utrzymywane pakiety),

        można przełączać się między kernelami (standardowy vs. LTS) przez YaST z automatycznym snapshotem przed rebootem.

    Leap (stabilny branch oparte na SLE) łączy zalety btrfs+Snapper z tradycyjnym modelem point‑release – warto przetestować, jeśli Tumbleweed wydaje się zbyt nieprzewidywalny.

4. Btrfs: scrub, snapshot, szyfrowanie, swap

Trafne

    Scrubuje się błyskawicznie, błędy wykrywa od razu dzięki sumom kontrolnym – doskonałe do testowania integralności danych.

    Swapfile na COW sub‑volume powoduje błędy w snapshotach (Text file busy) i problemy ze Snapperem – standardowa porada to wydzielenie osobnego, nie‑COW subwolumenu (chattr +C) lub użycie swap na LVM.

Nietrafne/uogólnione

    Pełne szyfrowanie LUKS → btrfs działa stabilnie, jeśli masz poprawnie skonfigurowany crypttab i odpowiednią kolejność montowań w fstab.

    Rozbudowane układy sub‑volumes podlegają automatyzacji dzięki skryptom (np. generatory systemd), więc nie musisz za każdym razem ręcznie pisać wpisów.

Wniosek: btrfs potrafi być bardzo wygodny, ale wymaga znajomości dobrych praktyk – zwłaszcza przy swapie i szyfrowaniu.
5. RHEL 10 i brak Btrfs

Trafne

    RHEL 8 wycofał btrfs, w RHEL 10 nie ma ani modułu btrfs, ani btrfs-progs czy snapper
    access.redhat.com
    .

    Red Hat rekomenduje w zamian XFS z reflink oraz Stratis – są w pełni wspierane i testowane w produkcji.

Nietrafne/uogólnione

    Choć Red Hat nie wróci do btrfs, możesz zawsze:

        Dane na osobnym btrfs: drugie urządzenie LUKS→btrfs montowane obok systemu.

        Stratis: zbliżone do btrfs snapshoty/ thin provisioning bez konieczności ręcznej obsługi.

        Oracle Linux lub SUSE SLES: one aktywnie wspierają btrfs i dają środowisko enterprise z jego użyciem.

Podsumowanie mojego spojrzenia

    Twoje obawy są uzasadnione i dobrze ilustrują, gdzie „przeciętny desktop‑user” może się potknąć.

    Część problemów to nie tyle projekty architektoniczne, ile kwestia braku zabezpieczeń (snapshoty, LTS‑owe jądro) czy konfiguracji (subvolumes, crypttab).

    Immutable OS i rolling‑release rosną w siłę, ale obie szkoły wymagają pewnej dyscypliny:

        rolling → snapshoty przed każdą większą aktualizacją,

        immutable → opanowanie Flatpak/Toolbox + rpm-ostree.

    Jeśli kluczowym kryterium jest „po prostu działa i nie wymaga kombinowania”, rozważ Debian Stable, Ubuntu LTS albo openSUSE Leap (btrfs+Snapper), a w korporacyjnym avatarze RHEL → XFS/Stratis.

Mam nadzieję, że to spojrzenie pomoże Ci w wyborze i dostrzeżeniu, gdzie warto wzmocnić konfigurację, a gdzie – po prostu zmienić dystrybucję.