Još nešto: Haiku paketi aplikacija?

TL; DR: Može li Haiku dobiti odgovarajuću podršku za pakete aplikacija, kao što su direktoriji aplikacija (npr .app na Macu) i/ili slike aplikacija (Linux AppImage)? Mislim da bi ovo bio dostojan dodatak koji je lakše pravilno implementirati od drugih sistema jer je većina infrastrukture već uspostavljena.

Pre nedelju dana Otkrio sam Haiku, neočekivano dobar sistem. Pa, pošto me već dugo zanimaju direktoriji i slike aplikacija (inspirisani jednostavnošću Macintosha), nije iznenađujuće što mi je pala na pamet ideja...

Radi potpunog razumijevanja, ja sam kreator i autor AppImage, Linux formata za distribuciju aplikacija koji ima za cilj jednostavnost Mac-a i daje potpunu kontrolu autorima aplikacija i krajnjim korisnicima (ako želite znati više, pogledajte Wiki и dokumentaciju).

Šta ako napravimo AppImage za Haiku?

Razmislimo malo, čisto teoretski: šta treba uraditi da bi se dobilo AppImage, ili nešto slično, na Haikuu? Nije potrebno nešto stvarati upravo sada, jer sistem koji već postoji u Haikuu radi zapanjujuće, ali imaginarni eksperiment bi bio dobar. Takođe demonstrira sofisticiranost Haikua, u poređenju sa Linux desktop okruženjima, gde su takve stvari užasno teške (imam pravo da kažem: borim se sa otklanjanjem grešaka već 10 godina).

Na Macintosh sistemu 1, svaka aplikacija je bila zasebna datoteka kojom se "upravlja" u Finderu. Koristeći AppImage pokušavam ponovo stvoriti isto korisničko iskustvo na Linuxu.

Prvo, šta je AppImage? Ovo je sistem za puštanje aplikacija trećih strana (npr. Ultimaker Cure), dozvoljavajući aplikacijama da budu puštene kada i kako žele: nema potrebe da se znaju specifičnosti različitih distribucija, pravila za izgradnju ili izgradnju infrastrukture, nije potrebna podrška za održavanje i ne govore korisnicima šta (ne) mogu da instaliraju na njihovim kompjuterima. AppImage treba shvatiti kao nešto slično Mac paketu u formatu .app unutar slike diska .dmg. Glavna razlika je u tome što se aplikacije ne kopiraju, već zauvijek ostaju unutar AppImage-a, slično kao i Haiku paketi .hpkg montiran, i nikada instaliran u uobičajenom smislu.

Tokom više od 10 godina postojanja, AppImage je stekao određenu privlačnost i popularnost: sam Linus Torvalds ga je javno podržao, a zajednički projekti (na primjer, LibreOffice, Krita, Inkscape, Scribus, ImageMagick) su ga prihvatili kao glavni način distribuirati kontinuirane ili noćne gradnje, ne ometajući instalirane ili deinstalirane korisničke aplikacije. Međutim, Linux desktop okruženja i distribucije najčešće se i dalje drže tradicionalnog, centraliziranog modela distribucije zasnovanog na održavanju i/ili promoviraju vlastito poslovno poslovanje i/ili inženjerske programe zasnovane na Flatpak (RedHat, Fedora, GNOME) i elegantan (Canonical, Ubuntu). Dolazi smiješno.

Kako to radi

• Svaka AppImage sadrži 2 dijela: mali ELF dvostrukim klikom (tzv. runtime.c), nakon čega slijedi slika sistema datoteka SquashFS.

• Datotečni sistem SquashFS sadrži korisni teret aplikacije i sve što je potrebno za njeno pokretanje, što se pri zdravoj pameti ne može smatrati dijelom zadane instalacije za svaki relativno novi ciljni sistem (Linux distribucija). Takođe sadrži metapodatke, kao što su naziv aplikacije, ikone, MIME tipovi, itd., itd.

• Kada ga pokrene korisnik, vrijeme izvođenja koristi FUSE i squashfuse za montiranje sistema datoteka, a zatim upravlja pokretanjem neke ulazne točke (aka AppRun) unutar montirane AppImage.
  Sistem datoteka se demontira nakon što se proces završi.

Sve izgleda jednostavno.

A ove stvari sve komplikuju:

• Sa takvom raznolikošću distribucija Linuxa, ništa se "pri dobrom umu" ne može nazvati "dijelom zadane instalacije za svaki novi ciljni sistem". Zaobilazimo ovaj problem gradnjom excludelist, što vam omogućava da odredite šta će biti upakovano u AppImage, a šta će biti potrebno prenijeti negdje drugdje. Istovremeno, ponekad nam nedostaje, uprkos činjenici da, generalno, sve funkcioniše odlično. Iz tog razloga, preporučujemo da kreatori paketa testiraju AppImages na svim ciljnim sistemima (distribucijama).
• Korisni učitavanje aplikacije mora biti premeštavo kroz sistem datoteka. Nažalost, mnoge aplikacije imaju tvrdo kodirane apsolutne putanje do, na primjer, resursa u /usr/share. Ovo treba nekako popraviti. Osim toga, morate ili izvesti LD_LIBRARY_PATH, ili popraviti rpath tako da učitavač može pronaći povezane biblioteke. Prvi metod ima svoje nedostatke (koji se prevazilaze na složene načine), a drugi je jednostavno glomazan.
• Najveća UX zamka za korisnike je to postaviti izvršni bit AppImage fajl nakon preuzimanja. Vjerovali ili ne, za neke je ovo prava prepreka. Potreba za postavljanjem bita izvršnosti je glomazna čak i za iskusne korisnike. Kao zaobilazno rješenje, predložili smo instaliranje male usluge koja nadgleda AppImage datoteke i postavlja njihov bit izvršnosti. U svom čistom obliku, to nije najbolje rješenje, jer neće raditi iz kutije. Linux distribucije ne pružaju ovu uslugu, stoga korisnici imaju loše iskustvo iz kutije.
• Korisnici Linuxa očekuju da nova aplikacija ima ikonu u startup meniju. Ne možete reći sistemu: "Vidi, ima nova aplikacija, idemo raditi." Umjesto toga, prema XDG specifikaciji, morate kopirati datoteku .desktop na pravo mesto u /usr za instalaciju u cijelom sistemu ili u $HOME za pojedinca. Ikone određenih veličina, prema XDG specifikaciji, moraju se postaviti na određena mjesta usr ili $HOME, a zatim pokrenite komande u radnom okruženju da ažurirate keš ikona ili se nadajte da će menadžer radnog okruženja to shvatiti i automatski otkriti sve. Isto je i sa MIME tipovima. Kao zaobilazno rješenje predlaže se korištenje istog servisa koji će, osim postavljanja zastavice izvršnosti, ako postoje ikone itd. u AppImage, kopirajte ih iz AppImage na prava mjesta prema XDG. Kada se izbriše ili premjesti, od servisa se očekuje da sve izbriše. Naravno, postoje razlike u ponašanju svakog radnog okruženja, u formatima grafičkih datoteka, njihovim veličinama, lokacijama skladištenja i metodama za ažuriranje keša, što stvara problem. Ukratko, ova metoda je štaka.
• Ako gore navedeno nije dovoljno, još uvijek nema ikone AppImage u upravitelju datoteka. Svijet Linuxa još nije odlučio implementirati elficon (uprkos tome rasprava и implementacija), tako da je nemoguće ugraditi ikonu direktno u aplikaciju. Tako se ispostavilo da aplikacije u file manageru nemaju svoje ikone (bez razlike, AppImage ili nešto treće), one su samo u start meniju. Kao zaobilazno rešenje, koristimo sličice, mehanizam koji je prvobitno dizajniran da omogući menadžerima desktopa da pokažu slike u pretpregledu sličica grafičkih datoteka kao njihove ikone. Shodno tome, servis za postavljanje bita izvršnosti radi i kao "minijaturizator", kreirajući i ispisujući sličice ikona na odgovarajuće lokacije /usr и $HOME. Ova usluga također vrši čišćenje ako se AppImage izbriše ili premjesti. Zbog činjenice da se svaki desktop menadžer ponaša malo drugačije, na primjer, u kojim formatima prihvata ikone, na kojim veličinama ili mjestima, sve je ovo zaista bolno.
• Aplikacija se jednostavno ruši prilikom izvršavanja ako se pojave greške (na primjer, postoji biblioteka koja nije dio osnovnog sistema i nije isporučena u AppImageu), i niko ne govori korisniku u GUI-ju šta se tačno dešava. Počeli smo ovo zaobilaziti korištenjem obavještenja na radnoj površini, što znači da moramo uhvatiti greške iz komandne linije, pretvoriti ih u poruke koje korisnik razumije, koje zatim treba prikazati na radnoj površini. I naravno, svako desktop okruženje ih rješava malo drugačije.
• Trenutno (septembar 2019. - napomena prevodioca) nisam našao jednostavan način da kažem sistemu da je fajl 1.png mora se otvoriti pomoću Krite, i 2.png - koristeći GIMP.

