Přešel jsem na Fedoru SIlverblue. Trochu srabácky, koupil jsem si druhý disk, na který pak přesunu #bazzite, jež se mačká na starém 512 GB NVMe.

Nevyhnul jsem se několika navrstveným balíčkům, docela trpím s terminálem co sice dobře pracuje s kontejnery, ale neumí split a samotné kontejnerové workflow mi úplně nesedí, až mi při správě systému stojí v cestě. Uvidím jak s tím budu zvládat development a každodenní práci. Tam myslím, že by se mi to mohlo líbit.🧵

Jinak je Silverblue úplně normální Fedora, která se liší jen tím, že instalace či aktualizace balíčků vytvoří image celého systému. Po rebootu se pak tenhle image použije pro systém a snadno se dá vrátit zpět, pokud něco nebude fungovat.🧵

U #bazzite to dává perfektní smysl. U daily systému už méně, ale dávám tomu šanci, protože by se mi to moc líbilo na serverech.

Instalaci jsem dělal na vlastním rozložení disku, i když se to nedoporučuje. Potřeboval jsem šifrovaný LVM volume group, kde půlka jde na normální systém a druhá jako thinpool pro VMka v Incusu.

Na předchozím systému jsem měl kvůli Incusu vypnutý SELinux. Doufám, že tady se mi ho už podaří udržet.

Budoucnost atomických Fedor je slibná, protože to vypadá, že se z ostree přechází na bootc, což dá možnost buildit si systém jako Docker image. Už teď jde použít Bluefin, který na bootc staví.

Po přechodu na Fedoru 42 se stala nešťastná věc. Fedora neaktualizovala Incus, ale aktualizovala Qemu a obojí je navzájem nekompatibilní. Qemu 9.2 je podporované až od Incus 6.9 (upstream je 6.11) a Fedora má 6.8.

Vyřešil jsem to .. dost překombinovaně. Přes distrobox jsem spustil Debian pod rootem a do něj namountil /var/lib/incus. Incus tam běží a má přístup do LVM thinpoolu. I SELinux zdá se být spokojený.

A ještě jsem řešil jednu věc na SIlverblue. Firefox náhodně končil s chybou při přehrávání videa na YouTube (a asi by se dělo i jinde). Pomohlo přejít na Flatpak verzi Firefoxu, což nechápu, proč není už v základním systému, a doinstalovat `org.freedesktop.Platform.ffmpeg-full`, u čehož zas nechápu, proč to není na jedno kliknutí v Software, jako to má se svými doplňky Steam. Navíc jsem to musel vykutat z nějaké diskuse.

@bycx To mi kdysi dělal FF na Waylandu. Možná Flatpack jede xwayland. Nebo tam bude jiná verze nějaké knihovny.

@mkyral V konzoli byla chyba s načítáním libavcodes a tohle fakt pomohlo.

@bycx @mkyral Fedora obsahuje nějaký vykuchaný ffmpeg, kde nejsou patentově chráněné kodeky. Možná to umřelo na tomto. Firefox ve Flatpaku umí používat rozšíření s plnohodnotným ffmpeg z Flathubu. Ekvivalentem v RPM je doinstalování ffmpeg z RPMFusion, ale v Silverblue je prostě lepší to dělat přes Flatpak.

@sesivany @mkyral Tomu rozumím. Čemu nerozumím je, že řešení musím vyzobávat z diskusí, když máme nástroje jak to udělat správně.

@bycx @mkyral mě překvapuje, že předinstalovaný Firefox je pořád RPM, je to určitě v přechodu na Flatpak, aby v základním obraze byly jen systémové utility.

@bycx Dost na prd, když to padne na hubu a nezobrazí chybovou zprávu.

@sesivany @bycx Já pořád beru Flatpak jako nouzovku, když v repozitáři daný program chybí, nebo je hodně zastaralý.

@mkyral @sesivany @bycx Ale pořád radši Flatpak než Snap 😉

@aikencz @sesivany @bycx

Snap raději nekomentuji…

@sesivany @bycx

Na Gentoo mám jen pár programů přes Flatpak a tohle mě dost štve - tři stejné knihovny, stejná verze 25.0.3, rozdílné velikosti. Proč? Proč nemůže být jen jedna?

🤔

@mkyral Mělo by to být komunikováno lépe na obou stranách. Jak v prohlížeči, tak ve správci balíčků.

