Zrovna Firefox je v Silverblue součástí základniho ostree image. Pro instalaci běžných RPM balíčků slouží layering, stačí `rpm-ostree install <package>`, ale vzhledem k tomu, že to vytváří lokální commity nad ostree image (což občas může vést ke konfliktům), je dobré používat tohle jako poslední možnost.
Jak už píše někdo přede mnou, jde to díky RPM overlay. Na rozdíl od třeba Endless OS, které je kompletně image-based, má Silverblue hybridní povahu díky nástroji rpm-ostree, který dokáže pracovat s balíčkovacím systémem a zapisovat do obrazů dodatečné balíčky. Nicméně jde to proti myšlence neměnného systému a pokud si těch balíčků nainstalujete opravdu hodně, tak se může stát, že se ten vámi upravený obraz nepodaří rebasnout na novější commit nebo větev. Proto by se to mělo používat jen na věci, u kterých to nejde jinak, např. instalaci ovladačů (Nvidia).
Já zkouším, jestli se dá na tom neměnném systému fungovat, takže RPM overlay vůbec nepoužívám, ale v praxi má většina uživatelů pár balíčků tímto způsobem nainstalovaných.
Uvedu jeden příklad, co se mi stal:
Omylem jsem si zrušil sudo u svého uživatele a roota měl bez hesla. Na Fedoře Workstation by tohle byl dost velký problém, který bych musel řešit přes Live USB, ale na Silverblue mi stačilo nabootovat předchozí image a vše bylo v pořádku.
Nevím, zda by to samé šlo s BTRFS.
Ano. Třeba OpenSUSE defaultně odděluje kořenový systém a home do separátnich subvolumes a pravidelně dělá snapshoty systémového oddílu. Z GRUB je pak možné nabootovat do několika historických verzí root oddílu a po úspěšném startu ten snapshot vybrat jako defaultní /aktuální. Pěkný návod jak to udělat na jiných distribucích má Arch wiki. https://wiki.archlinux.org/index.php/Snapper
Už mě to jednou zachránilo, když jsem experimentovala s rc verzí kernelu a povedlo se mi rozbít initramdisk :)
To je otázka, kterou dostávám často. Oba přístupy mají své výhody. Ten nejzjevnější u OSTree je svoboda ve výběru souborového systému. Něco k tomu napsal i sám autor OSTree.
Nicméně klasická Fedory nad BTRFS by řešila jen ty rollbacky. Ty můžete mít nad klasickou Fedorou už nyní díky LVM snapshots. Neřeší to ale rychlost a spolehlivost/bezpečnost aktualizací, oddělení aplikací od systému a jejich vlastní životní cyklus, oddělení vývojového a produkční prostředí, což jsou všechno věci, o které se se Silverblue snažíme.
V SUSE dělají něco podobného jako Silverblue (desktopový MicroOS) a jdou na to přes BTRFS, protože tam je víc zavedený než u nás. Má to své výhody i nevýhody, ale z pohledu cílů, které ty systémy mají, je to spíš jenom implementační detail.
Mimochodom, aka je velkost systemu? Da sa to aktualizovat cez bezny 20Mbit?
V clanku je popisane, co mi vadilo u RPM distribucii: aktualizacie su nebezpecne. Preco sa radsej neprejde na nieco, co sa prakticky neda pokazit? Tym myslim Deb-based distro. Debian Sid sa mi vaznejsie rozbil mozno 2x za 4 roky pouzivania a to islo o nekompatibilitu configov.
Velikost systému se nijak neliší od standardní Fedory. Obsah je stejný. Jak OSTree, tak Flatpak podporují delty, takže se stahují pouze rozdíly. Mám doma hodně pomalé ADSL (6 Mbps) a nemám s tím problém.
Jinak mezi RPM a DEB v tomto principiálně není rozdíl. Přechodem od jednoho k druhému si v tomto nijak nepomůžete. Oba neaktualizují transakčně, oba aktualizují soubory běžícím aplikacím, oba umožňují vytvářet nekonečné množství modifikací systému, které nikdy nebudeme schopní otestovat... Neříkám, že balíčkovací systémy jsou v tomto nějak zásadně nespolehlivé. Třeba u Fedory si myslím, že se nám podařilo upgrady velmi slušně vyladit, a drtivá většina uživatelů s nimi nemá problémy. Já Fedoru přeinstalováván jen s novým hardwarem, to znamená, že dělám cca 6 systémových upgradů po sobě, a bez problémů. Na 20 uživatelů bez problému ale narazíme na jednoho, kterému se při upgradu něco nepovede (velmi často kvůli jeho zásahům do systému), což je 95 % úspěšnost. My bychom se ale rádi dostali přes 99 %. U balíčkovacích systémů už ale narážíme na limity.