🥇Altceva: pachete de aplicații Haiku?

TL;DR: poate Haiku să primească suportul adecvat pentru pachetele de aplicații, de exemplu catalogul de aplicații (ca în .app Mac) și/sau imaginile de aplicații (Linux AppImage)? Mi se pare că ar fi o adăugire demnă, care ar fi mai ușor de implementat decât în alte sisteme, deoarece mare parte din infrastructură există deja.

Acum o săptămână am descoperit Haiku, un sistem surprinzător de bun. Și cum mă interesează de mult timp modulele și imaginile de aplicații (inspirate de simplitatea Macintosh), nu este de mirare că mi-a venit această idee...

Pentru o înțelegere completă: sunt creatorul și autorul AppImage, un format de distribuție a aplicațiilor Linux, destinat simplității Mac și oferind control total autorilor de aplicații și utilizatorilor finali (doriți să știți mai multe - vizitați wiki și documentație).

Ce-ar fi dacă am crea AppImage pentru Haiku?

Să ne gândim puțin, pur teoretic, ce ar fi nevoie pentru a obține AppImage, sau ceva similar, pe Haiku? Nu este nevoie să creăm ceva chiar acum, deoarece sistemul care există deja în Haiku funcționează uimitor, iar un experiment imaginar ar fi interesant. De asemenea, ar demonstra rafinamentul Haiku, în comparație cu mediile de lucru Linux, unde astfel de lucruri sunt extrem de dificile (am dreptul să vorbesc astfel: mă lupt cu debuggerea de 10 ani).

Pe Macintosh System 1, fiecare aplicație era un fișier separat, „gestionat” în Finder. Folosind AppImage încerc să recreez aceeași experiență utilizator pe Linux.

În primul rând, ce este AppImage? Este un sistem pentru lansarea aplicațiilor dezvoltatorilor terți (de exemplu, Ultimaker Cura), care permite lansarea aplicațiilor, când și cum doresc: nu este nevoie să cunoască particularitățile diferitelor distribuții, politicile de construire sau infrastructura de construire, nu este necesară suportul celor care acompaniază, iar ei nu le spun utilizatorilor ce (nu) pot instala pe computerele lor. AppImage ar trebui să fie înțeles ca ceva similar cu un pachet pentru Mac în formatul .app în interiorul imaginii de disc .dmg. Principala diferență este că aplicațiile nu sunt copiate, ci rămân întotdeauna în interiorul AppImage, la fel ca pachetele Haiku .hpkg se montează și nu sunt niciodată instalate în sensul obișnuit.

AppImage a câștigat o oarecare atractivitate și popularitate în cei peste 10 ani de existență: însuși Linus Torvalds l-a aprobat public, iar proiectele bine cunoscute (de exemplu, LibreOffice, Krita, Inkscape, Scribus, ImageMagick) l-au adoptat ca principal mod de distribuire a versiunilor continue sau nightly builds, care nu interferează cu aplicațiile instalate sau neinstalate ale utilizatorilor. Cu toate acestea, mediile de lucru și distribuțiile Linux se agățau adesea de modelul tradițional, centralizat de distribuire bazat pe programe asociate și/sau promovau propriile programe de afaceri și/sau inginerie, Flatpak (RedHat, Fedora, GNOME) și Snappy (Canonical, Ubuntu). Se ajunge la ridicol.

Cum funcționează totul

Fiecare AppImage conține 2 părți: un ELF executabil mic (numit runtime.c), urmat de imaginea sistemului de fișiere SquashFS.

Sistemul de fișiere SquashFS conține sarcina utilă sub formă de aplicație și tot ceea ce este necesar pentru a o rula, care în mod rezonabil nu ar trebui considerat parte a instalării implicite pentru fiecare sistem țintă (distribuție Linux) suficient de recent. De asemenea, conține metadate, de exemplu, numele aplicației, pictograme, tipuri MIME și alte informații.

La rulare, runtime-ul folosește FUSE și squashfuse pentru a monta sistemul de fișiere, apoi procesează lansarea unui anumit punct de intrare (numit AppRun) în cadrul AppImage-ului montat.
Sistemul de fișiere este demontat după ce procesul s-a încheiat.

Pare simplu.

Și aceste lucruri complică totul:

cu această diversitate de distribuții Linux, deja nimic «în mod rezonabil» nu poate fi numit «parte a instalării implicite pentru fiecare sistem țintă recent». Ocolim această problemă prin construirea unei excludelist, care permite determinarea a ceea ce va fi împachetat în AppImage și ce trebuie să fie preluat din altă parte. Totuși, uneori ne ratăm, în ciuda faptului că, în general, totul funcționează excelent. Din acest motiv, recomandăm creatorilor de pachete să testeze AppImages pe toate sistemele țintă (distribuții).
Aplicațiile ca sarcină utilă trebuie să fie portabile în sistemul de fișiere. Din păcate, în multe aplicații sunt setate drumuri absolute către, de exemplu, resurse în /usr/share. Trebuie să corectăm asta cumva. În plus, trebuie ori să exportăm LD_LIBRARY_PATH, ori să corectăm rpath pentru ca încărcătorul să poată găsi bibliotecile asociate. Prima metodă are dezavantajele sale (care sunt compensate prin metode complexe), iar a doua pur și simplu voluminoasă.
Cea mai mare capcană UX pentru utilizatori este că trebuie să setăm bitul executabil fișierului AppImage după descărcare. Vrei să crezi, vrei să nu, dar pentru unii acesta reprezintă un real obstacol. Necesitatea setării bitului de executabilitate este complicată chiar și pentru utilizatorii experimentați. Ca soluție alternativă, am propus instalarea unui mic serviciu care monitorizează fișierele AppImage și le setează bitul de executabilitate. În forma sa pură, nu este cea mai bună soluție, deoarece nu va funcționa „din cutie”. Distribuțiile Linux nu furnizează acest serviciu, prin urmare, utilizatorii „din cutie” au probleme.
Utilizatorii Linux se așteaptă ca o nouă aplicație să aibă o iconiță în meniul de lansare. Sistemului nu îi poți spune: „Uite, o nouă aplicație, hai să lucrăm”. În schimb, conform specificației XDG, trebuie să copiem fișierul .desktop în locul corespunzător în /usr pentru o instalare de sistem comună, sau în $HOME pentru individuală. Iconițele de dimensiuni specifice, conform specificației XDG, trebuie plasate în anumite locuri în usr sau $HOME, după care trebuie să rulezi comenzi în mediu pentru a actualiza cache-ul iconițelor, sau să speri că managerul de mediu va înțelege și va descoperi totul automat. La fel și pentru tipurile MIME. Ca soluție alternativă se recomandă folosirea aceluiași serviciu, care, pe lângă setarea bitului de executabilitate, va copia iconițele și alte resurse din AppImage în locurile corespunzătoare conform XDG. La ștergere sau mutare, serviciul ar trebui să curețe tot. Desigur, există diferențe în comportamentul fiecărui mediu de lucru, în formatele fișierelor grafice, dimensiunile acestora, locurile de stocare și modul de actualizare a cache-urilor, ceea ce generează problema. Pe scurt, această metodă este un workaround.
Dacă cele de mai sus nu sunt suficiente, în managerul de fișiere nu există nici o iconiță pentru AppImage. În lumea Linux, nu s-a ajuns încă la o decizie privind implementarea elficon (în ciuda faptului că... s-a dezactivat și implementare), deci nu este posibil să încorporăm o pictogramă direct în aplicație. Astfel, aplicațiile din managerul de fișiere nu au pictograme proprii (indiferent dacă este vorba despre AppImage sau altceva), ele există doar în meniul de lansare. Ca soluție, aplicăm miniaturile - un mecanism care a fost conceput inițial pentru ca managerii de desktop să poată afișa imagini reduse pentru previzualizarea fișierelor grafice ca pictograme. Prin urmare, serviciul pentru instalarea bitului de executabil funcționează și ca un „miniaturizator”, creând și salvând miniaturile pictogramelor în locurile corespunzătoare. /usr și $HOME. De asemenea, acest serviciu efectuează curățarea dacă AppImage este șters sau mutat. Deoarece fiecare manager de desktop se comportă puțin diferit, de exemplu, în ce formate acceptă pictogramele, în ce dimensiuni sau locații, totul devine cu adevărat problematic.
Aplicația pur și simplu se oprește în timpul execuției, dacă apar erori (de exemplu, există o bibliotecă care nu face parte din sistemul de bază și nu este livrată în AppImage), iar nimeni nu informează utilizatorul în GUI despre ceea ce se întâmplă. Am început să evităm acest lucru, folosind de către dezvoltatorii listei de blocare EasyPrivacy, a fost pe desktop, ceea ce înseamnă că trebuie să prindem erorile din linia de comandă, să le transformăm în mesaje ușor de înțeles pentru utilizator, care mai apoi trebuie afișate pe desktop. Și, desigur, fiecare mediu de lucru le gestionează puțin diferit.
În prezent (septembrie 2019, - nota traductorului), nu am găsit o modalitate simplă de a spune sistemului că fișierul 1.png trebuie deschis cu Krita, iar 2.png — cu GIMP.

