🥇Még valami: Haiku alkalmazáscsomagok?

Röviden összefoglalva: tud-e a Haiku megfelelő támogatást kapni alkalmazáscsomagokhoz, például alkalmazáskatalógusokhoz (mint .app a Mac-en) és/vagy alkalmazásképekhez (Linux AppImage)? Úgy tűnik számomra, hogy ez egy méltó kiegészítés lenne, amelyet könnyebb lenne integrálni, mint más rendszerekbe, mivel a legtöbb infrastruktúra már rendelkezésre áll.

Egy héttel ezelőtt fedeztem fel a Haiku-t, egy váratlanul jó rendszert. Mivel régóta érdeklődöm az alkalmazáskatalógusok és alkalmazásképek iránt (azok Mac-ra jellemző egyszerűsége miatt), nem meglepő, hogy eszembe jutott az ötlet...

A teljes megértés érdekében: én vagyok az AppImage készítője és szerzője, a Linux alkalmazások terjesztési formátuma, amely a Mac egyszerűségére összpontosít, és teljes irányítást biztosít az alkalmazásfejlesztők és a végfelhasználók számára (tudni szeretnél többet — lásd. wiki és a dokumentációval).

Mi lenne, ha AppImage-t készítenénk a Haiku számára?

Beszéljünk kicsit, tisztán elméletileg, arról, hogy mit kellene tenni ahhoz, hogy AppImage, vagy valami hasonlót kapjunk a Haiku-ra? Nem szükséges most azonnal valamit létrehozni, hiszen a Haiku-ban már meglévő rendszer elképesztően jól működik, de egy ilyen képzeletbeli kísérlet érdekes lenne. Emellett bemutatja a Haiku kifinomultságát a Linux munkakörnyezetekkel szemben, ahol az ilyen dolgok borzalmasan nehezek (jogosult vagyok ezt mondani: már 10 éve szenvedek a hibakereséssel).

A Macintosh System 1 alatt minden alkalmazás egy külön fájl volt, a Finder-ben "kezelve". Az AppImage használatával megpróbálom újra létrehozni ugyanezt a felhasználói élményt Linux alatt.

Először is, mi az az AppImage? Ez egy rendszer harmadik fél által készült alkalmazások kiadásához (például Ultimaker Cura), amely lehetővé teszi az alkalmazások kiadását, amikor és ahogy csak akarják: nem szükséges ismerni a különböző disztribúciók részleteit, a build-politikákat vagy az építési infrastruktúrát, nem kell támogatás, és nem mondják meg a felhasználóknak, hogy mit (nem) telepíthetnek a számítógépeikre. Az AppImage-ot valamihez kell hasonlítani, mint egy csomag a Mac-en, a .app disk image-en belül .dmg. A fő különbség az, hogy az alkalmazások nem másolódnak, hanem mindig az AppImage-ben maradnak, nagyjából úgy, ahogy a Haiku csomagok .hpkg fel vannak szerelve, és soha nem telepítődnek a hagyományos értelemben.

Az AppImage több mint 10 éve létezésével bizonyos vonzerőre és népszerűségre tett szert: maga Linus Torvalds nyilvánosan jóváhagyta, és több elterjedt projekt (például LibreOffice, Krita, Inkscape, Scribus, ImageMagick) alapértelmezett módként fogadta el a folyamatos vagy napi buildjeik terjesztésére, anélkül, hogy zavarba hoznák a felhasználók telepített vagy nem telepített alkalmazásait. Azonban a Linux munkakörnyezetek és disztribúciók többsége továbbra is ragaszkodik a hagyományos, központosított, kísérő- és/vagy saját vállalati üzleti és/vagy mérnöki programokra épülő terjesztési modellhez. Flatpak (RedHat, Fedora, GNOME) és Snappy (Canonical, Ubuntu). Eljut odáig hogy vicces.

Hogyan működik minden

Minden AppImage két részből áll: egy kicsi, dupla kattintással indítható ELF (azaz runtime.c), mellette egy fájlrendszer képpel SquashFS.

