🥇Még valami: Haiku alkalmazáscsomagok?

TL, DR: Megfelelő támogatást kaphat-e a Haiku az alkalmazáscsomagokhoz, például az alkalmazáskönyvtárakhoz (pl .app Mac rendszeren) és/vagy alkalmazásképek (Linux AppImage)? Úgy gondolom, hogy ez egy méltó kiegészítés lenne, amelyet könnyebb helyesen megvalósítani, mint más rendszereket, mivel az infrastruktúra nagy része már a helyén van.

Egy hete Felfedeztem a Haiku-t, egy váratlanul jó rendszert. Nos, mivel régóta érdekelnek a könyvtárak és az alkalmazásképek (amit a Macintosh egyszerűsége ihletett), nem meglepő, hogy eszembe jutott egy ötlet...

A tisztázás érdekében, én vagyok az AppImage, egy alkalmazásterjesztési formátum létrehozója és szerzője. Linux, amelynek célja, hogy egyszerűbbé tegye a Mac használatát, és teljes körű irányítást biztosítson az alkalmazáskészítők és a végfelhasználók kezébe (lásd alább). wiki и dokumentáció).

Mi van, ha készítünk egy AppImage-et a haiku számára?

Gondolkozzunk egy kicsit, pusztán elméletileg: mit kell tenni ahhoz, hogy megkapjuk AppImage, vagy valami hasonló a Haiku-n? Nincs szükség arra, hogy most valamit létrehozz, mivel a Haiku rendszere már elképesztően működik, de egy képzeletbeli kísérlet jó lenne. Ez a Haiku kifinomultságát is bemutatja az asztali környezetekhez képest. Linux, ahol az ilyesmi rettenetesen nehéz (jogom van ezt mondani: már 10 éve küzdök a hibakereséssel).

Macintosh System 1-en minden alkalmazás külön fájl volt, amelyet a Finderben „kezeltem”. Az AppImage segítségével megpróbálom ugyanazt a felhasználói élményt újraalkotni a következőn: Linux.

Először is, mi az AppImage? Ez egy harmadik féltől származó alkalmazások kiadására szolgáló rendszer (pl. Cura Ultimaker), lehetővé téve az alkalmazások kiadását, amikor és ahogy akarják: nincs szükség a különféle disztribúciók sajátosságainak ismeretére, házirendek létrehozására vagy infrastruktúra kiépítésére, nincs szükség karbantartói támogatásra, és nem mondják meg a felhasználóknak, hogy mit (nem) telepíthetnek. számítógépeiken. Az AppImage-et úgy kell érteni, mint valami hasonlót, mint egy Mac-csomag formátumában .app a lemezkép belsejében .dmg. A fő különbség az, hogy az alkalmazások nem másolódnak, hanem örökre az AppImage-ben maradnak, ugyanúgy, mint a Haiku csomagok .hpkg szerelve, és soha nem a szokásos értelemben.

Több mint 10 éves fennállása alatt az AppImage némi elismerésre és népszerűségre tett szert: maga Linus Torvalds is nyilvánosan támogatta, és népszerű projektek (pl. LibreOffice, Krita, Inkscape, Scribus, ImageMagick) a folyamatos vagy éjszakai verziók terjesztésének elsődleges módszerévé tették, amelyek nem zavarják a felhasználók telepített vagy eltávolított alkalmazásait. Az asztali környezetek és disztribúciók azonban Linux leggyakrabban továbbra is ragaszkodnak a hagyományos, központosított, karbantartókon alapuló elosztási modellhez és/vagy saját vállalati üzleti és/vagy mérnöki programjaikat népszerűsítik Flatpak (RedHat, Fedora, GNOME) és Lendületes (Kánoni, Ubuntu). Közeledik a célhoz. nevetségesen.

Hogyan működik

Minden AppImage 2 részből áll: egy kis dupla kattintással ELF (ún. runtime.c), majd egy fájlrendszer kép SquashFS.

