Încă ceva: pachetele de aplicații Haiku?

TL; DR: Poate Haiku să obțină suport adecvat pentru pachetele de aplicații, cum ar fi directoarele de aplicații (cum ar fi .app pe Mac) și/sau imagini ale aplicației (Linux AppImage)? Cred că aceasta ar fi o adăugare demnă, care este mai ușor de implementat corect decât alte sisteme, deoarece cea mai mare parte a infrastructurii este deja în vigoare.

Acum o saptamana Am descoperit Haiku, un sistem neașteptat de bun. Ei bine, din moment ce sunt de mult interesat de directoare și imagini de aplicații (inspirate din simplitatea Macintosh-ului), nu este de mirare că mi-a venit în minte o idee...

Pentru o înțelegere deplină, sunt creatorul și autorul AppImage, un format de distribuție a aplicațiilor Linux care vizează simplitatea Mac și oferă control deplin autorilor și utilizatorilor finali de aplicații (dacă doriți să aflați mai multe, consultați Wiki и documentație).

Ce se întâmplă dacă facem o AppImage pentru Haiku?

Să ne gândim puțin, pur teoretic: ce trebuie făcut pentru a obține AppImage, sau ceva similar, pe Haiku? Nu este necesar să creați ceva chiar acum, pentru că sistemul care există deja în Haiku funcționează uimitor, dar un experiment imaginar ar fi frumos. Demonstrează, de asemenea, sofisticarea Haiku, în comparație cu mediile desktop Linux, unde astfel de lucruri sunt teribil de dificile (am dreptul să spun așa: mă lupt de 10 ani cu depanarea).

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

În primul rând, ce este un AppImage? Acesta este un sistem pentru lansarea de aplicații terță parte (de exemplu, Cura Ultimaker), permițând aplicațiilor să fie lansate când și cum doresc: nu este nevoie să cunoașteți specificul diferitelor distribuții, să construiți politici sau să construiți infrastructură, nu este nevoie de suport pentru întreținere și nu le spun utilizatorilor ce (nu) pot instala pe computerele lor. AppImage ar trebui să fie înțeles ca ceva similar cu un pachet Mac în format .app în interiorul imaginii de disc .dmg. Principala diferență este că aplicațiile nu sunt copiate, ci rămân în interiorul AppImage pentru totdeauna, la fel ca și pachetele Haiku. .hpkg montat și niciodată instalat în sensul obișnuit.

De-a lungul a peste 10 ani de existență, AppImage a câștigat o oarecare atracție și popularitate: însuși Linus Torvalds a susținut-o public, iar proiectele comune (de exemplu, LibreOffice, Krita, Inkscape, Scribus, ImageMagick) l-au adoptat ca modalitate principală. pentru a distribui versiuni continue sau nocturne, fără a interfera cu aplicațiile utilizator instalate sau dezinstalate. Cu toate acestea, mediile și distribuțiile desktop Linux de cele mai multe ori încă se agață de modelul tradițional de distribuție bazat pe întreținere și/sau își promovează propriile afaceri și/sau programe de inginerie bazate pe Flatpak (RedHat, Fedora, GNOME) și Vioi (Canonic, Ubuntu). Este vorba ridicol.

Cum functioneazã

• Fiecare AppImage conține 2 părți: un mic dublu-clic ELF (așa-numitul. runtime.c), urmată de o imagine a sistemului de fișiere SquashFS.

• Sistemul de fișiere SquashFS conține încărcătura utilă a aplicației și tot ceea ce este necesar pentru a o rula, ceea ce, în minte, nu poate fi considerat parte a instalării implicite pentru fiecare sistem țintă destul de recent (distribuție Linux). De asemenea, conține metadate, cum ar fi numele aplicației, pictograme, tipuri MIME etc., etc.

• Când este rulat de utilizator, runtime folosește FUSE și squashfuse pentru a monta sistemul de fișiere și apoi se ocupă de rularea unui punct de intrare (alias AppRun) în interiorul AppImage montat.
  Sistemul de fișiere este demontat după finalizarea procesului.

Totul pare a fi simplu.

Și aceste lucruri complică totul:

• Cu o asemenea varietate de distribuții Linux, nimic „în mintea potrivită” nu poate fi numit „parte a instalării implicite pentru fiecare sistem țintă nou”. Rezolvăm această problemă prin construirea excludelist, permițându-vă să determinați ce va fi ambalat în AppImage și ce va trebui să fie luat în altă parte. În același timp, uneori ne lipsește, în ciuda faptului că, în general, totul funcționează excelent. Din acest motiv, recomandăm creatorilor de pachete să testeze AppImages pe toate sistemele (distribuții) țintă.
• Încărcările utile ale aplicației trebuie să fie relocabile în sistemul de fișiere. Din păcate, multe aplicații au căi absolute codificate greu către, de exemplu, resurse în /usr/share. Acest lucru trebuie rezolvat cumva. În plus, trebuie fie să exportați LD_LIBRARY_PATH, sau reparați rpath astfel încât încărcătorul să poată găsi biblioteci aferente. Prima metodă are dezavantajele sale (care sunt depășite în moduri complexe), iar a doua este pur și simplu greoaie.
• Cea mai mare capcană UX pentru utilizatori este aceea setați bitul executabil Fișierul AppImage după descărcare. Credeți sau nu, aceasta este o adevărată barieră pentru unii. Necesitatea de a seta bitul de executabilitate este greoaie chiar și pentru utilizatorii experimentați. Ca o soluție, am sugerat instalarea unui mic serviciu care monitorizează fișierele AppImage și setează bitul lor de executabilitate. În forma sa pură, nu este cea mai bună soluție, deoarece nu va funcționa din cutie. Distribuțiile Linux nu oferă acest serviciu, prin urmare, utilizatorii au o experiență proastă.
• Utilizatorii Linux se așteaptă ca o nouă aplicație să aibă o pictogramă în meniul de pornire. Nu poți spune sistemului: „Uite, există o nouă aplicație, hai să lucrăm.” În schimb, conform specificației XDG, trebuie să copiați fișierul .desktop la locul potrivit în /usr pentru o instalare la nivelul întregului sistem sau în $HOME pentru individ. Pictogramele de anumite dimensiuni, conform specificației XDG, trebuie plasate în anumite locuri în usr sau $HOME, apoi executați comenzi în mediul de lucru pentru a actualiza memoria cache a pictogramelor sau sperați că managerul mediului de lucru va înțelege și va detecta automat totul. Același lucru cu tipurile MIME. Ca o soluție, se propune utilizarea aceluiași serviciu, care, pe lângă setarea steagului de executabilitate, va, dacă există pictograme etc. în AppImage, copiați-le din AppImage în locurile potrivite conform XDG. Când este șters sau mutat, serviciul va șterge totul. Desigur, există diferențe în comportamentul fiecărui mediu de lucru, în formatele de fișiere grafice, dimensiunile acestora, locațiile de stocare și metodele de actualizare a cache-urilor, ceea ce creează o problemă. Pe scurt, această metodă este o cârjă.
• Dacă cele de mai sus nu sunt suficiente, încă nu există pictogramă AppImage în managerul de fișiere. Lumea Linux nu a decis încă să implementeze elficon (în ciuda discuție и implementare), deci este imposibil să încorporați pictograma direct în aplicație. Deci, se dovedește că aplicațiile din managerul de fișiere nu au propriile pictograme (fără diferență, AppImage sau altceva), ele sunt doar în meniul de pornire. Ca o soluție, folosim miniaturi, un mecanism care a fost conceput inițial pentru a permite managerilor de desktop să arate imagini de previzualizare în miniatură ale fișierelor grafice ca pictograme. În consecință, serviciul de setare a bitului de executabilitate funcționează și ca un „miniaturizator”, creând și scriind miniaturi de pictograme în locațiile corespunzătoare. /usr и $HOME. Acest serviciu efectuează, de asemenea, curățare dacă AppImage este șters sau mutat. Datorită faptului că fiecare manager de desktop se comportă ușor diferit, de exemplu, în ce formate acceptă pictograme, în ce dimensiuni sau locuri, totul este cu adevărat dureros.
• Aplicația pur și simplu se blochează la execuție dacă apar erori (de exemplu, există o bibliotecă care nu face parte din sistemul de bază și nu este furnizată în AppImage) și nimeni nu spune utilizatorului în GUI ce se întâmplă exact. Am început să ocolim acest lucru utilizând notificări pe desktop, ceea ce înseamnă că trebuie să captăm erorile din linia de comandă, să le convertim în mesaje înțelese de utilizator, care apoi trebuie să fie afișate pe desktop. Și, desigur, fiecare mediu desktop le gestionează puțin diferit.
• Momentan (septembrie 2019 - nota traducătorului) nu am găsit o modalitate simplă de a spune sistemului că fișierul 1.png trebuie deschis folosind Krita și 2.png - folosind GIMP.