Lokacija za pohranu specifikacija za različite radne površine koje se koriste u GNOME, KDE и Xfce je freedesktop.org

Postizanje nivoa sofisticiranosti duboko utkanog u Haiku radno okruženje je teško, ako ne i nemoguće, zbog specifikacija XDG sa freedesktop.org za više desktopa, kao i implementacije desktop menadžera na osnovu ovih specifikacija. Kao primjer možemo navesti jednu Firefox ikonu za cijeli sistem: očigledno, autori XDG-a nisu ni pomislili da korisnik može imati instalirano nekoliko verzija iste aplikacije.

Ikone za različite verzije Firefoxa

Pitao sam se šta bi Linux svijet mogao naučiti od Mac OS X-a kako bi izbjegao zajebavanje sistemske integracije. Ako imate vremena i volite ovo, svakako pročitajte šta je rekao Arnaud Gurdol, jedan od prvih Mac OS X inženjera:

Željeli smo da instalaciju aplikacije učinimo jednostavnim kao prevlačenje ikone aplikacije s nekog mjesta (server, eksterni disk) na disk vašeg računara. Da bi to uradio, paket aplikacije pohranjuje sve informacije, uključujući ikone, verziju, tip fajla koji se obrađuje, tip URL šema koje sistem treba da zna da bi obradio aplikaciju. Ovo takođe uključuje informacije za 'centralnu pohranu' u bazi podataka Icon Services i Launch Services. Da bi se podržale performanse, aplikacije se 'otkrivaju' na nekoliko 'dobro poznatih' mjesta: sistemski i korisnički direktoriji aplikacija, i neki drugi automatski ako korisnik dođe do Finder-a u direktoriju koji sadrži aplikaciju. U praksi je ovo funkcionisalo veoma dobro.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 sesija 144 - Mac OS X: aplikacije za pakovanje i štampanje dokumenata.

Ne postoji ništa slično ovoj infrastrukturi na Linux desktopima, tako da tražimo rješenja oko strukturnih ograničenja u AppImage projektu.

Da li Haiku dolazi u pomoć?

I još nešto: Linux platforme kao osnova desktop okruženja imaju tendenciju da budu toliko nedovoljno specificirane da su mnoge stvari koje su prilično jednostavne u dosljednom full-stack sistemu frustrirajuće fragmentirane i složene u Linuxu. Cijeli izvještaj sam posvetio problemima vezanim za Linux platformu za desktop okruženja (uvjereni programeri su potvrdili da će sve tako ostati još jako dugo).

Moj izvještaj o problemima Linux desktop okruženja u 2018

Čak je i Linus Torvalds priznao da je fragmentacija razlog zašto je ideja o radnom prostoru propala.

Lepo je videti Haiku!

Haiku sve čini neverovatno jednostavnim

Iako je naivan pristup "prenošenju" AppImage-a u Haiku jednostavno pokušati izgraditi (uglavnom runtime.c i servis) njegove komponente (što je možda čak i moguće!), ovo Haiku-u neće pružiti mnogo koristi. Jer, u stvari, većina ovih problema je rešena u haikuu i konceptualno su ispravna. Haiku pruža upravo one građevne blokove sistemske infrastrukture koje sam toliko dugo tražio u Linux desktop okruženjima i nisam mogao vjerovati da ih nema. naime:

Vjerovali ili ne, ovo je nešto što mnogi korisnici Linuxa ne mogu savladati. Na Haikuu se sve radi automatski!