A SquashFS fájlrendszer egy alkalmazás formájában lévő hasznos adatot és mindent tartalmaz, ami a futtatásához szükséges, ami épeszű fejjel nem tekinthető minden kellően új célrendszer (disztribúció) alapértelmezett telepítésének részének. Linux). Metaadatokat is tartalmaz, például az alkalmazás nevét, ikonokat, MIME-típusokat stb.

Amikor a felhasználó futtatja, a futtatókörnyezet a FUSE és a squashfuse segítségével csatlakoztatja a fájlrendszert, majd kezeli a belépési pont (más néven AppRun) futtatását a csatlakoztatott AppImage-en belül.
A folyamat befejezése után a fájlrendszert leválasztják.

Minden egyszerűnek tűnik.

És ezek a dolgok mindent bonyolítanak:

ilyen sokféle disztribúcióval Linux Ép ésszel semmi sem nevezhető többé „minden új célrendszer alapértelmezett telepítésének részének”. Ezt a problémát úgy oldjuk meg, hogy kizárási lista, amely lehetővé teszi annak meghatározását, hogy mi kerüljön az AppImage-be, és mit kell máshová vinni. Ugyanakkor néha hiányozunk, annak ellenére, hogy általában minden remekül működik. Emiatt azt javasoljuk, hogy a csomagkészítők teszteljék az AppImages-et az összes célrendszeren (terjesztésen).
Az alkalmazások rakományainak áthelyezhetőnek kell lenniük a fájlrendszerben. Sajnos sok alkalmazásnak van kemény kódolt abszolút elérési útja például a bejutó erőforrásokhoz /usr/share. Ezt valahogy javítani kell. Ezenkívül vagy exportálnia kell LD_LIBRARY_PATH, vagy javítani rpath hogy a betöltő megtalálja a kapcsolódó könyvtárakat. Az első módszernek megvannak a maga hátrányai (amelyeket összetett módszerekkel lehet kiküszöbölni), a második pedig egyszerűen nehézkes.
A felhasználók számára a legnagyobb UX buktató az állítsa be a végrehajtható bitet AppImage fájl letöltés után. Akár hiszed, akár nem, ez komoly akadályt jelenthet egyesek számára. A végrehajtható bit beállítása még a tapasztalt felhasználók számára is nehézkes. Megoldásként egy kis szolgáltatás telepítését javasoltuk, amely figyeli az AppImage fájlokat és beállítja azok végrehajtható bitjét. Tiszta formájában ez nem a legjobb megoldás, mivel azonnal nem fog működni. Disztribúciók Linux Nem nyújtják ezt a szolgáltatást, így a felhasználóknak rossz tapasztalataik vannak az elején.
Tagok Linux Azt várják el, hogy egy új alkalmazásnak legyen egy ikonja az indítóban. Nem mondhatod csak úgy a rendszernek, hogy „Nézd, van egy új alkalmazás, kezdjük el.” Ehelyett az XDG specifikációja szerint le kell másolni a fájlt. .desktop a megfelelő helyre /usr rendszerszintű telepítéshez vagy be $HOME egyéni számára. Bizonyos méretű ikonokat az XDG specifikáció szerint bizonyos helyeken el kell helyezni usr vagy $HOME, majd futtasson parancsokat a munkakörnyezetben az ikon-gyorsítótár frissítéséhez, vagy remélje, hogy a munkakörnyezet-kezelő kitalálja, és mindent automatikusan észlel. Ugyanez vonatkozik a MIME típusokra is. Kerülő megoldásként ugyanazt a szolgáltatást javasolják használni, amely a végrehajthatósági jelző beállítása mellett, ha vannak ikonok stb. az AppImage-ben másolja őket az AppImage-ből a megfelelő helyekre az XDG szerint. Törléskor vagy áthelyezéskor a szolgáltatás várhatóan mindent töröl. Természetesen eltérések mutatkoznak az egyes munkakörnyezetek viselkedésében, a grafikus fájlformátumokban, méretükben, tárolási helyeikben és a gyorsítótárak frissítési módszereiben, ami problémát okoz. Röviden, ez a módszer egy mankó.
Ha ez nem lenne elég, továbbra sincs AppImage ikon a fájlkezelőben. Linux még mindig nem döntöttem az elficon bevezetéséről (annak ellenére, hogy vita и végrehajtás), így lehetetlen az ikont közvetlenül az alkalmazásba beágyazni. Így kiderült, hogy a fájlkezelőben lévő alkalmazásoknak nincs saját ikonjuk (nincs különbség, AppImage vagy valami más), csak a start menüben vannak. Kerülő megoldásként miniatűröket használunk, egy olyan mechanizmust, amelyet eredetileg arra terveztek, hogy az asztali kezelők a grafikus fájlok előnézeti képeit ikonként jelenítsék meg. Következésképpen a végrehajthatósági bit beállítására szolgáló szolgáltatás „miniatürizálóként” is működik, létrehozva és a megfelelő helyekre ikon-bélyegképeket írva. /usr и $HOME. Ez a szolgáltatás az AppImage törlése vagy áthelyezése esetén is tisztítást végez. Tekintettel arra, hogy minden asztali kezelő kissé eltérően viselkedik, például milyen formátumban fogadja el az ikonokat, milyen méretben vagy helyen, ez mind nagyon fájdalmas.
Az alkalmazás egyszerűen összeomlik a végrehajtás során, ha hiba történik (például van egy olyan könyvtár, amely nem része az alaprendszernek, és nincs az AppImage-ben), és senki sem mondja meg a felhasználónak a grafikus felhasználói felületen, hogy pontosan mi történik. Ezt a használatával kezdtük megkerülni értesítéseket az asztalon, ami azt jelenti, hogy a hibákat a parancssorból kell elkapnunk, azokat felhasználó által érthető üzenetekké kell alakítanunk, amelyeket aztán meg kell jelenítenünk az asztalon. És természetesen minden asztali környezet egy kicsit másképp kezeli őket.
Jelenleg (2019. szeptember – a fordító megjegyzése) nem találtam egyszerű módot arra, hogy elmondjam a rendszernek, hogy a fájl 1.png a Krita használatával kell megnyitni, és 2.png - GIMP használatával.