Locația de stocare a specificațiilor cross-desktop, utilizate în GNOME, KDE și Xfce este freedesktop.org

Atingerea unui nivel de rafinament, profund înrădăcinat în mediul de lucru Haiku, este dificilă, dacă nu chiar „imposibilă”, din cauza specificațiilor XDG de la freedesktop.org pentru cross-desktop, precum și a implementărilor managerilor de desktop bazate pe aceste specificații. Ca exemplu, putem menționa o pictogramă comună a sistemului pentru Firefox: evident, autorii XDG nu s-au gândit că utilizatorul ar putea avea instalate mai multe versiuni ale aceleași aplicații.

Pictogramele diferitelor versiuni de Firefox

M-a interesat ce ar putea învăța lumea Linux de la Mac OS X pentru a nu greși în integrarea sistemelor. Dacă aveți timp și vă ocupați de așa ceva — citiți neapărat ce a spus Arno Gourdoll, unul dintre primii ingineri Mac OS X:

Am dorit ca instalarea aplicației să fie la fel de simplă ca și tragerea pictogramei aplicației de undeva (server, disc extern) pe discul computerului dumneavoastră. Pentru aceasta, în pachetul aplicației este salvată toată informația, inclusiv pictogramele, versiunea, tipul de fișier procesat, tipul de schemă URL pe care sistemul trebuie să o cunoască pentru a procesa aplicația. Aceasta include și informația pentru ‘stocarea centralizată’ în baza de date Icon Services și Launch Services. Pentru a susține performanța aplicației, acestea sunt ‘descoperite’ în mai multe locații ‘bine cunoscute’: în directorul sistemului și al utilizatorului Applications, precum și în alte locații automat, dacă utilizatorul a navigat în Finder într-un director care conține aplicația. În practică, acest mecanism a funcționat foarte bine.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 sesiunea 144 — Mac OS X: ambalarea aplicațiilor și imprimarea documentelor.

Nimic similar din această infrastructură nu există în mediile de lucru Linux, așa că căutăm soluții alternative pentru a depăși limitările structurale în proiectul AppImage.

Oare Haiku este pe cale să vină în ajutor?

De asemenea: platformele Linux ca bază pentru mediile de lucru sunt, în general, atât de slab specificate, încât multe lucruri care sunt foarte simple într-un sistem coerent cu un întreg stivă, se confruntă cu frustrare din cauza fragmentării și complexității în Linux. Am dedicat o întreagă prezentare problemelor legate de platforma Linux pentru mediile de lucru (dezvoltatorii experimentați au confirmat: totul va rămâne așa pentru mult timp).

Prezentarea mea despre problemele mediilor de lucru Linux în 2018

Chiar și Linus Torvalds a recunoscut că anume din cauza fragmentării, ideea mediilor de lucru nu a reușit.

Este plăcut să văd Haiku!

Cu Haiku, totul devine incredibil de simplu

Deși abordarea naivă de „portare” a AppImage pe Haiku constă în încercarea simplă de a construi (în principal runtime.c și componentele serviciului) acestea (ceea ce ar putea fi chiar posibil!), nu va aduce un mare beneficiu pentru Haiku. Deoarece, de fapt, majoritatea acestor probleme sunt deja rezolvate pe Haiku și sunt fundamentate conceptual. Haiku oferă exact acele componente de infrastructură de sistem pe care le căutam cu atâta timp în medii de lucru pe Linux și nu puteam să cred că nu le există acolo. Adică:

Credeți sau nu, dar acest lucru nu poate fi depășit de mulți utilizatori Linux. Pe Haiku totul se face automat!

