Názory k článku
Steam je dostupný jako snap
-
Opravdu? Včetně instalace/aktualizace flatpaků přes GUI (fork GNOME Software ve Snapu, který je v Ubuntu výchozí)? Včetně aktuálního Flatpaku a XDG portálů (namísto několik let starých, neaktualizovaných verzí plných CVE)? A ne, neargumentujte prosím používáním Flatpaku z PPA a jeho správou přes terminál (případně s custom GNOME Software), to vážně není řešení použitelné pro běžnější uživatele a faktem prostě je, že podpora Flatpaku v Ubuntu není v dobrém stavu a Canonical tento stav podporuje (viz jejich nedávný blogpost o Flatpaku a proč jej v Ubuntu nechtějí).
30. 4. 2022, 17:52 editováno autorem komentáře
-
Včetně aktuálního Flatpaku a XDG portálů (namísto několik let starých, neaktualizovaných verzí plných CVE)?
No ale takto to tam má přece většina balíčků. To není znak toho, že by Flatpaku dělali nějaké naschvály a chovali se k němu hůře než k jiným balíčkům. Jen to pro ně není priorita, aby se k němu chovali lépe než k ostatním balíčkům.
-
Co máte všici za problém? Ubuntu prostě jede Snapy, ne Flatpaky, Mark Shuttleworth to X-krát vysvětloval proč a tak nevidím problém, pokud bude Steam dostupný (i) ve Snapu, stejně jako mě netrápí, že je dostupný ve Flatpaku. Ať si to klidně (jako u Firefoxu) takhle balíčkujou přímo ti důvěryhodní vydavatelé (jako Mozilla) a odpadne tak starost, kdy to zabalíčkuje tvůrce distribuce. Až se dořeší různé ty dobíhající porodní problémy, tak člověk ani nepozná, přes co to běží. A argument rychlosti spouštění či většího zabraného místa na disku neberu, dnes se cokoli spouští velmi rychle (samozřejmě vyjma her atd.) a místo na SSD je konečně velmi levné (o HDD ani nemluvě, ale kdo by měl aplikace na HDD žejo). Je fajn, že má uživatel možnost se rozhodnout, zdali bude mít aplikaci XY ve Snapu, Flatpaku, nebo DEB/RPM a výchozí nastavení distribuce lze vždy měnit. Není problém ostatně založit ani AntiSnapbuntu, které se od Ubuntu bude lišit jen odstraněným Snapem.
-
Všici máme problém akorát s tím, jak to autor formuloval. Že zabalením steamu do snapu se stalo něco revolučního "to improve the Linux gaming on Ubuntu". Přitom je už několik let Ubuntu de-facto standardní distro pro steam gaming, žádná revoluce se nekoná.
Instalace Steamu je už dnes na Ubuntu maximálně jednoduchá: na stránkách Steamu zmáčknu Install Steam, dostanu .deb, ten nechám nainstalovat, a mám hotovo, včetně přidání PPA aby se to aktualizovalo samo. Na většině ostatních distribucí je Steam dokonce přímo v repozitářích.
-
FíkZlatý podporovatelAle to tak formuloval sám Canonical, ne já. Viz první odkaz:
As part of these efforts, our first step is to simplify the process of getting your gaming environment setup without the need to add PPAs to get bleeding edge packages or kernels.
30. 4. 2022, 11:41 editováno autorem komentáře
-
Red Hat většinou vyvíjí standardní upstream (Free Software) technologie, oproti tomu Canonical často vyvíjí downstream pro Ubuntu, uzavřený či jinak omezený a mnohdy jsou jeho technologie zcela nekompatibilní (či nestandardní) se zbytkem linuxového světa. Krásným příkladem je právě Snap, případně Mir. Těch příkladů by se nicméně dalo nalézt podstatně více.
Zda podobné chování připomíná či nepřipomíná Microsoft z konce 90. let nechám na Vašem posouzení, já svůj osobní názor již napsal.
-
k3dARStříbrný podporovatel@AsciiWolf
Canonical často vyvíjí downstream pro Ubuntu, uzavřený či jinak omezený a mnohdy jsou jeho technologie zcela nekompatibilní (či nestandardní) se zbytkem linuxového světa. Krásným příkladem je právě Snaphttps://wiki.archlinux.org/title/Snap
https://snapcraft.io/docs/installing-snap-on-debian
https://snapcraft.io/docs/installing-snap-on-opensuse
https://snapcraft.io/docs/installing-snap-on-fedora -
Problém technologií od Canonicalu je v tom, že většinou vznikají jako něco, co řeší problém jen pro Ubuntu. Podle toho se volí architektura a taky pravidla projektu. A dost to pak ty jejich technologie diskvalifikuje, když se mají prosadit jako něco, co budou používat všichni.
Každá firma zapojená do vývoje samozřejmě chce, aby se její nápady prosadily. To chceme i my v Red Hatu. Rozdíl je ale v tom, že u nás ty projekty od začátku vznikají jako něco, co má být pokud možno neutrální a nezávislé na Red Hatu, protože široká komunita Linuxu nepřijme nic, co je kontrolováno de facto jedním subjektem. Rozdíl je taky v tom, že v Red Hatu ty technologie většinou vznikají zespodu. Přijdou s nimi samotní vývojáři a sami musí přesvědčit vedení, aby ten projekt přijalo a časem zařadilo do RHELu. A přesvědčí je kromě toho, že to má technické kvality, taky tím, že je to jako open-source projekt životaschopné. A nejlepším důkazem toho je, že to používají i ostatní a má to přispěvatele mimo Red Hat. Proto "success story" systemd nebylo to, že to bude unikátní technologie RHELu, která ho odliší od ostatních, ale že ho nasadí Arch nebo Debian. Podobně to bylo s Flatpakem, kde nebylo cílem vytvořit něco, co budou mít jen uživatelé RHELu nebo Fedory, ale široce rozšířený formát, z kterého budou těžit všichni, protože jen tak to má šanci na nějakou dlouhodobou adopci. Paradoxně přesvědčit Red Hat o výhodách Flatpaku bylo složitější než jiné distribuce. Podobně to bylo tenkrát se systemd.
Naopak v Canonicalu ty projekty vznikají spíš top-down. Jde to od vedení a po vývojářích se chce, aby to implementovali, ač o tom občas nejsou sami přesvědčení. Pro budoucnost těch technologií je bohužel od začátku za nimi nějaký byznys záměr. Proto mají všechny contributor agreement, aby měl Canonical kontrolu nad kódem, proto je snap navržený de facto centralizovaně. Často taky vznikají jako řešení pro Ubuntu a až časem se myslí na to, aby kvůli adopci technologie fungovaly i jinde. Snap začal vznikat jako něco, co bude unikátní pro Ubuntu, bude to jejich konkurenční výhoda oproti ostatním, Až když viděli, že je tu Flatpak, který se snaží být neutrální, a že bez podpory v jiných distribucích to vývojáři aplikací nepřijmou, začalo se to portovat na jiné distribuce, ale ta architektura s tím na rozdíl od Flatpaku nepočítala, tak to prostě bolí a doteď pořádně nefunguje.
V tom je ten rozdíl. V momentě, kdy si Canonical uvědomí, že by bylo dobré, kdyby ta technologie měla široké přijetí a podporu v ostatních distribucích, už je několik let vyvíjený a nemá pro to dobře nastavený projekt a architekturu. Proto se nikdo jiný nechytne, Canonical to táhne sám, časem zjistí, že to není vůbec jednoduché a že náklady převyšují benefity, tak to vzdá a přejde na řešení, na kterém se mezitím shodl zbytek, což je vzhledem k výše zmíněným důvodům často řešení od Red Hatu. A tak se to opakuje znovu a znovu.
Mně je to celkem líto, protože v Canonicalu pracuje řada talentovaných lidí. Některé jejich projekty byly povedené (bzr, upstart).
-
Problém je, že i na nvme je zpomalení citelné a to i u triviálních apek jako gnome-calculator, který je na ubuntu ze záhadného důvodu ve snapu. Když na cestách používám starý laptop za 15 000 s windows, doma pak nový několikanásobně dražší desktop s ubuntu a pocitově to je downgrade, tak to je IMNSHO špatně.
-
A argument rychlosti spouštění či většího zabraného místa na disku neberu, dnes se cokoli spouští velmi rychle
Jenže ono to i na tom SSD disku trvá. Sám jsem to nezkoušel, ale co jsem četl zkušenosti lidí, tak i na high-endových noteboocích Firefox ve snapu startuje klidně 20-25s, což je prostě hrozně moc a nedivím se, že to lidi štve, protože jsou to zpoždění, na které uživatelé naráží dnes a denně.
-
To zpomalené startování by kupodivu tolik nevadilo u Steamu, který nastartujete jednou a pak už jen spouštíte hry, ale zrovna ten Firefox mne štve, protože ten používám stylem: "zapnout - vyhledat - přečíst a použít - vypnout", to celé i několikrát za hodinu (nebo třeba půlden ne). Pak je ta půlminuta čekání, až se to uráčí naběhnout, opravdu hodně protivná.
Ano, můžu to nechat běžet pořád někde na pozadí, ale od doby, co si stránky samy tahají další a další videa, reklamy, a podobně, radši to shazuji - ušetřím systémové prostředky a když potřebuju projít tcpdump, tak tam není tolik hnoje. -
Aha, tak to je jiná. Já tedy obecně Firefox spouštím tak jednou za několik dnů, a to pouze v občasných situacích, kdy se GNOME neprobere dobře ze spánku a musím použít RESET (btw děje se mi to na Mageie, openSUSE i Ubuntu, na Haswellu i Comet Lake a to pojítko je fakt GNOME, bez ohledu na jeho verzi). Jinak je FF u mě spuštěn vlastně trvale a suspend/resume přežívá stejně dobře jako cokoli jiného.
To 20-25s spouštění FF ze snapu, na něco takového vlastně narážím v jiné podobě: FF se sice spustí ihned (za zlomek sekundy, ze SATA SSD a v RPM podobě), ale pak člověk kolikrát čeká, než se načte GMail, mrkvosoftí Outlook/Off365 (to tedy v Chromiu) atd atd atd. Obecně já tyhle desítky sekund otravných prodlev nabírám X-krát za den při načítání služeb.
Samozřejmě je trapné, pokud se FF ze snapu spouští takhle dlouho, tak je to trapné, že (1) tomu tak je (2) Canonical s tím dosud nic neudělal.
-
Na flashce jsem zkoušel snap a stáhl si i flatpak verzi firefoxu. Snap se zpouštěl tak čtyřikrát delší dobu, asi 15-20 sekund. To fakt není použitelné. Ne každý má pcie ssd, a anii tam to asi není nic moc. Dalo by se to nějak přežít, ale to by tam musely být nějaké zásadní výhody oproti ostatním formátům, což vesměs moc nejsou. Mohla by se zrušit ta komprimace, ale pak by byly zase obří, kvůli absenci aspoň nějakých závislostí větší než flatpaky. Je docela škoda, že to stále ještě nejpoužívanější distribuce takhle protlačuje. Na desktop se to absolutně nehodí.
-
Klasicky vykrik typu "me to funguje, tak vam musi taky".
Dyt to je kazdou diskuzi o snapu, spousta lidi si stezuje ze to je pomale.
A uprimne, ja od softwarove novinky ocekavam, ze bude rychlejsi nez predchozi varianta. Nevim, proc by novejsi software mel byt pomalejsi, pokud neprinasi nejakou extra super novou vec.(a ted trochu bokem, ale jako priklad dobre - taky mate pocit, ze ty officy 15 let zpatky fungovaly stejne rychle jako ted na mnohem vykonnejsich pocitacich? A to pritom 90% uzivatelu pouziva tytez funkce.... Budiz, nad mrkvosoftem jsem uz davno zlomil hul, ale opravdu mi vadi, ze i dnes mi libreoffice writer porad startuje cca 10 s a to na i7 s SSD. Pred 15 lety jsem si predstavoval ze za 15 let to bude okamzity start, a ono furt nic...)
-
k3dARStříbrný podporovatel
ad rychlost pousteni... zkusil sem na:
NB CPU i7-3520M a SATA SSD - LO Writer se pustil za ~4.5s
PC CPU i3-7100T a NVMe - LO Writer se pustil za ~1.5s
(oboje: Xubuntu 20.04 , LibreOffice 7.3.2 z PPA)
-
Za mě: LO Writer 7.3.3 na openSUSE/Ext4 ze SATA SSD na stroji s 6core/12HT a 8GB RAM za ~1,5s.
Jinak obecně k předřečníkovi, já ten pocit nemám. LibreOffice používám už od éry StarOffice, někdy koncem 90. let a tehdy to byl suverénně nejhorší kancl balík co do rychlosti běhu. I Software602 Office byl daleko rychlejší (fakt DALEKO), o MS Off 95 a později 97 ani nemluvě, to proti tomu byla raketa. Co bylo hodně pomalé, byl MS Office 4.x na Win3.1 na stroji typu 486 s 4MB RAM a PIO2 HDD. To bylo peklo.
Nemám pocit, že by to dnes bylo horší než kdykoli v posledních 20 letech, spíš naopak. Ale pravdou je, že je tomu tak díky SSD. Kdysi v dobách HDD jsem nechával (ve Windows) povolené takové to přednačítání OO.org/LO při startu OS, protože z HDD to jinak bylo pocitově dlouhé.
Ono představovat si okamžitý start je iluze. Nikdy to tak nebude. Ten soft používá daleko víc věcí než kdysi, běží nad diametrálně odlišným OS, kterému se musí přizpůsobovat (u LO jde dokonce o to, že musí být platformně univerzální).
Buďme rádi, že máme LO, protože bez těch 25 let vývoje, které k němu vedly, bychom tu stále měli Microsoft Office s cenovkou na úrovni 4 průměrných výplat. I díky tlaku LO je dnes MS Off levnější a dostupnější, i díky tlaku ODF přišel - jakkoli stále záměrně zmršený - formát MS OOXML, který přeci jen funguje s každým dalším major vydáním LO lépe a lépe v LO. Já bych rád viděl řadu věcí v LO jinak (třeba fungování víceúrovňových odrážek / číslovaných seznamů či generování obsahu - nebo má už dnes LO také zápis rovnic z rozpoznání ručního zápisu, nebo stále píšeme cdot / over / atd?), ALE to nic nemění na tom, že je to výstavní projekt open-source světa, navíc s výbornou podporou české komunity, která překládá příručky atd.
ČLÁNKY DO MAILU