Tárolási hely a több asztalon használt specifikációkhoz GNOME, KDE и Xfce a freedesktop.org

A Haiku munkakörnyezetbe mélyen beleszőtt kifinomultság elérése nehéz, ha nem lehetetlen, a specifikációk miatt XDG a freedesktop.org webhelyről több asztali számítógéphez, valamint az asztali kezelők ezen specifikációk alapján történő megvalósításához. Példaként említhetünk egy egész rendszerre kiterjedő Firefox ikont: láthatóan az XDG szerzői nem is gondoltak arra, hogy egy felhasználónak ugyanannak az alkalmazásnak több verziója is telepítve lehet.

A Firefox különböző verzióihoz tartozó ikonok

Azon tűnődtem, mi a világ Linux Tanulhatnék a Mac OS X-től, hogy hogyan kerüljem el a rendszerintegráció elrontását. Ha van időd és részt veszel ebben, feltétlenül olvasd el, mit mondott Arnaud Gourdold, az egyik első Mac OS X mérnök:

Az alkalmazás telepítését olyan egyszerűvé akartuk tenni, mintha az alkalmazás ikonját valahonnan (szerverről, külső meghajtóról) a számítógép meghajtójára húznánk. Ehhez az alkalmazáscsomag minden információt tárol, beleértve az ikonokat, a verziót, a feldolgozott fájltípust, az URL-sémák típusát, amelyeket a rendszernek tudnia kell az alkalmazás feldolgozásához. Ez magában foglalja az Icon Services és Launch Services adatbázisban található „központi tárolás” adatait is. A teljesítmény támogatása érdekében az alkalmazások „felfedeződnek” több „jól ismert” helyen: a rendszer és a felhasználói Alkalmazások könyvtárában, és néhány más helyen automatikusan, ha a felhasználó az alkalmazást tartalmazó könyvtárban a Finderhez navigál. A gyakorlatban ez nagyon jól működött.

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

Semmi hasonló nincs ebben az infrastruktúrában az éles környezetekben. Linux, ezért megkerülő megoldásokat keresünk az AppImage projekt strukturális korlátaira.

Haiku jön a megmentésre?