A SquashFS fájlrendszer az alkalmazás hasznos terhelését tartalmazza, valamint mindazt, ami a futtatásához szükséges, amelyet józan ésszel nem lehet az alapértelmezett telepítés részének tekinteni minden elég friss célszisztémán (Linux disztribúción). Emellett metaadatokat is tartalmaz, például az alkalmazás nevét, ikonokat, MIME típusokat, és egyebeket.

A felhasználó általi indításkor a runtime a FUSE-t és a squashfuse-t használja a fájlrendszer csatolására, majd néhány belépési pont (úgynevezett AppRun) elindítását kezeli a csatolt AppImage-en belül.
A fájlrendszer leválasztásra kerül, miután a folyamat befejeződött.

Úgy tűnik, minden egyszerű.

De ezek a dolgok mind megnehezítik:

a Linux disztribúciók ilyen sokféleségével már semmit sem lehet 'józan ésszel' az 'alapértelmezett telepítés részének' nevezni minden friss célszisztémán. Ezt a problémát a "excludelist" összeállításával kerüljük el, amely meghatározza, hogy mi fog belekerülni az AppImage-be, és mit kell máshonnan beszerezni. Ennek ellenére néha hibázunk, annak ellenére, hogy általában minden jól működik. Emiatt azt javasoljuk, hogy a csomagkészítők minden célszisztémán (disztribúciókon) ellenőrizzék az AppImage-eket. Az alkalmazások hasznos terhelésként mozgathatóknak kell lenniük a fájlrendszerben. Sajnos sok alkalmazásban abszolút utak vannak megadva, például az erőforrásokhoz az. Ezt valahogy ki kell javítani. Ezen kívül vagy exportálni kell
, vagy javítani kell /usr/sharerpath LD_LIBRARY_PATH, vagy helyesbíteni rpath a töltőprogramnak meg kell találnia a kapcsolódó könyvtárakat. Az első módszernek vannak hátrányai (amelyek bonyolult megoldásokat igényelnek), a második pedig egyszerűen terjedelmes.
A legnagyobb UX csapda a felhasználók számára az, hogy be kell állítani az végrehajtható bitet az AppImage fájlra a letöltés után. Hiszed vagy sem, de ez valakinek valós akadályt jelent. Az végrehajtható bit beállítása még a tapasztalt felhasználók számára is terhes. Alternatív megoldásként felajánlottunk egy apró szolgáltatást, amely figyeli az AppImage fájlokat, és beállítja számukra az végrehajtható bitet. Tiszta formájában nem a legjobb megoldás, mivel nem működik „dobozból ki”. A Linux disztribúciók nem biztosítják ezt a szolgáltatást, így a felhasználók számára „dobozból ki” minden rossz.
A Linux felhasználói azt várják, hogy az új alkalmazásnak ikona jelenjen meg az indítómenüben. A rendszernek nem mondhatod: „Nézd, ott egy új alkalmazás, dolgozz vele”. Ehelyett az XDG specifikáció szerint másolnod kell a fájlt .desktop a megfelelő helyre a /usr rendszerszintű telepítéshez, vagy a $HOME egyéni telepítéshez. Az XDG specifikáció szerint bizonyos méretű ikonákat kell elhelyezni a megfelelő helyekre a usr vagy $HOME, majd parancsokat kell futtatni a munkakörnyezetben az ikonák gyorsítótárának frissítéséhez, vagy remélni kell, hogy a munkakörnyezet kezelője észreveszi és automatikusan felfedezi azokat. Hasonló a MIME típusokkal is. Alternatív megoldásként azt javasolják, hogy ugyanazt a szolgáltatást használjuk, amely az végrehajthatósági jel beállítása mellett, ha lehetőség van ikonokra, azt az AppImage-ból másolja a megfelelő helyekre az XDG szerint. Törlés vagy áthelyezés esetén a szolgáltatás valószínűleg mindent tisztít. Természetesen minden munkakörnyezet viselkedésében, a grafikus fájlformátumokban, azok méreteiben, tárolási helyeiben és a gyorsítótárak frissítési módjaiban eltérések vannak, ami problémát okoz. Röviden, ez a módszer – átmeneti megoldás.
Ha a fentiek nem elegendőek, az fájlkezelőben még mindig nincs AppImage ikon. A Linux világában még mindig nem született döntés az elficon bevezetéséről (annak ellenére, hogy vita és a megvalósításról), így lehetetlen közvetlenül beilleszteni az ikont az alkalmazásba. Így tehát az alkalmazások a fájlkezelőben nem rendelkeznek saját ikonokkal (függetlenül attól, hogy AppImage vagy valami más), ezek csak a futtatómenüben találhatóak. Alternatív megoldásként miniatűröket használunk – egy mechanizmust, amelyet eredetileg arra fejlesztettek ki, hogy az asztali kezelők csökkentett képeket mutathassanak a grafikai fájlok előnézeteként az ikonjaiként. Következésképpen a végrehajtási bitek telepítésére szolgáló szolgáltatás /usr és $HOME. Ez a szolgáltatás takarítást is végez, ha az AppImage-t törlik vagy áthelyezik. Mivel minden asztali kezelő kicsit másképp viselkedik, például, hogy milyen formátumban fogadja el az ikonokat, milyen méretekben vagy helyeken, ez valóban fájdalmas.
Az alkalmazás egyszerűen összeomlik a végrehajtás során, ha hibák lépnek fel (például ha van egy könyvtár, amely nem része az alapvető rendszernek, és nem szállítják az AppImage-tel), és senki sem tájékoztatja a felhasználót a GUI-ban arról, hogy mi történik. Kezdtük ezt kikerülni azzal, hogy értesítés a munkaasztalon van, ezért ki kell bogarásznunk a hibaüzeneteket a parancssorból, és fel kell őket dolgoznunk a felhasználó által érthető üzenetekké, amelyeket aztán megjelenítünk a munkaasztalon. Természetesen minden munkahelyi környezet egy kicsit másképp kezeli őket.
Jelenleg (2019 szeptemberében, — a fordító megjegyzése) nem találtam könnyű utat a rendszernek, hogy elmondjam, hogy a fájlt 1.png a Kritával kell megnyitni, és 2.png — a GIMP-pel.