• ELF datoteke koje nemaju bit izvršnosti dobijaju ga automatski kada se dvaput klikne u upravitelju datoteka.
• Aplikacije mogu imati ugrađene resurse, kao što su ikone, koje se prikazuju u upravitelju datotekama. Nema potrebe da kopirate gomilu slika u posebne direktorijume sa ikonama, pa stoga nema potrebe da ih čistite nakon brisanja ili premještanja aplikacije.
• Postoji baza podataka za povezivanje aplikacija sa dokumentima, za to nema potrebe za kopiranjem datoteka.
• U direktoriju lib/ pored izvršne datoteke, biblioteke se pretražuju po defaultu.
• Ne postoje brojne distribucije i desktop okruženja; sve što radi, radi svuda.
• Ne postoji poseban modul za pokretanje koji se razlikuje od direktorija aplikacija.
• Aplikacije nemaju ugrađene apsolutne putanje do svojih resursa; imaju posebne funkcije za određivanje lokacije u vrijeme izvođenja.
• Predstavljena je ideja komprimiranih slika sistema datoteka: ovo je bilo koji hpkg paket. Sve ih montira kernel.
• Svaki fajl otvara aplikacija koja ga je kreirala, osim ako izričito ne navedete drugačije. Kako je ovo cool!

Dvije png datoteke. Obratite pažnju na različite ikone koje označavaju da će ih otvoriti različite aplikacije kada ih dvaput kliknete. Također imajte na umu padajući meni "Otvori sa:" gdje korisnik može odabrati pojedinačnu aplikaciju. Kako jednostavno!

Čini se da mnoga štaka i zaobilazna rješenja koja zahtijeva AppImage na Linuxu postaju nepotrebna na Haiku-u, koji u svojoj srži ima jednostavnost i sofisticiranost zbog kojih može zadovoljiti većinu naših potreba.

Da li su Haiku-u ipak potrebni paketi aplikacija?

Ovo dovodi do velikog pitanja. Da je za red veličine lakše napraviti sistem kao što je AppImage na Haikuu nego na Linuxu, da li bi to bilo vredno uraditi? Ili je Haiku, sa svojim hpkg sistemom paketa, efektivno eliminisao potrebu za razvojem takve ideje? Pa, da bismo odgovorili, moramo pogledati motivaciju koja stoji iza postojanja AppImages-a.

Perspektiva korisnika

Pogledajmo našeg krajnjeg korisnika:

• Želim da instaliram aplikaciju bez traženja administratorske (root) lozinke. Ne postoji koncept administratora na Haiku-u, korisnik ima potpunu kontrolu jer je to lični sistem! (U principu, ovo možete zamisliti u multiplayer modu, nadam se da će programeri biti jednostavni)
• Želim da dobijem najnovije i najbolje verzije aplikacija, bez čekanja da se pojave u mojoj distribuciji (najčešće to znači „nikad“, barem ako ne ažuriram ceo operativni sistem). Na Haikuu je to "riješeno" plutajućim izdanjima. To znači da je moguće dobiti najnovije i najbolje verzije aplikacija, ali da biste to učinili morate stalno ažurirati ostatak sistema, efektivno ga pretvarajući u „pokretnu metu“.
• Želim nekoliko verzija iste aplikacije jednu pored druge, jer ne postoji način da se zna šta je pokvareno u najnovijoj verziji, ili, recimo, ja, kao web programer, moram da testiram svoj rad u različitim verzijama pretraživača. Haiku rešava prvi problem, ali ne i drugi. Vraćaju se ažuriranja, ali samo za cijeli sistem; nemoguće je (koliko ja znam) istovremeno pokrenuti, na primjer, nekoliko verzija WebPositive-a ili LibreOffice-a.

Jedan od programera piše:

U suštini razlog je sljedeći: slučaj upotrebe je toliko rijedak da optimizacija za njega nema smisla; tretirati ga kao poseban slučaj u HaikuPortsu čini se više nego prihvatljivim.

• Moram da držim aplikacije tamo gde mi se sviđaju, a ne na svom pokretačkom disku. Često mi ponestane prostora na disku, tako da moram da povežem eksterni disk ili mrežni direktorijum za skladištenje aplikacija (sve verzije koje sam preuzeo). Ako povežem takav disk, potrebno je da se aplikacije pokreću dvostrukim klikom. Haiku čuva stare verzije paketa, ali ne znam kako da ih premestim na eksterni disk, ili kako da kasnije pokrenem aplikacije odatle.

Komentar programera:

Tehnički, ovo je već moguće pomoću naredbe mount. Naravno, napravićemo GUI za ovo čim budemo imali dovoljno zainteresovanih korisnika.

• Ne trebaju mi ​​milioni datoteka raštrkanih po sistemu datoteka kojima ne mogu sam ručno upravljati. Želim jednu datoteku po aplikaciji koju mogu lako preuzeti, premjestiti, izbrisati. Na Haiku-u se ovaj problem rješava korištenjem paketa .hpkg, koji prenosi, na primjer, python, iz hiljada datoteka u jedan. Ali ako postoji, na primjer, Scribus koji koristi python, onda moram imati posla s najmanje dva fajla. I moram voditi računa da zadržim njihove verzije koje funkcioniraju jedna s drugom.