Fișierele ELF care nu au bitul de execuție îl obțin automat la o dublă clic în managerul de fișiere.
Aplicațiile pot avea resurse integrate, cum ar fi pictogramele, care sunt afișate în managerul de fișiere. Nu este nevoie să copiați o grămadă de imagini în directoare speciale cu pictograme, așa că nu trebuie să le curățați după ștergerea sau mutarea aplicației.
Există o bază de date pentru asocierea aplicațiilor cu documentele, nu este necesar să copiați vreun fișier pentru aceasta.
Librăriile sunt căutate în mod implicit în directorul lib/ lângă fișierul executabil.
Nu există numeroase distribuții și medii desktop, tot ce funcționează — funcționează peste tot.
Nu există un modul separat pentru lansare, care să fie diferit de directorul Applications.
Aplicațiile nu au căi absolute încorporate către resursele lor, există funcții speciale pentru determinarea locației în timpul execuției.
A fost implementată ideea de imagini de sistem de fișiere comprimate: orice pachet hpkg. Toate acestea sunt montate de nucleu.
Fiecare fișier este deschis de aplicația care l-a creat, dacă nu se specifică explicit altceva. Ce minunat este asta!

Două fișiere png. Observați pictogramele diferite, care arată că acestea vor fi deschise de aplicații diferite printr-o dublă clic. De asemenea, observați meniul derulant „Deschide cu:”, unde utilizatorul poate alege o aplicație separată. Ce simplu!

Se pare că multe soluții și ocoliri necesare pentru AppImage pe Linux devin inutile pe Haiku, care are în baza sa simplitatea și rafinamentul cu care face față celor mai multe nevoi ale noastre.

Sunt necesare, în cele din urmă, pachete de aplicații pentru Haiku?

Aceasta ne duce la o întrebare importantă. Dacă ar fi mai ușor să creăm un sistem de tip AppImage pe Haiku comparativ cu Linux, ar merita să ne ocupăm de aceasta? Sau Haiku, cu sistemul său de pachete hpkg, a eliminat practic necesitatea dezvoltării unei idei de acest gen? Ei bine, pentru a răspunde trebuie să ne uităm la motivația existenței AppImages.

O perspectivă din partea utilizatorului

Să ne uităm la utilizatorul final:

Vreau să instalez o aplicație fără a solicita parola de administrator (root). Pe Haiku nu există noțiunea de administrator, utilizatorul are control total, deoarece este un sistem personal! (În principiu, se poate imagina și în modul multi-utilizator, sper că dezvoltatorii vor păstra simplitatea)
Vreau să primesc cele mai recente și cele mai bune versiuni ale aplicațiilor, fără a aștepta să apară în distribuitorul meu (cel mai adesea asta înseamnă „niciodată”, cel puțin dacă nu actualizez întreaga operațiune). Pe Haiku, acest lucru este „rezolvat” prin lansări flotante. Asta înseamnă că există posibilitatea de a obține cele mai recente și cele mai bune versiuni ale aplicațiilor, dar pentru aceasta trebuie să actualizezi constant și restul sistemului, transformându-l practic într-o „țintă în mișcare”..
Îmi doresc mai multe versiuni ale aceleași aplicații alături, deoarece nu poți ști ce a fost stricat în ultima versiune sau, de exemplu, ca dezvoltator web, trebuie să-mi verific munca pe diferite versiuni de browser. Pe Haiku, prima problemă este rezolvată, dar nu și a doua. Actualizările se pot desfășura, dar doar pentru întreaga sistem, nu este posibil (cât știu) să rulez, de exemplu, mai multe versiuni de WebPositive sau LibreOffice simultan.

Unul dintre dezvoltatori scrie:

În esență, justificarea este aceasta: scenariul de utilizare este atât de rar, încât optimizarea pentru el nu are sens; tratamentul acestuia ca un caz special în HaikuPorts pare mai mult decât acceptabil.

Trebuie să pot salva aplicațiile acolo unde îmi place, nu pe discul de boot. Pe discuri, de multe ori îmi lipsește spațiu, astfel încât trebuie să contectez un disc extern sau un director de rețea pentru a stoca aplicațiile (toate versiunile pe care le-am descărcat). Dacă conectez un astfel de disc, aplicațiile trebuie să se deschidă prin dublu clic. Haiku păstrează versiunile mai vechi ale pachetelor, dar nu știu cum să le mut pe un disc extern și, de asemenea, cum să pornesc aplicațiile de acolo.

Comentariul dezvoltatorului:

Tehnic, acest lucru este deja posibil cu echipa mount. Desigur, vom face un GUI pentru asta, odată ce se adună suficienți utilizatori interesați.

Nu am nevoie de milioane de fișiere împrăștiate în sistemul de fișiere, pe care nu pot să le gestionez manual. Vreau un singur fișier pentru aplicație, pe care să-l pot descărca, muta, șterge cu ușurință. Pe Haiku, această problemă este rezolvată prin intermediul pachetelor .hpkg, care centralizează, de exemplu, python, din mii de fișiere într-unul. Dar dacă există, de exemplu, Scribus, care utilizează python, atunci trebuie să mă ocup de minimum două fișiere. Și trebuie să mă asigur că păstrez versiunile care funcționează împreună.