@mkyral @sesivany Flatpak řeší sandboxing a jednotný runtime pro appky. Tzn. udělám jeden balíček a ten poběží všude. Z pohledu uživatele instalace nesešrotuje celý systém a navíc ani nemusí mít přístup ke spoustě věcem v systému. Za mě to je preferovaná forma instalace.

Velké plus je, že když máš nový home, tak překopíruješ ~/.var/app a máš data všech flatpak appek. Stejně jednoduché je i zálohování. Směr je jasný, i když tu pořád bude klasika - mrsknout to přímo do systému.

@bycx @sesivany A nedá se udělat sandbox bez toho, abych měl v systému několik kopií té samé knihovny? K tomu přece knihovny jsou, aby stačilo nainstalovat ji jen jednou.

@mkyral @bycx To by se první museli tvůrci aplikací domluvit, kterou budou používat, což je bohužel scifi, proto máme realitu, kdy musí mít člověk těch knihoven několik. Flatpak umí deduplikaci dat, ty jednotlivé runtimy jsou udržované, člověk to má automaticky aktualizované... Ve skutečnosti to zase tolik nevýhod nemá.
Jednou jsem to počítal a při počtu 45 aplikací mi aplikace ve Flatpaku včetně runtimů zabíraly méně než 10 GB. To mi při velikosti dnešních disků přijde jako marginální objem.

@sesivany @bycx Velké disky nic nemění na tom, že se mi to nelíbí 😉

@bycx Správce balíčků netuší, že si budeš chtít přehrávat Youtube. Tohle má být ošetřeno v prohlížeči tak, aby nepadal. Možná už na to je v bugzille nějaké issue.

@mkyral Správce balíčků má možnost nabídnout nepovinné závislosti. Implementace v Software ve Fedoře je a některé appky to používají.

@pavel @bycx @mkyral Tady platí to samé co u těch disků. Zvlášť dnes, kdy každý dělá AI-ready notebooky, které papají tolik paměti, že nějaký Flatpak je vedle toho drobek. Jaký to má dopad na spotřebu paměti, jsem nikdy neměřil, ale EndlessOS je od začátku Flatpak-only a ještě donedávna podporovali počítače s 2 GB paměti a dosud myslím podporují se 4 GB a nikdy to pro ně nebyl zásadní problém.

@sesivany @pavel @mkyral Firefox sám si vezme klidně 30 GB RAM. DLV pro debug golang kódu uzme 10 GB. Pár duplicitních knihoven z Flatpaku je pod úrovní měřitelnosti.

@sesivany @pavel @bycx @mkyral myslim, ze vyvojari techhle technologii by meli pouzivat starsi stroje s malou pameti a pomalym cpu. Pouzvani nejnovejsiho hardware je vubec nenuti optimalizovat 😉

@pavel @mkyral @sesivany Možná proto, že každý používáme naše stroje jinak. Čtyři roky zpátky jsem přešel na notebook s 16 GB RAM. Taky to nějak fungovalo, ale žádná virtualizace a pokud se něco nepovedlo v mém kódu, tak mě DLV sežralo.

Dneska mám 64 GB RAM, oba moduly stály dohromady asi 7k a nic neřeším.

@bycx @pavel @sesivany Tak místa na disku i paměti mám zatím dost. I když raději na disk ulokládám svá data 😎

Jsem holt stará vojna. O systém a programy se stará jeden manager. V mém případě Portage.

Pokračuju se Silverblue, tentokrát připravuju dev environment. Devcontainers z vscode jsem vzdal, protože bych je musel připravit pro desítky aktivních projektů/repositářů, které tu mám. Takže jsem si udělal image s dev tooly včetně vscode a ten budu provozovat pomocí distrobox. Z distroboxu se dají exportovat aplikace ven, takže se to docela hezky integruje. Mám to zatím vyzkoušené na manuálně vytvořeném kontejneru a funguje to vcelku dobře.

Začíná se to finalizovat. Incus v distroboxu nefungoval ideálně. Nějaký dobrák naštěstí Incus nezištně buildí v COPRu, takže jsem mohl nainstalovat verzi 6.11, kompatibilní s qemu 9.2 z Fedory 42, odtamtud.

VSCode v kontejneru funguje perfektně. Tohle vidím jako krok vpřed.