Više verzija AppImages-a rade jedna pored druge na istom Linuxu

Perspektiva programera aplikacija

Pogledajmo sa stanovišta programera aplikacija:

• Želim kontrolirati cjelokupno korisničko iskustvo. Ne želim da zavisim od operativnog sistema koji će mi reći kada i kako da objavim aplikacije. Haiku dozvoljava programerima da rade sa sopstvenim hpkg repozitorijumima, ali to znači da će korisnici morati da ih podese ručno, što ideju čini "manje atraktivnom".
• Imam stranicu za preuzimanje na svojoj web stranici gdje distribuiram .exe za Windows, .dmg za Mac i .AppImage za Linux. Ili možda želim da unovčim pristup ovoj stranici, sve je moguće? Šta da stavim tamo za Haiku? Fajl je dovoljan .hpkg sa zavisnostima samo od HaikuPorts-a
• Moj softver zahtijeva određene verzije drugog softvera. Na primjer, poznato je da Krita zahtijeva zakrpljenu verziju Qt-a, ili Qt koji je fino podešen na određenu verziju Krite, barem dok se zakrpe ne vrate u Qt. Možete upakovati svoj Qt za svoju aplikaciju u paket .hpkg, ali to najvjerovatnije nije dobrodošlo.

Redovna stranica za preuzimanje aplikacija. Šta da objavim ovdje za Haiku?

Hoće li paketi (postoje kao direktoriji aplikacija poput AppDir ili .app u Apple stilu) i/ili slike (u obliku visoko modificiranih AppImages ili .dmg od Apple) aplikacija koristan dodatak Haiku desktop okruženju? Ili će to razvodniti cijelu sliku i dovesti do fragmentacije, a time i dodati složenost? Razderan sam: s jedne strane, ljepota i sofisticiranost haikua zasnovana je na činjenici da obično postoji jedan način da se nešto uradi, a ne mnogo. S druge strane, većina infrastrukture za kataloge i/ili pakete aplikacija je već uspostavljena, tako da sistem vapi da preostalih nekoliko posto stane na svoje mjesto.

Prema programeru gospodin. waddlesplash

Na Linuxu su (katalozi i kompleti za aplikacije, - cca. prevodilac) su najvjerovatnije tehničko rješenje sistemskih problema. U Haiku-u radije jednostavno rješavamo sistemske probleme.

Šta ti misliš?

Prije nego odgovorite...

Čekaj, hajde da izvršimo brzu provjeru stvarnosti: zapravo direktorije aplikacija - već dio Haikua:

Direktoriji aplikacija već postoje na Haiku-u, ali još nisu podržani u upravitelju datotekama

Oni jednostavno nisu tako dobro podržani kao, recimo, Macintosh Finder. Kako bi bilo cool da direktorij QtCreator ima ime i ikonu "QtCreator" u gornjem lijevom kutu, pokretanje aplikacije kada se dvaput klikne?

Već malo ranije pitan:

Jeste li sigurni da možete pokrenuti svoje decenije stare aplikacije danas kada su sve trgovine aplikacija i distribucijski repozitoriji zaboravili na njih i njihove ovisnosti? Jeste li sigurni da ćete i dalje moći pristupiti svom trenutnom poslu u budućnosti?

Da li već postoji odgovor od Haikua, ili mogu katalozi i paketi aplikacija pomoći ovdje? Mislim da mogu.

Prema riječima mr. waddlesplash:

Da, imamo odgovor na pitanje: jednostavno ćemo podržavati ove aplikacije onoliko dugo koliko je potrebno dok neko ne bude mogao pročitati njihove formate datoteka na pravi način ili pružiti funkcionalnost jedan na jedan. Naša posvećenost podršci BeOS R5 aplikacijama na Haikuu je dokaz ovoga...

Ovo je sigurno!

Koji pravac akcije treba da preduzme Haiku?

Mogu zamisliti mirnu koegzistenciju hpkg-a, direktorija i slika aplikacija:

• Sistemski softver koristi .hpkg
• Za softver koji se najčešće koristi (posebno onaj koji treba da zakaže nova izdanja), koristite .hpkg (otprilike 80% svih slučajeva)
• Neki instalirani putem .hpkg, aplikacije će imati koristi od prelaska na infrastrukturu direktorija aplikacija (npr. QtCreator): oni će se distribuirati kao .hpkg, kao prije.

