🥇Něco navíc: balíčky aplikací Haiku?

TL;DR: může Haiku získat adekvátní podporu aplikací, například katalogů aplikací (jako .*.app na Macu) a/nebo obrazů aplikací (Linux AppImage)? Přijde mi, že by to bylo cenné doplnění, které by se snadněji integrovalo než v jiných systémech, protože většina infrastruktury již existuje.

Před týdnem jsem objevil Haiku, nečekaně dobrý systém. A protože již dlouho mě zajímají katalogy a obrazy aplikací (inspirovány jednoduchostí Macintosh), není překvapením, že mě napadla myšlenka…

Pro úplné pochopení: jsem tvůrce a autor AppImage, formátu distribuce aplikací Linux zaměřeného na jednoduchost Mac a poskytujícího plnou kontrolu autorům aplikací a koncovým uživatelům (chcete vědět více — viz wiki a dokumentaci).

Co kdybychom vytvořili AppImage pro Haiku?

Pojďme teď trochu teoretizovat: co bychom potřebovali udělat, abychom získali AppImage, nebo něco podobného, na Haiku? Není nutné vytvářet něco hned, protože systém, který již existuje v Haiku, funguje úžasně a imaginární experiment by byl zajímavý. A navíc ukazuje sofistikovanost Haiku v porovnání s pracovními prostředími Linux, kde jsou podobné věci hrozně složité (mám na to právo: už 10 let se trápím s laděním).

Na Macintosh System 1 byla každá aplikace samostatným souborem, „spravovaným“ ve Finderu. Pomocí AppImage se snažím obnovit tento uživatelský zážitek na Linuxu.

Nejprve, co je AppImage? Je to systém pro distribuci aplikací třetích stran (například Ultimaker Cura), který umožňuje uvolňovat aplikace, kdy a jak chtějí: není třeba znát specifika různých distribucí, politiku kompilace nebo kompilovanou infrastrukturu, nepotřebují podporu správců a neříkají uživatelům, co (ne)mohou instalovat na své počítače. AppImage je třeba chápat jako něco, co vypadá jako balíček pro Mac ve formátu .*.app uvnitř obrazu disku .dmg. Hlavní rozdíl spočívá v tom, že aplikace se nekopírují, ale zůstávají uvnitř AppImage navždy, podobně jako balíčky Haiku .hpkg se přimontují a nikdy se neinstalují v obvyklém smyslu.

AppImage získal během více než 10 let své existence určitou přitažlivost a popularitu: sám Linus Torvalds jej veřejně schválil, a rozšířené projekty (například LibreOffice, Krita, Inkscape, Scribus, ImageMagick) jej přijaly jako hlavní způsob distribuce kontinuálních nebo nočních sestavení, která nezasahují do nainstalovaných ani nenainstalovaných aplikací uživatelů. Nicméně pracovní prostředí a distribuce Linuxu se většinou stále drží tradiční centralizované modelu distribuce na základě doprovodných a/nebo propagují vlastní korporátní obchodní a/nebo inženýrské programy na základě Flatpak (RedHat, Fedora, GNOME) a Snappy (Canonical, Ubuntu). Situace se dostává do komických situací.

Jak to funguje

Každý AppImage obsahuje 2 části: malý spustitelný soubor ELF (tzv. runtime.c), s následným obrazem souborového systému SquashFS.

Souborový systém SquashFS obsahuje užitečné zatížení ve formě aplikace a vše potřebné k jejímu spuštění, což nelze považovat za součást výchozí instalace na každém dostatečně moderním cílovém systému (distribuce Linuxu). Obsahuje také metadata, například název aplikace, ikony, typy MIME a další.

Při spuštění uživatelský runtime využívá FUSE a squashfuse k připojení souborového systému, po čemž zpracovává spuštění určitého místa vstupu (tzv. AppRun) uvnitř připojeného AppImage.
Souborový systém se odpojí poté, co proces skončí.

Vypadá to docela jednoduše.

Ale tyto věci to komplikují:

s takovým množstvím distribucí Linuxu už nic „v dobrém rozumu“ nelze nazvat „součástí výchozí instalace pro každý moderní cílový systém“. Tento problém obcházíme sestavením excludelist, které umožňuje určit, co bude zabalené do AppImage, a co je potřeba získat někde jinde. Přesto se někdy zmýlíme, i když vše obecně skvěle funguje. Proto doporučujeme tvůrcům balíčků testovat AppImages na všech cílových systémech (distribucích).
Aplikace ve formě užitečného zatížení by měly být přenositelné v souborovém systému. Bohužel, v mnoha aplikacích jsou pevně stanoveny absolutní cesty k, například, zdrojům v /usr/share. To je potřeba nějak opravit. Kromě toho je třeba buď exportovat LD_LIBRARY_PATH, nebo opravit rpath aby mohl bootloader najít související knihovny. První metoda má své nevýhody (které se obcházejí složitými způsoby), zatímco druhá je prostě nepraktická.
Největší UX pastí pro uživatele je, že je třeba nastavit spustitelný bit pro soubor AppImage po stažení. Chcete věřit, chcete ne, ale pro někoho je to skutečná překážka. Potřeba nastavení spustitelnosti je nepraktická i pro zkušené uživatele. Jako obcházející způsob jsme navrhli nainstalovat malou službu, která sleduje soubory AppImage a nastavuje jim spustitelný bit. V čisté podobě to není nejlepší řešení, protože to nebude fungovat 'out of the box'. Distribuce Linuxu tuto službu neposkytují, takže pro uživatele je to 'out of the box' problematické.
Uživatelé Linuxu očekávají, že nové aplikace budou mít ikonu v nabídkovém systému. Počítači nemůžete říct: 'Podívej, tam je nová aplikace, pojď pracovat'. Místo toho je podle specifikace XDG potřeba zkopírovat soubor .desktop na správné místo v /usr pro systémovou instalaci, nebo do $HOME pro individuální instalaci. Ikony určité velikosti je podle specifikace XDG třeba umístit na stanovená místa v usr nebo $HOME, poté spustit příkazy v pracovním prostředí pro obnovení cache ikon, nebo doufat, že správce pracovního prostředí si poradí a automaticky vše objeví. Podobně je to s typy MIME. Jako obcházející způsob se doporučuje používat tu samou službu, která kromě nastavení spustitelnosti bude, pokud existují ikony a další prvky v AppImage, kopírovat je z AppImage na správná místa podle XDG. Při odstranění nebo přesunu služba předpokládá, že vše vyčistí. Samozřejmě, existují rozdíly v chování každého pracovního prostředí, ve formátech grafických souborů, jejich velikostech, místech ukládání a způsobech obnovy cache, což vytváří problém. Zjednodušeně řečeno, tento způsob je záplata.
Pokud výše uvedené není dostatečné, v souborovém správci stále není ikona AppImage. V komunitě Linuxu dosud nebylo rozhodnuto o zavedení elficon (navzdory diskuze a provádění), takže není možné přímo vložit ikonu do aplikace. Takže aplikace ve správci souborů nemají vlastní ikony (nezáleží na tom, jestli AppImage nebo něco jiného), existují pouze v nabídce spouštění. Jako workaround používáme miniatury — mechanismus, který byl původně navržen tak, aby správci plochy mohli zobrazovat zmenšené obrázky pro náhled grafických souborů jako jejich ikony. Proto také služba pro nastavení bity spustitelnosti funguje jako „miniaturizátor“, který vytváří a zapisuje miniatury ikon na příslušná místa. /usr a $HOME. Taktéž tato služba provádí úklid, pokud je AppImage odstraněn nebo přesunut. Protože každý správce plochy se chová trochu jinak, například v tom, jaké formáty akceptuje ikony, jaké velikosti nebo místa, je to skutečně bolestivé.
Aplikace prostě spadne při spuštění, pokud dojde k chybám (například existuje knihovna, která není součástí základního systému a není dodávána v AppImage), a nikdo v GUI neříká uživateli, co se konkrétně děje. Začali jsme to obcházet používáním oznámení na ploše, což znamená, že musíme zachytávat chyby z příkazového řádku, převádět je na srozumitelné uživatelské zprávy, které pak musíme také zobrazit na ploše. A samozřejmě, každé pracovní prostředí je zpracovává poněkud odlišně.
V současné době (září 2019 — pozn. překladatele) jsem nenalezl jednoduchý způsob, jak říct systému, že soubor 1.png by měl být otevřen pomocí Krita, a 2.png — pomocí GIMP.

