Još nešto: Haiku paketi aplikacija?

TL; DR: Može li Haiku dobiti odgovarajuću podršku za aplikacijske pakete, kao što su direktoriji aplikacija (kao .app na Macu) i/ili slike aplikacija (Linux AppImage)? Mislim da bi ovo bio vrijedan dodatak koji je lakše pravilno implementirati nego druge sustave budući da je većina infrastrukture već postavljena.

Prije tjedan dana Otkrio sam Haiku, neočekivano dobar sustav. Pa, budući da sam već dugo zainteresiran za imenike i slike aplikacija (nadahnut jednostavnošću Macintosha), nije čudno da mi je ideja pala na pamet...

Za potpuno razumijevanje, ja sam kreator i autor AppImagea, formata distribucije Linux aplikacija koji cilja na jednostavnost Maca i daje potpunu kontrolu autorima aplikacija i krajnjim korisnicima (ako želite znati više, pogledajte wiki и dokumentacija).

Što ako napravimo AppImage za Haiku?

Razmislimo malo, čisto teorijski: što treba napraviti da bi se dobilo AppImage, ili nešto slično, na Haiku? Nije potrebno stvarati nešto upravo sada, jer sustav koji već postoji u Haikuu radi nevjerojatno, ali bi zamišljeni eksperiment dobro došao. Također pokazuje sofisticiranost Haikua, u usporedbi s Linux desktop okruženjima, gdje su takve stvari užasno teške (imam pravo to reći: mučim se s otklanjanjem pogrešaka već 10 godina).

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

Prvo, što je AppImage? Ovo je sustav za puštanje aplikacija trećih strana (npr. Ultimaker lijek), omogućujući da se aplikacije izdaju kada i kako žele: nema potrebe za poznavanjem specifičnosti raznih distribucija, pravila izgradnje ili izgradnje infrastrukture, nije potrebna podrška održavatelja i ne govore korisnicima što (ne) mogu instalirati na svojim računalima. 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 AppImagea, slično kao i Haiku paketi .hpkg montiran, a nikada instaliran u uobičajenom smislu.

Tijekom više od 10 godina postojanja, AppImage je stekao privlačnost i popularnost: sam Linus Torvalds ga je javno podržao, a uobičajeni projekti (na primjer, LibreOffice, Krita, Inkscape, Scribus, ImageMagick) prihvatili su ga kao glavni način za distribuciju kontinuiranih ili noćnih nadogradnji, ne ometajući instalirane ili deinstalirane korisničke aplikacije. Međutim, desktop okruženja i distribucije Linuxa najčešće se još uvijek drže tradicionalnog, centraliziranog modela distribucije temeljenog na održavanju i/ili promiču vlastito poslovno poslovanje i/ili inženjerske programe temeljene na Flatpak (RedHat, Fedora, GNOME) i Lijep (Canonical, Ubuntu). Dolazi smiješno.

Kako radi

• Svaka AppImage sadrži 2 dijela: mali ELF dvostrukog klika (tzv. runtime.c), nakon čega slijedi slika datotečnog sustava SquashFS.

• Datotečni sustav SquashFS sadrži sadržaj aplikacije i sve što je potrebno za njezino pokretanje, što se pri zdravoj pameti ne može smatrati dijelom zadane instalacije za svaki noviji ciljni sustav (Linux distribucija). Također sadrži metapodatke, kao što su naziv aplikacije, ikone, MIME vrste itd., itd.

• Kada ga pokrene korisnik, runtime koristi FUSE i squashfuse za montiranje datotečnog sustava, a zatim upravlja pokretanjem neke ulazne točke (aka AppRun) unutar montirane AppImage.
  Datotečni sustav se demontira nakon završetka procesa.

Sve izgleda jednostavno.

A ove stvari sve kompliciraju:

• S takvom raznolikošću distribucija Linuxa, ništa se "pri zdravoj pameti" ne može nazvati "dijelom zadane instalacije za svaki novi ciljni sustav." Ovaj problem rješavamo izgradnjom excludelist, što vam omogućuje da odredite što će biti upakirano u AppImage, a što će se morati odnijeti negdje drugdje. U isto vrijeme, ponekad promašimo, unatoč činjenici da, općenito, sve radi odlično. Iz tog razloga preporučujemo da kreatori paketa testiraju AppImages na svim ciljnim sustavima (distribucijama).
• Korisni teret aplikacije mora se moći premjestiti preko datotečnog sustava. Nažalost, mnoge aplikacije imaju tvrdo kodirane apsolutne putove do, na primjer, resursa u /usr/share. Ovo se mora nekako popraviti. Osim toga, morate ili izvesti LD_LIBRARY_PATH, ili popraviti rpath tako da učitavač može pronaći srodne biblioteke. Prva metoda ima svoje nedostatke (koji se prevladavaju na složene načine), a druga je jednostavno glomazna.
• Najveća UX zamka za korisnike je to postaviti izvršni bit AppImage datoteka nakon preuzimanja. Vjerovali ili ne, nekima je to prava prepreka. Potreba za postavljanjem bita izvršnosti glomazna je čak i za iskusne korisnike. Kao zaobilazno rješenje, predložili smo instaliranje male usluge koja nadzire AppImage datoteke i postavlja njihovu izvršnost. U svom čistom obliku, to nije najbolje rješenje, jer neće raditi izvan kutije. Distribucije Linuxa ne pružaju ovu uslugu, stoga korisnici imaju loše iskustvo odmah nakon postavljanja.
• Korisnici Linuxa očekuju da nova aplikacija ima ikonu u početnom izborniku. Ne možete reći sustavu: "Vidi, tu je nova aplikacija, idemo raditi." Umjesto toga, prema specifikaciji XDG, trebate kopirati datoteku .desktop na pravo mjesto u /usr za instalaciju na cijelom sustavu ili u $HOME za pojedinca. Ikone određenih veličina, prema XDG specifikaciji, potrebno je postaviti na određena mjesta u usr ili $HOME, a zatim pokrenite naredbe u radnom okruženju za ažuriranje predmemorije ikona ili se nadajte da će upravitelj radnog okruženja to shvatiti i automatski otkriti sve. Isto je s MIME vrstama. Kao zaobilazno rješenje, predlaže se korištenje iste usluge, koja će, osim postavljanja oznake izvršnosti, ako postoje ikone itd. u AppImageu, kopirajte ih iz AppImagea na prava mjesta prema XDG-u. Kada se izbriše ili premjesti, očekuje se da će usluga sve izbrisati. Naravno, postoje razlike u ponašanju svakog radnog okruženja, u formatima grafičkih datoteka, njihovim veličinama, mjestima pohranjivanja i metodama ažuriranja predmemorija, što stvara problem. Ukratko, ova metoda je štaka.
• Ako gore navedeno nije dovoljno, još uvijek nema AppImage ikone u upravitelju datotekama. Svijet Linuxa još nije odlučio implementirati elficon (unatoč rasprava и provedba), stoga je nemoguće ugraditi ikonu izravno u aplikaciju. Tako ispada da aplikacije u upravitelju datotekama nemaju vlastite ikone (bez razlike, AppImage ili nešto treće), one su samo u početnom izborniku. Kao zaobilazno rješenje, koristimo minijature, mehanizam koji je izvorno dizajniran da omogući upraviteljima stolnih računala da prikažu minijaturne slike grafičkih datoteka kao svoje ikone. Posljedično, usluga za postavljanje bita izvršnosti također radi kao "minijaturizator", stvarajući i pišući minijature ikona na odgovarajuća mjesta /usr и $HOME. Ova usluga također vrši čišćenje ako se AppImage izbriše ili premjesti. Zbog činjenice da se svaki desktop manager ponaša malo drugačije, na primjer, u kojim formatima prihvaća ikone, u kojim veličinama ili na kojim mjestima, sve je to jako bolno.
• Aplikacija se jednostavno ruši prilikom izvođenja ako se pojave pogreške (na primjer, postoji biblioteka koja nije dio osnovnog sustava i nije isporučena u AppImageu), a nitko ne govori korisniku u GUI-ju što se točno događa. Počeli smo to zaobilaziti korištenjem obavijesti na radnoj površini, što znači da trebamo uhvatiti pogreške iz naredbenog retka, pretvoriti ih u korisniku razumljive poruke, koje zatim treba prikazati na radnoj površini. I naravno, svako okruženje radne površine ih obrađuje malo drugačije.
• U ovom trenutku (rujan 2019. - napomena prevoditelja) nisam pronašao jednostavan način da kažem sustavu da datoteka 1.png mora se otvoriti pomoću Krite, i 2.png - koristeći GIMP.

