Še nekaj: paketi aplikacij Haiku?

TL; DR: Ali lahko Haiku dobi ustrezno podporo za pakete aplikacij, kot so imeniki aplikacij (npr .app na Macu) in/ali slike aplikacij (Linux AppImage)? Mislim, da bi bil to vreden dodatek, ki bi ga bilo lažje pravilno implementirati kot druge sisteme, saj je večina infrastrukture že postavljena.

Pred enim tednom Odkril sem Haiku, nepričakovano dober sistem. No, ker me že dolgo zanimajo imeniki in slike aplikacij (navdihnjen s preprostostjo Macintosha), ni presenetljivo, da se mi je porodila ideja ...

Za popolno razumevanje sem ustvarjalec in avtor AppImage, formata za distribucijo aplikacij Linux, ki si prizadeva za preprostost Mac in daje popoln nadzor avtorjem aplikacij in končnim uporabnikom (če želite izvedeti več, glejte wiki и dokumentacijo).

Kaj če naredimo AppImage za Haiku?

Pomislimo malo, čisto teoretično: kaj je treba narediti, da bi dobili AppImage, ali kaj podobnega, na Haiku? Ni nujno, da nekaj ustvarite prav zdaj, ker sistem, ki že obstaja v Haikuju, deluje neverjetno, vendar bi bil namišljen eksperiment dober. Prav tako dokazuje prefinjenost Haikuja v primerjavi z namiznimi okolji Linuxa, kjer so takšne stvari strašno težke (imam pravico reči: 10 let se mučim z odpravljanjem napak).

V sistemu Macintosh System 1 je bila vsaka aplikacija ločena datoteka, »upravljana« v Finderju. Z uporabo AppImage poskušam znova ustvariti isto uporabniško izkušnjo v Linuxu.

Prvič, kaj je AppImage? To je sistem za sprostitev aplikacij tretjih oseb (npr. Ultimaker Cure), ki omogoča izdajo aplikacij, kadar in kakor hočejo: ni treba poznati posebnosti različnih distribucij, graditi politik ali graditi infrastrukture, ni potrebna podpora vzdrževalcev in uporabnikom ne povedo, kaj (ne) lahko namestijo na svojih računalnikih. AppImage je treba razumeti kot nekaj podobnega paketu Mac v formatu .app znotraj slike diska .dmg. Glavna razlika je v tem, da se aplikacije ne kopirajo, ampak za vedno ostanejo znotraj AppImage, podobno kot paketi Haiku .hpkg nameščen in nikoli nameščen v običajnem pomenu.

V več kot 10 letih obstoja je AppImage pridobil nekaj privlačnosti in priljubljenosti: sam Linus Torvalds ga je javno podprl, skupni projekti (na primer LibreOffice, Krita, Inkscape, Scribus, ImageMagick) pa so ga sprejeli kot glavni način za distribucijo neprekinjenih ali nočnih gradenj, ne da bi posegali v nameščene ali odstranjene uporabniške aplikacije. Vendar pa se namizna okolja in distribucije Linuxa najpogosteje še vedno oklepajo tradicionalnega, centraliziranega distribucijskega modela, ki temelji na vzdrževalcih, in/ali promovirajo lastne poslovne in/ali inženirske programe, ki temeljijo na Flatpak (RedHat, Fedora, GNOME) in Snappy (Canonical, Ubuntu). Prihaja smešno.

Kako vse deluje

• Vsaka AppImage vsebuje 2 dela: majhen dvojni klik ELF (tako imenovani. runtime.c), ki ji sledi slika datotečnega sistema SquashFS.

• Datotečni sistem SquashFS vsebuje obremenitev aplikacije in vse, kar je potrebno za njeno izvajanje, česar pri zdravi pameti ni mogoče šteti za del privzete namestitve za vsak dokaj nov ciljni sistem (distribucija Linuxa). Vsebuje tudi metapodatke, kot so ime aplikacije, ikone, vrste MIME itd. itd.

• Ko zažene uporabnik, izvajalno okolje uporablja FUSE in squashfuse za namestitev datotečnega sistema, nato pa obravnava izvajanje neke vstopne točke (aka AppRun) znotraj nameščene AppImage.
  Datotečni sistem se po končanem postopku odklopi.

Vse se zdi preprosto.

In te stvari vse zapletejo:

• Pri tako raznolikih distribucijah Linuxa nič »pri zdravi pameti« ne moremo imenovati »del privzete namestitve za vsak nov ciljni sistem«. To težavo rešimo z gradnjo excludelist, ki vam omogoča, da določite, kaj bo zapakirano v AppImage in kaj bo treba vzeti drugam. Hkrati včasih zgrešimo, kljub dejstvu, da na splošno vse deluje odlično. Iz tega razloga priporočamo, da ustvarjalci paketov testirajo AppImages na vseh ciljnih sistemih (distribucijah).
• Koristne obremenitve aplikacije morajo biti premestljive po datotečnem sistemu. Na žalost imajo številne aplikacije trdo kodirane absolutne poti do, na primer, virov v /usr/share. To je treba nekako popraviti. Poleg tega morate bodisi izvoziti LD_LIBRARY_PATH, ali popraviti rpath tako da lahko nalagalnik najde povezane knjižnice. Prva metoda ima svoje pomanjkljivosti (ki jih je mogoče premagati na zapletene načine), druga pa je preprosto okorna.
• Največja past UX za uporabnike je to nastavite izvršilni bit Datoteka AppImage po prenosu. Verjeli ali ne, za nekatere je to prava ovira. Potreba po nastavitvi bita za izvedljivost je okorna celo za izkušene uporabnike. Kot rešitev smo predlagali namestitev majhne storitve, ki spremlja datoteke AppImage in nastavi njihov izvedljivi bit. V svoji čisti obliki ni najboljša rešitev, saj ne bo delovala takoj. Distribucije Linuxa ne zagotavljajo te storitve, zato imajo uporabniki že takoj po namestitvi slabo izkušnjo.
• Uporabniki Linuxa pričakujejo, da bo imela nova aplikacija ikono v zagonskem meniju. Sistemu ne morete reči: "Glej, nova aplikacija je, gremo delati." Namesto tega morate v skladu s specifikacijo XDG kopirati datoteko .desktop na pravo mesto v /usr za sistemsko namestitev ali v $HOME za posameznika. Ikone določenih velikosti, v skladu s specifikacijo XDG, je treba postaviti na določena mesta v usr ali $HOME, nato pa zaženite ukaze v delovnem okolju za posodobitev predpomnilnika ikon ali upajte, da bo upravitelj delovnega okolja to ugotovil in samodejno zaznal vse. Enako z vrstami MIME. Kot rešitev je predlagana uporaba iste storitve, ki bo poleg nastavitve zastavice izvedljivosti, če obstajajo ikone itd. v AppImage jih kopirajte iz AppImage na prava mesta glede na XDG. Ko je izbrisana ali premaknjena, se pričakuje, da bo storitev počistila vse. Seveda obstajajo razlike v obnašanju posameznega delovnega okolja, v formatih grafičnih datotek, njihovih velikostih, lokacijah shranjevanja in načinih posodabljanja predpomnilnikov, kar povzroča težave. Skratka, ta metoda je bergla.
• Če zgoraj navedeno ni dovolj, v upravitelju datotek še vedno ni ikone AppImage. Svet Linuxa se še ni odločil za implementacijo elficon (kljub razprava и izvajanje), zato ikone ni mogoče vdelati neposredno v aplikacijo. Tako se izkaže, da aplikacije v upravitelju datotek nimajo svojih ikon (brez razlike, AppImage ali kaj drugega), so samo v začetnem meniju. Kot rešitev uporabljamo sličice, mehanizem, ki je bil prvotno zasnovan tako, da upraviteljem namizij omogoča prikaz predogleda sličic grafičnih datotek kot njihovih ikon. Posledično storitev za nastavitev izvršljivega bita deluje tudi kot »miniaturizer«, ustvarja in piše sličice ikon na ustrezne lokacije /usr и $HOME. Ta storitev izvede tudi čiščenje, če je AppImage izbrisan ali premaknjen. Ker se vsak upravitelj namizja obnaša nekoliko drugače, na primer v kakšnih formatih sprejema ikone, v kakšnih velikostih ali na katerih mestih, je vse to res boleče.
• Aplikacija se med izvajanjem preprosto zruši, če pride do napak (na primer, obstaja knjižnica, ki ni del osnovnega sistema in ni na voljo v AppImage), in nihče uporabniku v GUI ne pove, kaj točno se dogaja. Temu smo se začeli izogniti z uporabo obvestil na namizju, kar pomeni, da moramo napake ujeti iz ukazne vrstice, jih pretvoriti v uporabniku razumljiva sporočila, ki jih je nato treba prikazati na namizju. In seveda jih vsako namizno okolje obravnava nekoliko drugače.
• Trenutno (september 2019 - opomba prevajalca) nisem našel preprostega načina, da bi sistemu povedal, da datoteka 1.png je treba odpreti s Krito in 2.png - z uporabo GIMP.