Místem úložiště specifikací pro cross-desktop, používaných v GNOME, KDE a Xfce je freedesktop.org.

Dosažení úrovně rafinovanosti, hluboce propleteného do pracovního prostředí Haiku, je obtížné, ne-li nemožné, kvůli specifikacím XDG od freedesktop.org pro cross-desktop, stejně jako realizacím správců ploch na základě těchto specifikací. Jako příklad můžeme uvést jednu systémovou ikonu Firefox: očividně autoři XDG ani přemýšleli o tom, že uživatel může mít nainstalováno několik verzí stejné aplikace.

Ikony různých verzí Firefox

Zajímalo mě, co se může svět Linuxu naučit od Mac OS X, aby se vyhnul chybám při systémové integraci. Pokud máte čas a zabýváte se tímto tématem, určitě si přečtěte, co řekl Arnaud Gurdol, jeden z prvních inženýrů Mac OS X:

Chtěli jsme, aby instalace aplikace byla stejně jednoduchá jako přetáhnout ikonu aplikace odkudkoli (server, externí disk) na disk vašeho počítače. Proto je v balíčku aplikace uložena veškerá informace, včetně ikon, verze, zpracovávaného typu souboru, typu URL schématu, které systém musí znát pro zpracování aplikace. Sem patří také informace pro ‚centralizované uložiště‘ v databázi Icon Services a Launch Services. Pro podporu výkonu aplikace se ‚objevují‘ na několika ‚známých‘ místech: v systémovém a uživatelském adresáři Applications, stejně jako na dalších místech automaticky, pokud uživatel přejde v Finderu do adresáře obsahujícího aplikaci. V praxi to velmi dobře fungovalo.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000, session 144 — Mac OS X: balení aplikací a tisk dokumentů.

Nic podobného z této infrastruktury není v pracovních prostředích Linuxu, takže hledáme alternativní cesty kolem strukturálních omezení v projektu AppImage.

Opravdu se Haiku žene na pomoc?

A ještě: platformy Linux jako základ pracovních prostředí jsou obvykle tak nedostatečně specifikovány, že mnoho věcí, které jsou ve konzistentním systému s plným stackem velmi jednoduché, zklamou fragmentací a složitostí v Linuxu. Věnoval jsem celou přednášku otázkám spojeným s platformou Linux pro pracovní prostředí (znalí vývojáři potvrdili: vše zůstane ve stavu, jakém je, ještě velmi dlouho).

Moje přednáška o problémech pracovních prostředí Linuxu v roce 2018

Dokonce i Linus Torvalds uznal, že právě kvůli fragmentaci se idea pracovních prostředí nezdařila.

Je skvělé vidět Haiku!

S Haiku je všechno úžasně jednoduché

I když je naivní přístup k "přenesení" AppImage na Haiku jednoduchým pokusem o sestavení (hlavně runtime.c a služeb) jeho komponent, což je možná i možné, nepřinese to Haiku žádný zvláštní užitek. Většina těchto problémů je totiž ve skutečnosti na Haiku již vyřešena a koncepčně zdůvodněna. Haiku poskytuje přesně ty stavební bloky systémové infrastruktury, které jsem tak dlouho hledal v pracovních prostředích na Linuxu a nemohl uvěřit, že tam nejsou. A to konkrétně:

Ať už věříte nebo ne, mnoho uživatelů Linuxu to nedokáže překonat. Na Haiku se to všechno děje automaticky!