Numeroase versiuni AppImages, rulate simultan pe un singur Linux

Perspectivele din partea dezvoltatorului de aplicații

Să analizăm din perspectiva dezvoltatorului de aplicații:

Vreau să controlez complet experiența utilizatorului. Nu vreau să depind de sistemul de operare care îmi spune când și cum trebuie să lansez aplicațiile. Pe Haiku, dezvoltatorii pot lucra cu propriile lor repozitorii hpkg, dar asta înseamnă că utilizatorii trebuie să le configureze manual, ceea ce face această idee «mai puțin atractivă».
Am o pagină de descărcări pe site-ul meu, unde distribuie .exe pentru Windows, .dmg pentru Mac și .AppImage pentru Linux. Poate că aș vrea să monetizez accesul la această pagină, totul este posibil? Ce ar trebui să plasez acolo pentru Haiku? Un singur fișier .hpkg cu dependențe doar de HaikuPorts
Software-ul meu are nevoie de anumite versiuni ale altor programe. De exemplu, este cunoscut că pentru Krita este necesară o versiune corectată a Qt, sau Qt care este optimizată pentru o versiune specifică a Krita, cel puțin până când corecțiile sunt integrate înapoi în Qt. Se poate ambala propriul Qt pentru aplicație în pachet .hpkg, dar cel mai probabil, acest lucru nu este încurajat.

O pagină obișnuită de descărcare a aplicației. Ce ar trebui să plasez aici pentru Haiku?

Vor deveni pachetele (existente sub formă de directoare de aplicații, cum ar fi AppDir sau .app în stil Apple) și/sau imaginile (sub formă de AppImages puternic modificate sau .dmg de la Apple) aplicații sunt o completare utilă pentru mediul de lucru Haiku? Sau va dilua imaginea de ansamblu și va conduce la fragmentare, adăugând astfel complexitate? Mă simt împărțit: pe de o parte, frumusețea și rafinamentul Haiku se bazează pe faptul că, de obicei, există o singură modalitate de a face ceva, nu multe. Pe de altă parte, mare parte a infrastructurii pentru directoare și/sau suite de aplicații este deja în loc, astfel că sistemul cere să își ocupe și restul de câteva procente.

Conform dezvoltatorului mr. waddlesplash

Pe Linux ele (directoare și suite de aplicații, — nota traductorului) sunt cel mai probabil o soluție tehnică pentru problemele sistemului. Pe Haiku preferăm pur și simplu să rezolvăm problemele sistemului.

Ce părere aveți?

Înainte de a răspunde…

Așteptați, hai să facem o verificare rapidă a realității: de fapt directoarele aplicațiilor — sunt deja parte din Haiku:

Directoarele aplicațiilor există deja pe Haiku, dar nu sunt încă suportate în managerul de fișiere

Ele pur și simplu nu sunt susținute la fel de bine ca, să zicem, în Finder-ul Macintosh. Cât de tare ar fi dacă directorul QtCreator ar avea în colțul din stânga sus numele și iconița „QtCreator”, lansând aplicația la un dublu click?

Puțin mai devreme am întrebat:

Sunteți siguri că veți rula aplicațiile dvs. din urmă cu zece ani astăzi, când toate magazinele de aplicații și repository-urile distribuțiilor vor uita de ele și de dependențele lor? Sunteți siguri că veți putea în continuare să accesați munca dvs. actuală în viitor?

Există deja un răspuns din partea Haiku, sau directoarele și suitele de aplicații vor putea ajuta aici? Cred că vor putea.

Conform lui mr. waddlesplash:

Da, avem un răspuns la întrebare: vom susține aceste aplicații atât timp cât este necesar, până când cineva va putea citi corect formatele lor de fișier sau va asigura funcționalitatea unu-la-unu. Dorința noastră de a susține aplicațiile BeOS R5 pe Haiku este o dovadă directă a acestui lucru…

Asta e sigur!

Ce plan de acțiune ar trebui să adopte Haiku?

Îmi pot imagina o coexistență pașnică a hpkg, directoarelor și imagilor aplicațiilor:

Software-ul de sistem utilizează .hpkg
Pentru cea mai frecvent utilizată software (în special pentru cea care trebuie planificată cu lansări suspendate) se folosește .hpkg (aproximativ 80% din toate cazurile)
Unele, instalate prin .hpkg, aplicații vor beneficia de trecerea la o infrastructură cu directoare de aplicații (de exemplu, QtCreator): acestea vor fi distribuite sub forma .hpkg, ca și înainte.