Lokacija shranjevanja za specifikacije med namizji, ki se uporabljajo v GNOME, KDE и Xfce je freedesktop.org

Doseganje ravni prefinjenosti, ki je globoko vtkana v delovno okolje Haiku, je težko, če ne nemogoče, zaradi specifikacij XDG s spletnega mesta freedesktop.org za več namizij, kot tudi implementacije upraviteljev namizij, ki temeljijo na teh specifikacijah. Kot primer lahko navedemo eno sistemsko ikono Firefoxa: očitno avtorji XDG sploh niso pomislili, da ima lahko uporabnik nameščenih več različic iste aplikacije.

Ikone za različne različice Firefoxa

Spraševal sem se, kaj bi se svet Linuxa lahko naučil od Mac OS X, da bi se izognil motnjam sistemske integracije. Če imate čas in vas zanima to, ne pozabite prebrati, kaj je rekel Arnaud Gurdol, eden prvih inženirjev Mac OS X:

Želeli smo narediti namestitev aplikacije tako enostavno, kot da ikono aplikacije povlečete od nekje (strežnik, zunanji pogon) na pogon vašega računalnika. Da bi to naredil, paket aplikacije shrani vse informacije, vključno z ikonami, različico, vrsto datoteke, ki se obdeluje, vrsto shem URL, ki jih mora sistem poznati za obdelavo aplikacije. To vključuje tudi informacije za 'centralno shranjevanje' v zbirki podatkov Icon Services in Launch Services. Da bi podprli zmogljivost, so aplikacije 'odkrite' na več 'dobro znanih' mestih: v sistemskem in uporabniškem imeniku aplikacij ter na nekaterih drugih samodejno, če se uporabnik pomakne do Finderja v imeniku, ki vsebuje aplikacijo. V praksi je to delovalo zelo dobro.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 seja 144 - Mac OS X: aplikacije za pakiranje in tiskanje dokumentov.

Na namizjih Linux ni nič podobnega tej infrastrukturi, zato iščemo rešitve za strukturne omejitve v projektu AppImage.

Ali Haiku prihaja na pomoč?

In še ena stvar: platforme Linux kot osnova namiznih okolij so ponavadi tako premalo opredeljene, da je veliko stvari, ki so v konsistentnem sistemu polnega sklada precej preproste, v Linuxu frustrirajoče razdrobljene in zapletene. Celotno poročilo sem posvetil vprašanjem, povezanim s platformo Linux za namizna okolja (izkušeni razvijalci so potrdili, da bo vse tako ostalo še zelo dolgo).

Moje poročilo o težavah namiznih okolij Linux v letu 2018

Celo Linus Torvalds je priznal, da je ideja o delovnem prostoru propadla zaradi razdrobljenosti.

Lepo je videti Haiku!

Haiku naredi vse neverjetno preprosto

Medtem ko je naiven pristop k "prenašanju" AppImage v Haiku preprosto poskušati zgraditi (predvsem runtime.c in storitev) njegove komponente (kar je morda celo mogoče!), to Haikuju ne bo prineslo veliko koristi. Ker je pravzaprav večina teh problemov rešenih v Haikuju in so konceptualno neoporečni. Haiku ponuja točno tiste gradnike sistemske infrastrukture, ki sem jih tako dolgo iskal v namiznih okoljih Linux in nisem mogel verjeti, da jih ni. namreč:

Verjeli ali ne, tega mnogi uporabniki Linuxa ne morejo premagati. Na Haiku se vse naredi samodejno!