Mjesto pohrane za specifikacije za više stolnih računala koje se koriste u GNOME, KDE и Xfce je freedesktop.org

Postizanje razine sofisticiranosti koja je duboko utkana u haiku radno okruženje teško je, ako ne i nemoguće, zbog specifikacija XDG s freedesktop.org za cross-desktop, kao i implementacije desktop managera temeljene na ovim specifikacijama. Kao primjer možemo navesti jednu ikonu Firefoxa za cijeli sustav: očito 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 što svijet Linuxa može naučiti od Mac OS X-a da izbjegne zajebavanje integracije sustava. Ako imate vremena i zanima vas ovo, svakako pročitajte što je rekao Arnaud Gurdol, jedan od prvih Mac OS X inženjera:

Htjeli smo instalaciju aplikacije učiniti jednostavnom poput povlačenja ikone aplikacije s nekog mjesta (poslužitelj, vanjski pogon) na pogon vašeg računala. Da biste to učinili, aplikacijski paket pohranjuje sve informacije, uključujući ikone, verziju, vrstu datoteke koja se obrađuje, vrstu URL sheme koje sustav treba znati za obradu aplikacije. Ovo također uključuje informacije za 'centralnu pohranu' u bazi podataka Icon Services i Launch Services. Kako bi se podržala izvedba, aplikacije se 'otkrivaju' na nekoliko 'dobro poznatih' mjesta: direktorijima sustava i korisničkih aplikacija te nekim drugim automatski ako korisnik ode do Finder-a u direktoriju koji sadrži aplikaciju. U praksi je to vrlo dobro funkcioniralo.

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

Ne postoji ništa slično ovoj infrastrukturi na Linux stolnim računalima, pa tražimo zaobilazna rješenja za strukturna ograničenja u projektu AppImage.

Dolazi li haiku u pomoć?

I još jedna stvar: 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 sustavu frustrirajuće fragmentirane i složene u Linuxu. Cijeli sam izvještaj posvetio pitanjima vezanim uz Linux platformu za desktop okruženja (upućeni programeri potvrdili su da će sve tako ostati još jako dugo).

Moje izvješće o problemima Linux desktop okruženja u 2018

Čak je i Linus Torvalds priznao da je ideja o radnom prostoru propala zbog fragmentacije.

Lijepo je vidjeti Haiku!

Haiku sve čini nevjerojatno jednostavnim

Iako je naivan pristup "prenošenju" AppImagea na Haiku jednostavno pokušati izgraditi (uglavnom runtime.c i servis) njegove komponente (što bi čak moglo biti moguće!), to Haikuu neće donijeti mnogo koristi. Jer zapravo je većina tih problema riješena u haikuu i konceptualno su zdravi. Haiku pruža upravo one građevne blokove sistemske infrastrukture koje sam tako 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 prevladati. Na Haikuu se sve radi automatski!

