🥇Još nešto: paketi aplikacija Haiku?

TL;DR: može li Haiku dobiti odgovarajuću podršku za aplikacijske pakete, na primjer kataloge aplikacija (kao .app na Macu) i/ili slike aplikacija (Linux AppImage)? Čini mi se da bi to bilo dostojno dodatka kojeg bi bilo lakše implementirati nego u drugim sustavima, budući da velika većina infrastrukture već postoji.

Prije tjedan dana otkrio sam Haiku, neočekivano dobar sustav. A budući da se dugo zanimam za kataloge i slike aplikacija (nadahnut jednostavnošću MacIntosha), nije iznenađujuće da mi je ta ideja pala na pamet…

Za potpuni kontekst: ja sam tvorac i autor AppImage, formata za distribuciju aplikacija na Linuxu, usmjerenog na jednostavnost Maca i pružanje potpune kontrole autorima aplikacija i krajnjim korisnicima (želite li saznati više - pogledajte wiki i dokumentaciju).

Što ako napravimo AppImage za Haiku?

Razmislimo malo teoretski: što bi trebalo učiniti da bismo dobili AppImage, ili nešto slično, na Haiku? Nije nužno odmah nešto stvoriti, jer sustav koji već postoji u Haiku radi izvanredno, dok bi zamišljeni eksperiment bio zanimljiv. Osim toga, pokazuje sofisticiranost Haikua u usporedbi s radnim okruženjima Linuxa, gdje su slične stvari strašno teške (imam pravo to reći: već 10 godina se mučim s ispravcima).

Na Macintosh sustavu 1 svaka aplikacija bila je zasebna datoteka, „upravljana“ u Finderu. Koristeći AppImage pokušavam ponovno stvoriti to iskustvo na Linuxu.

Prvo, što je AppImage? To je sustav za otpuštanje aplikacija trećih strana (na primjer, Ultimaker Cura), koji omogućava izdavanje aplikacija kad god i kako im se sviđa: nije potrebno poznavati posebnosti različitih distribucija, politike izgradnje ili infrastrukturu izgradnje, nije potrebna podrška održavatelja, i oni ne govore korisnicima što (ne) mogu instalirati na svojim računalima. AppImage se treba razumjeti kao nešto što liči na paket za Mac u formatu .app unutar slike diska .dmg. Glavna razlika je u tome što se aplikacije ne kopiraju, nego ostaju unutar AppImage-a zauvijek, otprilike na način da se paketi Haiku .hpkg montiraju i nikada se ne instaliraju u običnom smislu.

AppImage je tijekom više od 10 godina svoje egzistencije stekao određenu privlačnost i popularnost: sam Linus Torvalds ga je javno odobrio, a poznati projekti (poput LibreOffice, Krita, Inkscape, Scribus, ImageMagick) usvojili su ga kao glavni način distribucije kontinuiranih ili noćnih izdanja, ne ometajući instalirane ili neinstalirane aplikacije korisnika. Međutim, radna okruženja i distribucije Linuxa najčešće se i dalje drže tradicionalnog, centraliziranog modela distribucije temeljenog na pratećim i/ili promicanju vlastitih korporativnih poslovnih i/ili inženjerskih programa temeljenih na Flatpak (RedHat, Fedora, GNOME) i Snappy (Canonical, Ubuntu). Dolazi do smiješnog.

Kako sve funkcionira

Svaki AppImage sadrži 2 dijela: mali izvršni ELF pokretni (t. naz. runtime.c), s sljedećim oblikom datotečnog sustava SquashFS.

Datotečni sustav SquashFS sadrži korisnu težinu u obliku aplikacije i svega što je potrebno za njezino pokretanje, što se ne može zdravog razuma smatrati dijelom zadane instalacije za svaki dovoljno svjež ciljanu sustavu (distributiv Linuxa). Također sadrži metapodatke, na primjer naziv aplikacije, ikone, MIME tipove i drugo.

Pri pokretanju korisnik koristi FUSE i squashfuse za montiranje datotečnog sustava, nakon čega obrađuje pokretanje neke točke ulaza (tzv. AppRun) unutar montiranog AppImagea.
Datotečni sustav se demontira nakon što proces završi.

Izgleda da je sve jednostavno.

A te stvari sve kompliciraju:

s tolikim različitim distribucijama Linuxa ništa se više ne može „zdravim razumom“ nazvati „dijelom zadane instalacije za svaki svjež ciljni sustav“. Ovu problematiku zaobilazimo putem izrade excludelist, koji omogućuje određivanje što će biti upakirano u AppImage, a što će trebati uzeti negdje drugdje. Pri tome ponekad promašujemo, unatoč tome što sve u cjelini dobro funkcionira. Iz tog razloga preporučujemo kreatorima paketa da testiraju AppImages na svim ciljnim sustavima (distribucijama).
Aplikacije u obliku korisne težine trebaju biti prenosive po datotečnom sustavu. Nažalost, u mnogim aplikacijama tvrdo su postavljeni apsolutni putovi do, na primjer, resursa u /usr/share. Ovo treba nekako ispraviti. Osim toga, potrebno je ili eksportirati LD_LIBRARY_PATH, ili ispraviti rpath da bi učitavač mogao pronaći povezane biblioteke. Prvi način ima svoje nedostatke (koji se rješavaju složenim načinima), dok je drugi jednostavno glomazan.
Najveća UX zamka za korisnike je to što treba postaviti izvršni bit datoteci AppImage nakon preuzimanja. Vjerovali ili ne, za nekoga je to stvarna prepreka. Potreba za postavljanjem izvršnog bita je glomazna čak i za iskusne korisnike. Kao zaobilazno rješenje, predložili smo instalaciju malog servisa koji prati datoteke AppImage i postavlja im bit izvršenja. U svom čistom obliku, to nije najbolje rješenje, jer neće raditi 'iz kutije'. Linux distribucije ne isporučuju ovu uslugu, stoga korisnicima 'iz kutije' nije dobro.
Korisnici Linuxa očekuju da će nova aplikacija imati ikonu u izborniku za pokretanje. Sustavu ne možeš reći: 'Gledaj, nova aplikacija, hajde da radimo'. Umjesto toga, prema XDG specifikaciji, treba kopirati datoteku .desktop na pravo mjesto u /usr za sustavnu instalaciju, ili u $HOME za pojedinačnu. Ikone određenih dimenzija, prema XDG specifikaciji, treba smjestiti na određena mjesta u usr ili $HOME, nakon čega treba pokrenuti naredbe u radnom okruženju za ažuriranje predmemorije ikona, ili se nadati da će upravitelj radnog okruženja prepoznati i automatski sve otkriti. Slično je i s MIME tipovima. Kao zaobilazno rješenje, predlaže se korištenje istog servisa koji osim postavljanja oznake izvršenja, u prisutnosti ikona i drugih stvari u AppImage, kopira ih iz AppImage na pravo mjesto prema XDG. Pri brisanju ili premještanju, servis bi se pretpostavljao da će očistiti sve. Naravno, postoje razlike u ponašanju svakog radnog okruženja, u formatima grafičkih datoteka, njihovim dimenzijama, mjestima pohrane i načinima ažuriranja predmemorija, što stvara problem. Ukratko, ovaj način je 'zaštitni pojas'.
Ako prethodno navedeno nije dovoljno, u upravitelju datoteka nema ni ikone AppImage. U svijetu Linuxa još uvijek nije donesena odluka o implementaciji elficon (unatoč na diskusija i implementaciji), tako da je nemoguće integrirati ikonu direktno u aplikaciju. Tako dolazimo do situacije da aplikacije u upravitelju datoteka nemaju vlastite ikone (bilo da se radi o AppImage ili nečemu drugom), one postoje samo u izborniku za pokretanje. Kao rješenje, koristimo miniatures - mehanizam koji je prvotno razvijen kako bi upravitelji radne površine mogli prikazivati smanjene slike za pregled grafičkih datoteka kao njihove ikone. Stoga usluga za postavljanje bitne izvršivosti također funkcionira kao „miniaturizer“, stvarajući i snimajući miniatures ikona na odgovarajuća mjesta /usr i $HOME. Također, ova usluga obavlja čišćenje kada se AppImage ukloni ili premjesti. S obzirom na to da svaki upravitelj radne površine malo drugačije reagira, na primjer, u kojim formatima prihvaća ikone, u kojim veličinama ili na kojim mjestima, to može biti stvarno bolno.
Aplikacija jednostavno pada pri izvršavanju ako dođe do grešaka (na primjer, postoji biblioteka koja nije dio osnovnog sustava i nije isporučena u AppImage), a nitko ne obavještava korisnika u GUI-u što točno se događa. Počeli smo to zaobilaziti koristeći obavijesti na radnoj površini, što znači da moramo prikupiti greške iz naredbenog retka, pretvoriti ih u poruke razumljive korisnicima, koje potom treba prikazati na radnoj površini. I naravno, svako radno okruženje obrađuje ih malo drugačije.
Trenutno (rujan 2019. godine, — napomena prevoditelja) nisam pronašao jednostavan način da kažem sustavu da datoteku 1.png treba otvoriti s Kritom, a 2.png — sa GIMP-om.