És még: platformok Linux a munkakörnyezetek alapjául szolgáló megoldások jellemzően annyira aluldefiniáltak, hogy sok olyan dolog, ami egy koherens, teljes körű rendszerben meglehetősen egyszerű lenne, frusztrálóan fragmentálttá és összetetté válik. LinuxEgy teljes jelentést szenteltem a platformmal kapcsolatos problémáknak. Linux munkakörnyezetekhez (a hozzáértő fejlesztők megerősítették, hogy minden így is marad még nagyon sokáig).

Jelentésem a munkakörnyezet problémáiról Linux az 2018-ban

Még Linus Torvalds is elismerte, hogy a munkaterület-ötlet a töredezettség volt az oka.

Jó látni Haiku-t!

A Haiku mindent elképesztően egyszerűvé tesz

Bár az AppImage Haiku-ra „portolásának” naiv megközelítése az lenne, ha egyszerűen megpróbálnánk lefordítani a komponenseit (főleg a runtime.c-t és a szolgáltatást) (ami akár lehetséges is lehet!), ez nem sok hasznot hozna a Haiku számára. Mert valójában ezeknek a problémáknak a nagy részét a Haiku megoldja, és koncepciójukban megalapozottak. A Haiku pontosan azokat az építőelemeket biztosítja a rendszerinfrastruktúrához, amelyeket már régóta keresek az asztali környezetekben. Linux és nem hitték el, hogy nincsenek ott. Nevezetesen:

Hiszed vagy sem, sok felhasználó nem tudja ezt leküzdeni. LinuxA Haiku-n minden automatikusan történik!

Azok az ELF fájlok, amelyek nem rendelkeznek végrehajtható bittel, automatikusan kapnak egyet, ha duplán kattintanak a fájlkezelőben.
Az alkalmazások rendelkezhetnek beépített erőforrásokkal, például ikonokkal, amelyek a fájlkezelőben jelennek meg. Nincs szükség arra, hogy egy csomó képet speciális ikonokkal ellátott könyvtárakba másoljon, ezért nem kell megtisztítani őket az alkalmazás törlése vagy áthelyezése után.
Létezik adatbázis az alkalmazások és dokumentumok összekapcsolására, ehhez nem kell fájlokat másolni.
A futtatható fájl melletti lib/ könyvtárban alapértelmezés szerint a programkönyvtárak keresése történik.
Nem létezik számos disztribúció és asztali környezet; ami működik, az mindenhol működik.
Nincs olyan külön futtatható modul, amely eltérne az Applications könyvtártól.
Az alkalmazásoknak nincs beépített abszolút elérési útjuk az erőforrásaikhoz, hanem speciális funkciókkal rendelkeznek a hely meghatározására futás közben.
Bemutatták a tömörített fájlrendszer-képek ötletét: ez bármilyen hpkg csomag. Mindegyiket a kernel csatlakoztatja.
Minden fájlt az azt létrehozó alkalmazás nyit meg, hacsak kifejezetten másként nem ad meg. Milyen klassz ez!

Két png fájl. Figyelje meg a különböző ikonokat, amelyek azt jelzik, hogy dupla kattintáskor különböző alkalmazások nyitják meg őket. Vegye figyelembe a "Megnyitás:" legördülő menüt is, ahol a felhasználó kiválaszthat egy egyedi alkalmazást. Milyen egyszerű!

Úgy tűnik, hogy az AppImage által igényelt hackek és kerülő megoldások nagy része Linux, szükségtelenné válnak a Haiku-n, amelynek lényege az egyszerűség és a kifinomultság, ami a legtöbb igényünk kielégítésére alkalmassá teszi.

A Haikának mégiscsak szüksége van alkalmazáscsomagokra?

Ez felvet egy nagy kérdést. Vajon egy olyan rendszer létrehozása, mint az AppImage a Haiku-n, nagyságrendekkel könnyebb lenne, mint a Linux, érdemes lenne folytatni? Vagy a Haiku a hpkg csomagolórendszerével gyakorlatilag kiküszöbölte egy ilyen ötlet szükségességét? Nos, hogy erre a kérdésre válaszoljunk, meg kell vizsgálnunk az AppImages mögött álló motivációt.