Soubory ELF, které nemají bit spuštění, jej získávají automaticky při dvojitém kliknutí ve správci souborů.
Aplikace mohou mít vestavěné zdroje, například ikony, které se zobrazují ve správci souborů. Není potřeba kopírovat spoustu obrázků do zvláštních adresářů s ikonami, takže není nutné je uklízet po odstranění nebo přesunutí aplikace.
Existuje databáze pro propojení aplikací s dokumenty, není třeba kopírovat žádné soubory pro toto.
Knihovny se ve výchozím nastavení hledají v adresáři lib/ vedle spustitelného souboru.
Není mnoho distribucí a desktopových prostředí, vše, co funguje, funguje všude.
Neexistuje samostatný modul pro spuštění, který by se lišil od adresáře Aplikace.
V aplikacích nejsou vestavěné absolutní cesty k jejich zdrojům, existují speciální funkce pro určení umístění během běhu.
Zavedena byla myšlenka komprimovaných obrazů souborových systémů: to je jakýkoliv balíček hpkg. Všechny jsou přimontovány jádrem.
Každý soubor je otevřen aplikací, která jej vytvořila, pokud není výslovně uvedeno něco jiného. Jak skvělé je to!

Dva soubory png. Všimněte si různých ikon, které ukazují, že budou otevřeny různými aplikacemi při dvojitém kliknutí. Také si povšimněte rozbalovacího menu "Otevřít s:", kde si uživatel může vybrat konkrétní aplikaci. Jak jednoduché!

Vypadá to, že mnoho workaroundů a obraných cest, které jsou potřeba pro AppImage na Linuxu, se na Haiku stávají zbytečnými díky jednoduchosti a sofistikovanosti, které zvládají většinu našich potřeb.

Jsou balíčky aplikací pro Haiku nakonec potřeba?

To je velký otázka. Pokud by bylo na Haiku snazší vytvořit systém podobný AppImage než na Linuxu, mělo by to smysl? Nebo Haiku se svým systémem balíčků hpkg vlastně eliminuje potřebu takové myšlenky? No, abychom na to odpověděli, musíme se podívat na motivaci existence AppImages.

Pohled z uživatelské perspektivy

Podívejme se na našeho koncového uživatele:

Chci nainstalovat aplikaci bez požadavku na heslo správce (root). Na Haiku neexistuje pojem správce, uživatel má plnou kontrolu, protože je to osobní systém! (V zásadě si to lze představit i v režimu s více uživateli, doufám, že vývojáři zachovají jednoduchost)
Chci dostávat poslední a nejlepší verze aplikací, nemusím čekat, až se objeví v mé distribuci (většinou to znamená „nikdy“, pokud neaktualizuji celý operační systém). Na Haiku je to „vyřešeno“ pomocí plovoucích vydání. To znamená, že existuje možnost dostávat poslední a nejlepší verze aplikací, ale pro to musíte neustále aktualizovat i zbytek systému, vlastně to přetváří na „neustále se měnící cíl“..
Rád bych měl vedle sebe několik verzí téže aplikace, protože nelze vědět, co bylo rozbito v poslední verzi, nebo, dejme tomu, jako webový vývojář, potřebuji otestovat svou práci v různých verzích prohlížeče. Na Haiku je vyřešen první problém, ale ne druhý. Aktualizace jsou vráceny, ale pouze pro celý systém, není (jak mi je známo) možné spustit například několik verzí WebPositive nebo LibreOffice současně.

Jeden z vývojářů píše:

V podstatě je odůvodnění následující: scénář použití je natolik vzácný, že optimalizace pro něj nemá smysl; zpracování jako výjimečný případ v HaikuPorts se zdá být více než přijatelné.

Potřebuji uchovávat aplikace tam, kde se mi líbí, a ne na spouštěcím disku. Disky mi často docházejí místo, takže musím připojit externí disk nebo síťový adresář pro ukládání aplikací (všech verzí, které jsem stáhl). Když připojím takový disk, aplikace by se měly spouštět dvojitým kliknutím. Haiku uchovává staré verze balíčků, ale nevím, jak je přemístit na externí disk, a také jak poté spouštět aplikace odtud.

Komentář vývojáře:

Technicky je to už možné s příkazem mount. Samozřejmě, GUI pro to uděláme, jakmile se najde dostatek zainteresovaných uživatelů.

Nepotřebuji miliony souborů rozptýlených po souborovém systému, kterými nemohu ručně spravovat. Chci jeden soubor na aplikaci, který si mohu snadno stáhnout, přesunout, smazat. Na Haiku je tento problém vyřešen pomocí balíčků .hpkg, které převedou například python z tisíců souborů do jednoho. Ale pokud je například Scribus, který používá python, musím se vypořádat alespoň se dvěma soubory. A musím se postarat o to, aby spolupracovaly jejich funkční verze.