Mjesto pohrane cross-desktop specifikacija korištenih u GNOME, KDE i Xfce je freedesktop.org

Postizanje razine sofisticiranosti, duboko utkane u radno okruženje Haiku, otežano je, da ne kažem „nemoguće“, zbog specifikacija XDG s freedesktop.org za cross-desktop, kao i implementacija upravitelja radne površine temeljenih na tim specifikacijama. Kao primjer možemo navesti jednu općenitu ikonu Firefox: očito autorima XDG nije palo na pamet da korisnik može imati više verzija iste aplikacije instalirane.

Ikone različitih verzija Firefoxa

Zanima me što bi svijet Linuxa mogao naučiti od Mac OS X-a kako bi izbjegao probleme s sistemskom integracijom. Ako imate vremena i bavite se tim, obavezno pročitajte što je rekao Arno Gourdol, jedan od prvih inženjera Mac OS X:

Željeli smo da instalacija aplikacije bude tako jednostavna kao povlačenje ikone aplikacije s nekog mjesta (poslužitelj, vanjski disk) na disk vašeg računala. Zbog toga paket aplikacije sadrži sve informacije, uključujući ikone, verziju, obrađivanu vrstu datoteke, tip URL sheme koju sustav treba znati za obradu aplikacije. Ovdje također spadaju informacije za 'centralizirano pohranjivanje' u bazi podataka Icon Services i Launch Services. Radi podrške performansama, aplikacije se 'otkrivaju' na nekoliko 'dobro poznatih' mjesta: u sistemskom i korisničkom direktoriju Applications, kao i na nekim drugim mjestima automatski, ako je korisnik prešao u Finder u direktorij koji sadrži aplikaciju. U praksi je to jako dobro funkcioniralo.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 sesija 144 — Mac OS X: pakiranje aplikacija i ispis dokumenata.

Ništa slično ovoj infrastrukturi ne postoji u radnim okruženjima Linuxa, pa tražimo zaobilazna rješenja oko strukturalnih ograničenja u projektu AppImage.

Zar Haiku žuri u pomoć?

I još: Linux platforme kao osnova radnih okruženja obično su tako nedovoljno specificirane da mnoge stvari koje su vrlo jednostavne u dosljednom sustavu s punim stogom, razočaraju fragmentiranošću i složenošću u Linuxu. Posvetio sam cijelu prezentaciju pitanjima vezanim uz Linux platformu za radna okruženja (oni koji znaju potvrdili su: sve će ostati tako još jako dugo).

Moja prezentacija o problemima radnih okruženja Linuxa 2018.

Čak je i Linus Torvalds priznao da je upravo zbog fragmentacije ideja radnih okruženja propala.

Drago mi je vidjeti Haiku!

S Haikuom postaje nevjerojatno jednostavno.

Iako je naivni pristup 'prijenosu' AppImage-a na Haiku jednostavno pokušati sastaviti njegove komponente (uglavnom runtime.c i servis), to neće donijeti veliku korist za Haiku. To je zato što je većina tih problema zapravo riješena na Haiku i koncepira se opravdano. Haiku pruža upravo one građevne blokove za sustavnu infrastrukturu koje sam dugo tražio u radnim okruženjima na Linux-u i teško mi je bilo povjerovati da ih tamo nema. Naime:

Vjerovali ili ne, ali to ne mogu savladati mnogi korisnici Linux-a. Na Haiku se sve radi automatski!

