TL; DR: Môže Haiku získať správnu podporu pre aplikačné balíky, ako sú adresáre aplikácií (napr .app na Macu) a/alebo obrázky aplikácií (Linux AppImage)? Myslím si, že by to bol hodný doplnok, ktorý sa správne implementuje ľahšie ako iné systémy, pretože väčšina infraštruktúry je už zavedená.
Objavil som Haiku, nečakane dobrý systém. No, keďže sa už dlho zaujímam o adresáre a obrázky aplikácií (inšpirované jednoduchosťou Macintosha), nie je prekvapujúce, že ma napadla myšlienka...
Pre úplné pochopenie som tvorcom a autorom AppImage, formátu distribúcie aplikácií pre Linux, ktorý sa zameriava na jednoduchosť Mac a poskytuje plnú kontrolu autorom aplikácií a koncovým používateľom (ak chcete vedieť viac, pozrite si и ).
Čo ak vytvoríme AppImage pre Haiku?
Zamyslime sa trochu, čisto teoreticky: čo je potrebné urobiť, aby sme získali , alebo niečo podobné, na Haiku? Nie je potrebné hneď niečo vytvárať, pretože systém, ktorý už v Haiku existuje, funguje úžasne, ale pomyselný experiment by bol fajn. Tiež demonštruje sofistikovanosť Haiku v porovnaní s desktopovými prostrediami Linuxu, kde sú takéto veci strašne ťažké (mám právo to povedať: bojujem s ladením už 10 rokov).
V systéme Macintosh System 1 bola každá aplikácia samostatným súborom „spravovaným“ vo Finderi. Pomocou AppImage sa snažím znovu vytvoriť rovnakú používateľskú skúsenosť v systéme Linux.
Po prvé, čo je AppImage? Ide o systém na uvoľňovanie aplikácií tretích strán (napr. ), ktorý umožňuje vydávať aplikácie, kedy a ako chcú: nie je potrebné poznať špecifiká rôznych distribúcií, budovať politiky alebo budovať infraštruktúru, nie je potrebná žiadna podpora správcu a používateľom nehovoria, čo si (ne)môžu nainštalovať na svojich počítačoch. AppImage treba chápať ako niečo podobné ako balík Mac vo formáte .app vnútri obrazu disku .dmg. Hlavný rozdiel je v tom, že aplikácie sa neskopírujú, ale navždy zostanú v AppImage, podobne ako balíčky Haiku .hpkg namontované a nikdy nenamontované v obvyklom zmysle.
V priebehu viac ako 10 rokov existencie si AppImage získal určitú príťažlivosť a popularitu: sám Linus Torvalds ho verejne podporil a bežné projekty (napríklad LibreOffice, Krita, Inkscape, Scribus, ImageMagick) ho prijali ako hlavný spôsob. na distribúciu nepretržitých alebo nočných zostavení, ktoré nezasahujú do nainštalovaných alebo odinštalovaných používateľských aplikácií. Avšak desktopové prostredia a distribúcie Linuxu sa najčastejšie stále držia tradičného, centralizovaného distribučného modelu založeného na správcoch a/alebo podporujú svoje vlastné podnikové obchodné a/alebo inžinierske programy založené na (RedHat, Fedora, GNOME) a (Kanonický, Ubuntu). Prichádza .
Ako to celé funguje
- Každý AppImage obsahuje 2 časti: malý ELF na dvojité kliknutie (tzv.
runtime.c), za ktorým nasleduje obraz systému súborov .
- Súborový systém SquashFS obsahuje užitočné zaťaženie aplikácie a všetko potrebné na jej spustenie, čo v správnom myslení nemožno považovať za súčasť predvolenej inštalácie pre každý pomerne nedávny cieľový systém (distribúcia Linuxu). Obsahuje tiež metadáta, ako je názov aplikácie, ikony, typy MIME atď.
- Keď beží používateľ, runtime používa FUSE a squashfuse na pripojenie súborového systému a potom sa stará o spustenie niektorého vstupného bodu (aka AppRun) vo vnútri pripojeného AppImage.
Po dokončení procesu sa systém súborov odpojí.
Všetko sa zdá byť jednoduché.
A tieto veci všetko komplikujú:
- Pri takom množstve distribúcií Linuxu nemožno nič „správne“ nazvať „súčasťou predvolenej inštalácie pre každý nový cieľový systém“. Tento problém riešime budovaním , čo vám umožní určiť, čo bude zabalené v AppImage a čo bude potrebné vziať niekde inde. Zároveň nám niekedy chýba, napriek tomu, že vo všeobecnosti všetko funguje skvele. Z tohto dôvodu odporúčame, aby tvorcovia balíkov testovali AppImages na všetkých cieľových systémoch (distribúciách).
- Užitočné zaťaženia aplikácie musia byť premiestniteľné v rámci systému súborov. Bohužiaľ, veľa aplikácií má pevne zakódované absolútne cesty, napríklad k zdrojom v
/usr/share. Toto treba nejako opraviť. Okrem toho musíte buď exportovaťLD_LIBRARY_PATHalebo opraviťrpathaby nakladač mohol nájsť súvisiace knižnice. Prvá metóda má svoje nevýhody (ktoré sa prekonávajú zložitými spôsobmi) a druhá je jednoducho ťažkopádna. - Najväčšou UX nástrahou pre používateľov je to Súbor AppImage po stiahnutí. Verte či nie, pre niektorých je to skutočná prekážka. Potreba nastaviť bit spustiteľnosti je ťažkopádna aj pre skúsených používateľov. Ako riešenie sme navrhli inštaláciu malej služby, ktorá monitoruje súbory AppImage a nastavuje ich bit spustiteľnosti. Vo svojej čistej forme to nie je najlepšie riešenie, pretože to nebude fungovať hneď po vybalení. Linuxové distribúcie túto službu neposkytujú, preto majú používatelia zlú skúsenosť hneď po vybalení.
- Používatelia Linuxu očakávajú, že nová aplikácia bude mať ikonu v úvodnej ponuke. Systému nemôžete povedať: "Pozri, je tu nová aplikácia, poďme pracovať." Namiesto toho, podľa špecifikácie XDG, musíte skopírovať súbor
.desktopna správne miesto v/usrpre celosystémovú inštaláciu alebo v$HOMEpre jednotlivca. Ikony určitých veľkostí podľa špecifikácie XDG musia byť umiestnené na určitých miestach vusralebo$HOMEa potom spustite príkazy v pracovnom prostredí na aktualizáciu vyrovnávacej pamäte ikon alebo dúfajte, že správca pracovného prostredia na to príde a automaticky všetko zistí. To isté s typmi MIME. Ako riešenie sa navrhuje použiť rovnakú službu, ktorá okrem nastavenia príznaku spustiteľnosti bude, ak existujú ikony atď. v AppImage ich skopírujte z AppImage na správne miesta podľa XDG. Po odstránení alebo premiestnení sa očakáva, že služba vymaže všetko. Samozrejme, existujú rozdiely v správaní každého pracovného prostredia, vo formátoch grafických súborov, ich veľkostiach, miestach uloženia a spôsoboch aktualizácie vyrovnávacej pamäte, čo vytvára problém. Tento spôsob je skrátka barličkou. - Ak vyššie uvedené nestačí, v správcovi súborov stále nie je ikona AppImage. Svet Linuxu sa ešte nerozhodol implementovať elficon (napriek и ), takže ikonu nie je možné vložiť priamo do aplikácie. Ukazuje sa teda, že aplikácie v správcovi súborov nemajú svoje vlastné ikony (bez rozdielu, AppImage alebo niečo iné), sú iba v ponuke štart. Ako riešenie používame miniatúry, mechanizmus, ktorý bol pôvodne navrhnutý tak, aby umožnil správcom pracovnej plochy zobrazovať náhľady obrázkov grafických súborov ako ich ikony. V dôsledku toho služba na nastavenie bitu spustiteľnosti funguje aj ako „miniaturizátor“ a vytvára a zapisuje miniatúry ikon na príslušné miesta.
/usrи$HOME. Táto služba tiež vykoná vyčistenie, ak sa AppImage odstráni alebo presunie. Vzhľadom na to, že každý správca pracovnej plochy sa správa mierne odlišne, napríklad v akých formátoch prijíma ikony, v akých veľkostiach či miestach, je to všetko naozaj bolestivé. - Aplikácia jednoducho zlyhá pri spustení, ak sa vyskytnú chyby (napríklad existuje knižnica, ktorá nie je súčasťou základného systému a nie je dodávaná v AppImage) a v GUI nie je nikto, kto by používateľovi povedal, čo sa presne deje. Začali sme to obchádzať používaním na ploche, čo znamená, že potrebujeme zachytiť chyby z príkazového riadku, previesť ich na správy zrozumiteľné pre používateľa, ktoré je potom potrebné zobraziť na ploche. A samozrejme, každé desktopové prostredie s nimi narába trochu inak.
- Momentálne (september 2019 – pozn. prekladateľa) som nenašiel jednoduchý spôsob, ako povedať systému, že súbor
1.pngmusia byť otvorené pomocou Krity a2.png- pomocou GIMPu.
Miesto úložiska pre špecifikácie naprieč počítačmi používané v , и je freedesktop.org
Dosiahnutie úrovne sofistikovanosti, ktorá je hlboko votkaná do pracovného prostredia Haiku, je ťažké, ak nie nemožné, vzhľadom na špecifikácie pre cross-desktop, ako aj implementácie desktopových manažérov na základe týchto špecifikácií. Ako príklad môžeme uviesť jednu celosystémovú ikonu Firefoxu: očividne autori XDG ani nepomysleli na to, že používateľ môže mať nainštalovaných niekoľko verzií tej istej aplikácie.
Ikony pre rôzne verzie Firefoxu
Zaujímalo by ma, čo by sa svet Linuxu mohol naučiť od systému Mac OS X, aby sa zabránilo pokazeniu systémovej integrácie. Ak máte čas a venujete sa tomu, určite si prečítajte, čo povedal Arnaud Gurdol, jeden z prvých inžinierov Mac OS X:
Chceli sme, aby inštalácia aplikácie bola taká jednoduchá ako pretiahnutie ikony aplikácie odniekiaľ (server, externý disk) na disk počítača. Aby to bolo možné, balík aplikácie ukladá všetky informácie vrátane ikon, verzie, typu spracovávaného súboru, typu schém URL, ktoré systém potrebuje poznať na spracovanie aplikácie. Patria sem aj informácie pre „centrálne úložisko“ v databáze Icon Services a Launch Services. Na podporu výkonu sú aplikácie „objavené“ na niekoľkých „známych“ miestach: v systémových a používateľských adresároch aplikácií a na niektorých ďalších automaticky, ak používateľ prejde na Finder v adresári obsahujúcom aplikáciu. V praxi to fungovalo veľmi dobre.
Apple WWDC 2000 session 144 - Mac OS X: balenie aplikácií a tlač dokumentov.
Na linuxových desktopoch nie je nič podobné ako táto infraštruktúra, preto hľadáme riešenia štrukturálnych obmedzení v projekte AppImage.
Prichádza Haiku na záchranu?
A ešte jedna vec: Linuxové platformy ako základ desktopových prostredí majú tendenciu byť tak málo špecifikované, že mnohé veci, ktoré sú v konzistentnom full-stack systéme celkom jednoduché, sú v Linuxe frustrujúco roztrieštené a zložité. Celú správu som venoval problémom spojeným s platformou Linux pre desktopové prostredia (znalí vývojári potvrdili, že všetko takto zostane veľmi dlho).
Moja správa o problémoch desktopových prostredí Linuxu v roku 2018
Dokonca aj Linus Torvalds priznal, že fragmentácia bola dôvodom, prečo myšlienka pracovného priestoru zlyhala.
Rád vidím Haiku!
Haiku robí všetko úžasne jednoduchým
Zatiaľ čo naivným prístupom k „portovaniu“ AppImage na Haiku je jednoducho pokúsiť sa zostaviť (hlavne runtime.c a servis) jeho komponenty (čo môže byť dokonca možné!), Haiku to neprinesie veľa výhod. Pretože v skutočnosti je väčšina týchto problémov vyriešená v Haiku a sú koncepčne správne. Haiku poskytuje presne tie stavebné bloky systémovej infraštruktúry, ktoré som tak dlho hľadal v desktopových prostrediach Linuxu a neveril som, že neexistujú. menovite:
Verte tomu alebo nie, toto je niečo, čo mnohí používatelia Linuxu nedokážu prekonať. Na Haiku sa všetko robí automaticky!
- Súbory ELF, ktoré nemajú bit spustiteľnosti, ho získajú automaticky po dvojitom kliknutí v správcovi súborov.
- Aplikácie môžu mať vstavané prostriedky, ako sú ikony, ktoré sa zobrazujú v správcovi súborov. Nie je potrebné kopírovať kopu obrázkov do špeciálnych adresárov s ikonami, a teda ani upratovať po odstránení alebo presune aplikácie.
- Existuje databáza na prepojenie aplikácií s dokumentmi, na to nie je potrebné kopírovať žiadne súbory.
- V adresári lib/ vedľa spustiteľného súboru sa štandardne vyhľadávajú knižnice.
- Neexistujú žiadne početné distribúcie a desktopové prostredia; čokoľvek funguje, funguje všade.
- Neexistuje žiadny samostatný modul na spustenie, ktorý by sa líšil od adresára Applications.
- Aplikácie nemajú vstavané absolútne cesty k svojim prostriedkom, majú špeciálne funkcie na určenie polohy za behu.
- Bola predstavená myšlienka komprimovaných obrazov systému súborov: ide o akýkoľvek balík hpkg. Všetky sú namontované jadrom.
- Každý súbor otvára aplikácia, ktorá ho vytvorila, pokiaľ výslovne nešpecifikujete inak. Aké je to skvelé!
Dva súbory png. Všimnite si rôzne ikony, ktoré označujú, že ich po dvojitom kliknutí otvoria rôzne aplikácie. Všimnite si tiež rozbaľovaciu ponuku „Otvoriť pomocou:“, kde si používateľ môže vybrať individuálnu aplikáciu. Aké jednoduché!
Vyzerá to tak, že mnohé barličky a riešenia, ktoré vyžaduje AppImage na Linuxe, sa stávajú zbytočnými na Haiku, ktorého jadro je jednoduchosť a sofistikovanosť, vďaka ktorej zvládne väčšinu našich potrieb.
Potrebuje Haiku predsa balíky aplikácií?
To vedie k veľkej otázke. Ak by bolo o rádovo jednoduchšie vytvoriť systém ako AppImage na Haiku ako na Linuxe, stálo by to za to? Alebo Haiku so systémom balíkov hpkg účinne eliminovalo potrebu rozvíjať takýto nápad? Aby sme odpovedali, musíme sa pozrieť na motiváciu existencie AppImages.
Pohľad užívateľa
Pozrime sa na nášho koncového používateľa:
- Chcem nainštalovať aplikáciu bez toho, aby som požadoval heslo správcu (root). Na Haiku neexistuje pojem správcu, používateľ má plnú kontrolu, keďže ide o osobný systém! (V princípe si to viete predstaviť v režime pre viacerých hráčov, dúfam, že to vývojári ponechajú jednoduché)
- Chcem získať najnovšie a najlepšie verzie aplikácií bez toho, aby som čakal, kým sa objavia v mojej distribúcii (najčastejšie to znamená „nikdy“, aspoň pokiaľ neaktualizujem celý operačný systém). Na Haiku je to „riešené“ plávajúcimi vydaniami. To znamená, že je možné získať najnovšie a najlepšie verzie aplikácií, ale aby ste to dosiahli, musíte neustále aktualizovať zvyšok systému a efektívne ho premeniť na „pohyblivý cieľ“.
- Chcem niekoľko verzií tej istej aplikácie vedľa seba, pretože neexistuje spôsob, ako zistiť, čo bolo v najnovšej verzii poškodené, alebo, povedzme, ja ako webový vývojár potrebujem otestovať svoju prácu v rôznych verziách prehliadača. Haiku rieši prvý problém, ale nie druhý. Aktualizácie sú vrátené, ale len pre celý systém, nie je možné (pokiaľ viem) spustiť napríklad viacero verzií WebPositive alebo LibreOffice súčasne.
Jeden z vývojárov píše:
Zdôvodnenie je v podstate toto: prípad použitia je taký zriedkavý, že optimalizácia preň nedáva zmysel; považovať to za špeciálny prípad v HaikuPorts sa zdá byť viac než prijateľné.
- Potrebujem mať aplikácie tam, kde sa mi páčia, nie na štartovacej jednotke. Často mi dochádza miesto na disku, takže potrebujem pripojiť externý disk alebo sieťový adresár na uloženie aplikácií (všetky verzie, ktoré mám stiahnuté). Ak pripojím takýto disk, potrebujem, aby sa aplikácie spúšťali dvojitým kliknutím. Haiku ukladá staré verzie balíkov, ale neviem, ako ich presunúť na externý disk, ani ako odtiaľ neskôr spúšťať aplikácie.
Komentár vývojára:
Technicky je to už možné pomocou príkazu mount. Samozrejme, vytvoríme na to GUI hneď, ako budeme mať dostatok zainteresovaných používateľov.
- Nepotrebujem milióny súborov roztrúsených po súborovom systéme, ktoré nemôžem manuálne spravovať. Chcem jeden súbor na aplikáciu, ktorý si môžem jednoducho stiahnuť, presunúť, odstrániť. Na Haiku je tento problém vyriešený pomocou balíkov
.hpkg, ktoré prenášajú napríklad python z tisícov súborov do jedného. Ale ak existuje napríklad Scribus používajúci python, potom sa musím zaoberať aspoň dvoma súbormi. A musím sa postarať o to, aby som zachoval ich verzie, ktoré spolu fungujú.
Viaceré verzie AppImages bežia vedľa seba na rovnakom Linuxe
Pohľad vývojára aplikácie
Pozrime sa na to z pohľadu vývojára aplikácie:
- Chcem mať pod kontrolou celú používateľskú skúsenosť. Nechcem sa spoliehať na operačný systém, ktorý mi hovorí, kedy a ako mám vydať aplikácie. Haiku umožňuje vývojárom pracovať s ich vlastnými repozitármi hpkg, ale to znamená, že ich používatelia budú musieť nastaviť manuálne, čo robí túto myšlienku „menej atraktívnou“.
- Na svojej webovej stránke mám stránku na stiahnutie, kde ju distribuujem
.exepre Windows,.dmgpre Mac a.AppImagepre Linux. Alebo možno chcem speňažiť prístup na túto stránku, je možné čokoľvek? Čo tam mám dať za Haiku? Súbor stačí.hpkgso závislosťami iba od HaikuPorts - Môj softvér vyžaduje špecifické verzie iného softvéru. Napríklad je známe, že Krita vyžaduje opravenú verziu Qt alebo Qt, ktorá je doladená na konkrétnu verziu Krity, aspoň kým sa záplaty nevložia späť do Qt. Môžete si zabaliť svoje vlastné Qt pre vašu aplikáciu do balíka
.hpkg, ale s najväčšou pravdepodobnosťou to nie je vítané.
Pravidelná stránka na stiahnutie aplikácie. Čo by som tu mal uverejniť pre Haiku?
Bude zväzky (existujúce ako adresáre aplikácií ako AppDir alebo .app v štýle Apple) a/alebo obrázky (vo forme výrazne upravených AppImages resp .dmg od Apple) aplikácie užitočným doplnkom k desktopovému prostrediu Haiku? Alebo to rozriedi celý obraz a povedie k fragmentácii, a teda pridá na zložitosti? Som na roztrhanie: na jednej strane je krása a sofistikovanosť Haiku založená na skutočnosti, že zvyčajne existuje jeden spôsob, ako niečo urobiť, a nie veľa. Na druhej strane, väčšina infraštruktúry pre katalógy a/alebo balíky aplikácií je už na svojom mieste, takže systém kričí, aby sa zvyšných pár percent dostalo na miesto.
Podľa vývojára
Na Linuxe sú (katalógy a aplikačné súpravy, - cca. prekladateľ) sú s najväčšou pravdepodobnosťou technickým riešením systémových problémov. V Haiku uprednostňujeme jednoduché riešenie systémových problémov.
Co si myslis?
Skôr ako odpovieš...
Počkajte, urobme rýchlu kontrolu reality: v skutočnosti adresáre aplikácií - už súčasťou Haiku:
Adresáre aplikácií už na Haiku existujú, ale ešte nie sú podporované v správcovi súborov
Len nie sú tak dobre podporované ako napríklad Macintosh Finder. Aké skvelé by bolo, keby adresár QtCreator mal v ľavom hornom rohu názov a ikonu „QtCreator“, ktorá spustí aplikáciu po dvojitom kliknutí?
Ja už trochu skôr :
Ste si istý, že môžete spustiť svoje desaťročie staré aplikácie dnes, keď na ne a ich závislosti zabudli všetky obchody s aplikáciami a distribučné úložiská? Ste si istý, že v budúcnosti budete mať stále prístup k svojej súčasnej práci?
Existuje už odpoveď z Haiku alebo tu môžu pomôcť katalógy a balíky aplikácií? Myslím, že môžu.
Podľa p. waddlesplash:
Áno, máme odpoveď na otázku: jednoducho budeme tieto aplikácie podporovať tak dlho, ako to bude potrebné, kým niekto nebude vedieť čítať ich formáty súborov správnym spôsobom alebo poskytovať funkcie one-to-one. Náš záväzok podporovať aplikácie BeOS R5 na Haiku je toho dôkazom...
To je isté!
Aký postup by mal Haiku prijať?
Viem si predstaviť pokojnú koexistenciu hpkg, adresárov a obrázkov aplikácií:
- Použitie systémového softvéru
.hpkg - V prípade najčastejšie používaného softvéru (najmä tých, ktoré potrebujú naplánovať priebežné vydania), použite
.hpkg(približne 80 % všetkých prípadov) - Niektoré nainštalované cez
.hpkg, budú aplikácie profitovať z presunu do aplikačnej adresárovej infraštruktúry (napr. QtCreator): budú distribuované ako.hpkg, ako predtým.
Pán. waddlesplash píše:
Ak všetko, čo potrebujete, je zobraziť aplikácie v
/system/apps, namiesto toho by sme mali spraviť adresáre na Deskbare pre používateľov lepšie spravovateľné, pretože/system/appsnie je určený na pravidelné otváranie a prezeranie používateľom (na rozdiel od MacOS). Pre takéto situácie má Haiku inú paradigmu, ale táto možnosť je teoreticky prijateľná.
- Haiku dostáva infraštruktúru na spúšťanie obrazov aplikácií, nočné, nepretržité a testovacie zostavy softvéru, ako aj pre prípady, keď ho chce používateľ „zmraziť v čase“, pre súkromný a interný softvér a iné špeciálne prípady použitia (asi 20 % zo všetkých). Tieto obrázky obsahujú súbory potrebné na spustenie aplikácie
.hpkg, namontované systémom a po dokončení aplikácie - odpojené. (Možno správca súborov môže umiestniť súbory.hpkgdo obrázkov aplikácií, automaticky alebo na žiadosť používateľa – dobre, ako keď pretiahnete aplikáciu do sieťového adresára alebo na externý disk. Je to len pieseň! Alebo skôr poézia - haiku.) Na druhej strane používateľ môže chcieť nainštalovať obsah obrázka vo forme súborov.hpkg, po ktorom budú aktualizované a spracované rovnakým spôsobom, ako keby boli nainštalované cez HaikuDepot... Potrebujeme brainstorming).
Citát od p. waddlesplash:
Spúšťanie aplikácií z externých diskov alebo sieťových adresárov môže byť potenciálne užitočné. A pridanie možnosti konfigurovať viac „zón“ pre pkgman by bola určite príjemná funkcia.
Takýto systém by využíval hpkg, adresáre a obrazy aplikácií. Sú dobrí jednotlivo, ale spolu sa stanú neporaziteľnými.
Záver
Haiku má rámec, ktorý poskytuje jednoduchú a sofistikovanú používateľskú skúsenosť pre PC a ďaleko presahuje rámec toho, čo sa zvyčajne poskytuje pre PC so systémom Linux. Balíkový systém .hpkg je jedným z takýchto príkladov, ale zvyšok systému je tiež presiaknutý sofistikovanosťou. Haiku by však prospela správna podpora adresárov a obrázkov aplikácií. O tom, ako to najlepšie urobiť, stojí za to diskutovať s ľuďmi, ktorí poznajú Haiku, jeho filozofiu a architektúru oveľa lepšie ako ja. Predsa len, Haiku používam niečo vyše týždňa. Napriek tomu verím, že dizajnéri, vývojári a architekti Haiku budú ťažiť z tejto novej perspektívy. Prinajmenšom by som bol šťastný, keby som bol ich „sparring partnerom“. Mám viac ako 10 rokov praktických skúseností s katalógmi a balíkmi linuxových aplikácií a rád by som pre ne našiel využitie v Haiku, ku ktorému sa podľa mňa perfektne hodia. Potenciálne riešenia, ktoré som navrhol, nie sú ani zďaleka jediné správne pre problémy, ktoré som opísal, a ak sa tím Haiku rozhodne nájsť iné, elegantnejšie, som za to. V podstate už rozmýšľam nad myšlienkou, ako urobiť systém hpkg ešte úžasnejšie bez zmeny spôsobu, akým to funguje. Ukazuje sa, že tím Haiku pri implementácii systému správy balíkov dlho premýšľal o balíkoch aplikácií, ale bohužiaľ (myslím) sa tento nápad stal „zastaraným“. Možno je čas ho oživiť?
Skúste to sami! Koniec koncov, projekt Haiku poskytuje vygenerované obrázky na zavedenie z DVD alebo USB .
Máte nejaké otázky? Pozývame vás na rusky hovoriaci .
Prehľad chýb:
Od preklad: toto je ôsmy a posledný článok zo série o Haiku.
Zoznam článkov:
Do prieskumu sa môžu zapojiť iba registrovaní užívatelia. Prosím.
Má zmysel portovať systém hpkg na Linux?
-
Да
-
Nie
-
Už implementované, napíšem do komentárov
Hlasovalo 20 užívateľov. 5 užívateľov sa zdržalo hlasovania.
Zdroj: hab.com