Extra "vrstvené" balíčky nějak nezpomalují build systémového obrazu, ale vlastní initramfs už docela ano. Potřebuju ho na podporu bluetooth během startu systému, kdy se odemyká disk, ale na Silverblue mi to nefunguje.

Ještě poznámka k navrstveným balíčkům. Myslím, že budu schopen se zbavit všeho kromě incusu, qemu, swtpm a distroboxu, protože distrobox umí docela snadno spouštět příkazy z hosta, tzn. do mého dev kontejneru dostanu i věci, které v něm jinak běžet nemůžou, jako třeba podman.

Kdybyste se někdy pustili do #Silverblue, tak tady je můj devcontainer, ve kterém jsou nástroje co používám + VSCode a integrovaný Podman a Incus z hosta. Myslím, že tenhle setup využije málo kdo, ale je to dobré pro inspiraci.

https://gitea.ceperka.net/cx/devcontainer

V nové instalaci #silverblue se za každou cenu snažím zachovat SELinux. Nejsem úplně fanoušek, mám radši AppArmor, ale je blbost SELinux vypínat kvůli detailům s přístupem k jednomu či dvěma souborům. Tak první překážkou bylo OpenVPN. NetworkManager mě nutí zkopírovat certifikáty do /etc/openvpn, z čehož nejsem úplně nadšený. Byl bych radši, kdyby si je uložil někam k sobě a neotravoval mě s konkrétní cestou, ze které je schopen je načíst.

Když jsem přecházel na #silverblue, tak jsem měl docela obavy, že mě to bude omezovat natolik, že nebudu moct ani pracovat. Že třeba v kontejnerech nerozjedu nějakou potřebnou věc. Nakonec mi nefunguje jen bluetooth klávesnice během bootu při odemykání disku.

Trochu zklamaný jsem z toolbxu, což je vrstva pro Podman pro vývoj.

https://docs.fedoraproject.org/en-US/fedora-silverblue/toolbox/

Vývojáři aktivně blokují integraci s prostředím hosta a oddělený home. Naštěstí je tu alternativa distrobox.

https://github.com/89luca89/distrobox

@bycx To aktivní blokování s prostředím hosta by mě zajímalo, máš k tomu nějaké tickety? Toolbx má totiž na starosti můj tým a integrace s hostem je naopak náš cíl. 🙂
Jinak ano, Distrobox má víc funkcí, ale to je prostě dané i zaměřením. My se snažíme mít Toolbx enteprise grade, protože se používá i v RHELu. To znamená, že to musíme podporovat 10 let, zákazníci na tom závisí atd. Každou novou věc musíme dvakrát zvážit, než ji implementujeme. Distrobox je živelný komunitní vývoj, takové věci je moc netrápí. Na druhou stranu je to fork starého Toolbxu, který byl napsaný ještě v shellu a který parsoval textové výstupy Podmanu místo, aby používal jeho API. Je to trochu na hliněných nohou.

@pavel @mkyral @sesivany Tak tomu nic nebrání je dál používat🙂

@sesivany Export GUI appek je tady :

https://github.com/containers/toolbox/issues/417

Ale podle mě chybí i export normálních binárek.

Oddělený home je zase tady:

https://github.com/containers/toolbox/issues/1470

Ten třeba já úplně nepotřebuju, ale je to jedna z věcí, kvůli kterým uživatelé instalují distrobox. I Universal Blue projekty ho upřednostňují.

Můžeš argumentovat, že si můžu vytvořit desktop file a změnit proměnnou HOME, ale to můžu rovnou použít podman místo toolbxu 🙂

@bycx jo, desktop files bylo velké téma. Nakonec převážil osvětový názor, že kdybychom tohle udělali, tak budou vývojáři lidem říkat, ať si nainstalují aplikaci do Toolbxu místo, aby vytvořili Flatpak. Dnes už by proti tomu asi taková opozice nebyla, ale priority jsou jinde: nedávno jsme rozcházeli podporu Nvidia ovladače a teď děláme na integraci se subscription managerem.

@bycx co se týče odděleného home, tak to je z kategorie "udělat to pořádně není tak jednoduché a na pořádné řešení jsme zatím neměli čas". Distrobox má hodně těch řešení dost zbastlených. Nakonec i tu podporu pro Nvidia ovladač. Co implementujeme my, s tím musíme žít minimálně 10 let, takže u nás to znamená, že buď pořádně nebo vůbec, což holt občas dopadne jako "vůbec".