• Datoteke ELF, ki nimajo izvršljivega bita, ga samodejno pridobijo, ko dvokliknete v upravitelju datotek.
• Aplikacije imajo lahko vgrajene vire, kot so ikone, ki so prikazane v upravitelju datotek. Ni vam treba kopirati kopice slik v posebne imenike z ikonami, zato jih ni treba čistiti po brisanju ali premikanju aplikacije.
• Obstaja baza podatkov za povezovanje aplikacij z dokumenti, za to ni treba kopirati nobenih datotek.
• V imeniku lib/ poleg izvedljive datoteke se privzeto iščejo knjižnice.
• Ni številnih distribucij in namiznih okolij; karkoli deluje, deluje povsod.
• Za zagon ni ločenega modula, ki se razlikuje od imenika aplikacij.
• Aplikacije nimajo vgrajenih absolutnih poti do svojih virov, imajo posebne funkcije za določanje lokacije med izvajanjem.
• Predstavljena je bila zamisel o stisnjenih slikah datotečnega sistema: to je kateri koli paket hpkg. Vse jih priklopi jedro.
• Vsako datoteko odpre aplikacija, ki jo je ustvarila, razen če izrecno določite drugače. Kako kul je to!

Dve datoteki png. Upoštevajte različne ikone, ki označujejo, da jih bodo odprle različne aplikacije, ko jih dvokliknete. Upoštevajte tudi spustni meni »Odpri z:«, kjer lahko uporabnik izbere posamezno aplikacijo. Kako enostavno!

Videti je, da mnoge bergle in rešitve, ki jih zahteva AppImage v Linuxu, postanejo nepotrebne pri Haikuju, ki ima preprostost in prefinjenost v svojem jedru, zaradi česar lahko zadovolji večino naših potreb.

Ali Haiku kljub vsemu potrebuje pakete aplikacij?

To vodi do velikega vprašanja. Če bi bilo za red velikosti lažje ustvariti sistem, kot je AppImage, na Haiku kot na Linuxu, bi se to splačalo narediti? Ali pa je Haiku s svojim paketnim sistemom hpkg dejansko odpravil potrebo po razvoju takšne ideje? No, da odgovorimo, moramo pogledati motivacijo za obstoj AppImages.

Uporabnikova perspektiva

Poglejmo našega končnega uporabnika:

• Želim namestiti aplikacijo, ne da bi zahteval skrbniško (root) geslo. Na Haiku ni koncepta skrbnika, uporabnik ima popoln nadzor, saj gre za osebni sistem! (Načeloma si lahko to predstavljate v načinu za več igralcev, upam, da razvijalci ostanejo preprosti)
• Želim dobiti najnovejše in najboljše različice aplikacij, ne da bi čakal, da se pojavijo v moji distribuciji (najpogosteje to pomeni "nikoli", vsaj če ne posodobim celotnega operacijskega sistema). Na Haiku je to "rešeno" z lebdečimi izpusti. To pomeni, da je mogoče pridobiti najnovejše in najboljše različice aplikacij, vendar morate za to nenehno posodabljati preostanek sistema in ga tako spremeniti v »gibljivo tarčo«..
• Želim več različic iste aplikacije eno ob drugi, saj ni mogoče vedeti, kaj je bilo pokvarjeno v zadnji različici, ali pa moram, recimo, kot spletni razvijalec preizkusiti svoje delo pod različnimi različicami brskalnika. Haiku reši prvi problem, drugega pa ne. Posodobitve so povrnjene, vendar samo za celoten sistem; nemogoče je (kolikor vem) zagnati na primer več različic WebPositive ali LibreOffice hkrati.

Eden od razvijalcev piše:

V bistvu je razlog naslednji: primer uporabe je tako redek, da optimizacija zanj nima smisla; obravnavanje tega kot posebnega primera v HaikuPorts se zdi več kot sprejemljivo.

• Aplikacije moram hraniti tam, kjer so mi všeč, ne na zagonskem pogonu. Pogosto mi zmanjka prostora na disku, zato moram povezati zunanji disk ali omrežni imenik za shranjevanje aplikacij (vseh različic, ki sem jih prenesel). Če priklopim tak disk, potrebujem, da se aplikacije zaženejo z dvojnim klikom. Haiku shrani stare verzije paketov, vendar ne vem, kako jih premakniti na zunanji disk, ali kako kasneje od tam zagnati aplikacije.

Komentar razvijalca:

Tehnično je to že mogoče z ukazom mount. Seveda bomo GUI za to naredili takoj, ko bomo imeli dovolj zainteresiranih uporabnikov.

• Ne potrebujem milijonov datotek, raztresenih po datotečnem sistemu, ki jih sam ne morem ročno upravljati. Želim eno datoteko na aplikacijo, ki jo lahko enostavno prenesem, premaknem, izbrišem. Na Haiku je ta problem rešen s paketi .hpkg, ki na primer python prenašajo iz tisočih datotek v eno. Če pa obstaja na primer Scribus, ki uporablja python, potem se moram ukvarjati z vsaj dvema datotekama. In paziti moram, da ohranim njihove različice, ki delujejo med seboj.