• ELF datoteke koje nemaju bit izvršnosti dobivaju ga automatski kada se dvaput klikne u upravitelju datotekama.
• Aplikacije mogu imati ugrađene resurse, poput ikona, koje se prikazuju u upravitelju datotekama. Nema potrebe kopirati hrpu slika u posebne direktorije s ikonama, pa stoga nema potrebe čistiti ih nakon brisanja ili premještanja aplikacije.
• Postoji baza podataka za povezivanje aplikacija s dokumentima, za to nema potrebe kopirati datoteke.
• U direktoriju lib/ pored izvršne datoteke, biblioteke se pretražuju prema zadanim postavkama.
• Ne postoje brojne distribucije i desktop okruženja, što god radi, radi svugdje.
• Ne postoji zasebni modul za pokretanje koji se razlikuje od imenika aplikacija.
• Aplikacije nemaju ugrađene apsolutne staze do svojih resursa; one imaju posebne funkcije za određivanje lokacije tijekom izvođenja.
• Uvedena je ideja komprimiranih slika datotečnog sustava: ovo je bilo koji hpkg paket. Sve njih montira kernel.
• Svaku datoteku otvara aplikacija koja ju je stvorila, osim ako izričito ne odredite drugačije. Kako je ovo super!

Dvije png datoteke. Obratite pozornost na različite ikone koje pokazuju da će ih otvoriti različite aplikacije kada se dvaput klikne. Također imajte na umu padajući izbornik "Otvori s:" na kojem korisnik može odabrati pojedinačnu aplikaciju. Kako jednostavno!

Čini se da mnoge štake i zaobilazna rješenja koja zahtijeva AppImage na Linuxu postaju nepotrebna na Haikuu, koji u svojoj srži ima jednostavnost i sofisticiranost zbog kojih može podnijeti većinu naših potreba.

Treba li Haiku ipak pakete aplikacija?

Ovo dovodi do velikog pitanja. Da je za red veličine lakše stvoriti sustav poput AppImagea na Haikuu nego na Linuxu, bi li to bilo vrijedno? Ili je Haiku, sa svojim sustavom paketa hpkg, učinkovito eliminirao potrebu za razvojem takve ideje? Pa, da bismo odgovorili, moramo pogledati motivaciju iza postojanja AppImagesa.

Korisnička perspektiva

Pogledajmo našeg krajnjeg korisnika:

• Želim instalirati aplikaciju bez traženja administratorske (root) lozinke. Na Haikuu ne postoji koncept administratora, korisnik ima potpunu kontrolu jer je to osobni sustav! (U principu, ovo možete zamisliti u načinu rada za više igrača, nadam se da će programeri to učiniti jednostavnim)
• Želim dobiti najnovije i najbolje verzije aplikacija, bez čekanja da se pojave u mojoj distribuciji (najčešće to znači "nikada", barem ako ne ažuriram cijeli operativni sustav). 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 sustava, učinkovito ga pretvarajući u "pokretnu metu".
• Želim nekoliko verzija iste aplikacije jednu pored druge, budući da ne postoji način da znam što je pokvareno u zadnjoj verziji, ili, recimo, ja, kao web programer, moram testirati svoj rad pod različitim verzijama preglednika. Haiku rješava prvi problem, ali ne i drugi. Ažuriranja se vraćaju, ali samo za cijeli sustav; nemoguće je (koliko ja znam) pokrenuti, na primjer, nekoliko verzija WebPositive ili LibreOfficea u isto vrijeme.

Jedan od programera piše:

U biti, obrazloženje je sljedeće: 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.

• Aplikacije trebam držati tamo gdje mi se sviđaju, a ne na pogonu za pokretanje. Često mi ponestane prostora na disku, pa moram spojiti vanjski pogon ili mrežni direktorij za pohranu aplikacija (sve verzije koje sam preuzeo). Ako spojim takav disk, trebam aplikacije koje se pokreću duplim klikom. Haiku sprema stare verzije paketa, ali ne znam kako ih premjestiti na vanjski disk, niti kako kasnije odatle pokrenuti aplikacije.

Komentar programera:

Tehnički, to je već moguće s naredbom mount. Naravno, napravit ćemo GUI za to čim budemo imali dovoljno zainteresiranih korisnika.

• Ne trebaju mi ​​milijuni datoteka razasutih po datotečnom sustavu kojima ne mogu sam ručno upravljati. Želim jednu datoteku po aplikaciji koju mogu jednostavno preuzeti, premjestiti, izbrisati. Na Haikuu je ovaj problem riješen pomoću paketa .hpkg, koji prenose, primjerice, python, iz tisuća datoteka u jednu. Ali ako postoji, na primjer, Scribus koji koristi python, onda se moram nositi s najmanje dvije datoteke. I moram paziti da zadržim njihove verzije koje rade jedna s drugom.

Višestruke verzije AppImages-a rade jedna uz drugu na istom Linuxu

Perspektiva programera aplikacija

Pogledajmo sa stajališta programera aplikacije:

• Želim kontrolirati cjelokupno korisničko iskustvo. Ne želim ovisiti o operativnom sustavu da mi govori kada i kako trebam izdati aplikacije. Haiku programerima omogućuje rad s vlastitim hpkg spremištima, ali to znači da će ih korisnici morati postaviti ručno, što ideju čini "manje privlačnom".
• Na svojoj web stranici imam stranicu za preuzimanje na kojoj distribuiram .exe za Windows, .dmg za Mac i .AppImage za Linux. Ili možda želim unovčiti pristup ovoj stranici, sve je moguće? Što bih trebao staviti tamo za haiku? Datoteka je dovoljna .hpkg s ovisnostima samo o HaikuPortsu
• Moj softver zahtijeva određene verzije drugog softvera. Na primjer, poznato je da Krita zahtijeva zakrpanu 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 upakirati vlastiti Qt za svoju aplikaciju u paket .hpkg, ali najvjerojatnije to nije dobrodošlo.

Redovna stranica za preuzimanje aplikacije. Što bih trebao objaviti 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 Applea) aplikacije koristan dodatak Haiku desktop okruženju? Ili će razvodniti cjelokupnu sliku i dovesti do fragmentacije, a time i dodati složenost? Razdiran sam: s jedne strane, ljepota i sofisticiranost haikua temelje se na činjenici da obično postoji jedan način da se nešto učini, a ne više. S druge strane, većina infrastrukture za kataloge i/ili pakete aplikacija već je postavljena, pa sustav vapi za preostalih nekoliko postotaka da sjednu na svoje mjesto.

Prema programeru gosp. geganje

Na Linuxu su (katalozi i paketi aplikacija, - cca. prevoditelj) najvjerojatnije su tehničko rješenje za sustavne probleme. U Haiku radije jednostavno rješavamo probleme sustava.

Što misliš?

Prije nego odgovoriš...

Čekaj, napravimo kratku provjeru stvarnosti: zapravo imenici aplikacija - već dio haikua:

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

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

Već sam malo ranije pitao:

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

Postoji li već odgovor od Haikua ili tu mogu pomoći katalozi i paketi aplikacija? Mislim da mogu.

Prema riječima mr. geganje:

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

Ovo je sigurno!

Što bi haiku trebao poduzeti?

Mogu zamisliti miran suživot hpkg-a, imenika i slika aplikacija:

• Sistemski softver koristi .hpkg
• Za najčešće korišteni softver (posebno za one koji trebaju planirati tekuća izdanja), koristite .hpkg (otprilike 80% svih slučajeva)
• Neki instalirani putem .hpkg, aplikacije će imati koristi od prelaska na infrastrukturu imenika aplikacija (npr. QtCreator): one će se distribuirati kao .hpkg, kao prije.

gosp. waddlesplash piše:

Ako sve što trebate je pregledati aplikacije u /system/apps, umjesto toga trebali bismo učiniti direktorije u Deskbaru lakšim za rukovanje za korisnike, jer /system/apps nije namijenjen redovitom otvaranju i pregledu od strane korisnika (za razliku od MacOS-a). Za takve situacije haiku ima drugačiju paradigmu, ali ta je opcija, teoretski, prihvatljiva.

