Nevím co konkrétně bych měl u fedory "vydržet". Prostě funguje. Ubuntu nezatracuju, ale přišlo mi, že už nemá vizi a směr, spousta drobností se dlouho neřešila a oznámení Canonicalu, že se nadále chtějí orientovat na framework Flutter (neboli, opět orientace na mobil a "konvergenci") byla poslední kapka.
Já jsem třeba na Fedoře nerozdýchal očesané openssl, nevydržel jsem a přešel na arch.
Na F34 se těším, ale měl jsem za to, že s PipeWire se jasně počítalo, je to nějaká změna na poslední chvíli, že to možná odsunou až do F35?
Není. Původní článek je několik týdnů starý. To ještě nebylo úplně jisté, jestli PipeWire v F34 zůstane nebo se na základě testování vrátíme k PulseAudio. Te už je jisté, že tam PipeWire zůstane. Finální verze má vyjít za necelých 14 dní a už se jede jen závěrečné testování.
Na stolním počítači zvukový výstup přepínám mezi bluetooth sluchátky a bednami, mikrofon mám ve webkameře a funguje to pro mě bez problémů. Stejně tak na noteboocích jsem nezaznamenal problém. Ohromně se to posunulo za poslední tři měsíce, kdy vývojáři udělali na stabilizaci velký kus práce. Poslední měsíc je dokonce najatý kontraktor, aby ty problémy vychytával, protože vrátit se u Fedory 34 k PulseAudio by byl krok zpět.
Výhody oproti PA? Dá se to používat jako náhrada jak za PA, tak za JACK. Lidi, kteří pracují s pro-audio aplikacemi, které vyžadují JACK, nemusí složitě přepínat mezi dvěma zvukovými servery. Pro běžné uživatele je pak výhodou to, že PipeWire na rozdíl od PA podporuje pokročilé kodeky pro Bluetooth (LDAC, AAC, AptX...), takže zvuk v Bluetooth sluchátkách a reproduktorech zní lépe, u některých fakt citelně lépe. V budoucnu se bude hodit i to, že video a audio jdou přes stejného démona (lepší sychronizace audia a videa atd.).
Za ty dva měsíce se to dost zlepšilo, i když mě to tedy nepadalo ani tenkrát. Ono se to může taky lišit distribuci od distribuce. Ve Fedoře to bude default, takže ladíme, co to jde. Wayland jsem taky roky bez problémů používal a přitom četl zkušenosti uživatelů z jiných distribucí, kteří s ním měli mnohem horší zkušenost, protože jejich distribuce jela primárně na X11 a Wayland moc neřešili.
Důvod? Já jsem z něj sice před skoro dvouma rokama odešel, ale důvod byl čistě ideologistický - nelíbilo se mi jejich vyjádření podpory LGBT komunitě, protoze nějaký uřvaný LGBT nemá nic společnýho s otevřenym operačnim systémem.
Nicméně jsem Debian testing na desktopu používal spokojeně asi 10 let.
11. 4. 2021, 13:19 editováno autorem komentáře
Radši jsem odešel spát, protože tady v Austrálii už bylo docela pozdě a dneska brzo ráno mě čekalo pár věcí. Nevím, co je tohle "radši" zase za blbost: nemusím se nikomu zpovídat z toho, jaké používám distro, a Debianistům ani nikomu jinému opravdu nedlužím žádné vysvětlení.
Mimochodem Debian jsem používal před Ubuntu. Důvodů, proč už ho na desktop (resp. laptop) nechci je několik. Extrémně dlouhé cykly znamenají, že buď mám potenciálně leta zastaralý GNOME, zastaralé jádro, zastaralý wine, PipeWire v nedohlednu atd., nebo musím nasadit testing, což je v podstatě téměř rolling. Když jsem tehdy testing používal, stávalo se občas, že se věci rozbily, nebo že nastal dependency hell. Na některá využití se velmi dlouhé cykly hodí, na desktop alespoň pro mé potřeby ne.
Nevím, jak je na tom Debian dneska s podporou desktopových funkcí, jestli v něm normálně funguje flatpak nebo suspend/resume (tím myslím funguje normálně a rovnou, ne vi /etc/tohlenebotamto a po třech hodinách pokusů dospět do stadia, kdy to často funguje ale někdy ne). Full disk encryption zřejmě stále ještě není ve stadiu "prostě funguje" jedním klikem při instalaci.
Kromě toho to, že Debian nemá žádné "oficiální" GUI (ať už GNOME, KDE nebo jiné) znamená, že žádné z nich není doopravdy integrované. Například nastavení tiskáren nebo VPN je v Ubuntu nebo ve Fedoře otázka pár kliků a prostě funguje, stejně tak bluetooth apod. Kontejnery jsou pro má workflow nezbytné, v Ubuntu jsem používal LXD, v Silverblue tento nefunguje, ale s toolboxem si vystačím. V Debianu opět, pokud vím, nic takového dosud není oficiálně podporované.
Navíc Silverblue má transakční aktualizace, což je zrovna na pracovní stanici nádherná vlastnost. V Debianu jsem se doopravdy neobešel bez rekompilace jádra. Zkrátka chci OS, se kterým se můžu soustředit na lukrativní činnost, absolutně nemám zájem ho muset adminovat.
"Ideologistický"? To je nějaký hybrid slov ideologie a logistika? Jakou roli v tom hraje ta logistika? To by mě docela zajímalo. :-)
Jinak já si tedy žádného "uřvaného LGBT" nevšiml, ale možná je to tím, že nějak nejsem vysazen na to podobné informace nějak cíleně vyhledávat a pak se nad nimi pohoršovat. Ale pokud to někoho baví... :-)
Aha, tak to ho asi používám jen na toasteru a ledničce... :-)
Ale vážně. Proč ne? Já Debian používám i na desktopu docela dlouho, sice jsem si od něj někdy před 10 či více lety nějakou dobu odskočil k Gentoo, ale pak jsem se zase pokorně vrátil. Před více lety jsem ho nainstaloval i třeba rodičům a nemohu si to vynachválit, hodně mi ubylo starostí.
Měl jsem Fedoru WS pár dní, pak jsem ze zvědavosti zkusil Silverblue a už u ní zůstal. Ostré hrany jsem zatím zaznamenal tři:
1. Ve výchozím stavu nefungují thumbnails u video souborů. To se dá spravit, stačí doinstalovat totem pomocí rpm-ostree (namísto flatpaku). Není to sice zrovna v intencích Silverblue, ale dokud si nautilus nebude rozumět s totemem ve flatpaku, tak jsou jediné dvě možnosti buď tohle, nebo thumbnaily oželet.
2. Nejde instalovat wine. Dá se používat jenom v toolboxu, což by samo o sobě nevadilo, ale problém je, že v tom případě je nutné ručně editovat všechny .desktop soubory pro windowsové aplikace a přidat do nich tooolbox run ...... Není to user friendly, specielně ne pro BFU
3. Patrně nefunguje DKMS (logicky předpokládám, nezkoušel jsem). To nebude problém pro toho, kdo má oficielně podporované hardware a na případnou virtualizaci používá jedině virt-manager nebo boxes, ne virtualbox ani vmware.
Ad 2) už jsme zvažovali, že bychom .desktop soubory exportovali z Toolboxu. Pak by to uživatel mohl pouštět jako jakoukoliv jinou aplikaci. Zatím jsme se k tomu neodhodlali, protože to výrazně zjednodušuje něco, co je nesystémové a jde proti duchu Silverblue. Je ale možné, že to časem přehodnotíme.
Ad 3) dodatečné ovladače jsou u immutable systému obecně problém. Většinou se takové systémy nasazují na předem definovaný hardware a ten obraz je pro něj odladěný. Tím, že je Silverblue obecný systém, který si může člověk nainstalovat na cokoliv, ten problém řešit musí. Třeba Nvidia ovladače se přes RPM overlay doinstalovávat dají, časem asi bude nějaké obecnější řešení. Ale platí, že čím více chce člověk dělat zásahy do samotného systému, tím méně je vhodné Silverblue a tím více je vhodná klasická Fedora.
Momentálně ani ne. Typickým uživatelem Silverblue je power user, který je zvyklý na kontejnerové workflow. Už na klasické linuxové distribuci dělal např. celý vývoj v kontejnerech místo v samotném systému. Silverblue je tak pro něj celkem přirozený krok.
Samozřejmě do budoucna to má velký potenciál právě směrem k běžným uživatelům, protože to je výrazně nerozbitnější než klasický balíčkovací systém. Ale ještě je potřeba tomu obrousit hrany.
Jinak velká poptávka po něčem takovém je i mezi zákazníky, kteří provozují stovky až tisíce stanic. Těm by to výrazně usnadnilo jejich správu.
Díky za podnětné odpovědi. Ad 2), proti duchu Silverblue to sice je, nicméně v praxi na to uživatel narazí snadno, např. hry od GOG nebo pár utilit pro Windows, které potřebuje používat. Nepodporovat wine vůbec mu připadá jako příliš velké uživatelské omezení. Dokud nebude pro takové případy doopravdy funkční řešení formou flatpaku je toolbox jedinou cestou. Ono by vlastně stačilo mít RPM, který by šel přidat jako layer a obsahoval by /usr/bin/wine, což by byl one-liner, který by jenom zavolal skutečný wine v toolboxu...
Ad 3) Nejde jenom o vrtání se v systému, ale opět o situaci, se kterou se člověk může snadno setkat. Např. má pár VM ve Virtualboxu, přejde na Silverblue a zjistí, že Virtualbox se nedá instalovat. Přitom mi připadá, že by to snad mohlo jít. DKMS by přeložené moduly ukládal do nějakého zapisovatelého adresáře ve /var. Zatím jsem ostree tak dalece neštudoval, abych věděl, zdali by se pak daly nalayerovat a aktivovat v rámci dalšího commitu, v nejhorším případě, jako hack, by mělo být možné je přidat do initramfs a načíst při bootu.
Ja som v Silverblue narazil ešte na jeden problém - nešťastný hp-plugin. Môže sa stať, že aj keď si človek dáva pozor, pred kúpou si pozrie, či vyhliadnutý model nepotrebuje hp-plugin, po zapojení môže zistiť, že informácie na stránkach HP neboli pravdivé a nakoniec ho predsa potrebuje (napr. Color LaserJet Pro MFP M181fw ho naozaj potrebuje - nie na tlač, ale na skenovanie).
No a problém je, že musí byť umiestnený v /usr, nie v /usr/local, ani /opt a zároveň HP nebol ochotný ani len povoliť redistribúciu binárky, aby mohol byť nalayerovaný do ostree aspoň cez rpm.
Jo, já jsem měl stejný problém s ovladačem pro tiskárnu Fuji Xerox v práci. Pak jsem objevil, že jde stáhnout jako balík .deb. Ten jsem tedy konvertoval pomocí alienu. Nebylo to bezbolestné, nakonec jsem musel provést některé úpravy ručně, ale výsledný rpm jsem potom instaloval pomocí rpm-ostree a funguje mi to.
Aj pre hp-plugin existuje spec súbor pre rpm, nie je problém si ho zbuildovať. Problém je takýto systém dlhodobo prevádzkovať - fedora môže hocikedy updatnúť hplip na verziu, pre ktorú treba stiahnuť nový build pluginu (a bežne to aj doteraz robila). V prípade rpm systému to závislosti postrážia, jednoducho hplip sa neupgradne pokiaľ používateľ nedodá aj nový hp-plugin; v prípade ostree je to problém, pretože systém sa updatne a starý plugin prestane fungovať.
Pre power usera to nie je problém, ten si to ustráži, resp. dá dokopy keď sa to rozsype. Pre bežného používateľa to problém je, pretože po update mu prestane fungovať tlač alebo skenovanie a problém si sám nevyrieši, bude na to potrebovať asistenciu toho power usera. Tým pádom je to nepoužiteľné ako systém, ktorý chcem mať maximálne bezúdržbový.
Co se Wine týče, slyšel jsem docela chválu na Bottles (https://flathub.org/apps/details/com.usebottles.bottles), ale sám jsem jej nezkoušel. Flatpak verze Lutrisu (je dostupná ve Flathub Beta repu) bohužel ani po letech není v ideálním stavu. Ještě je na Flathubu dostupný PlayOnLinux 5 (https://flathub.org/apps/details/org.phoenicis.playonlinux), což je ovšem javová šílenost a rovněž má k dokonalosti daleko. Další možností je si přes rpm-ostree nalayerovat systémové Wine, což ale není zrovna ideální řešení.