Více verzí AppImages spuštěných vedle sebe na jednom Linuxu

Pohled z pohledu vývojáře aplikací

Podívejme se z pohledu vývojáře aplikací:

Chci mít plnou kontrolu nad uživatelskou zkušeností. Nechci být závislý na operačním systému, který mi říká, kdy a jak mám aplikace vydávat. Na Haiku mohou vývojáři pracovat se svými vlastními repozitáři hpkg, ale to znamená, že uživatelé si je budou muset nastavit ručně, což tuto myšlenku činí "méně atraktivní".
Mám stránku pro stahování na své webové stránce, kde distribuuji .exe pro Windows, .dmg pro Mac a .AppImage pro Linux. A co když chci monetizovat přístup k této stránce, možná? Co bych měl umístit tam pro Haiku? Stačí soubor .hpkg se závislostmi pouze na HaikuPorts.
Můj software potřebuje specifické verze jiného softwaru. Například je známo, že pro Krita je potřeba opravená verze Qt, nebo Qt, která je přesně přizpůsobena konkrétní verzi Krita, alespoň dokud se opravy nevrátí zpět do Qt. Mohu zabalit vlastní Qt pro aplikaci v balíčku .hpkg, ale pravděpodobně to nebude vítáno.

Obvyklá stránka pro stahování aplikace. Co bych měl zde umístit pro Haiku?

Budou sady (existující ve formě adresářů aplikací, jako AppDir nebo .*.app ve stylu Apple) a/nebo obrazy (ve formě silně modifikovaných AppImages nebo .dmg Je aplikace od Apple užitečným doplněním pracovní prostředí Haiku? Nebo to naruší celkový obraz a povede k fragmentaci, což by přidalo na složitosti? Jsem rozpolcený: na jedné straně krása a elegantnost Haiku spočívají v tom, že obvykle existuje jeden způsob, jak něco udělat, nikoli mnoho. Na druhé straně velká část infrastruktury pro katalogy a/nebo aplikace už je na místě, takže systém volá po tom, aby zbývající procenta zaujala svá místa.

Podle vývojáře mr. waddlesplash

Na Linuxu jsou (katalogy a sady aplikací, pozn. překl.) pravděpodobně technickým řešením systémových problémů. V Haiku preferujeme prostě řešit systémové problémy.

A co vy si o tom myslíte?

Než odpovíte…

Počkejte, udělejme rychlou kontrolu reality: ve skutečnosti katalogy aplikací už jsou součástí Haiku:

Katalogy aplikací už existují v Haiku, ale zatím nejsou podporovány v souborovém manažeru.

Jednoduše nejsou tak dobře podporovány, jako například v Macintosh Finderu. Jak by bylo skvělé, kdyby měl katalog QtCreator v levém horním rohu název a ikonu „QtCreator“, která by spuštění aplikace po dvojitém kliknutí?

Už jsem se ptal:

Jste si jisti, že dnes spustíte své aplikace z před deseti let, když všechny obchody s aplikacemi a úložiště distribucí na ně zapomenou a na jejich závislostech? Jste si jisti, že se budete moci přístupovat k vaší aktuální práci v budoucnu?

Existuje už odpověď od Haiku, nebo mohou katalogy a sady aplikací pomoci? Myslím, že mohou.

Podle pana waddlesplashe:

Ano, máme odpověď na otázku: prostě budeme tyto aplikace podporovat tak dlouho, jak bude třeba, dokud někdo nebude moci správným způsobem číst jejich formáty souborů nebo zajistit funkčnost jeden k jednomu. Naše snaha podporovat aplikace BeOS R5 na Haiku je toho přímým důkazem…

To je pravda!

Jaký plán by měl Haiku přijmout?

Mohu si představit mírumilovné soužití hpkg, katalogů a obrazů aplikací:

Systémový software používá .hpkg
Pro nejčastěji používaný software (zejména pro ten, který je potřeba naplánovat na plovoucí verze) se používá .hpkg (asi 80 % všech případů)
Některé, nainstalované prostřednictvím .hpkg, aplikace budou mít prospěch z přechodu na infrastrukturu s katalogy aplikací (například QtCreator): budou se šířit ve formě .hpkg, jako dříve.

mr. waddlesplash píše:

Pokud je vše, co potřebujete, jen prohlížení aplikací v /system/apps, místo toho by se měly katalogy v Deskbaru učinit uživatelsky přívětivější, protože /system/apps není určen k tomu, aby ho uživatelé pravidelně otevírali a prohlíželi (na rozdíl od MacOS). Pro takové situace má Haiku jinou paradigmu, ale tato varianta je ideálně přijatelná.

Haiku dostává infrastrukturu pro spuštění obrazů aplikací, noční, kontinuální a testovací sestavy softwaru, a také pro případy, kdy si uživatel přeje „zmrazit to v čase“, pro soukromý a interní software a další specifické případy použití (kolem 20 % ze všech). Tyto obrazy obsahují potřebné soubory pro spuštění aplikace .hpkg, které se připojují systémovými prostředky, a po dokončení aplikace se odpojí. (Možná by správce souborů mohl umístit soubory .hpkg do obrazů aplikací, automaticky nebo na žádost uživatele - jako když přetahujete aplikaci do síťového katalogu nebo na externí disk. To je prostě báseň! A přesněji řečeno poezie — haiku.) Na druhou stranu může uživatel chtít nainstalovat obsah obrazu jako soubory.hpkg, po čemž budou aktualizovány a zpracovávány stejně, jako by byly nainstalovány přes HaikuDepot… Je třeba uspořádat brainstorm).