• Haiku dobiva infrastrukturu za pokretanje slika aplikacija, noćne, kontinuirane i testne nadogradnje softvera, kao i za slučajeve kada ga korisnik želi “zamrznuti na vrijeme”, za privatni i interni softver, te druge posebne slučajeve upotrebe (oko 20% od svega). Ove slike sadrže datoteke potrebne za pokretanje aplikacije .hpkg, montiran od strane sustava, a nakon završetka aplikacije - demontiran. (Možda bi upravitelj datoteka mogao staviti datoteke .hpkg u slike aplikacija, automatski ili na zahtjev korisnika - pa, kao kad povučete aplikaciju u mrežni direktorij ili vanjski pogon. To je samo pjesma! Ili bolje rečeno, poezija - haiku.) S druge strane, korisnik može htjeti instalirati sadržaj slike u obliku datoteka.hpkg, nakon čega će biti ažurirani i obrađeni na isti način kao da su instalirani kroz HaikuDepot... Moramo pametovati).

Citat mr. geganje:

Pokretanje aplikacija s vanjskih diskova ili mrežnih direktorija može biti korisno. A dodavanje mogućnosti konfiguriranja više "zona" za pkgman definitivno bi bila zgodna značajka.

Takav bi sustav iskoristio hpkg, direktorije i slike aplikacija. Pojedinačno su dobri, ali zajedno će postati nepobjedivi.

Zaključak

Haiku ima okvir koji pruža jednostavno i sofisticirano korisničko iskustvo za osobno računalo i nadilazi ono što se obično nudi za osobno računalo s Linuxom. Paketni sustav .hpkg jedan je od takvih primjera, ali i ostatak sustava prožet je sofisticiranošću. Međutim, Haiku bi imao koristi od odgovarajuće podrške direktorija i slike aplikacije. Kako to najbolje učiniti vrijedi razgovarati s ljudima koji poznaju haiku, njegovu filozofiju i arhitekturu puno bolje od mene. Uostalom, Haiku koristim nešto više od tjedan dana. Ipak, vjerujem da će Haiku dizajneri, programeri i arhitekti imati koristi od ove svježe perspektive. U najmanju ruku, rado bih bio njihov “sparing partner”. Imam više od 10 godina praktičnog iskustva s katalozima i paketima Linux aplikacija i želio bih im pronaći primjenu u Haikuu, za koji mislim da savršeno odgovaraju. Moguća rješenja koja sam predložio nipošto nisu jedina ispravna za probleme koje sam opisao, a ako Haiku tim odluči pronaći druga, elegantnija, ja sam za to. Uglavnom, već razmišljam o ideji kako napraviti sustav hpkg još nevjerojatnije bez promjene načina na koji funkcionira. Ispostavilo se da je Haiku tim dugo razmišljao o paketima aplikacija prilikom implementacije sustava za upravljanje paketima, ali je nažalost (mislim) ideja postala "zastarjela". Možda je vrijeme da ga oživimo?

Pokušajte sami! Na kraju krajeva, projekt Haiku pruža generirane slike za dizanje s DVD-a ili USB-a dnevno.
Imate li kakvih pitanja? Pozivamo vas na ruski govorni jezik brzojavni kanal.

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

Iz Autor prijevod: ovo je osmi i posljednji članak u seriji o haikuu.

Popis članaka: Prvi Drugi Treći Četvrta peti Šesti Sedmi

U anketi mogu sudjelovati samo registrirani korisnici. Prijaviti se, molim.

Ima li smisla prenijeti hpkg sustav na Linux?

• Da

• Ne

• Već implementirano, napisat ću u komentarima

Glasovalo je 20 korisnika. Suzdržano je bilo 5 korisnika.

Izvor: www.habr.com