A cross-desktop specifikációk tárolási helye, amelyeket a GNOME, KDE és Xfce a freedesktop.org

A Haiku munkahelyi környezetébe mélyen beágyazott kifinomultság elérése nehézkes, ha nem mondhatjuk, hogy "lehetetlen", a freedesktop.org XDG specifikációi miatt, valamint a specifikációkon alapuló asztali kezelők megvalósításai miatt. Például említhető egy általános rendszerikon a Firefoxhoz: a XDG szerzőinek nyilvánvalóan nem jutott eszébe, hogy a felhasználónak lehet több verziója is ugyanannak az alkalmazásnak. A különböző Firefox verziók ikonjai.

A különböző Firefox verziók ikonjai.

Érdekes volt számomra, hogy mit tanulhatna a Linux világ a Mac OS X-től, hogy ne hibázzon a rendszerintegrációnál. Ha van időd és ezzel foglalkozol, mindenképpen olvasd el, mit mondott Arno Gurdol, a Mac OS X egyik első mérnöke:

Azt szerettük volna, hogy egy alkalmazás telepítése olyan egyszerű legyen, mint az alkalmazás ikonjának áthúzása valahonnan (szerver, külső meghajtó) a számítógép merevlemezére. Ehhez az alkalmazáspakkban minden információt tárolunk, beleértve az ikonokat, verziót, a feldolgozott fájltípust, a URL sémák típusát, amelyet a rendszernek tudnia kell az alkalmazás feldolgozásához. Ide tartozik az információ a 'központi tárolásról' is az Icon Services és Launch Services adatbázisában. Az alkalmazások 'felfedezése' a teljesítmény támogatása érdekében több 'jól ismert' helyen történik: a rendszer és a felhasználói Applications mappában, valamint néhány más helyen automatikusan, ha a felhasználó a Finderben arra a könyvtárra lép, amely az alkalmazást tartalmazza. A gyakorlatban ez nagyon jól működött.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 144. szekció — Mac OS X: alkalmazások csomagolása és dokumentumok nyomtatása.

Nincs hasonló infrastruktúra a Linux munkakörnyezeteiben, ezért alternatív megoldásokat keresünk a projekt AppImage struktúrájának korlátai körül.

Valóban a Haiku siet segítségére?