Felhasználó nézőpontja

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

Egy alkalmazást szeretnék telepíteni anélkül, hogy rendszergazdai (root) jelszót kérnék. A Haiku-n nincs rendszergazda fogalma, a felhasználó teljes ellenőrzése alatt áll, mivel ez egy személyes rendszer! (Elvileg ezt többjátékos módban is el lehet képzelni, remélem a fejlesztők egyszerűek lesznek)
Az alkalmazások legújabb és legjobb verzióit szeretném megszerezni anélkül, hogy megvárnám, hogy megjelenjenek a disztribúciómban (ez legtöbbször azt jelenti, hogy „soha”, legalábbis hacsak nem frissítem a teljes operációs rendszert). A Haikukon ez lebegő kiadásokkal van "megoldva". Ez azt jelenti, hogy beszerezhető az alkalmazások legújabb és legjobb verziója, de ehhez folyamatosan frissíteni kell a rendszer többi részét, hatékonyan „mozgó célponttá” alakítva azt..
Ugyanabból az alkalmazásból szeretnék több verziót egymás mellett, mert nem lehet tudni, hogy a legújabb verzióban mi ment tönkre, vagy mondjuk webfejlesztőként a böngésző különböző verziói alatt kell tesztelnem a munkámat. A haiku megoldja az első problémát, de a másodikat nem. A frissítések vissza vannak állítva, de csak az egész rendszerre, lehetetlen (tudtommal) például a WebPositive vagy a LibreOffice több verzióját egyszerre futtatni.

Az egyik fejlesztő ezt írja:

Az indoklás lényegében a következő: a használati eset olyan ritka, hogy nincs értelme az erre való optimalizálásnak; a HaikuPorts speciális eseteként kezelni több mint elfogadhatónak tűnik.

Az alkalmazásokat ott kell tartanom, ahol szeretem őket, nem pedig az indítómeghajtómon. Gyakran elfogy a lemezterületem, ezért külső meghajtót vagy hálózati könyvtárat kell csatlakoztatnom az alkalmazások (az összes letöltött verzió) tárolásához. Ha ilyen meghajtót csatlakoztatok, akkor dupla kattintással kell elindítani az alkalmazásokat. A Haiku elmenti a csomagok régi verzióit, de nem tudom, hogyan kell őket külső meghajtóra áthelyezni, vagy később hogyan lehet onnan alkalmazásokat indítani.

Fejlesztői megjegyzés:

Technikailag ez már a mount paranccsal lehetséges. Természetesen készítünk ehhez egy grafikus felhasználói felületet, amint lesz elegendő érdeklődő felhasználónk.

Nincs szükségem több millió fájlra szétszórva a fájlrendszerben, amelyeket magam nem tudok manuálisan kezelni. Alkalmazásonként egy fájlt szeretnék, amelyet egyszerűen letölthetek, áthelyezhetek, törölhetek. A Haiku esetében ezt a problémát csomagok segítségével oldják meg .hpkg, amelyek például a pythont több ezer fájlból egybe helyezik át. De ha van például pythont használó Scribus, akkor legalább két fájllal kell foglalkoznom. És ügyelnem kell arra, hogy megőrizzem ezeknek a változatait, amelyek együttműködnek.

Az AppImages több verziója fut egymás mellett egy gépen Linux

Az alkalmazásfejlesztő nézőpontja

Nézzük egy alkalmazásfejlesztő szemszögéből:

A teljes felhasználói élményt szeretném irányítani. Nem akarok egy operációs rendszertől függeni, hogy megmondja, mikor és hogyan kell kiadnom az alkalmazásokat. A Haiku lehetővé teszi a fejlesztők számára, hogy saját hpkg tárolóikkal dolgozzanak, de ez azt jelenti, hogy a felhasználóknak manuálisan kell beállítaniuk azokat, ami "kevésbé vonzóvá teszi" az ötletet.
A webhelyemen van egy letöltési oldal, ahol terjesztem .exe a Windows, .dmg Mac és .AppImage a LinuxVagy talán szeretném pénzzé tenni az oldalhoz való hozzáférést? Bármi lehetséges? Mit tegyek oda a Haikuhoz? A fájl elég .hpkg csak a HaikuPorts-tól származó függőségekkel
A szoftveremhez más szoftverek meghatározott verzióira van szükség. Például ismert, hogy a Krita a Qt javított verzióját igényli, vagy a Qt-t, amely a Krita egy adott verziójára van finomhangolva, legalábbis addig, amíg a javítások vissza nem kerülnek a Qt-be. Csomagolhatja saját Qt-jét az alkalmazásához .hpkg, de ez valószínűleg nem üdvözlendő.