Locație de stocare pentru specificațiile cross-desktop utilizate în GNOME, KDE и Xfce este freedesktop.org

Atingerea nivelului de sofisticare țesut adânc în mediul de lucru Haiku este dificilă, dacă nu imposibilă, din cauza specificațiilor XDG de pe freedesktop.org pentru cross-desktop, precum și implementări ale managerilor desktop bazate pe aceste specificații. Ca exemplu, putem cita o pictogramă Firefox la nivel de sistem: se pare că autorii XDG nici nu s-au gândit că un utilizator ar putea avea instalate mai multe versiuni ale aceleiași aplicații.

Pictograme pentru diferite versiuni de Firefox

Mă întrebam ce ar putea învăța lumea Linux de la Mac OS X pentru a evita să distrugă integrarea sistemului. Dacă aveți timp și vă interesează acest lucru, asigurați-vă că citiți ceea ce a spus Arnaud Gurdol, unul dintre primii ingineri Mac OS X:

Am vrut să facem instalarea aplicației la fel de ușoară precum tragerea pictogramei aplicației de undeva (server, unitate externă) pe unitatea computerului. Pentru a face acest lucru, pachetul aplicației stochează toate informațiile, inclusiv pictogramele, versiunea, tipul fișierului în curs de procesare, tipul de scheme URL pe care sistemul trebuie să le cunoască pentru a procesa aplicația. Aceasta include, de asemenea, informații pentru „stocare centrală” în baza de date a Serviciilor Icon și a Serviciilor de lansare. Pentru a susține performanța, aplicațiile sunt „descoperite” în mai multe locuri „cunoscute”: directoarele de sistem și aplicații ale utilizatorilor și altele automat dacă utilizatorul navighează la Finder din directorul care conține aplicația. În practică, acest lucru a funcționat foarte bine.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 sesiunea 144 - Mac OS X: ambalarea aplicațiilor și tipărirea documentelor.

Nu există nimic ca această infrastructură pe desktop-urile Linux, așa că căutăm soluții pentru limitările structurale din proiectul AppImage.

Haiku vine în ajutor?

Și încă ceva: platformele Linux ca bază a mediilor desktop tind să fie atât de subspecificate încât multe lucruri care sunt destul de simple într-un sistem full-stack consistent sunt frustrant de fragmentate și complexe în Linux. Am dedicat un întreg raport problemelor legate de platforma Linux pentru medii desktop (dezvoltatorii cunoscători au confirmat că totul va rămâne așa pentru foarte mult timp).

Raportul meu despre problemele mediilor desktop Linux în 2018

Chiar și Linus Torvalds a recunoscut că fragmentarea a fost motivul pentru care ideea spațiului de lucru a eșuat.

Mă bucur să văd Haiku!

Haiku face totul uimitor de simplu

În timp ce abordarea naivă pentru „portarea” AppImage la Haiku este să încerce pur și simplu să construiască (în principal runtime.c și service) componentele sale (ceea ce poate chiar să fie posibil!), acest lucru nu va oferi prea multe beneficii pentru Haiku. Pentru că, de fapt, majoritatea acestor probleme sunt rezolvate în Haiku și sunt corecte din punct de vedere conceptual. Haiku oferă exact elementele de bază ale infrastructurii sistemului pe care le-am căutat atât de mult timp în mediile desktop Linux și nu mi-a venit să cred că nu sunt acolo. Și anume:

Credeți sau nu, acesta este ceva ce mulți utilizatori Linux nu pot depăși. Pe Haiku totul se face automat!

• Fișierele ELF care nu au un bit de executabilitate primesc unul automat când se face dublu clic în managerul de fișiere.
• Aplicațiile pot avea resurse încorporate, cum ar fi pictograme, 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 și, prin urmare, nu este nevoie să le curățați după ștergerea sau mutarea aplicației.
• Există o bază de date pentru conectarea aplicațiilor cu documente, nu este nevoie să copiați niciun fișier pentru aceasta.
• În directorul lib/ de lângă fișierul executabil, bibliotecile sunt căutate implicit.
• Nu există numeroase distribuții și medii desktop; orice funcționează, funcționează peste tot.
• Nu există un modul separat de rulat care să fie diferit de directorul Aplicații.
• Aplicațiile nu au căi absolute încorporate către resursele lor; au funcții speciale pentru determinarea locației în timpul execuției.
• A fost introdusă ideea de imagini comprimate ale sistemului de fișiere: acesta este orice pachet hpkg. Toate sunt montate de nucleu.
• Fiecare fișier este deschis de aplicația care l-a creat, cu excepția cazului în care specificați în mod explicit altfel. Ce tare este asta!