Emellett: a Linux platformok a munkakörnyezetek alapjául általában annyira alul-specifikáltak, hogy sok dolog, ami egy összesített rendszerben teljes értékű, a fragmentáltság és összetettség miatt csalódást keltő a Linuxban. Egy egész előadást szenteltem a Linux munkakörnyezetek kérdéseinek (a hozzáértő fejlesztők megerősítették: ez még nagyon sokáig így marad).

Az előadásom a Linux munkakörnyezetek problémáiról 2018-ban.

Még Linus Torvalds is elismerte, hogy a fragmentáció miatt nem sikerült az ötlet a munkakörnyezetekről.

Öröm látni a Haikut!

A Haikunal minden lélegzetelállítóan egyszerűvé válik.

Bár a "pénzkivonás" AppImage Haiku-ra való naiv megközelítése elsősorban az összetevői (főként runtime.c és a szolgáltatás) összeszerelésében rejlik (ami talán lehetséges!), nem hoz különösebb előnyöket Haiku számára. Mivel valójában ezeknek a problémáknak a többsége már megoldásra került Haiku alatt, és koncepcionálisan indokolt. Haiku pontosan azokat az építőelemeket biztosítja a rendszerinfrastruktúrához, amelyeket olyan régóta kerestem a Linux munkakörnyezetekben, és nem tudtam elhinni, hogy nem léteznek ott. Nevezetesen:

Elhiszed vagy sem, de ezt sok Linux felhasználó nem tudja legyőzni. Haiku-n minden automatikusan történik!

A futtathatósági bit nélküli ELF fájlok automatikusan megkapják ezt a fájlkezelőben való dupla kattintás kapcsán.
Az alkalmazások beágyazott erőforrásokkal rendelkezhetnek, például ikonokkal, amelyek a fájlkezelőben megjelennek. Nem szükséges rengeteg képet másolni speciális ikonok mappába, így nem kell őket eltávolítani sem az alkalmazás törlése vagy áthelyezése után.
Van egy adatbázis az alkalmazások és a dokumentumok összekapcsolására, nem szükséges fájlokat másolni ehhez.
A lib/ könyvtárban a végrehajtható fájlok mellett a könyvtárak alapértelmezés szerint keresésre kerülnek.
Nincsenek rengeteg disztribúció és asztali környezet, ami működik – az mindenhol működik.
Nincs külön indítómodul, ami eltérne az Applications könyvtártól.
Az alkalmazások nincsenek beágyazott abszolút elérési utakkal a saját erőforrásaikhoz, vannak speciális funkciók a helymeghatározásra futás közben.
Beépítették a tömörített fájlrendszer-képek ötletét: ez bármely hpkg csomag. Mindet a mag csatolja.
Minden fájl azzal az alkalmazással nyílik meg, amely létrehozta, hacsak nem adunk meg kifejezetten mást. Milyen menő!

Két png fájl. Figyeld meg a különböző ikonokat, amelyek azt mutatják, hogy ezeket különböző alkalmazások nyitják meg dupla kattintásra. Emellett figyeld meg a 'Megnyitás ezzel:' legördülő menüt, ahol a felhasználó választhat egy külön alkalmazást. Milyen egyszerű!

Úgy tűnik, hogy sok, az AppImage-hoz szükséges kerülő megoldás és trükk feleslegessé válik Haiku-n, amelynek alapja az egyszerűség és finomság, ezek teszik lehetővé, hogy a legtöbb igényünket kielégítse.

Szükség van-e a Haiku-n alkalmazáscsomagokra végül?

Ez egy nagy kérdéshez vezet. Ha a Haiku rendszerén az AppImage-hoz hasonló rendszert létrehozni sokkal egyszerűbb lenne, mint Linuxon, érdemes lenne ezzel foglalkozni? Vagy a Haiku hpkg csomagkezelő rendszere lényegében megszünteti egy hasonló ötlet kidolgozásának szükségességét? Nos, a válaszhoz meg kell néznünk az AppImage létezésének motivációját.

Felhasználói nézőpont

Nézzük a végfelhasználónkat:

Szeretném telepíteni az alkalmazást anélkül, hogy rendszergazda (root) jelszót kérne. A Haiku rendszerén nincs adminisztrátor fogalma, a felhasználónak teljes irányítása van, mivel ez egy személyes rendszer! (Elvileg ezt is elképzelhetjük többfelhasználós módban, remélem, a fejlesztők megőrzik az egyszerűséget)
Azt szeretném, hogy a legújabb és legjobb verziókat kapjam, ne kelljen várnom, amíg azok megjelennek a disztribúciómban (ami a legtöbb esetben azt jelenti, hogy "soha", hacsak nem frissítem az egész operációs rendszert). A Haiku ezt "megoldja" lebegő kiadásokkal. Ez azt jelenti, hogy van lehetőség a legújabb és legjobb verziók megszerzésére, de ehhez folyamatosan frissíteni kell a rendszer többi részét is, valójában „mozgó céllá” változtatva azt..
Szeretnék több verziót a ugyanarról az alkalmazásról egymás mellett, mivel nem lehet tudni, hogy mi hibás az utolsó verzióban, vagy mondjuk, mint webfejlesztőnek, le kell tesztelnem a munkámat különböző böngészőverziók alatt. A Haikuban az első probléma megoldva, de a második nem. A frissítések visszagördíthetők, de csak az egész rendszer esetében, (ahogy tudom) nem lehetséges, például, hogy egyszerre több verziót futtassak a WebPositive vagy a LibreOffice programból.

Az egyik fejlesztő írja:

Alapvetően az indoklás így szól: a használati forgatókönyv olyan ritka, hogy a benne való optimalizálásnak nincs értelme; ennek kivételként való kezelése a HaikuPorts-ban több mint elfogadhatónak tűnik.

Szeretném az alkalmazásokat ott tárolni, ahol nekem tetszik, és ne a bootlemezen. A meghajtóimon gyakran kifogy a hely, ezért külső meghajtót vagy hálózati mappát kell csatlakoztatnom az alkalmazások tárolására (minden verziót, amit letöltöttem). Ha csatlakoztatok egy ilyen meghajtót, az alkalmazásoknak kettős kattintással kell indulniuk. A Haiku megőrzi a régi csomagverziókat, de nem tudom, hogyan tudnám áthelyezni őket egy külső meghajtóra, és hogyan indíthatnám el az alkalmazásokat onnan.

Fejlesztői megjegyzés:

Technikailag ez már lehetséges a mount parancs segítségével. Természetesen GUI-t is csinálunk ehhez, amint összegyűlik elég érdeklődő felhasználó.

Nincs szükségem millió fájlra, szétszórva a fájlrendszerben, amelyeket nem tudok manuálisan kezelni. Egy fájlt szeretnék az alkalmazáshoz, amit könnyen letölthetek, áthelyezhetek, törölhetek. A Haiku ezt a problémát csomagokkal oldja meg, .hpkg, amelyek például a python-t több ezer fájlból egybe gyűjtik. De ha van például Scribus, amely python-t használ, akkor legalább két fájllal kell foglalkoznom. Gondoskodnom kell róla, hogy a működő verziókat megtartsam.

Több verziójú AppImage, párhuzamosan futtatva egy Linuxon

A fejlesztők szemszögéből

Nézzük meg a fejlesztők szempontjából:

Teljes mértékben szeretném irányítani a felhasználói élményt. Nem akarok függni az operációs rendszertől, amely előírja nekem, mikor és hogyan kell kiadnom az alkalmazásokat. A Haikuban a fejlesztők saját hpkg adattárakkal dolgozhatnak, de ez azt jelenti, hogy a felhasználóknak manuálisan kell beállítaniuk ezeket, ami kevésbé vonzóvá teszi az ötletet.
Van egy letöltési oldalam a webhelyemen, ahol terjesztem .exe Windows-ra, .dmg Mac-re és .AppImage Linux-ra. Lehet, hogy szeretném monetizálni a hozzáférést ehhez az oldalhoz, bármi megtörténhet? Mit kellene ott elhelyeznem a Haikuhoz? Elég lenne egy fájl, .hpkg amely csak a HaikuPorts-tól függ.
A szoftveremnek bizonyos verziójú más szoftverekre van szüksége. Például tudvalevő, hogy a Kritához javított verziójú Qt szükséges, vagy olyan Qt, amely pontosan a Krita adott verziójára van beállítva, legalább addig, amíg a javítások vissza nem kerülnek a Qt-be. Lehet csomagolni a saját Qt-jét az alkalmazáshoz csomagban, .hpkgde valószínűleg ez nem üdvözlendő.