Rendszeres alkalmazásletöltő oldal. Mit tegyek ide a Haiku miatt?

Will kötegek (olyan alkalmazáskönyvtárakként léteznek, mint az AppDir vagy .app Apple stílusban) és/vagy képek (erősen módosított AppImages vagy .dmg az Apple) alkalmazások hasznos kiegészítője a Haiku asztali környezetnek? Vagy felhígítja az összképet, és töredezettséghez vezet, és ezáltal bonyolultabbá teszi? El vagyok szakadva: egyrészt a Haiku szépsége és kifinomultsága azon alapszik, hogy általában nem sok, hanem egyféleképpen lehet valamit csinálni. Másrészt a katalógusok és/vagy alkalmazáscsomagok infrastruktúrájának nagy része már kiépült, így a rendszer azért kiált, hogy a maradék néhány százalék a helyére kerüljön.

A fejlesztő szerint úr. waddlesplash

tovább Linux Ők (katalógusok és alkalmazáskészletek, - kb. fordító) valószínűleg technikai megoldást jelentenek a rendszerszintű problémákra. A Haikunál inkább egyszerűen megoldjuk a rendszerproblémákat.

Mit gondolsz?

Mielőtt válaszolsz...

Várj, végezzünk egy gyors valóságellenőrzést: valójában alkalmazáskönyvtárak - már a Haiku része:

Már léteznek alkalmazáskönyvtárak a Haiku-n, de a fájlkezelő még nem támogatja őket

Egyszerűen nem olyan jól támogatottak, mint például a Macintosh Finder. Milyen jó lenne, ha a QtCreator könyvtár bal felső sarkában egy "QtCreator" név és ikon szerepelne, amely dupla kattintásra elindítja az alkalmazást?

Én már kicsit korábban kérdezte:

Biztos benne, hogy már ma is futtathatja évtizedes alkalmazásait, amikor az összes alkalmazásbolt és terjesztési adattár megfeledkezett róluk és a függőségeikről? Biztos benne, hogy a jövőben is hozzáférhet jelenlegi állásához?

Van már válasz a Haikutól, vagy a katalógusok és az alkalmazáscsomagok segíthetnek itt? Szerintem megtehetik.

szerint mr. waddlesplash:

Igen, megvan a válasz a kérdésre: egyszerűen támogatni fogjuk ezeket az alkalmazásokat addig, amíg szükséges, amíg valaki nem tudja a megfelelő módon olvasni a fájlformátumokat, vagy nem biztosít egy-egy funkciót. Elkötelezettségünk, hogy támogassuk a BeOS R5 alkalmazásokat a Haiku-n, ezt bizonyítja...

Biztos!

Milyen lépéseket kell tennie Haikunak?

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

Rendszerszoftver-használat .hpkg
A leggyakrabban használt szoftverekhez (különösen azokhoz, amelyeknek ütemezni kell a gördülő kiadásokat), használja a .hpkg (az összes eset körülbelül 80%-a)
Néhányan keresztül telepítve vannak .hpkg, az alkalmazások számára előnyös lesz, ha egy alkalmazás-címtár-infrastruktúrába (pl. QtCreator) költözik: ezek a következőképpen lesznek elosztva .hpkg, mint azelőtt.

úr. waddlesplash írja:

Ha csak az alkalmazások megtekintésére van szüksége /system/apps, ehelyett a Deskbar könyvtárait kezelhetőbbé kell tennünk a felhasználók számára, mivel /system/apps nem arra szolgál, hogy a felhasználók rendszeresen megnyissák és megtekintsék (ellentétben a MacOS-szal). Az ilyen helyzetekre a Haikunak más paradigmája van, de ez a lehetőség elméletben elfogadható.