Două fișiere png. Rețineți diferitele pictograme care indică faptul că acestea vor fi deschise de diferite aplicații atunci când se face dublu clic. Rețineți, de asemenea, meniul derulant „Deschide cu:” unde utilizatorul poate selecta o aplicație individuală. Ce simplu!

Se pare că multe dintre cârjele și soluțiile necesare de AppImage pe Linux devin inutile pe Haiku, care are la bază simplitatea și sofisticarea care îl face să răspundă majorității nevoilor noastre.

Are Haiku nevoie de pachete de aplicații până la urmă?

Acest lucru duce la o mare întrebare. Dacă ar fi cu un ordin de mărime mai ușor să creezi un sistem ca AppImage pe Haiku decât pe Linux, ar merita să faci asta? Sau Haiku, cu sistemul său de pachete hpkg, a eliminat efectiv nevoia de a dezvolta o astfel de idee? Ei bine, pentru a răspunde trebuie să ne uităm la motivația din spatele existenței AppImages.

Perspectiva utilizatorului

Să ne uităm la utilizatorul final:

• Vreau să instalez o aplicație fără a cere o parolă de administrator (rădăcină). Nu există conceptul de administrator pe Haiku, utilizatorul are controlul deplin deoarece este un sistem personal! (În principiu, vă puteți imagina acest lucru în modul multiplayer, sper ca dezvoltatorii să fie simplu)
• Vreau să obțin cele mai recente și mai bune versiuni de aplicații, fără să aștept să apară în distribuția mea (cel mai adesea asta înseamnă „niciodată”, cel puțin dacă nu actualizez întregul sistem de operare). Pe Haiku acest lucru este „rezolvat” cu lansări plutitoare. Aceasta înseamnă că este posibil să obțineți cele mai recente și mai bune versiuni de aplicații, dar pentru a face acest lucru trebuie să actualizați constant restul sistemului, transformându-l efectiv într-o „țintă în mișcare”.
• Vreau mai multe versiuni ale aceleiași aplicații una lângă alta, deoarece nu există nicio modalitate de a ști ce a fost spart în cea mai recentă versiune sau, să zicem, eu, ca dezvoltator web, trebuie să-mi testez munca în diferite versiuni ale browserului. Haiku rezolvă prima problemă, dar nu și a doua. Actualizările sunt anulate, dar numai pentru întregul sistem; este imposibil (din câte știu eu) să rulezi, de exemplu, mai multe versiuni de WebPositive sau LibreOffice în același timp.

Unul dintre dezvoltatori scrie:

În esență, rațiunea este următoarea: cazul de utilizare este atât de rar încât optimizarea pentru el nu are sens; tratarea lui ca un caz special în HaikuPorts pare mai mult decât acceptabilă.

• Trebuie să păstrez aplicațiile acolo unde îmi plac, nu pe unitatea de pornire. De multe ori rămân fără spațiu pe disc, așa că trebuie să conectez o unitate externă sau un director de rețea pentru a stoca aplicații (toate versiunile pe care le-am descărcat). Dacă conectez o astfel de unitate, am nevoie ca aplicațiile să fie lansate făcând dublu clic. Haiku salvează versiuni vechi ale pachetelor, dar nu știu cum să le muți pe o unitate externă sau cum să lansez aplicații de acolo mai târziu.

Comentariul dezvoltatorului:

Din punct de vedere tehnic, acest lucru este deja posibil cu comanda mount. Desigur, vom face o interfață grafică pentru aceasta de îndată ce vom avea destui utilizatori interesați.

• Nu am nevoie de milioane de fișiere împrăștiate în sistemul de fișiere pe care nu le pot gestiona manual. Vreau un fișier per aplicație pe care să îl pot descărca, muta, șterge cu ușurință. Pe Haiku această problemă este rezolvată folosind pachete .hpkg, care transferă, de exemplu, python, din mii de fișiere într-unul singur. Dar dacă există, de exemplu, Scribus care folosește python, atunci trebuie să mă ocup de cel puțin două fișiere. Și trebuie să am grijă să păstrez versiuni ale acestora care funcționează între ele.

