Valami más: 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 teljes megértés érdekében én vagyok az AppImage, egy Linux-alkalmazás-terjesztési formátum megalkotója és szerzője, amely a Mac egyszerűségét célozza, és teljes ellenőrzést biztosít az alkalmazások készítőinek és végfelhasználóinak (ha többet szeretne tudni, lásd 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? Nem kell most valamit alkotni, mert a Haikuban már meglévő rendszer elképesztően működik, de jó lenne egy képzeletbeli kísérlet. Ez is jól mutatja a Haiku kifinomultságát a Linux asztali környezetekhez képest, ahol az ilyesmi borzasztóan nehéz (jogom van kijelenteni: 10 éve küszködöm a hibakereséssel).

A Macintosh System 1 rendszeren minden alkalmazás külön fájl volt, amelyet a Finderben „kezeltek”. Az AppImage használatával ugyanazt a felhasználói élményt próbálom újra létrehozni Linuxon.

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 vonzerőre és népszerűségre tett szert: Linus Torvalds nyilvánosan támogatta, és a közös projektek (például LibreOffice, Krita, Inkscape, Scribus, ImageMagick) ezt alkalmazták fő útnak. folyamatos vagy éjszakai buildek terjesztésére, nem zavarva a telepített vagy eltávolított felhasználói alkalmazásokat. A Linux asztali környezetek és disztribúciók azonban leggyakrabban továbbra is ragaszkodnak a hagyományos, központosított karbantartó alapú disztribúciós modellhez és/vagy népszerűsítik saját vállalati üzleti és/vagy mérnöki programjaikat. Flatpak (RedHat, Fedora, GNOME) és Lendületes (Canonical, Ubuntu). Jön 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 tartalmazza az alkalmazás hasznos terhét és mindent, ami a futtatásához szükséges, ami józan észben nem tekinthető minden viszonylag friss célrendszer (Linux disztribúció) alapértelmezett telepítésének. Metaadatokat is tartalmaz, például az alkalmazás nevét, ikonokat, MIME-típusokat stb. 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:

• A Linux disztribúciók ilyen sokfélesége mellett semmi „józan észben” nem nevezhető „minden új célrendszer alapértelmezett telepítésének részének”. Ezt a problémát építéssel kerüljük meg 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 hiszi, akár nem, ez egyesek számára igazi akadály. A végrehajthatósági bit beállításának szükségessége még a tapasztalt felhasználók számára is nehézkes. Megkerülő megoldásként egy kis szolgáltatás telepítését javasoltuk, amely figyeli az AppImage fájlokat, és beállítja a végrehajthatósági bitet. Tiszta formájában nem a legjobb megoldás, mivel a dobozból nem fog működni. A Linux disztribúciók nem biztosítják ezt a szolgáltatást, ezért a felhasználók rossz tapasztalattal rendelkeznek.
• A Linux-felhasználók elvárják, hogy egy új alkalmazásnak legyen ikonja az indítási menüben. Nem mondhatja a rendszernek: "Nézd, van egy új alkalmazás, dolgozzunk." Ehelyett az XDG specifikáció szerint másolni kell 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 a fentiek nem elegendőek, továbbra sem található AppImage ikon a fájlkezelőben. A Linux világ még nem döntött az elficon bevezetése mellett (annak ellenére 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

Kíváncsi voltam, mit tanulhatna a Linux világ a Mac OS X-től, hogy elkerülje a rendszerintegráció elrontását. Ha van időd, és szeretnéd, feltétlenül olvasd el, mit mondott Arnaud Gurdol, 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.

A Linux asztali számítógépeken nincs ehhez hasonló infrastruktúra, ezért az AppImage projekt szerkezeti korlátaira megoldásokat keresünk.

Haiku jön a megmentésre?

És még valami: a Linux platformok mint az asztali környezetek alapja, általában annyira aluldefiniáltak, hogy sok olyan dolog, ami egy konzisztens full-stack rendszerben meglehetősen egyszerű, bosszantóan töredezett és bonyolult a Linuxban. Egy teljes jelentést szenteltem az asztali környezetek Linux platformjával kapcsolatos problémáknak (a hozzáértő fejlesztők megerősítették, hogy minden így marad még nagyon sokáig).

Jelentésem a Linux asztali környezetek problémáiról 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

Míg az AppImage Haikura való „portolásának” naiv megközelítése az, hogy egyszerűen megpróbáljuk felépíteni (főleg a runtime.c-t és a szolgáltatást) annak összetevőit (ami akár lehetséges is!), ez nem sok hasznot hoz a Haiku számára. Mert valójában ezeknek a problémáknak a többsége a haikuban van megoldva, és fogalmilag megalapozott. A Haiku pontosan azokat a rendszerinfrastruktúra építőelemeket nyújtja, amelyeket olyan régóta keresek Linux asztali környezetekben, és el sem tudtam hinni, hogy nincsenek ott. Ugyanis:

Akár hiszi, akár nem, ezt sok Linux-felhasználó nem tudja leküzdeni. A Haiku-n minden automatikusan megtö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 a Linuxon az AppImage által megkívánt sok mankó és kerülő megoldás szükségtelenné válik a Haiku esetében, amelynek lényege az az egyszerűség és kifinomultság, hogy a legtöbb szükségletünket kielégíti.

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

Ez egy nagy kérdéshez vezet. Ha egy nagyságrenddel könnyebb lenne egy olyan rendszert létrehozni, mint az AppImage Haiku-n, mint Linuxon, akkor érdemes lenne megtenni? Vagy a Haiku a hpkg csomagrendszerével gyakorlatilag megszüntette egy ilyen ötlet kidolgozásának szükségességét? Nos, a válaszhoz meg kell vizsgálnunk az AppImages létezésének motivációjá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 ugyanazon a Linuxon

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 Windowshoz, .dmg Mac és .AppImage Linuxhoz. Vagy esetleg szeretnék bevételt szerezni az oldalhoz való hozzáféréssel, bármi lehetséges? Mit tegyek oda 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

Linuxon ő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 olyan keretrendszerrel rendelkezik, amely egyszerű és kifinomult felhasználói élményt biztosít a PC-n, és messze túlmutat a Linux PC-re jellemzően. Csomagrendszer .hpkg egy ilyen példa, de a rendszer többi részét is áthatja a kifinomultság. A Haikunak azonban jól jönne a megfelelő könyvtár- és alkalmazáskép-támogatás. Hogy ezt hogyan lehet a legjobban megtenni, érdemes megvitatni olyan emberekkel, akik nálam sokkal jobban ismerik a Haiku-t, annak filozófiáját és építészetét. Végül is kicsit több mint egy hete használom a Haiku-t. Mindazonáltal úgy gondolom, hogy a Haiku tervezői, fejlesztői és építészei profitálni fognak ebből az új nézőpontból. Legalább szívesen lennék a „sparring partnerük”. Több mint 10 éves gyakorlati tapasztalattal rendelkezem a Linux alkalmazáskatalógusok és csomagok terén, és a Haiku-ban szeretnék hasznot húzni, amire szerintem tökéletesen megfelelnek. Az általam javasolt lehetséges megoldások korántsem az egyedüli helyesek az általam leírt problémákra, és ha a Haiku csapat úgy dönt, hogy más, elegánsabb megoldást keres, én mindenben mellette állok. Alapvetően már azon gondolkodom, hogyan készítsek rendszert 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.

Van értelme a hpkg rendszert Linuxra portolni?

• Igen

• Nincs

• Már végrehajtották, megírom a megjegyzésekben

20 felhasználó szavazott. 5 felhasználó tartózkodott.

Forrás: will.com