Več različic AppImages, ki se izvajajo ena ob drugi v istem Linuxu

Pogled razvijalca aplikacije

Poglejmo z vidika razvijalca aplikacij:

• Želim nadzorovati celotno uporabniško izkušnjo. Nočem biti odvisen od operacijskega sistema, da mi pove, kdaj in kako naj izdam aplikacije. Haiku omogoča razvijalcem, da delajo z lastnimi repozitoriji hpkg, vendar to pomeni, da jih bodo morali uporabniki nastaviti ročno, zaradi česar je ideja "manj privlačna".
• Na svojem spletnem mestu imam stran za prenos, kjer distribuiram .exe za Windows, .dmg za Mac in .AppImage za Linux. Ali pa morda želim monetizirati dostop do te strani, je vse mogoče? Kaj naj dam tja za haiku? Datoteka je dovolj .hpkg z odvisnostmi samo od HaikuPorts
• Moja programska oprema zahteva posebne različice druge programske opreme. Na primer, znano je, da Krita zahteva popravljeno različico Qt ali Qt, ki je natančno nastavljen na določeno različico Krite, vsaj dokler popravki niso potisnjeni nazaj v Qt. Svoj Qt za svojo aplikacijo lahko zapakirate v paket .hpkg, a najverjetneje to ni dobrodošlo.

Redna stran za prenos aplikacije. Kaj naj objavim tukaj za haiku?

Bodo paketi (obstoječi kot imeniki aplikacij, kot sta AppDir ali .app v slogu Apple) in/ali slike (v obliki močno spremenjenih AppImages oz .dmg od Apple) uporaben dodatek k namiznemu okolju Haiku? Ali pa bo razvodenilo celotno sliko in povzročilo razdrobljenost ter s tem dodalo kompleksnost? Raztrgan sem: po eni strani lepota in prefinjenost haikuja temeljita na dejstvu, da običajno obstaja en način, da nekaj naredimo, in ne več. Po drugi strani pa je večina infrastrukture za kataloge in/ali pakete aplikacij že vzpostavljena, zato sistem kliče, da se preostalih nekaj odstotkov postavi na svoje mesto.

Po mnenju razvijalca gospod. waddlesplash

Na Linuxu so (katalogi in aplikacijski kompleti, - pribl. prevajalec) so najverjetneje tehnična rešitev sistemskih težav. Pri Haiku raje preprosto rešujemo sistemske težave.

Kaj misliš?

Preden odgovoriš ...

Počakajte, naredimo hitro preverjanje resničnosti: v resnici imeniki aplikacij - že del haikuja:

Imeniki aplikacij že obstajajo na Haiku, vendar še niso podprti v upravitelju datotek

Enostavno niso tako dobro podprti kot na primer Macintosh Finder. Kako kul bi bilo, če bi imel imenik QtCreator v zgornjem levem kotu ime in ikono »QtCreator«, ki bi zagnala aplikacijo, ko bi dvokliknili?

Malo prej sem že vprašal:

Ali ste prepričani, da lahko danes izvajate svoje desetletja stare aplikacije, ko so vse trgovine z aplikacijami in distribucijski repozitoriji pozabili nanje in njihove odvisnosti? Ali ste prepričani, da boste v prihodnosti še vedno lahko dostopali do svoje trenutne službe?

Ali že obstaja odgovor Haikuja ali lahko tukaj pomagajo katalogi in paketi aplikacij? Mislim, da lahko.

Po mnenju g. waddlesplash:

Da, imamo odgovor na vprašanje: te aplikacije bomo preprosto podpirali, dokler bo potrebno, dokler nekdo ne bo prebral njihovih formatov datotek na pravi način ali zagotovil funkcionalnost ena proti ena. Naša zaveza k podpori aplikacij BeOS R5 na Haiku je dokaz tega ...

To je gotovo!

Kakšno pot naj ukrepa Haiku?

Lahko si predstavljam mirno sobivanje hpkg, imenikov in slik aplikacij:

• Sistemska programska oprema uporablja .hpkg
• Za najpogosteje uporabljeno programsko opremo (zlasti tisto, ki mora načrtovati tekoče izdaje), uporabite .hpkg (približno 80% vseh primerov)
• Nekateri nameščeni prek .hpkg, bodo aplikacije imele koristi od selitve v infrastrukturo aplikacijskega imenika (npr. QtCreator): distribuirane bodo kot .hpkg, kot prej.