Mai multe versiuni de AppImages rulează una lângă alta pe același Linux

Perspectiva unui dezvoltator de aplicații

Să privim din punctul de vedere al dezvoltatorului de aplicații:

• Vreau să controlez întreaga experiență a utilizatorului. Nu vreau să depind de un sistem de operare pentru a-mi spune când și cum ar trebui să lansez aplicațiile. Haiku permite dezvoltatorilor să lucreze cu propriile depozite hpkg, dar asta înseamnă că utilizatorii vor trebui să le configureze manual, ceea ce face ca ideea să fie „mai puțin atractivă”.
• Am o pagină de descărcare pe site-ul meu unde distribui .exe pentru Windows, .dmg pentru Mac și .AppImage pentru Linux. Sau poate vreau să monetizez accesul la această pagină, ceva este posibil? Ce ar trebui să pun acolo pentru Haiku? Dosarul este suficient .hpkg cu dependențe doar de la HaikuPorts
• Software-ul meu necesită versiuni specifice ale altor software. De exemplu, se știe că Krita necesită o versiune corectată a lui Qt sau Qt care este ajustată fin la o anumită versiune a lui Krita, cel puțin până când patch-urile sunt împinse înapoi în Qt. Vă puteți împacheta propriul Qt pentru aplicația dvs. într-un pachet .hpkg, dar cel mai probabil acest lucru nu este binevenit.

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

Pachetele Will (existând ca directoare de aplicații precum AppDir sau .app în stil Apple) și/sau imagini (sub formă de AppImagini foarte modificate sau .dmg de la Apple) aplicații un plus util pentru mediul desktop Haiku? Sau va dilua întreaga imagine și va duce la fragmentare și, prin urmare, va adăuga complexitate? Sunt sfâșiat: pe de o parte, frumusețea și rafinamentul lui Haiku se bazează pe faptul că, de obicei, există o singură modalitate de a face ceva, mai degrabă decât multe. Pe de altă parte, cea mai mare parte a infrastructurii pentru cataloage și/sau suite de aplicații este deja în vigoare, așa că sistemul strigă ca restul de procente să se încadreze.

Potrivit dezvoltatorului Domnul. waddlesplash

Pe Linux ei (cataloage și truse de aplicații, - aprox. traducător) sunt cel mai probabil o soluție tehnică la problemele sistemice. La Haiku preferăm să rezolvăm pur și simplu problemele de sistem.

Ce crezi?

Inainte sa raspunzi...

Stai, hai să facem o verificare rapidă a realității: de fapt directoarele de aplicații - face parte deja din Haiku:

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

Pur și simplu nu sunt la fel de bine acceptate ca, să zicem, Macintosh Finder. Cât de tare ar fi dacă directorul QtCreator ar avea un nume și o pictogramă „QtCreator” în colțul din stânga sus, lansând aplicația la dublu clic?

Puțin mai devreme deja întrebă:

Ești sigur că poți rula aplicațiile tale vechi de un deceniu astăzi, când toate magazinele de aplicații și depozitele de distribuție au uitat de ele și de dependențele lor? Sunteți încrezător că veți putea în continuare să vă accesați actualul job în viitor?

Există deja un răspuns de la Haiku sau cataloagele și pachetele de aplicații pot ajuta aici? Cred că pot.

Potrivit dl. waddlesplash:

Da, avem răspunsul la întrebare: pur și simplu vom susține aceste aplicații atâta timp cât este necesar, până când cineva își poate citi formatele de fișiere în mod corect sau poate oferi funcționalități one-to-one. Angajamentul nostru de a sprijini aplicațiile BeOS R5 pe Haiku este dovada acestui lucru...

Acest lucru este sigur!

Ce curs de acțiune ar trebui să ia Haiku?

Îmi pot imagina coexistența pașnică a hpkg, directoarelor și imaginilor aplicației:

• Utilizează software-ul de sistem .hpkg
• Pentru software-ul cel mai frecvent utilizat (în special cei care trebuie să programeze lansări rulante), utilizați .hpkg (aproximativ 80% din toate cazurile)
• Unele instalate prin .hpkg, aplicațiile vor beneficia de mutarea într-o infrastructură de director de aplicații (ex. QtCreator): vor fi distribuite ca .hpkg, Ca înainte.