mr. waddlesplash spune:

Dacă tot ce este nevoie este vizualizarea aplicațiilor în /system/apps, în loc de asta, trebuie să facem directoarele din Deskbar mai gestionabile pentru utilizatori, deoarece /system/apps nu este destinat ca utilizatorii să-l deschidă și să-l vizioneze frecvent (spre deosebire de MacOS). Pentru astfel de situații, Haiku are o altă paradigmă, dar această opțiune este, teoretic, acceptabilă.

Haiku obține o infrastructură pentru a lansa imagini ale aplicațiilor, versiuni de noapte, construiri continue și de testare a software-ului, precum și pentru cazurile în care utilizatorul dorește să „înghețe în timp”, pentru software privat și intern și alte cazuri specifice de utilizare (aproximativ 20% din toate). Aceste imagini conțin fișierele necesare pentru a rula aplicația .hpkg, montate prin mijloacele sistemului, iar după finalizarea aplicației — demontate. (Poate că managerul de fișiere ar putea plasa fișiere .hpkg în imaginile aplicațiilor, automat sau la cererea utilizatorului — adică, așa cum se întâmplă când tragi aplicația într-un director de rețea sau pe un disc extern. Este pur și simplu o melodie! Sau, mai bine spus, o poezie — haiku.) Pe de altă parte, utilizatorul poate dori să instaleze conținutul imaginii sub formă de fișiere.hpkg, după care acestea vor fi actualizate și procesate exact așa cum ar fi fost instalate prin HaikuDepot… Trebuie să facem un brainstorming).

Citat de la mr. waddlesplash:

Rularea aplicațiilor de pe discuri externe sau directoare de rețea poate fi potențial utilă. Adiția posibilității de a configura mai multe „zone” pentru pkgman va deveni cu siguranță o caracteristică bună.

O astfel de sistem va folosi avantajele hpkg, directoarelor și imaginilor aplicațiilor. Ele sunt bune și separat, dar împreună vor deveni invincibile.

Concluzie

Pentru Haiku există o infrastructură care furnizează o interfață utilizator simplă și rafinată pentru PC-uri, depășind de departe ceea ce este de obicei oferit pentru PC pe Linux. Sistemul de pachete .hpkg — un exemplu de acest tip, dar și celelalte părți ale sistemului sunt impregnate cu rafinament. Cu toate acestea, un suport corespunzător pentru directoare și imagini de aplicații ar aduce beneficii Haiku. Cum să facem asta cel mai bine — ar trebui discutat cu oameni care cunosc Haiku, filosofia și arhitectura acesteia mult mai bine decât mine. Până la urmă, folosesc Haiku de puțin peste o săptămână. Dar cred că această nouă perspectivă va fi utilă designerilor, dezvoltatorilor și arhitecților Haiku. Cel puțin, sunt bucuros să fiu „partener de sparring” pentru ei. Am peste 10 ani de experiență practică cu directoare și seturi de aplicații pentru Linux și mi-ar plăcea să le găsesc aplicabilitate în Haiku, pentru concepția căreia, în opinia mea, se potrivesc perfect. Soluțiile potențiale pe care le propun nu sunt deloc singurele corecte pentru problemele pe care le-am descris, iar dacă echipa Haiku decide să găsească altele, mai elegante — mă bucur foarte mult. În principiu, mă gândesc deja la cum să fac sistemul. hpkg inclusiv mai uimitor, fără a schimba modul său de funcționare. Se pare că echipa Haiku a gândit de mult despre seturi de aplicații în implementarea sistemului de gestionare a pachetelor, dar din păcate, (mi se pare) ideea a devenit „de modă veche”. Poate că a venit vremea să o reînvie?

Încercați singuri! Proiectul Haiku oferă imagini pentru descărcare de pe DVD sau USB, care sunt generate zilnic.
Aveți întrebări? Vă invităm în canalul Telegram în limba rusă.

Revizuirea erorilor: Cum să te împuști în picior în C și C++. Colecția de rețete Haiku OS

De la autor al traducerii: este al optulea și ultimul articol dintr-o serie despre Haiku.

Lista articolelor: Primul Al doilea Al treilea Al patrulea Al cincilea Al șaselea Al șaptelea

Numai utilizatorii înregistrați pot participa la sondaj. Conectați-vă, vă rugăm.