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ę.

Ja słucham ekstremalnego metalu i nie zdziadziałem do poziomu ZZ Top, ale wszystko przede mną ;D

Pewnie za rok skuszę się na nowe Ubuntu LTS, żeby potestować, bo w tej rundzie zabaw Ubuntu nie instalowałem. Ale póki co wychodzi mi, że Debian, RHEL i ewentualnie klony [Alma, Rocky - ale ich nie sprawdzałem], a potencjalnie Ubuntu LTS - tylko to się nadaje na moje potrzeby desktopowe. Ale w sumie nie do końca wiem, jaką przewagę ma Ubuntu nad Debianem. I tak poza bazą wszystko instaluję we flatpakach, więc pewnie zamiana flatpaków na snapy i bardziej fikuśne UI niż waniliowy Gnome.

Nie rozumiem fenomenu Minta i środowiska Cinnamon - po instalacji działał bez problemu [ale to akurat potrafi na moim starym kompie wiele stabilnych wydań  dystrybucji], ale samo środowisko jest jakieś pozbawione charakteru, taka dziecinna podróbka Windows, ani nie tak fajny i konfigurowalny jak KDE, ani nie wprowadzający nieco świeżości do workflow jak Gnome [byle z dash to dock, bo bez tego trochę mnie męczy].

Druga rzecz, która mnie kusi, to zrobić porządną instalację ręczną Debiana pod btrfs, ale jak AI mi powiedziała, jakie operacje muszę wykonać, to mnie zraziło, zwłaszcza że wiem, że lubi się pomylić, napieprzyć w fstabie i potem muszę reanimować z live, a jestem w tym kiepski. Problem w tym, że oprócz btrfs chcę swap wraz z root pod LV, żeby nie wklepywać 2 razy hasła i do tego wszystko szyfrowane Luksem. I z doświadczenia wiem, że robią się schody, a korzystałem z usług Gemini, ChatGPT i Deepseek. Natomiast jak już btrfs działa, to faktycznie ekspresowe przywracanie i możliwość sprawdzania integralności plików w działającym systemie są bardzo fajne.

Edycja - bonus, instrukcja instalacji z użyciem btrfs i szyfrowania - bułka z masłem, o ile zadziała :D

1. Przygotowanie nośnika i start instalatora
============================================
1. Pobierz obraz netinstall Debiana 13 testing:
   https://cdimage.debian.org/cdimage/weekly-builds/am … 4-netinst.iso
2. Nagraj obraz na pendrive (np. przy użyciu dd lub Etcher).
3. W BIOS/UEFI włącz tryb UEFI (wyłącz Legacy/CSM).
4. Zbootuj z pendrive’a w trybie UEFI.

2. Partycjonowanie dysku
=========================
Zakładamy cały dysk /dev/sda (dostosuj według potrzeby).

1. Wybierz “Guided – manual partitioning” w partman.
2. Utwórz tablicę partycji GPT na /dev/sda.
3. Stwórz dwie partycje:
   - /dev/sda1 – 512 MiB – EFI System (FAT32), flagi: boot, esp
   - /dev/sda2 – pozostała przestrzeń – Linux LVM
4. Zapisz zmiany.

3. Szyfrowanie LUKS i konfiguracja LVM
======================================
1. Wybierz /dev/sda2, “Configure encrypted volumes” → “Create encrypted volumes”.
   - Algorytm: aes-xts-plain64, długość klucza: 512 bit.
   - Nadaj silne hasło LUKS.
2. Po utworzeniu pojawi się /dev/mapper/cryptroot.
3. Wybierz cryptroot → “Configure the Logical Volume Manager”:
   - Utwórz Physical volume.
   - Utwórz Volume group (np. vg0).
4. W vg0 utwórz:
   - Logical volume `swap` – 20 GB
   - Logical volume `root` – pozostała przestrzeń

4. Formatowanie i układ Btrfs z subwolumenami
============================================
1. Sformatuj EFI:
   mkfs.vfat -F32 /dev/sda1
2. Sformatuj root w Btrfs:
   mkfs.btrfs /dev/vg0/root
3. Utwórz tymczasowo subwolumeny:
   mount /dev/vg0/root /mnt
   for sv in @ @home @var_log @snapshots; do
     btrfs subvolume create /mnt/$sv
   done
   umount /mnt
4. Montowanie subwolumenów:
   mount -o noatime,compress=zstd,subvol=@       /dev/vg0/root /mnt
   mkdir -p /mnt/{home,var/log,.snapshots,boot/efi}
   mount -o noatime,compress=zstd,subvol=@home   /dev/vg0/root /mnt/home
   mount -o noatime,compress=zstd,subvol=@var_log/dev/vg0/root /mnt/var/log
   mount -o noatime,compress=zstd,subvol=@snapshots/dev/vg0/root /mnt/.snapshots
   mount /dev/sda1                              /mnt/boot/efi

5. Swap
=======
mkswap /dev/vg0/swap
swapon /dev/vg0/swap
(SWAP jest wewnątrz LUKS, brak podwójnego hasła.)

6. Instalacja systemu podstawowego
==================================
1. W partman przyporządkuj punkty montowania jak wyżej.
2. Kontynuuj instalację, wybierz mirror, pakiety.
3. Nie instaluj bootloadera na końcu – zrobimy to ręcznie.

7. Konfiguracja fstab i crypttab
================================
- /etc/crypttab:
  cryptroot UUID=<UUID /dev/sda2> none luks,discard

- /etc/fstab:
  UUID=<UUID sda1>    /boot/efi   vfat    defaults        0 2
  /dev/vg0/root       /           btrfs   defaults,noatime,compress=zstd,subvol=@        0 1
  /dev/vg0/root       /home       btrfs   defaults,noatime,compress=zstd,subvol=@home    0 2
  /dev/vg0/root       /var/log    btrfs   defaults,noatime,compress=zstd,subvol=@var_log 0 2
  /dev/vg0/root       /.snapshots btrfs   defaults,noatime,compress=zstd,subvol=@snapshots 0 2
  /dev/vg0/swap       none        swap    sw              0 0

8. Instalacja i konfiguracja GRUB+UEFI
======================================
apt update
apt install --no-install-recommends grub-efi-amd64 btrfs-progs lvm2 cryptsetup

W /etc/default/grub:
  GRUB_ENABLE_CRYPTODISK=y
  GRUB_CMDLINE_LINUX="cryptdevice=UUID=<UUID /dev/sda2>:cryptroot root=/dev/vg0/root"

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=debian --recheck
update-grub

9. Migawki Btrfs
================
Skrypt /usr/local/bin/btrfs-snapshot:
#!/bin/bash
SNAPDIR=/.snapshots/$(date +%Y-%m-%d_%H%M)
btrfs subvolume snapshot /      $SNAPDIR/root
btrfs subvolume snapshot /home  $SNAPDIR/home

Dodaj do crontaba:
0 2 * * * root /usr/local/bin/btrfs-snapshot

Ostatnio edytowany przez miwie (Dzisiaj 12:22:32)