Elf datoteke koje nemaju izvršnu dozvolu automatski je dobijaju dvostrukim klikom u upravitelju datoteka.
Aplikacije mogu imati ugrađene resurse, poput ikona, koje se prikazuju u upravitelju datoteka. Nema potrebe za kopiranjem gomile slika u posebne direktorije za ikone, pa stoga ne treba ni čistiti nakon brisanja ili premještanja aplikacije.
Postoji baza podataka za povezivanje aplikacija s dokumentima, nije potrebno kopirati bilo kakve datoteke za to.
U direktoriju lib/ pored izvršne datoteke, biblioteke se prema zadanim postavkama traže.
Nema brojnih distribucija i okruženja radne površine, sve što radi – radi svugdje.
Ne postoji zaseban modul za pokretanje koji bi se razlikovao od direktorija Applications.
U aplikacijama nema ugrađenih apsolutnih putanja prema svojim resursima, postoje posebne funkcije za određivanje lokacije u vrijeme izvršenja.
Uvedena je ideja komprimiranih slika datotečnih sustava: to su svi hpk paketi. Svi se montiraju od strane jezgre.
Svaka datoteka se otvara pomoću aplikacije koja ju je stvorila, osim ako izričito nije navedeno nešto drugo. Kako je to super!

Dva png datoteke. Obratite pozornost na različite ikone, koje pokazuju da će se otvoriti različitim aplikacijama dvostrukim klikom. Također, obratite pozornost na padajući izbornik „Otvoriti s:” gdje korisnik može odabrati pojedinačnu aplikaciju. Kako jednostavno!

Izgleda da mnoge 'štake' i zaobilaznice potrebne AppImage-u na Linux-u postaju suvišne na Haiku, koja se temelji na jednostavnosti i sofisticiranosti, koja rješava većinu naših potreba.

Treba li Haiku konačno pakete aplikacija?

To dovodi do velikog pitanja. Ako bi stvaranje sustava poput AppImage na Haiku bilo znatno lakše nego na Linuxu, vrijedi li to pokušati? Ili je Haiku sa svojim sustavom paketa hpkg zapravo eliminirao potrebu za razvojem slične ideje? Pa, da bismo odgovorili, moramo pogledati motivaciju postojanja AppImages.

Pogled s korisničke strane

Pogledajmo našeg krajnjeg korisnika:

Želim instalirati aplikaciju bez traženja administratorske lozinke (root). Na Haiku ne postoji koncept administratora, korisnik ima potpunu kontrolu jer je to osobni sustav! (U načelu, to se može zamisliti i u višekorisničkom načinu, nadam se da će programeri zadržati jednostavnost)
Želim dobiti najnovije i najbolje verzije aplikacija, ne želim čekati da se pojave u mom distribuciji (najčešće to znači "nikada", barem ako ne ažuriram cijeli operativni sustav). Na Haiku je to "riješeno" s pomoću plutajućih izdanja. To znači da postoji mogućnost dobivanja najnovijih i najboljih verzija aplikacija, ali za to je potrebno stalno ažurirati i ostatak sustava, zapravo pretvarajući ga u "pokretni cilj"..
Želim imati nekoliko verzija iste aplikacije poredane, jer ne mogu znati što je pokvareno u posljednjoj verziji, ili, recimo, kao web programer, trebam provjeriti svoj rad na različitim verzijama preglednika. Na Haiku je prvi problem riješen, ali ne i drugi. Ažuriranja se vraćaju, ali samo za cijeli sustav, nije moguće ( koliko ja znam) pokrenuti, na primjer, nekoliko verzija WebPositive ili LibreOfficea istovremeno.

Jedan od programera piše:

U suštini, opravdanje je sljedeće: scenarij korištenja je toliko rijedak da optimizacija za njega nema smisla; obrada kao posebnog slučaja u HaikuPorts-u čini se više nego prihvatljivom.

Moram čuvati aplikacije gdje mi se sviđa, a ne na pokretačkom disku. Na diskovima često nemam dovoljno prostora, tako da moram priključivati vanjski disk ili mrežni direktorij za pohranu aplikacija (sve verzije koje sam preuzeo). Ako priključim takav disk — aplikacije trebaju raditi na dvostruki klik. Haiku čuva stare verzije paketa, ali ne znam kako ih premjestiti na vanjski disk, niti kako potom pokrenuti aplikacije odatle.

Komentar programera:

Tehnički, to je već moguće s mount timom. Naravno, napravit ćemo GUI za to čim se skupi dovoljno zainteresiranih korisnika.