Citát od mr. waddlesplash:

Spuštění aplikací z externích disků nebo síťových katalogů může být potenciálně užitečné. A přidání možnosti konfigurovat více „zóny“ pro pkgman bude rozhodně dobrou funkcí.

Takový systém využije výhod hpkg, katalogů a obrazů aplikací. Ty jsou dobré samostatně, ale společně se stanou neporazitelnými.

Závěr

Pro Haiku existuje infrastruktura, která poskytuje jednoduché a sofistikované uživatelské rozhraní pro PC, a daleko přesahuje to, co je obvykle poskytováno pro PC na Linuxu. Systém balíčků .hpkg — je jedním z těchto příkladů, ale ostatní části systému jsou také prostoupeny vytříbeností. Nicméně, správná podpora katalogů a obrazů aplikací by pro Haiku byla prospěšná. Jak to nejlépe udělat, by mělo být prodiskutováno s lidmi, kteří znají Haiku, její filozofii a architekturu mnohem lépe než já. Nakonec Haiku používám něco přes týden. Přesto věřím, že tento čerstvý pohled bude užitečný pro designéry, vývojáře a architekty Haiku. Minimálně bych rád sloužil jako jejich „tréninkový partner“. Mám více než 10 let praktických zkušeností s katalogy a sady aplikací pro Linux a rád bych našel jejich využití pro Haiku, jehož konceptu, jak si myslím, dokonale odpovídají. Navrhovaná potenciální řešení nejsou jedinými správnými pro problémy, které jsem popsal, a pokud tým Haiku rozhodne najít jiná, elegantnější, budu jen rád. hpkg ještě úžasnější, aniž by se změnil způsob, jakým funguje. Ukazuje se, že tým Haiku dlouho uvažoval o sadách aplikací při zavádění systému správy balíčků, ale bohužel, (mám dojem) že tato myšlenka upadla v zapomnění. Možná je čas ji oživit?

Vyzkoušejte to sami! Projekt Haiku poskytuje obrazy pro spuštění z DVD nebo USB, které jsou vytvářeny denně.
Máte otázky? Zveme vás do rusky mluvícího telegramového kanálu.

Přehled chyb: Jak si střelit do nohy v C a C++. Sbírka receptů Haiku OS

Od autora překladu: je to osmý a poslední článek cyklu o Haiku.

Seznam článků: První Druhý Třetí Čtvrtá Pátá Šestá Sedmá

Pouze registrovaní uživatelé se mohou účastnit ankety. Přihlaste se, prosím.