Egy szokásos alkalmazás letöltő oldal. Mit kellene itt elhelyezni a Haikuhoz?

Megvalósulnak a csomagok (léteznek alkalmazáskönyvtárak formájában, mint az AppDir vagy .app Apple-stílus) és/vagy képek (erősen módosított AppImages formájában vagy .dmg használja az Apple-től származó alkalmazások értékes kiegészítéseket a Haiku munkakörnyezetében? Vagy ez megtöri az egységet, ami fragmentálja a rendszert, és ezáltal bonyolultságot ad? Kínlódok: egyrészt a Haiku szépsége és kifinomultsága azon alapul, hogy általában van egyetlen módja annak, hogy valamit megtegyünk, nem sok. Másrészt a legtöbb infrastruktúra a könyvtárakkal és / vagy alkalmazáskészletekkel már megvan, így a rendszer meghívja, hogy az utolsó pár százalék is a helyére kerüljön.

A fejlesztő szerint mr. waddlesplash

Linuxon ők (a könyvtárak és alkalmazáskészletek, - a fordító megjegyzése) valószínűleg technikai megoldásai a rendszerszintű problémáknak. A Haikunál inkább egyszerűen megoldjuk a rendszerszintű problémákat.

Mit gondolsz?

Mielőtt válaszolnál…

Várj, csináljunk egy gyors valóságellenőrzést: valójában alkalmazáskatalógusok már része a Haikunak:

Az alkalmazáskatalógusok már léteznek a Haikuban, de egyelőre nem támogatottak a fájlkezelőben.

Egyszerűen nem támogatják olyan jól, mint mondjuk a Macintosh Finder. Mennyire menő lenne, ha a QtCreator könyvtárának a bal felső sarkában név és a ‘QtCreator’ ikon lenne, amely megnyitja az alkalmazást dupla kattintással?

Kicsit korábban már kérdeztem:

Biztos vagy benne, hogy a tíz évvel ezelőtti alkalmazásaidat ma is futtatni fogod, amikor az összes alkalmazásbolt és disztribúciós tároló elfelejti azokat és a függőségeiket? Biztos vagy benne, hogy a jelenlegi munkádat a jövőben is elérheted?

Van már válasz a Haikutól, vagy a könyvtárak és alkalmazáskészletek segíthetnek itt? Azt hiszem, hogy igen.

Mr. waddlesplash szerint:

Igen, van válaszunk a kérdésre: egyszerűen csak támogatni fogjuk ezeket az alkalmazásokat annyi ideig, amennyire szükség van, amíg valaki helyesen el nem tudja olvasni a fájlformátumaikat vagy biztosítani nem tudja az egy az egyben funkciókat. Azt, hogy az BeOS R5 alkalmazások működését a Haikuban támogatni kívánjuk, ennek közvetlen bizonyítéka…

Ez pontosan így van!

Milyen cselekvési tervet kellene követnie a Haikunak?

El tudom képzelni a hpkg, a könyvtárak és az alkalmazásképek békés együttélését:

A rendszerprogramok használják .hpkg
A leggyakrabban használt szoftverhez (különösen a folyó kiadások ütemezésére) használják .hpkg (kb. a használati esetek 80%-a)
Néhány, amiket telepítettek .hpkg, az alkalmazások nyernek, ha áttérnek az alkalmazáskatalógusokkal rendelkező infrastruktúrára (például a QtCreator): így kerülnek terjesztésre, mint .hpkg, mint eddig.

mr. waddlesplash írja:

Ha csak arra van szükség, hogy alkalmazásokat nézzen meg a /system/apps, ehelyett a Deskbar katalógusait a felhasználók számára kezelhetőbbé kell tenni, mivel /system/apps nem arra lett tervezve, hogy a felhasználók rendszeresen megnyissák és megnézzék (ellentétben a MacOS-szel). Az ilyen helyzetekre a Haikunak más paradigma áll rendelkezésére, de ez a megoldás elvileg elfogadható.

A Haiku infrastruktúrát kap az alkalmazásképek futtatásához, éjszakai, folyamatos és tesztelő csomagokhoz, valamint olyan esetekben, amikor a felhasználó szeretné azt "lefagyasztani az időben", privát és belső szoftverekhez, valamint más különféle használati esetekhez (a teljes használat körülbelül 20%-át teszi ki). Ezek a képek a szükséges fájlokat tartalmazzák az alkalmazások futtatásához, .hpkg, amelyeket a rendszer eszközeivel csatolnak, majd a program befejezése után leválasztanak. (Lehetséges, hogy a fájlkezelő fájlokat tudna elhelyezni .hpkg az alkalmazásképekbe, automatikusan vagy a felhasználó kérésére – mint amikor az alkalmazást hálózati mappába vagy külső meghajtóra húzzuk. Ez egyszerűen zene! Pontosabban költészet – haiku.) Másrészt a felhasználó szeretné telepíteni a kép tartalmát fájlokká,.hpkg, amelyeket ezután pontosan úgy frissítenek és kezelnek, mintha a HaikuDepot-on keresztül telepítették volna… Ötletbörzét kellene tartani).