Ne trebaju mi milioni datoteka raspršenih po datotečnom sustavu kojima ne mogu upravljati ručno. Želim jednu datoteku po aplikaciji, koju mogu lako preuzeti, premjestiti, izbrisati. Na Haiku je ovaj problem riješen pomoću paketa .hpkg, koji premještaju, na primjer, python, iz tisuća datoteka u jednu. Ali ako postoji, na primjer, Scribus koji koristi python, tada sam suočen s najmanje dvije datoteke. I moram paziti da zadržim njihove verzije koje međusobno rade.

Brojne verzije AppImages, pokrenute paralelno na jednom Linuxu

Pogled iz perspektive programera aplikacija

Pogledajmo iz perspektive programera aplikacija:

Želim upravljati korisničkim iskustvom u cijelosti. Ne želim ovisiti o operativnom sustavu koji će mi nalagati kada i kako trebam objaviti aplikacije. Na Haiku programeri mogu raditi sa svojim vlastitim repozitorijima hpkg, ali to znači da će korisnicima trebati ručno ih konfigurirati, što ovu ideju čini 'manje privlačnom'.
Imam stranicu za preuzimanje na svojoj web stranici gdje distribuiram .exe za Windows, .dmg za Mac i .AppImage za Linux. A možda ću htjeti monetizirati pristup toj stranici, sve može biti? Što trebam staviti tamo za Haiku? Dovoljna je datoteka .hpkg s ovisnostima samo o HaikuPorts
Moj softver zahtijeva određene verzije drugog softvera. Na primjer, poznato je da Krita zahtijeva ispravljenu verziju Qt-a, ili Qt koji je točno podešen na određenu verziju Krite, barem dok ispravke ne budu vraćene natrag u Qt. Mogu se zapakirati vlastiti Qt za aplikaciju u paketu .hpkg, ali vjerojatno to nije dobrodošlo.

Obična stranica za preuzimanje aplikacije. Što staviti ovdje za Haiku?

Hoće li setovi (koji postoje u obliku direktorija aplikacija, poput AppDir ili .app u Apple stilu) i/ili slike (u obliku jako modificiranih AppImages ili .dmg da li bi aplikacije od Applea bile korisno dodatak za radno okruženje Haiku? Ili bi to razbilo cjelinu i dovelo do fragmentacije, a samim time povećalo složenost? Raskoljen sam: s jedne strane, ljepota i senzibilitet Haiku temelje se na činjenici da obično postoji jedan način da nešto učinite, a ne mnogo. S druge strane, veći dio infrastrukture za kataloge i/ili pakete aplikacija već je na mjestu, pa sustav poziva da se preostali postotak uklopi.

Prema razvijaču mr. waddlesplash

Na Linuxu oni (kataloge i pakete aplikacija, — napomena prevoditelja) su vjerojatno tehničko rješenje sistemskih problema. Na Haiku radije rješavamo sistemske probleme.

Što vi mislite?

Prije nego odgovorite…

Pričekajte, brzo ćemo provjeriti realnost: zapravo kataloge aplikacija — već su dio Haiku:

Kataloge aplikacija već postoje na Haiku, ali još nisu podržani u upravitelju datoteka

Jednostavno nisu tako dobro podržani kao, recimo, u Macintosh Finderu. Kako bi bilo sjajno da bi katalog QtCreator imao u gornjem lijevom kutu naziv i ikonu 'QtCreator' koja pokreće aplikaciju dvostrukim klikom?

Malo ranije sam već pitao:

Jeste li sigurni da ćete danas pokrenuti svoje aplikacije starije od deset godina kada će svi dućani aplikacija i repozitoriji distribucija zaboraviti na njih i njihove ovisnosti? Jeste li sigurni da ćete i dalje moći pristupiti svom trenutnom radu u budućnosti?

Da li već postoji odgovor sa strane Haiku, ili će katalogi i paketi aplikacija moći pomoći? Mislim da hoće.

Prema g. waddlesplash:

Da, imamo odgovor na pitanje: samo ćemo podržavati te aplikacije koliko god bude potrebno, dok netko ne bude mogao ispravno pročitati njihove formate datoteka ili osigurati funkcionalnost jedan na jedan. Naša težnja da podržimo rad aplikacija BeOS R5 na Haiku — izravan je dokaz tome...

Tako je!

Kojim akcijskim planom treba ići Haiku?

Mogu zamisliti mirnu su-existenciju hpkg, katalogâ i slika aplikacija:

Sustavni softver koristi .hpkg
Za najčešće korišteni softver (osobito za onaj koji zahtijeva raspored za plutajuća izdanja) koristi se .hpkg (otprilike 80% svih slučajeva)
Neki, instalirani putem .hpkg, aplikacije će imati koristi od prijelaza na infrastrukturu s katalogom aplikacija (na primjer, QtCreator): bit će distribuirane kao .hpkg, kao i prije.

mr. waddlesplash piše:

Ako je sve što nam treba pregledavanje aplikacija u /system/apps, umjesto toga treba učiniti kataloge u Deskbaru upravljivijima za korisnike, jer /system/apps nije namijenjen tome da korisnici redovito otvaraju i pregledavaju (za razliku od MacOS-a). U takvim situacijama Haiku ima drugu paradigmu, ali ova opcija je, u teoriji, prihvatljiva.

Haiku dobiva infrastrukturu za pokretanje slika aplikacija, noćnih, kontinuiranih i testnih gradnji softvera, kao i za situacije kada korisnik želi 'zamrznuti u vremenu', za privatni i unutarnji softver, i druge posebne slučajeve korištenja (oko 20% od ukupne upotrebe). Ove slike sadrže potrebne datoteke za pokretanje aplikacija .hpkg, montirane od strane sustava, a nakon završetka aplikacije — odmontirane. (Možda bi upravitelj datoteka mogao stavljati datoteke .hpkg u slike aplikacija, automatski ili na zahtjev korisnika — pa, kao kada povlačite aplikaciju u mrežni katalog ili vanjski disk. To je jednostavno pjesma! A točnije poezija — haiku.) S druge strane, korisnik može htjeti instalirati sadržaj slike kao datoteke.hpkg, nakon čega će se ažurirati i obrađivati baš kao da su instalirani putem HaikuDepota... Treba organizirati brainstorming.)