A Haiku megkapja az infrastruktúrát az alkalmazásképek futtatásához, a szoftverek éjszakai, folyamatos és teszt buildjéhez, valamint azokhoz az esetekhez, amikor a felhasználó "időben le akarja fagyasztani", magán- és belső szoftverekhez, valamint egyéb speciális felhasználási esetekhez (kb. 20%) mindenböl). Ezek a képek az alkalmazás futtatásához szükséges fájlokat tartalmazzák .hpkg, a rendszer által felszerelve, és az alkalmazás befejezése után - lecsatolva. (Talán egy fájlkezelő elhelyezhet fájlokat .hpkg alkalmazásképekbe, automatikusan vagy a felhasználó kérésére – nos, mint amikor egy alkalmazást hálózati könyvtárra vagy külső meghajtóra húzunk. Ez csak egy dal! Illetve a költészet - haiku.) Másrészt előfordulhat, hogy a felhasználó a kép tartalmát fájlok formájában szeretné telepíteni.hpkg, utána ugyanúgy frissítésre és feldolgozásra kerülnek, mintha a HaikuDepoton keresztül telepítették volna... Ötletelni kell).

Idézet Mr. waddlesplash:

Hasznos lehet alkalmazások futtatása külső meghajtókról vagy hálózati könyvtárakról. És a pkgman további "zónák" beállításának képessége mindenképpen jó funkció lenne.

Egy ilyen rendszer kihasználná a hpkg, a könyvtárak és az alkalmazásképek előnyeit. Külön-külön is jók, de együtt legyőzhetetlenek lesznek.

Következtetés

A Haiku infrastruktúrája egyszerű és kifinomult felhasználói felületet biztosít a PC-k számára, és messze túlmutat a PC-ken jellemzően biztosítottakon. LinuxCsomagrendszer .hpkg – egy ilyen példa, de a rendszer más részei is kifinomultak. A Haiku azonban profitálna az alkalmazáskatalógusok és képek megfelelő támogatásából. Hogy ezt hogyan lehet a legjobban megvalósítani, érdemes megbeszélni olyanokkal, akik sokkal jobban ismerik a Haikut, annak filozófiáját és architektúráját, mint én. Végül is csak valamivel több mint egy hete használom a Haikut. Mindazonáltal hiszem, hogy ez az új perspektíva hasznos lesz a Haiku tervezői, fejlesztői és építészei számára. Legalábbis boldogan lennék „sparringpartnerük”. Több mint 10 éves gyakorlati tapasztalattal rendelkezem az alkalmazáskatalógusok és képcsomagok kezelésében a következők számára: Linux, és szeretnék találni nekik egy felhasználási módot a Haikuban, amihez szerintem tökéletesen illenek. Az általam javasolt lehetséges megoldások nem az egyetlenek a leírt problémákra, és ha a Haiku csapat úgy dönt, hogy más, elegánsabb megoldásokat talál, én teljes mértékben támogatom. Elvileg már gondolkodom egy ötleten, hogyan lehetne a rendszert megvalósítani hpkg még csodálatosabb anélkül, hogy megváltoztatná a működését. Kiderült, hogy a Haiku csapata egy csomagkezelő rendszer bevezetésekor már régóta gondolkodott az alkalmazáscsomagokon, de sajnos (szerintem) az ötlet "elavult". Talán ideje újraéleszteni?

Próbáld ki magad! Végül is a Haiku projekt képeket biztosít a DVD-ről vagy USB-ről történő indításhoz, generált formában napi.
Van kérdésed? Meghívjuk Önt az orosz nyelvű távirati csatorna.

Hiba áttekintése: Hogyan lődd lábon magad C és C++ nyelven. Haiku OS receptgyűjtemény

-Tól szerző fordítás: ez a nyolcadik és egyben utolsó cikk a Haikuról szóló sorozatban.

Cikkek listája: Első A második harmadik negyedik ötödik Hatodik hetedik

A felmérésben csak regisztrált felhasználók vehetnek részt. Bejelentkezés, kérem.