Vlákno názorů k článku
Co nového přinese Fedora Workstation 34
od okalousek - Ještě by stálo za zmínku že ve výchozím...
-
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í.
ČLÁNKY DO MAILU