Idézet mr. waddlesplash-tól:

Alkalmazások indítása külső meghajtókról vagy hálózati mappákból potenciálisan hasznos lehet. A pkgman számára több „zóna” konfigurálásának lehetősége határozottan jó funkció lenne.

Az ilyen rendszer kihasználja a hpkg, a katalógusok és az alkalmazásképek előnyeit. Ezek jól működnek külön-külön, de együtt verhetetlenek lesznek.

Zárás

A Haiku számára egy egyszerű és kifinomult felhasználói felületet biztosító infrastruktúra áll rendelkezésre, amely messze túlmutat a Linuxon biztosított átlagos PC-funkciókon. A csomagrendszer .hpkg — az egyik ilyen példa, de a rendszer többi része is kifinomultsággal van átitatva. Mindazonáltal a Haiku alkalmazáskönyvtárainak és képeinek megfelelő támogatásból profitálna. Hogy ezt a legjobban hogyan lehetne megvalósítani, érdemes azokkal beszélni, akik a Haiku-t, annak filozófiáját és architektúráját sokkal jobban ismerik nálam. Végül is, alig több mint egy hete használom a Haiku-t. Mégis úgy gondolom, hogy ez az új nézőpont hasznos lehet a Haiku tervezői, fejlesztői és építészei számára. Legalábbis örömmel lennék „edzőpartner” számukra. Több mint 10 év gyakorlati tapasztalatom van Linux alkalmazáskatalógusok és csomagok terén, és szeretnék alkalmazást találni a Haiku számára, amelyhez véleményem szerint tökéletesen illeszkednek. Az általam javasolt potenciális megoldások nem feltétlenül a helyes válaszok a leírt problémákra, és ha a Haiku csapata más, elegánsabb megoldásokat talál, azért csak örömmel fogadom. Egyébként már gondolkodom azon, hogyan lehetne a rendszert hpkg még lenyűgözőbbé tenni anélkül, hogy megváltoztatnánk a működését. Kiderült, hogy a Haiku csapata már régóta fontolgatta az alkalmazáscsomagokat a csomagkezelő rendszer bevezetésekor, de sajnos (úgy tűnik) az ötlet „elavulttá” vált. Talán itt az idő, hogy felélesszük?

Próbáld ki te is! A Haiku projekt DVD- vagy USB-ről letölthető képeket biztosít, amelyek napi rendszerességgel.
Kérdéseid vannak? Meghívunk a magyar nyelvű telegram csatornánkra.

Hibák áttekintése: Hogyan lőjön lábon magának C és C++ használatával. A Haiku OS receptgyűjteménye

Től szerző fordítás: ez a nyolcadik és egyben záró cikk a Haiku-ról szóló cikksorozatból.

Cikkek listája: Első Második Harmadik Negyedik Ötödik Hatodik Hetedik

Csak a regisztrált felhasználók vehetnek részt a szavazáson. Kérem, jelentkezzen be., kérem.