Domnul. waddlesplash scrie:

Dacă tot ce aveți nevoie este să vizualizați aplicațiile în /system/apps, în schimb ar trebui să facem directoarele din Deskbar mai ușor de gestionat pentru utilizatori, deoarece /system/apps nu este destinat să fie deschis și vizualizat în mod regulat de către utilizatori (spre deosebire de MacOS). Pentru astfel de situații, Haiku are o altă paradigmă, dar această opțiune este, teoretic, acceptabilă.

• Haiku primește infrastructura pentru rularea imaginilor aplicațiilor, versiuni de noapte, continue și de testare ale software-ului, precum și pentru cazurile în care utilizatorul dorește să-l „înghețe în timp”, pentru software-ul privat și intern și alte cazuri speciale de utilizare (aproximativ 20% dintre toate). Aceste imagini conțin fișierele necesare rulării aplicației .hpkg, montat de sistem, iar după finalizarea aplicației - demontat. (Poate că un manager de fișiere ar putea pune fișiere .hpkg în imaginile aplicației, automat sau la cererea utilizatorului - ei bine, cum ar fi atunci când glisați o aplicație într-un director de rețea sau într-o unitate externă. Este doar un cântec! Sau mai degrabă, poezie - haiku.) Pe de altă parte, utilizatorul poate dori să instaleze conținutul imaginii sub formă de fișiere.hpkg, după care vor fi actualizate și procesate în același mod ca și cum ar fi instalate prin HaikuDepot... Trebuie să facem brainstorming).

Citat din dl. waddlesplash:

Rularea aplicațiilor de pe unități externe sau directoare de rețea poate fi utilă. Și adăugarea capacității de a configura mai multe „zone” pentru pkgman ar fi cu siguranță o caracteristică plăcută.

Un astfel de sistem ar profita de hpkg, directoare și imagini ale aplicațiilor. Sunt buni individual, dar împreună vor deveni invincibili.

Concluzie

Haiku are un cadru care oferă o experiență de utilizator simplă și sofisticată pentru PC și depășește cu mult ceea ce este furnizat de obicei pentru PC-ul Linux. Sistemul de pachete .hpkg este un astfel de exemplu, dar restul sistemului este, de asemenea, impregnat de sofisticare. Cu toate acestea, Haiku ar beneficia de suport adecvat pentru directoare și imaginea aplicației. Cum să faceți cel mai bine acest lucru merită să discutați cu oameni care cunosc Haiku, filozofia și arhitectura lui mult mai bine decât mine. La urma urmei, folosesc Haiku de puțin peste o săptămână. Cu toate acestea, cred că designerii, dezvoltatorii și arhitecții Haiku vor beneficia de această nouă perspectivă. Cel puțin, aș fi fericit să fiu „partenerul lor de lupta”. Am peste 10 ani de experiență practică cu cataloagele și pachetele de aplicații Linux și aș dori să le găsesc o utilizare în Haiku, pentru care cred că se potrivesc perfect. Potențialele soluții pe care le-am propus nu sunt deloc singurele corecte pentru problemele pe care le-am descris, iar dacă echipa Haiku se hotărăște să găsească altele, mai elegante, sunt de acord. Practic, deja mă gândesc la ideea cum să fac un sistem hpkg chiar mai uimitor fără a schimba modul în care funcționează. Se pare că echipa Haiku s-a gândit de mult la pachetele de aplicații când a implementat un sistem de management al pachetelor, dar din păcate (cred) ideea a devenit „învechită”. Poate este timpul să-l reînvie?

Incearca-l tu insuti! La urma urmei, proiectul Haiku oferă imagini pentru pornire de pe DVD sau USB, generate zilnic.
Aveti vreo intrebare? Vă invităm la limba rusă canal de telegramă.

Prezentare generală a erorilor: Cum să te împuști în picior în C și C++. Colecție de rețete Haiku OS

De la autor traducere: acesta este al optulea și ultimul articol din seria despre Haiku.

Lista articolelor: în primul rând Al doilea Al treilea al patrulea al cincilea al șaselea al șaptelea

Numai utilizatorii înregistrați pot participa la sondaj. Loghează-te, Vă rog.

Are sens să porți sistemul hpkg pe Linux?

• Da

• Nu

• Deja implementat, voi scrie în comentarii

Au votat 20 utilizatori. 5 utilizatori s-au abținut.

Sursa: www.habr.com