Citat od mr. waddlesplash:

Pokretanje aplikacija s vanjskih diskova ili mrežnih kataloga potencijalno može biti korisno. A dodavanje mogućnosti konfiguriranja većeg broja 'zona' za pkgman svakako će postati dobra funkcija.

Ovakav sustav će iskoristiti prednosti hpkg, kataloga i slika aplikacija. Oni su dobri i odvojeno, ali zajedno postaju nepobjedivi.

Zaključak

Za Haiku postoji infrastruktura koja pruža jednostavno i sofisticirano korisničko sučelje za PC, daleko nadilazeći ono što se obično nudi za Linux PC. Sustav paketa .hpkg — jedan od takvih primjera, ali ostali dijelovi sustava također su prožeti sofisticiranošću. Ipak, Haiku bi imalo koristi od pravilne podrške katalogu i slikama aplikacija. Kako to najbolje učiniti — trebali bismo razgovarati s ljudima koji bolje poznaju Haiku, njenu filozofiju i arhitekturu nego ja. Na kraju krajeva, koristim Haiku nešto više od tjedan dana. Ipak, vjerujem da će ovaj svježi pogled biti koristan dizajnerima, programerima i arhitektama Haiku-a. U najmanju ruku, rado ću biti njihov „sparring partner“. Imam više od 10 godina praktičnog iskustva u radu s katalogom i paketima aplikacija za Linux, i volio bih pronaći njihovu primjenu za Haiku, za čiji koncept mislim da su savršeni. Predložena potencijalna rješenja nisu jedina moguća za probleme koje sam opisao, i ako tim Haiku odluči pronaći neka druga, elegantnija — ja samo podržavam. U principu, već razmišljam o tome kako napraviti sustav hpkg još nevjerojatnijim, a da ne promijenim način na koji radi. Pokazuje se da je tim Haiku davno razmišljao o paketima aplikacija prilikom implementacije sustava upravljanja paketima, ali nažalost, (čini se) ideja je postala „zastarjela“. Možda je došlo vrijeme da je oživimo?

Isprobajte sami! Na kraju krajeva, projekt Haiku pruža slike za preuzimanje s DVD-a ili USB-a, koje se formiraju svakodnevno.
Imate pitanja? Pozivamo vas u ruski telegram kanal.

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

Od autor prijevod: ovo je osmi i konačni članak iz ciklusa o Haiku.

Popis članaka: Prvi Drugi Treći Četvrti Peta Šesta Sedma

Samo registrirani korisnici mogu sudjelovati u anketi. Prijavite se, molimo.