gospodin. waddlesplash piše:

Ako sve što trebate je da pregledate aplikacije u /system/apps, umjesto toga trebalo bi da direktorije u Deskbaru učinimo lakšim za upravljanje korisnicima, jer /system/apps nije predviđeno da ga korisnici redovno otvaraju i pregledaju (za razliku od MacOS-a). Za takve situacije Haiku ima drugačiju paradigmu, ali ova opcija je, u teoriji, prihvatljiva.

• Haiku dobija infrastrukturu za pokretanje slika aplikacija, noćne, kontinuirane i testne verzije softvera, kao i za slučajeve kada korisnik želi da ga „zamrzne na vreme“, za privatni i interni softver i druge slučajeve posebne upotrebe (oko 20% od svega). Ove slike sadrže datoteke potrebne za pokretanje aplikacije .hpkg, montira sistem, a nakon završetka aplikacije - demontira. (Možda bi upravitelj datoteka mogao staviti fajlove .hpkg u slike aplikacije, automatski ili na zahtjev korisnika - pa, kao kada prevučete aplikaciju u mrežni direktorij ili vanjski disk. To je samo pesma! Ili bolje rečeno, poezija - haiku.) S druge strane, korisnik može poželeti da instalira sadržaj slike u obliku fajlova.hpkg, nakon čega će biti ažurirani i obrađeni na isti način kao da su instalirani preko HaikuDepota... Treba da razmislimo).

Citat mr. waddlesplash:

Pokretanje aplikacija s vanjskih diskova ili mrežnih direktorija može biti korisno. A dodavanje mogućnosti konfigurisanja više "zona" za pkgman bi definitivno bila dobra karakteristika.

Takav sistem bi iskoristio prednosti hpkg-a, direktorija i slika aplikacija. Pojedinačno su dobri, ali zajedno će postati nepobedivi.

zaključak

Haiku ima okvir koji pruža jednostavno i sofisticirano korisničko iskustvo za PC, i nadilazi ono što se obično nudi za Linux PC. Paketni sistem .hpkg je jedan takav primjer, ali ostatak sistema je također prožet sofisticiranošću. Međutim, Haiku bi imao koristi od odgovarajuće podrške za imenike i slike aplikacije. Kako to najbolje uraditi, vredi razgovarati sa ljudima koji poznaju haiku, njegovu filozofiju i arhitekturu mnogo bolje od mene. Na kraju krajeva, koristim Haiku nešto više od nedelju dana. Ipak, vjerujem da će ova svježa perspektiva biti korisna Haikuovim dizajnerima, programerima i arhitektima. U najmanju ruku, bio bih srećan da im budem „sparing partner“. Imam preko 10 godina praktičnog iskustva sa katalozima i paketima Linux aplikacija i želeo bih da im nađem upotrebu u Haikuu, konceptu za koji mislim da se savršeno uklapaju. Potencijalna rješenja koja sam predložio nisu jedina istinita za probleme koje sam opisao, a ako Haiku tim odluči da pronađe druga, elegantnija, ja sam za to. U suštini, već razmišljam o ideji kako napraviti sistem hpkg još nevjerovatnije bez promjene načina na koji funkcionira. Ispostavilo se da je Haiku tim već dugo razmišljao o paketima aplikacija prilikom implementacije sistema za upravljanje paketima, ali je nažalost (mislim) ideja postala "zastarjela". Možda je vrijeme da ga oživite?

Probajte sami! Na kraju krajeva, Haiku projekat obezbeđuje slike za pokretanje sa DVD-a ili USB-a, generisane ежедневно.
Imate bilo kakvih pitanja? Pozivamo vas na rusko govorno područje telegram kanal.

Pregled grešaka: Kako pucati sebi u nogu u C i C++. Haiku OS zbirka recepata

od autor prevod: ovo je osmi i poslednji članak u seriji o haikuu.

Spisak članaka: Prvi Drugi Treći Četvrto Peto Šesto Sedmo

Samo registrovani korisnici mogu učestvovati u anketi. Prijavite semolim.

Ima li smisla portirati hpkg sistem na Linux?

• Da

• Nijedan

• Već implementirano, pisaću u komentarima

Glasalo je 20 korisnika. Uzdržano je bilo 5 korisnika.

izvor: www.habr.com