TL, DR: Může Haiku získat správnou podporu pro balíčky aplikací, jako jsou adresáře aplikací (např .app na Macu) a/nebo obrazy aplikací (Linux AppImage)? Myslím, že by to byl hodný doplněk, který se snáze implementuje správně než jiné systémy, protože většina infrastruktury je již na svém místě.
Objevil jsem Haiku, nečekaně dobrý systém. No, protože mě už dlouho zajímají adresáře a obrázky aplikací (inspirované jednoduchostí Macintoshe), není divu, že mě napadla myšlenka...
Pro úplné pochopení jsem tvůrcem a autorem AppImage, formátu distribuce aplikací pro Linux, který se zaměřuje na jednoduchost Mac a poskytuje plnou kontrolu autorům aplikací a koncovým uživatelům (pokud chcete vědět více, viz и ).
Co když vytvoříme AppImage pro Haiku?
Zamysleme se trochu, čistě teoreticky: co je potřeba udělat, abychom dostali , nebo něco podobného, na Haiku? Není nutné hned něco vytvářet, protože systém, který už v Haiku existuje, funguje úžasně, ale pomyslný experiment by byl fajn. Také to ukazuje sofistikovanost Haiku ve srovnání s linuxovými desktopovými prostředími, kde jsou takové věci strašně těžké (mám právo to říci: 10 let se potýkám s laděním).
V systému Macintosh 1 byla každá aplikace samostatným souborem "spravovaným" ve Finderu. Pomocí AppImage se snažím znovu vytvořit stejnou uživatelskou zkušenost v Linuxu.
Za prvé, co je AppImage? Jedná se o systém pro vydávání aplikací třetích stran (např. ), které umožňují vydávat aplikace, kdy a jak chtějí: není potřeba znát specifika různých distribucí, vytvářet zásady nebo budovat infrastrukturu, není potřeba žádná podpora správce a neříkají uživatelům, co (ne)mohou nainstalovat na jejich počítačích. AppImage je třeba chápat jako něco podobného jako balíček pro Mac ve formátu .app uvnitř obrazu disku .dmg. Hlavní rozdíl je v tom, že aplikace se nekopírují, ale zůstávají navždy uvnitř AppImage, podobně jako balíčky Haiku .hpkg namontován a nikdy nainstalován v obvyklém smyslu.
Během více než 10 let existence si AppImage získal určitou přitažlivost a popularitu: sám Linus Torvalds jej veřejně podpořil a běžné projekty (například LibreOffice, Krita, Inkscape, Scribus, ImageMagick) jej přijaly jako hlavní způsob. distribuovat nepřetržité nebo noční sestavení, aniž by zasahovalo do nainstalovaných nebo odinstalovaných uživatelských aplikací. Nicméně desktopová prostředí a distribuce Linuxu se nejčastěji stále drží tradičního, centralizovaného distribučního modelu založeného na správcích a/nebo propagují své vlastní podnikové obchodní a/nebo inženýrské programy založené na (RedHat, Fedora, GNOME) a (Canonical, Ubuntu). Přichází to .
Jak to všechno funguje
- Každý AppImage obsahuje 2 části: malý ELF na dvojité kliknutí (tzv.
runtime.c), za kterým následuje obraz systému souborů .
- Souborový systém SquashFS obsahuje datovou část aplikace a vše potřebné k jejímu spuštění, což v pravém slova smyslu nelze považovat za součást výchozí instalace pro každý poměrně nedávný cílový systém (distribuce Linuxu). Obsahuje také metadata, jako je název aplikace, ikony, typy MIME atd., atd.
- Když je spuštěn uživatelem, runtime používá FUSE a squashfuse k připojení souborového systému a pak se stará o spuštění nějakého vstupního bodu (aka AppRun) uvnitř připojeného AppImage.
Po dokončení procesu je systém souborů odpojen.
Zdá se, že vše je jednoduché.
A tyto věci vše komplikují:
- S tak rozmanitými linuxovými distribucemi nelze nic „správného“ nazvat „součástí výchozí instalace pro každý nový cílový systém“. Tento problém řešíme stavbou , což vám umožní určit, co bude zabaleno do AppImage a co bude třeba vzít někam jinam. Zároveň se nám občas stýská, přestože obecně vše funguje skvěle. Z tohoto důvodu doporučujeme, aby tvůrci balíčků testovali AppImages na všech cílových systémech (distribucích).
- Užitná zatížení aplikace musí být přemístitelná napříč systémem souborů. Bohužel mnoho aplikací má pevně zakódované absolutní cesty například ke zdrojům v
/usr/share. Tohle je potřeba nějak opravit. Kromě toho musíte buď exportovatLD_LIBRARY_PATHnebo opravitrpathaby zavaděč mohl najít související knihovny. První metoda má své nevýhody (které lze překonat složitými způsoby) a druhá je jednoduše těžkopádná. - Největší UX úskalí pro uživatele je to Soubor AppImage po stažení. Věřte nebo ne, pro některé je to opravdová překážka. Potřeba nastavit bit spustitelnosti je těžkopádná i pro zkušené uživatele. Jako řešení jsme navrhli instalaci malé služby, která monitoruje soubory AppImage a nastavuje jejich bit spustitelnosti. Ve své čisté formě to není nejlepší řešení, protože to nebude fungovat hned po vybalení. Linuxové distribuce tuto službu neposkytují, proto mají uživatelé z krabice špatné zkušenosti.
- Uživatelé Linuxu očekávají, že nová aplikace bude mít ve spouštěcí nabídce ikonu. Nemůžete říct systému: "Podívejte, je tu nová aplikace, pojďme pracovat." Místo toho, podle specifikace XDG, musíte soubor zkopírovat
.desktopna správné místo v/usrpro celosystémovou instalaci nebo v$HOMEpro jednotlivce. Ikony určitých velikostí, podle specifikace XDG, musí být umístěny na určitých místech vusrnebo$HOMEa poté spusťte příkazy v pracovním prostředí pro aktualizaci mezipaměti ikon nebo doufejte, že na to správce pracovního prostředí přijde a automaticky vše zjistí. Totéž s typy MIME. Jako řešení se navrhuje použít stejnou službu, která kromě nastavení příznaku spustitelnosti bude, pokud existují ikony atd. v AppImage je zkopírujte z AppImage na správná místa podle XDG. Při odstranění nebo přesunutí se očekává, že služba vše vymaže. Samozřejmě existují rozdíly v chování každého pracovního prostředí, ve formátech grafických souborů, jejich velikostech, umístěních úložišť a metodách aktualizace mezipaměti, což vytváří problém. Tato metoda je zkrátka berličkou. - Pokud výše uvedené nestačí, ve správci souborů stále není ikona AppImage. Linuxový svět se ještě nerozhodl implementovat elficon (navzdory и ), takže není možné ikonu vložit přímo do aplikace. Ukazuje se tedy, že aplikace ve správci souborů nemají své vlastní ikony (bez rozdílu, AppImage nebo něco jiného), jsou pouze v nabídce start. Jako řešení používáme miniatury, mechanismus, který byl původně navržen tak, aby umožňoval správcům desktopů zobrazovat náhledy obrázků grafických souborů jako jejich ikony. V důsledku toho služba pro nastavení bitu spustitelnosti funguje také jako „miniaturizér“, vytváří a zapisuje miniatury ikon na příslušná místa
/usrи$HOME. Tato služba také provádí čištění, pokud je AppImage odstraněn nebo přesunut. Vzhledem k tomu, že se každý správce plochy chová trochu jinak, například v jakých formátech přijímá ikony, v jakých velikostech či místech, je to všechno opravdu bolestivé. - Aplikace jednoduše spadne při spuštění, pokud se vyskytnou chyby (například existuje knihovna, která není součástí základního systému a není dodávána v AppImage), a v GUI není nikdo, kdo by uživateli řekl, co se přesně děje. Začali jsme to obcházet používáním na ploše, což znamená, že potřebujeme zachytit chyby z příkazového řádku, převést je na uživatelsky srozumitelné zprávy, které je pak třeba zobrazit na ploše. A každé desktopové prostředí je samozřejmě řeší trochu jinak.
- V tuto chvíli (září 2019 – pozn. překladatele) jsem nenašel jednoduchý způsob, jak systému sdělit, že soubor
1.pngmusí být otevřena pomocí Krity a2.png- pomocí GIMPu.
Umístění úložiště pro specifikace mezi počítači používané v , и je freedesktop.org
Dosažení úrovně sofistikovanosti hluboce vetknuté do pracovního prostředí Haiku je obtížné, ne-li nemožné, kvůli specifikacím pro cross-desktop, stejně jako implementace desktopových manažerů na základě těchto specifikací. Jako příklad můžeme uvést jednu systémovou ikonu Firefoxu: očividně autoři XDG ani nenapadlo, že by uživatel mohl mít nainstalovaných několik verzí stejné aplikace.
Ikony pro různé verze Firefoxu
Zajímalo by mě, co by se svět Linuxu mohl naučit od Mac OS X, aby se vyhnul zpackané systémové integraci. Pokud máte čas a máte na to chuť, přečtěte si, co řekl Arnaud Gurdol, jeden z prvních inženýrů Mac OS X:
Chtěli jsme, aby instalace aplikace byla stejně snadná jako přetažení ikony aplikace odněkud (server, externí disk) na disk vašeho počítače. K tomu jsou v aplikačním balíčku uloženy všechny informace, včetně ikon, verze, typu zpracovávaného souboru, typu schémat URL, které systém potřebuje znát pro zpracování aplikace. To také zahrnuje informace pro „centrální úložiště“ v databázi Icon Services a Launch Services. Pro podporu výkonu jsou aplikace „objevovány“ na několika „známých“ místech: v systémových a uživatelských adresářích aplikací a některých dalších automaticky, pokud uživatel přejde do Finderu v adresáři obsahujícím aplikaci. V praxi to fungovalo velmi dobře.
Apple WWDC 2000 session 144 - Mac OS X: balení aplikací a tisk dokumentů.
Na linuxových desktopech nic jako tato infrastruktura neexistuje, takže hledáme řešení strukturálních omezení v projektu AppImage.
Přichází Haiku na záchranu?
A ještě jedna věc: Linuxové platformy jako základ desktopových prostředí bývají tak nedostatečně specifikované, že mnoho věcí, které jsou v konzistentním full-stack systému docela jednoduché, je v Linuxu frustrujícím způsobem roztříštěných a složitých. Problémům souvisejícím s platformou Linux pro desktopová prostředí jsem věnoval celou zprávu (znalí vývojáři potvrdili, že vše tak zůstane ještě velmi dlouho).
Moje zpráva o problémech desktopových prostředí Linuxu v roce 2018
Dokonce i Linus Torvalds připustil, že fragmentace byla důvodem, proč myšlenka pracovního prostoru selhala.
Rád vidím Haiku!
Haiku dělá všechno úžasně jednoduchým
Zatímco naivním přístupem k „portování“ AppImage na Haiku je jednoduše se pokusit sestavit (především runtime.c a servis) jeho komponenty (což může být dokonce možné!), Haiku to nepřinese mnoho výhod. Protože ve skutečnosti je většina těchto problémů vyřešena v haiku a jsou koncepčně v pořádku. Haiku poskytuje přesně ty stavební bloky systémové infrastruktury, které jsem v desktopových prostředích Linuxu tak dlouho hledal a nemohl jsem uvěřit, že tam nejsou. A to:
Věřte tomu nebo ne, to je něco, co mnoho uživatelů Linuxu nemůže překonat. Na Haiku se vše děje automaticky!
- Soubory ELF, které nemají spustitelný bit, jej získají automaticky po poklepání ve správci souborů.
- Aplikace mohou mít vestavěné prostředky, jako jsou ikony, které se zobrazují ve správci souborů. Není potřeba kopírovat hromadu obrázků do speciálních adresářů s ikonami, a tedy ani uklízet po smazání nebo přesunutí aplikace.
- Existuje databáze pro propojení aplikací s dokumenty, není k tomu potřeba kopírovat žádné soubory.
- V adresáři lib/ vedle spustitelného souboru se standardně prohledávají knihovny.
- Neexistuje mnoho distribucí a desktopových prostředí; co funguje, funguje všude.
- Neexistuje žádný samostatný modul ke spuštění, který by se lišil od adresáře Applications.
- Aplikace nemají vestavěné absolutní cesty ke svým prostředkům, mají speciální funkce pro určení umístění za běhu.
- Byla představena myšlenka komprimovaných obrazů souborového systému: jedná se o jakýkoli balíček hpkg. Všechny jsou připojeny jádrem.
- Každý soubor je otevřen aplikací, která jej vytvořila, pokud výslovně neurčíte jinak. Jak skvělé je to!
Dva soubory png. Všimněte si různých ikon, které označují, že je po poklepání otevřou různé aplikace. Všimněte si také rozbalovací nabídky „Otevřít pomocí:“, kde si uživatel může vybrat jednotlivou aplikaci. Jak jednoduché!
Zdá se, že mnoho berliček a řešení požadovaných aplikací AppImage na Linuxu se stává zbytečnými na Haiku, jehož jádro spočívá v jednoduchosti a propracovanosti, díky níž zvládne většinu našich potřeb.
Potřebuje Haiku nakonec balíčky aplikací?
To vede k velké otázce. Pokud by bylo řádově jednodušší vytvořit systém jako AppImage na Haiku než na Linuxu, stálo by to za to? Nebo Haiku se svým balíčkovým systémem hpkg účinně eliminovalo potřebu rozvíjet takový nápad? Abychom odpověděli, musíme se podívat na motivaci existence AppImages.
Pohled uživatele
Podívejme se na našeho koncového uživatele:
- Chci nainstalovat aplikaci bez požadavku na heslo správce (root). Na Haiku neexistuje žádný koncept správce, uživatel má plnou kontrolu, protože jde o osobní systém! (V principu si to dokážete představit v režimu pro více hráčů, doufám, že to vývojáři udrží jednoduché)
- Chci získat nejnovější a nejlepší verze aplikací, aniž bych čekal, až se objeví v mé distribuci (nejčastěji to znamená „nikdy“, alespoň pokud neaktualizuji celý operační systém). Na Haiku je to „řešeno“ plovoucími verzemi. To znamená, že je možné získat nejnovější a nejlepší verze aplikací, ale abyste to mohli udělat, musíte neustále aktualizovat zbytek systému a účinně jej proměnit v „pohyblivý cíl“.
- Chci několik verzí stejné aplikace vedle sebe, protože neexistuje způsob, jak zjistit, co bylo v nejnovější verzi rozbité, nebo, řekněme, já jako webový vývojář musím otestovat svou práci pod různými verzemi prohlížeče. Haiku řeší první problém, ale ne druhý. Aktualizace jsou vráceny zpět, ale pouze pro celý systém, nelze (pokud vím) spustit například několik verzí WebPositive nebo LibreOffice současně.
Jeden z vývojářů píše:
Důvodem je v podstatě toto: případ použití je tak vzácný, že optimalizace pro něj nedává smysl; považovat to za zvláštní případ v HaikuPorts se zdá více než přijatelné.
- Potřebuji mít aplikace tam, kde je mám rád, ne na spouštěcí jednotce. Často mi dochází místo na disku, takže potřebuji připojit externí disk nebo síťový adresář pro uložení aplikací (všech verzí, které mám stažené). Pokud připojím takový disk, potřebuji, aby se aplikace spouštěly dvojitým kliknutím. Haiku ukládá staré verze balíčků, ale nevím, jak je přesunout na externí disk, nebo jak odtud později spouštět aplikace.
Komentář vývojáře:
Technicky je to již možné pomocí příkazu mount. Samozřejmě pro to uděláme GUI, jakmile budeme mít dostatek zainteresovaných uživatelů.
- Nepotřebuji miliony souborů roztroušených po souborovém systému, které nemohu sám ručně spravovat. Chci jeden soubor na aplikaci, který mohu snadno stáhnout, přesunout, odstranit. Na Haiku je tento problém vyřešen pomocí balíčků
.hpkg, které převádějí například python z tisíců souborů do jednoho. Ale pokud existuje například Scribus používající python, pak se musím vypořádat minimálně se dvěma soubory. A musím se postarat o to, abych zachoval jejich verze, které spolu fungují.
Více verzí AppImages běžících vedle sebe na stejném Linuxu
Pohled vývojáře aplikací
Podívejme se z pohledu vývojáře aplikace:
- Chci mít pod kontrolou celou uživatelskou zkušenost. Nechci být závislý na operačním systému, který mi bude říkat, kdy a jak mám vydat aplikace. Haiku umožňuje vývojářům pracovat s jejich vlastními repozitáři hpkg, ale to znamená, že je uživatelé budou muset nastavit ručně, což činí tento nápad "méně atraktivní."
- Na svém webu mám stránku ke stažení, kam distribuuji
.exepro Windows,.dmgpro Mac a.AppImagepro Linux. Nebo možná chci zpeněžit přístup na tuto stránku, je možné cokoliv? Co tam mám dát za Haiku? Soubor stačí.hpkgse závislostmi pouze z HaikuPorts - Můj software vyžaduje specifické verze jiného softwaru. Je například známo, že Krita vyžaduje opravenou verzi Qt nebo Qt, která je doladěna na konkrétní verzi Krity, alespoň do té doby, než budou záplaty zatlačeny zpět do Qt. Do balíčku můžete zabalit vlastní Qt pro vaši aplikaci
.hpkg, ale s největší pravděpodobností to není vítáno.
Pravidelná stránka pro stahování aplikací. Co bych sem měl napsat pro Haiku?
Will bundles (existující jako adresáře aplikací jako AppDir nebo .app ve stylu Apple) a/nebo obrázky (ve formě silně upravených AppImages popř .dmg od Applu) aplikace užitečným doplňkem desktopového prostředí Haiku? Nebo to rozmělní celý obraz a povede k roztříštěnosti, a tudíž přidá na složitosti? Jsem na roztrhání: na jedné straně je krása a sofistikovanost Haiku založena na tom, že obvykle existuje jeden způsob, jak něco udělat, spíše než mnoho. Na druhou stranu, většina infrastruktury pro katalogy a/nebo sady aplikací je již na svém místě, takže systém volá po zbývajících pár procentech, aby zapadly.
Podle vývojáře
Na Linuxu jsou (katalogy a aplikační sady, - cca. překladatel) jsou s největší pravděpodobností technickým řešením systémových problémů. V Haiku preferujeme jednoduché řešení systémových problémů.
Co myslíš?
Než odpovíš...
Počkejte, pojďme si rychle ověřit realitu: ve skutečnosti adresáře aplikací - již součástí Haiku:
Adresáře aplikací již na Haiku existují, ale ve správci souborů ještě nejsou podporovány
Jen nejsou tak dobře podporovány jako například Macintosh Finder. Jak skvělé by bylo, kdyby adresář QtCreator měl v levém horním rohu název a ikonu „QtCreator“, která spustí aplikaci po poklepání?
Já už trochu dříve :
Jste si jisti, že můžete spustit své deset let staré aplikace dnes, když na ně a jejich závislosti všechny obchody s aplikacemi a distribuční repozitáře zapomněly? Jste si jisti, že v budoucnu budete mít stále přístup ke své současné práci?
Existuje již odpověď z Haiku, nebo zde mohou pomoci katalogy a balíčky aplikací? Myslím, že mohou.
Podle pana waddlesplash:
Ano, máme odpověď na otázku: jednoduše budeme tyto aplikace podporovat tak dlouho, jak to bude nutné, dokud někdo nebude schopen číst jejich formáty souborů správným způsobem nebo poskytovat funkce one-to-one. Náš závazek podporovat aplikace BeOS R5 na Haiku je toho důkazem...
Je to jisté!
Jaký postup by měl Haiku přijmout?
Dovedu si představit poklidné soužití hpkg, adresářů a obrázků aplikací:
- Použití systémového softwaru
.hpkg - U nejčastěji používaného softwaru (zejména u těch, které potřebují naplánovat průběžná vydání), použijte
.hpkg(přibližně 80 % všech případů) - Některé instalované přes
.hpkg, budou aplikace těžit z přesunu do aplikační adresářové infrastruktury (např. QtCreator): budou distribuovány jako.hpkg, jako dříve.
pan. waddlesplash píše:
Pokud vše, co potřebujete, je prohlížet aplikace v
/system/apps, místo toho bychom měli vytvořit adresáře na Deskbaru pro uživatele lépe spravovatelné, protože/system/appsnení určen k pravidelnému otevírání a prohlížení uživateli (na rozdíl od MacOS). Pro takové situace má Haiku jiné paradigma, ale tato možnost je teoreticky přijatelná.
- Haiku získává infrastrukturu pro spouštění aplikačních obrazů, noční, průběžné a testovací sestavení softwaru, jakož i pro případy, kdy jej uživatel chce „zmrazit v čase“, pro soukromý a interní software a další speciální případy použití (asi 20 % ze všech). Tyto obrázky obsahují soubory potřebné ke spuštění aplikace
.hpkg, připojený systémem a po dokončení aplikace - odpojen. (Možná by správce souborů mohl umístit soubory.hpkgdo obrazů aplikace, automaticky nebo na žádost uživatele – dobře, jako když přetáhnete aplikaci do síťového adresáře nebo na externí disk. Je to jen píseň! Nebo spíše poezie - haiku.) Na druhou stranu může uživatel chtít nainstalovat obsah obrázku ve formě souborů.hpkg, po kterém budou aktualizovány a zpracovány stejným způsobem, jako kdyby byly nainstalovány přes HaikuDepot... Musíme brainstormovat).
Citace od mr. waddlesplash:
Spouštění aplikací z externích disků nebo síťových adresářů může být potenciálně užitečné. A přidání možnosti konfigurovat více „zón“ pro pkgman by bylo rozhodně příjemnou funkcí.
Takový systém by využíval hpkg, adresáře a obrazy aplikací. Jsou dobří jednotlivě, ale společně se stanou neporazitelnými.
Závěr
Haiku má rámec, který poskytuje jednoduchou a sofistikovanou uživatelskou zkušenost pro PC a jde daleko nad rámec toho, co je obvykle poskytováno pro PC s Linuxem. Balíkový systém .hpkg je jedním z takových příkladů, ale i zbytek systému je prodchnutý sofistikovaností. Haiku by však prospěla řádná podpora adresářů a obrazů aplikací. Jak nejlépe to udělat, stojí za to diskutovat s lidmi, kteří znají Haiku, jeho filozofii a architekturu mnohem lépe než já. Ostatně Haiku používám něco málo přes týden. Přesto věřím, že designéři, vývojáři a architekti Haiku budou z této nové perspektivy těžit. Přinejmenším bych byl rád, kdybych byl jejich „sparring partnerem“. Mám přes 10 let praktických zkušeností s linuxovými aplikačními katalogy a balíčky a rád bych pro ně našel využití v Haiku, pro které si myslím, že se perfektně hodí. Potenciální řešení, která jsem navrhl, nejsou v žádném případě jediná správná pro problémy, které jsem popsal, a pokud se tým Haiku rozhodne najít jiná, elegantnější, jsem pro. V podstatě už přemýšlím o myšlence, jak udělat systém hpkg ještě úžasnější, aniž by se změnil způsob, jakým to funguje. Ukazuje se, že tým Haiku při implementaci systému pro správu balíčků uvažoval o balíčcích aplikací dlouhou dobu, ale bohužel (myslím) tento nápad „zastaral“. Možná je čas to oživit?
Zkus to sám! Projekt Haiku koneckonců poskytuje vygenerované obrazy pro bootování z DVD nebo USB .
Máte nějaké dotazy? Zveme vás na rusky mluvící .
Přehled chyb:
Z překlad: toto je osmý a poslední článek ze série o Haiku.
Seznam článků:
Průzkumu se mohou zúčastnit pouze registrovaní uživatelé. , prosím.
Má smysl portovat systém hpkg na Linux?
-
Ano
-
Ne
-
Již implementováno, napíšu do komentářů
Hlasovalo 20 uživatelů. 5 uživatelů se zdrželo hlasování.
Zdroj: www.habr.com