gospod. waddlesplash piše:

Če potrebujete le ogled aplikacij v /system/apps, namesto tega bi morali narediti imenike v Deskbaru bolj obvladljive za uporabnike, saj /system/apps ni namenjeno rednemu odpiranju in pregledovanju s strani uporabnikov (za razliko od MacOS). Za takšne situacije ima haiku drugačno paradigmo, vendar je ta možnost teoretično sprejemljiva.

• Haiku prejme infrastrukturo za izvajanje slik aplikacij, nočne, neprekinjene in testne gradnje programske opreme, kot tudi za primere, ko želi uporabnik "zamrzniti čas", za zasebno in interno programsko opremo ter druge posebne primere uporabe (približno 20% od vseh). Te slike vsebujejo datoteke, potrebne za zagon aplikacije .hpkg, nameščen s strani sistema in po zaključku aplikacije - odklopljen. (Morda bi lahko upravitelj datotek shranil datoteke .hpkg v slike aplikacij, samodejno ali na zahtevo uporabnika – no, kot ko povlečete aplikacijo v omrežni imenik ali zunanji disk. To je samo pesem! Oziroma poezija - haiku.) Po drugi strani pa bo uporabnik morda želel namestiti vsebino slike v obliki datotek.hpkg, nato pa bodo posodobljeni in obdelani na enak način, kot če bi bili nameščeni prek HaikuDepot ... Moramo razmišljati).

Citat g. waddlesplash:

Izvajanje aplikacij z zunanjih pogonov ali omrežnih imenikov je lahko koristno. In dodajanje zmožnosti konfiguriranja več "območij" za pkgman bi bila vsekakor dobra funkcija.

Tak sistem bi izkoristil hpkg, imenike in slike aplikacij. Posamično sta dobra, a skupaj bosta postala nepremagljiva.

Zaključek

Haiku ima ogrodje, ki zagotavlja preprosto in prefinjeno uporabniško izkušnjo za osebni računalnik in daleč presega tisto, kar je običajno na voljo za osebni računalnik z Linuxom. Paketni sistem .hpkg je eden takih primerov, vendar je tudi preostali del sistema prežet s sofisticiranostjo. Vendar bi Haikuju koristila ustrezna podpora za imenik in sliko aplikacije. O tem, kako to najbolje narediti, se je vredno pogovoriti z ljudmi, ki Haiku, njegovo filozofijo in arhitekturo poznajo veliko bolje kot jaz. Navsezadnje uporabljam Haiku malo več kot teden dni. Kljub temu verjamem, da bodo Haikujevi oblikovalci, razvijalci in arhitekti imeli koristi od te sveže perspektive. Vsaj z veseljem bi bil njihov »sparring partner«. Imam več kot 10 let praktičnih izkušenj s katalogi in svežnji aplikacij za Linux in rad bi jim našel uporabo v Haikuju, za katerega menim, da se odlično prilegajo. Možne rešitve, ki sem jih predlagal, nikakor niso edine pravilne za probleme, ki sem jih opisal, in če se ekipa Haiku odloči poiskati druge, bolj elegantne, sem za to. V bistvu že razmišljam o ideji, kako narediti sistem hpkg še bolj neverjetno, ne da bi spremenili način delovanja. Izkazalo se je, da je ekipa Haiku pri implementaciji sistema za upravljanje paketov že dolgo razmišljala o aplikacijskih svežnjih, a je žal (mislim) ideja postala "zastarela". Morda je čas, da ga oživimo?

Poskusite sami! Navsezadnje projekt Haiku nudi ustvarjene slike za zagon z DVD-ja ali USB-ja vsak dan.
Imate vprašanja? Vabimo vas na rusko govoreče telegramski kanal.

Pregled napak: Kako se ustreliti v nogo v C in C++. Zbirka receptov Haiku OS

Od avtor prevod: to je osmi in zadnji članek v seriji o haikuju.

Seznam člankov: Prvič 2. Tretji Četrtič Peta Šestič Sedmo

V anketi lahko sodelujejo samo registrirani uporabniki. Prijaviti se, prosim.

Ali je smiselno prenesti sistem hpkg v Linux?

• Da

• Št

• Že izvedeno, bom napisal v komentarjih

Glasovalo je 20 uporabnikov. 5 uporabnikov se je vzdržalo.

Vir: www.habr.com