Jotain muuta: Haiku-sovelluspaketit?

TL; DR: Saako Haiku kunnollista tukea sovelluspaketteille, kuten sovellushakemistoille (esim .app Macissa) ja/tai sovelluskuvia (Linux AppImage)? Mielestäni tämä olisi arvokas lisäys, joka on helpompi toteuttaa oikein kuin muut järjestelmät, koska suurin osa infrastruktuurista on jo olemassa.

Viikko sitten Löysin Haikun, odottamattoman hyvän järjestelmän. No, koska olen pitkään ollut kiinnostunut hakemistoista ja sovelluskuvista (Macintoshin yksinkertaisuuden innoittamana), ei ole yllättävää, että mieleeni tuli idea...

Täydellisen ymmärtämisen vuoksi olen luonut ja kirjoittanut AppImagen, Linux-sovellusten jakelumuodon, joka tähtää Macin yksinkertaisuuteen ja antaa täyden hallinnan sovellusten tekijöille ja loppukäyttäjille (jos haluat tietää lisää, katso wiki и dokumentointi).

Mitä jos teemme AppImagen haikulle?

Mietitään vähän, puhtaasti teoreettisesti: mitä pitää tehdä saadakseen AppImage, tai jotain vastaavaa, Haikulla? Ei tarvitse juuri nyt luoda mitään, sillä Haikussa jo olemassa oleva järjestelmä toimii hämmästyttävän hyvin, mutta kuvitteellinen kokeilu olisi mukavaa. Se myös osoittaa Haikun hienostuneisuutta verrattuna Linuxin työpöytäympäristöihin, joissa tällaiset asiat ovat hirvittävän vaikeita (minulla on oikeus sanoa niin: olen kamppaillut virheenkorjauksen kanssa 10 vuotta).

Macintosh System 1:ssä jokainen sovellus oli erillinen tiedosto, jota "hallittiin" Finderissa. AppImagen avulla yritän luoda saman käyttökokemuksen uudelleen Linuxissa.

Ensinnäkin, mikä on AppImage? Tämä on järjestelmä, jolla julkaistaan ​​kolmannen osapuolen sovelluksia (esim. Ultimaker Cure), mahdollistaa sovellusten julkaisemisen milloin ja miten he haluavat: ei tarvitse tietää eri jakeluiden yksityiskohtia, rakentaa käytäntöjä tai rakentaa infrastruktuuria, ylläpitäjän tukea ei tarvita, eivätkä ne kerro käyttäjille, mitä (ei) he voivat asentaa tietokoneita. AppImage tulee ymmärtää joksikin samanlaisena kuin Mac-paketti muodossa .app levykuvan sisällä .dmg. Suurin ero on, että sovelluksia ei kopioida, vaan ne pysyvät AppImagen sisällä ikuisesti, samoin kuin Haiku-paketit .hpkg asennettu, eikä koskaan asennettu tavallisessa merkityksessä.

Yli 10 vuoden olemassaolon aikana AppImage on saavuttanut jonkin verran vetovoimaa ja suosiota: Linus Torvalds itse tuki sitä julkisesti, ja yhteiset projektit (esim. LibreOffice, Krita, Inkscape, Scribus, ImageMagick) ovat ottaneet sen pääasiallisena keinona. jakaa jatkuvia tai öisin koontiversioita häiritsemättä asennettuja tai poistettuja käyttäjäsovelluksia. Linuxin työpöytäympäristöt ja -jakelut kuitenkin useimmiten edelleen takertuvat perinteiseen, keskitettyyn ylläpitäjään perustuvaan jakelumalliin ja/tai edistävät omaa yritystoimintaansa ja/tai suunnitteluohjelmia, jotka perustuvat Flatpak (RedHat, Fedora, GNOME) ja Reipas (Canonical, Ubuntu). Se tulee naurettavaa.

Miten se kaikki toimii

• Jokainen AppImage sisältää 2 osaa: pienen kaksoisnapsautetun ELF:n (ns. runtime.c), jota seuraa tiedostojärjestelmän kuva SquashFS.

• SquashFS-tiedostojärjestelmä sisältää sovelluksen hyötykuorman ja kaiken sen suorittamiseen tarvittavan, mitä ei oikein voi pitää osana oletusasennusta jokaisessa melko tuoreessa kohdejärjestelmässä (Linux-jakelu). Se sisältää myös metatietoja, kuten sovelluksen nimen, kuvakkeet, MIME-tyypit jne., jne.

• Kun käyttäjä suorittaa sen, runtime käyttää FUSE:ta ja squashfusea tiedostojärjestelmän liittämiseen ja käsittelee sitten jonkin aloituspisteen (alias AppRun) suorittamisen asennetun AppImagen sisällä.
  Tiedostojärjestelmä irrotetaan prosessin päätyttyä.

Näyttää siltä, ​​että kaikki on yksinkertaista.

Ja nämä asiat vaikeuttavat kaikkea:

• Tällaisissa erilaisissa Linux-jakeluissa mitään "oikeassa mielessä" ei voida kutsua "jokaisen uuden kohdejärjestelmän oletusasennuksen osaksi". Kierrämme tämän ongelman rakentamalla poissulkemislista, jonka avulla voit määrittää, mitä AppImage-sovellukseen pakataan ja mikä on otettava muualle. Samaan aikaan kaipaamme joskus, huolimatta siitä, että yleensä kaikki toimii loistavasti. Tästä syystä suosittelemme, että pakettien luojat testaavat AppImages-kuvia kaikissa kohdejärjestelmissä (jakeluissa).
• Sovellusten hyötykuormien on oltava siirrettävissä tiedostojärjestelmän välillä. Valitettavasti monilla sovelluksilla on kovakoodatut absoluuttiset polut esimerkiksi resursseihin /usr/share. Tämä on korjattava jotenkin. Lisäksi sinun on joko vietävä LD_LIBRARY_PATH, tai korjaa rpath jotta lataaja voi löytää aiheeseen liittyviä kirjastoja. Ensimmäisellä menetelmällä on haittapuolensa (jotka voidaan ratkaista monimutkaisin tavoin), ja toinen on yksinkertaisesti hankala.
• Suurin UX-syöttö käyttäjille on se aseta suoritettava bitti AppImage-tiedosto latauksen jälkeen. Usko tai älä, tämä on todellinen este joillekin. Suoritettavuusbitin asettaminen on hankalaa jopa kokeneille käyttäjille. Kiertokeinona ehdotimme pienen palvelun asentamista, joka valvoo AppImage-tiedostoja ja asettaa niiden suoritettavuusbitin. Puhtaassa muodossaan se ei ole paras ratkaisu, koska se ei toimi laatikosta otettuna. Linux-jakelut eivät tarjoa tätä palvelua, joten käyttäjillä on huono käyttökokemus.
• Linux-käyttäjät odottavat, että uudella sovelluksella on kuvake käynnistysvalikossa. Et voi sanoa järjestelmälle: "Katso, siellä on uusi sovellus, toimitaan." Sen sijaan sinun on kopioitava tiedosto XDG-määrityksen mukaan .desktop oikeaan paikkaan /usr järjestelmän laajuiseen asennukseen tai sisään $HOME yksilölle. XDG-määrityksen mukaan tietyn kokoiset kuvakkeet on sijoitettava tiettyihin paikkoihin usr tai $HOME, ja suorita sitten komentoja työympäristössä kuvakevälimuistin päivittämiseksi tai toivoa, että työympäristön johtaja selvittää sen ja tunnistaa kaiken automaattisesti. Sama MIME-tyyppien kanssa. Kiertokeinona ehdotetaan käytettäväksi samaa palvelua, joka suorittaa suoritettavuuslipun asettamisen lisäksi, jos kuvakkeita on jne. kopioi ne AppImagessa oikeisiin paikkoihin XDG:n mukaan. Kun palvelu poistetaan tai siirretään, sen odotetaan tyhjentävän kaikki. Tietysti jokaisen työympäristön käyttäytymisessä, graafisissa tiedostomuodoissa, niiden koosta, tallennuspaikoissa ja välimuistien päivitysmenetelmissä on eroja, mikä aiheuttaa ongelmia. Lyhyesti sanottuna tämä menetelmä on kainalosauva.
• Jos yllä oleva ei riitä, tiedostonhallinnassa ei vieläkään ole AppImage-kuvaketta. Linux-maailma ei ole vielä päättänyt ottaa elficonin käyttöön (huolimatta keskustelu и toteutus), joten kuvaketta ei voi upottaa suoraan sovellukseen. Joten käy ilmi, että tiedostonhallinnan sovelluksilla ei ole omia kuvakkeita (ei eroa, AppImage tai jotain muuta), ne ovat vain käynnistysvalikossa. Kiertokeinona käytämme pikkukuvia, mekanismia, joka alun perin suunniteltiin sallimaan työpöydän johtajien näyttää graafisten tiedostojen esikatselukuvia kuvakkeinaan. Tästä johtuen suoritettavuusbitin asetuspalvelu toimii myös "pienikokoisena" luoden ja kirjoittaen kuvakkeiden pikkukuvia sopiviin paikkoihin. /usr и $HOME. Tämä palvelu suorittaa myös siivouksen, jos AppImage poistetaan tai siirretään. Johtuen siitä, että jokainen työpöydän hallintaohjelma käyttäytyy hieman eri tavalla, esimerkiksi missä muodoissa se hyväksyy kuvakkeet, missä koossa tai paikoissa, tämä kaikki on todella tuskallista.
• Sovellus yksinkertaisesti kaatuu suorituksen aikana, jos tapahtuu virheitä (esimerkiksi on olemassa kirjasto, joka ei ole osa perusjärjestelmää ja jota ei toimiteta AppImagessa), eikä kukaan kerro käyttäjälle graafisessa käyttöliittymässä, mitä tarkalleen tapahtuu. Aloimme kiertää tätä käyttämällä ilmoitukset työpöydällä, mikä tarkoittaa, että meidän on löydettävä virheet komentoriviltä, ​​muutettava ne käyttäjälle ymmärrettäviksi viesteiksi, jotka on sitten näytettävä työpöydällä. Ja tietysti jokainen työpöytäympäristö käsittelee niitä hieman eri tavalla.
• Tällä hetkellä (syyskuu 2019 - kääntäjän huomautus) en ole löytänyt yksinkertaista tapaa kertoa järjestelmälle, että tiedosto 1.png on avattava Kritalla ja 2.png - GIMPillä.

Tallennuspaikka tietokoneiden välisille eritelmille, joita käytetään GNOME, KDE и xfce on freedesktop.org

Haiku-työympäristöön syvälle kudotun hienostuneisuuden tason saavuttaminen on spesifikaatioiden vuoksi vaikeaa, ellei mahdotonta XDG osoitteesta freedesktop.org työpöydänvälisille tietokoneille sekä näihin spesifikaatioihin perustuviin työpöytähallintaohjelmiin. Esimerkkinä voimme mainita yhden koko järjestelmän kattavan Firefox-kuvakkeen: XDG:n kirjoittajat eivät ilmeisesti edes uskoneet, että käyttäjällä voisi olla asennettuna useita versioita samasta sovelluksesta.

Firefoxin eri versioiden kuvakkeet

Mietin, mitä Linux-maailma voisi oppia Mac OS X:stä välttääkseen järjestelmäintegraation pilaamisen. Jos sinulla on aikaa ja olet kiinnostunut tästä, muista lukea, mitä Arnaud Gurdol, yksi ensimmäisistä Mac OS X -insinööreistä, sanoi:

Halusimme tehdä sovelluksen asentamisesta yhtä helppoa kuin sovelluksen kuvakkeen raahaamisen jostain (palvelimelta, ulkoisesta asemasta) tietokoneen asemalle. Tätä varten sovelluspaketti tallentaa kaikki tiedot, mukaan lukien kuvakkeet, version, käsiteltävän tiedostotyypin ja URL-mallien tyypit, jotka järjestelmän on tiedettävä sovelluksen käsittelyyn. Tämä sisältää myös tiedot Icon Services- ja Launch Services -tietokannan "keskustallennustilasta". Suorituskyvyn tukemiseksi sovelluksia "löydetään" useista "tunnetuista" paikoista: järjestelmä- ja käyttäjäsovellushakemistoista ja joistakin muista automaattisesti, jos käyttäjä siirtyy Finderiin sovelluksen sisältävässä hakemistossa. Käytännössä tämä toimi erittäin hyvin.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 -istunto 144 - Mac OS X: sovellusten pakkaus ja asiakirjojen tulostus.

Linux-työasemilla ei ole mitään tämänkaltaista infrastruktuuria, joten etsimme ratkaisuja AppImage-projektin rakenteellisiin rajoituksiin.

Tuleeko Haiku apuun?

Ja vielä yksi asia: Linux-alustat työpöytäympäristöjen perustana ovat yleensä niin alimääriteltyjä, että monet asiat, jotka ovat melko yksinkertaisia ​​johdonmukaisessa täyspinojärjestelmässä, ovat turhauttavan pirstoutuneita ja monimutkaisia ​​Linuxissa. Omistan kokonaisen raportin ongelmille, jotka liittyvät työpöytäympäristöjen Linux-alustaan ​​(asiantuntevat kehittäjät vahvistivat, että kaikki pysyy sellaisena hyvin pitkään).

Raporttini Linux-työpöytäympäristöjen ongelmista vuonna 2018

Jopa Linus Torvalds myönsi, että pirstoutuminen johtui siitä, miksi työtilaidea epäonnistui.

Kiva nähdä Haikua!

Haiku tekee kaikesta hämmästyttävän yksinkertaista

Vaikka naiivi lähestymistapa AppImagen "siirtämiseen" Haikulle on yksinkertaisesti yrittää rakentaa (pääasiassa runtime.c ja palvelu) sen komponentit (mikä voi olla jopa mahdollista!), tästä ei ole paljon hyötyä Haikulle. Koska itse asiassa useimmat näistä ongelmista ratkaistaan ​​haikuissa ja ovat käsitteellisesti järkeviä. Haiku tarjoaa juuri ne järjestelmäinfrastruktuurin rakennuspalikat, joita olen etsinyt Linux-työpöytäympäristöistä niin kauan, enkä olisi voinut uskoa, että niitä ei ollut olemassa. Nimittäin:

Usko tai älä, tätä monet Linux-käyttäjät eivät voi voittaa. Haikulla kaikki tapahtuu automaattisesti!

• ELF-tiedostot, joissa ei ole suoritettavuusbittiä, saavat sellaisen automaattisesti, kun niitä kaksoisnapsautetaan tiedostonhallinnassa.
• Sovelluksissa voi olla sisäänrakennettuja resursseja, kuten kuvakkeita, jotka näkyvät tiedostonhallinnassa. Sinun ei tarvitse kopioida joukkoa kuvia erityisiin kuvakkeilla varustettuihin hakemistoihin, eikä niitä siksi tarvitse puhdistaa sovelluksen poistamisen tai siirtämisen jälkeen.
• Sovellusten linkittämiseen asiakirjoihin on tietokanta, jota varten ei tarvitse kopioida tiedostoja.
• Suoritettavan tiedoston vieressä olevassa lib/-hakemistossa kirjastoja etsitään oletusarvoisesti.
• Ei ole olemassa lukuisia jakeluita ja työpöytäympäristöjä; mikä tahansa toimii, toimii kaikkialla.
• Ei ole erillistä suoritettavaa moduulia, joka eroaisi Sovellukset-hakemistosta.
• Sovelluksilla ei ole sisäänrakennettuja absoluuttisia polkuja resursseihinsa, vaan niillä on erityisiä toimintoja sijainnin määrittämiseksi suorituksen aikana.
• Pakatun tiedostojärjestelmän kuvien idea on otettu käyttöön: tämä on mikä tahansa hpkg-paketti. Ne kaikki on asennettu ytimen avulla.
• Jokaisen tiedoston avaa sen luonut sovellus, ellet nimenomaisesti määritä toisin. Kuinka siistiä tämä on!

Kaksi png-tiedostoa. Huomaa eri kuvakkeet, jotka osoittavat, että eri sovellukset avaavat ne kaksoisnapsauttamalla. Huomaa myös avattava "Avaa:" -valikko, josta käyttäjä voi valita yksittäisen sovelluksen. Kuinka yksinkertaista!

Näyttää siltä, ​​että monet Linuxin AppImagen vaatimista kainalosauvoista ja kiertotavoista tulevat tarpeettomiksi Haikussa, jonka ytimessä on yksinkertaisuus ja hienostuneisuus, jonka ansiosta se pystyy käsittelemään suurimman osan tarpeistamme.

Tarvitseeko Haiku lopulta sovelluspaketteja?

Tämä johtaa suureen kysymykseen. Jos AppImagen kaltaisen järjestelmän luominen Haikulle olisi suuruusluokkaa helpompaa kuin Linuxille, kannattaako se tehdä? Vai onko Haiku hpkg-pakettijärjestelmänsä ansiosta poistanut tehokkaasti tällaisen idean kehittämisen tarpeen? No, vastataksemme meidän on tarkasteltava AppImagesin olemassaolon taustalla olevaa motivaatiota.

Käyttäjän näkökulma

Katsotaanpa loppukäyttäjäämme:

• Haluan asentaa sovelluksen pyytämättä järjestelmänvalvojan (root) salasanaa. Haikussa ei ole järjestelmänvalvojan käsitettä, käyttäjällä on täysi hallinta, koska kyseessä on henkilökohtainen järjestelmä! (Periaatteessa voit kuvitella tämän moninpelitilassa, toivottavasti kehittäjät pitävät sen yksinkertaisena)
• Haluan saada uusimmat ja parhaat versiot sovelluksista odottamatta niiden ilmestymistä jakeluun (useimmiten tämä tarkoittaa "ei koskaan", ainakin ellei päivitä koko käyttöjärjestelmää). Haikulla tämä on "ratkaistu" kelluvilla julkaisuilla. Tämä tarkoittaa, että on mahdollista saada uusimmat ja parhaat versiot sovelluksista, mutta tätä varten sinun on jatkuvasti päivitettävä muun järjestelmän osa ja muutettava se tehokkaasti "liikkuvaksi kohteeksi"..
• Haluan useita versioita samasta sovelluksesta vierekkäin, koska ei voi tietää, mikä uusimmassa versiossa meni rikki, tai vaikka minun on web-kehittäjänä testattava työtäni eri selaimen versioilla. Haiku ratkaisee ensimmäisen ongelman, mutta ei toista. Päivityksiä palautetaan, mutta vain koko järjestelmälle, on mahdotonta (tietääkseni) ajaa esimerkiksi useita WebPositive- tai LibreOffice-versioita samanaikaisesti.

Yksi kehittäjistä kirjoittaa:

Pohjimmiltaan perustelu on tämä: käyttötapaus on niin harvinainen, että sen optimointi ei ole järkevää; sen käsitteleminen erikoistapauksena HaikuPortsissa vaikuttaa enemmän kuin hyväksyttävältä.

• Minun on säilytettävä sovellukset siellä, missä niistä pidän, ei käynnistysasemassani. Levytila ​​loppuu usein kesken, joten minun on liitettävä ulkoinen asema tai verkkohakemisto sovellusten tallentamista varten (kaikki versiot, jotka olen ladannut). Jos liitän tällaisen aseman, minun on käynnistettävä sovellukset kaksoisnapsauttamalla. Haiku tallentaa paketeista vanhoja versioita, mutta en tiedä miten ne siirretään ulkoiselle levyasemalle tai miten sieltä myöhemmin käynnistetään sovelluksia.

Kehittäjän kommentti:

Teknisesti tämä on jo mahdollista mount-komennolla. Tietysti teemme tälle graafisen käyttöliittymän heti, kun meillä on tarpeeksi kiinnostuneita käyttäjiä.

• En tarvitse miljoonia tiedostoja hajallaan tiedostojärjestelmään, joita en voi itse hallita manuaalisesti. Haluan yhden tiedoston sovellusta kohden, jonka voin helposti ladata, siirtää ja poistaa. Haikulla tämä ongelma ratkaistaan ​​pakettien avulla .hpkg, jotka siirtävät esimerkiksi pythonin tuhansista tiedostoista yhdeksi. Mutta jos esimerkiksi Scribus käyttää pythonia, minun on käsiteltävä vähintään kaksi tiedostoa. Ja minun on huolehdittava siitä, että säilytän niistä versiot, jotka toimivat keskenään.

Useita AppImages-versioita, jotka toimivat rinnakkain samassa Linuxissa

Sovelluskehittäjän näkökulma

Katsotaanpa sovelluskehittäjän näkökulmasta:

• Haluan hallita koko käyttökokemusta. En halua olla riippuvainen käyttöjärjestelmästä, joka kertoo minulle, milloin ja miten minun pitäisi julkaista sovelluksia. Haiku antaa kehittäjille mahdollisuuden työskennellä omien hpkg-arkistojensa kanssa, mutta tämä tarkoittaa, että käyttäjien on määritettävä ne manuaalisesti, mikä tekee ideasta "vähemmän houkuttelevan".
• Verkkosivustollani on lataussivu, jolla jaan .exe Windowsille, .dmg Macille ja .AppImage Linuxille. Tai ehkä haluan kaupallistaa pääsyn tälle sivulle, onko kaikki mahdollista? Mitä minun pitäisi laittaa sinne Haikua varten? Tiedosto riittää .hpkg riippuvuuksilla vain HaikuPortsista
• Ohjelmistoni vaatii tiettyjä versioita muista ohjelmistoista. Tiedetään esimerkiksi, että Krita vaatii korjatun version Qt:stä ​​tai Qt:stä, joka on hienosäädetty tietylle Kritan versiolle, ainakin siihen asti, kunnes paikat työnnetään takaisin Qt:hen. Voit pakata oman Qt:n sovelluksellesi paketissa .hpkg, mutta luultavasti tämä ei ole tervetullutta.

Tavallinen sovelluksen lataussivu. Mitä minun pitäisi kirjoittaa tänne Haikuksi?

Se niputtaa (olemassa sovellushakemistoina, kuten AppDir tai .app Apple-tyyliin) ja/tai kuvia (paljolti muokattuina AppImages tai .dmg Applelta) hyödyllinen lisäys Haiku-työpöytäympäristöön? Vai laimentaako se kokonaiskuvaa ja johtaa pirstoutumiseen, mikä lisää monimutkaisuutta? Olen repeytynyt: toisaalta haikun kauneus ja hienostuneisuus perustuu siihen, että yleensä on olemassa yksi tapa, ei monia. Toisaalta suurin osa luetteloiden ja/tai sovelluspakettien infrastruktuurista on jo olemassa, joten järjestelmä huutaa, että loput muutamat prosenttiosuudet loksahtavat paikalleen.

Kehittäjän mukaan Herra. waddlesplish

Linuxissa he (luettelot ja sovellussarjat, - n. kääntäjä) ovat todennäköisesti tekninen ratkaisu systeemisiin ongelmiin. Haikulla me mieluummin ratkaisemme järjestelmäongelmat.

Mitä mieltä sinä olet?

Ennen kuin vastaat...

Odota, tehdään nopea todellisuustarkistus: itse asiassa sovellushakemistoja - jo osa Haikua:

Haikussa on jo sovellushakemistoja, mutta niitä ei vielä tueta tiedostonhallinnassa

Niitä ei vain tueta niin hyvin kuin esimerkiksi Macintosh Finderia. Kuinka siistiä olisikaan, jos QtCreator-hakemiston vasemmassa yläkulmassa olisi "QtCreator"-nimi ja -kuvake, joka käynnistää sovelluksen kaksoisnapsauttamalla?

Minä jo vähän aikaisemmin kysyi:

Oletko varma, että voit käyttää vuosikymmeniä vanhoja sovelluksiasi tänään, kun kaikki sovelluskaupat ja jakeluvarastot ovat unohtaneet ne ja niiden riippuvuudet? Oletko varma, että pääset edelleen nykyiseen työhösi tulevaisuudessa?

Onko Haikulta jo vastaus, vai voivatko luettelot ja sovelluspaketit auttaa tässä? Luulen, että he voivat.

Mr. waddlespllash:

Kyllä, meillä on vastaus kysymykseen: tuemme yksinkertaisesti näitä sovelluksia niin kauan kuin on tarpeen, kunnes joku osaa lukea heidän tiedostomuotonsa oikealla tavalla tai tarjota yksitellen toimintoja. Sitoutumisemme BeOS R5 -sovellusten tukemiseen Haikussa on todiste tästä...

Se on varmaa!

Mihin toimiin Haikun tulisi ryhtyä?

Voin kuvitella hpkg:n, hakemistojen ja sovelluskuvien rauhanomaisen rinnakkaiselon:

• Järjestelmäohjelmiston käyttö .hpkg
• Käytä useimmin käytetyille ohjelmistoille (erityisesti niille, joiden on ajoitettava jatkuvat julkaisut). .hpkg (noin 80 % kaikista tapauksista)
• Jotkut asennettu kautta .hpkg, sovellukset hyötyvät siirtymisestä sovellushakemistoinfrastruktuuriin (esim. QtCreator): ne jaetaan muodossa .hpkg, kuten ennen.

Herra. waddlesplash kirjoittaa:

Jos tarvitset vain tarkastella sovelluksia /system/apps, sen sijaan meidän pitäisi tehdä Deskbarin hakemistoista käyttäjien hallittavia, koska /system/apps ei ole tarkoitettu käyttäjien säännöllisesti avattavaksi ja tarkastettavaksi (toisin kuin MacOS). Tällaisissa tilanteissa Haikulla on erilainen paradigma, mutta tämä vaihtoehto on teoriassa hyväksyttävä.

• Haiku saa infrastruktuurin sovelluskuvien ajamiseen, ohjelmistojen öisiin, jatkuviin ja testiversioihin sekä tapauksiin, joissa käyttäjä haluaa "jäädyttää sen ajoissa", yksityisiin ja sisäisiin ohjelmistoihin sekä muihin erikoiskäyttötapauksiin (n. 20 % kaikista). Nämä kuvat sisältävät sovelluksen suorittamiseen tarvittavat tiedostot .hpkg, järjestelmän asentama, ja sovelluksen valmistuttua - irrotettu. (Ehkä tiedostonhallinta voisi laittaa tiedostoja .hpkg sovelluskuviin, automaattisesti tai käyttäjän pyynnöstä - esimerkiksi kun vedät sovelluksen verkkohakemistoon tai ulkoiseen asemaan. Se on vain laulu! Tai pikemminkin runous - haiku.) Toisaalta käyttäjä saattaa haluta asentaa kuvan sisällön tiedostoina.hpkg, jonka jälkeen ne päivitetään ja käsitellään samalla tavalla kuin jos ne olisi asennettu HaikuDepotin kautta... Meidän on ideoitava).

Lainaus Mr. waddlespllash:

Sovellusten suorittaminen ulkoisista asemista tai verkkohakemistoista voi olla hyödyllistä. Ja lisäämällä mahdollisuus määrittää enemmän "vyöhykkeitä" pkgmanille olisi varmasti mukava ominaisuus.

Tällainen järjestelmä hyödyntäisi hpkg:ta, hakemistoja ja sovelluskuvia. He ovat hyviä erikseen, mutta yhdessä heistä tulee voittamattomia.

Johtopäätös

Haikulla on kehys, joka tarjoaa yksinkertaisen ja hienostuneen käyttökokemuksen PC:lle ja menee paljon pidemmälle kuin mitä tavallisesti tarjotaan Linux-tietokoneille. Pakettijärjestelmä .hpkg on yksi tällainen esimerkki, mutta myös muu järjestelmä on täynnä hienostuneisuutta. Haiku hyötyisi kuitenkin asianmukaisesta hakemisto- ja sovelluskuvatuesta. Miten tämä parhaiten tehdään, kannattaa keskustella ihmisten kanssa, jotka tuntevat haikun, sen filosofian ja arkkitehtuurin paljon paremmin kuin minä. Olenhan käyttänyt Haikua vähän yli viikon. Uskon kuitenkin, että tästä tuoreesta näkökulmasta on hyötyä Haikun suunnittelijoille, kehittäjille ja arkkitehdeille. Ainakin olisin mielelläni heidän "sparringkumppaninsa". Minulla on yli 10 vuoden käytännön kokemus Linux-sovellusluetteloista ja -nipuista ja haluaisin löytää niille käyttöä Haikussa, konseptiin, johon ne sopivat mielestäni täydellisesti. Ehdottamani mahdolliset ratkaisut eivät ole ainoita todellisia kuvailemiini ongelmiin, ja jos Haiku-tiimi päättää löytää muita, tyylikkäämpiä, olen sen puolella. Pohjimmiltaan mietin jo ajatusta järjestelmän tekemisestä hpkg vieläkin hämmästyttävämpää muuttamatta sen toimintatapaa. Kävi ilmi, että Haiku-tiimi oli pitkään ajatellut sovelluspaketteja paketinhallintajärjestelmää toteuttaessaan, mutta valitettavasti (luulen) idea "vanhentui". Ehkä on aika elvyttää se?

Kokeile itse! Loppujen lopuksi Haiku-projekti tarjoaa kuvia käynnistettäväksi DVD- tai USB-levyltä päivittäin.
Onko sinulla kysymyksiä? Kutsumme sinut venäjänkieliseen sähke kanava.

Virheiden yleiskatsaus: Kuinka ampua itseäsi jalkaan C:ssä ja C++:ssa. Kokoelma Haiku OS -reseptejä

Alkaen kirjailija käännös: tämä on kahdeksas ja viimeinen artikkeli Haikua käsittelevässä sarjassa.

Luettelo artikkeleista: Ensimmäinen Toinen Kolmas neljäs viides kuudes seitsemäs

Vain rekisteröityneet käyttäjät voivat osallistua kyselyyn. Kirjaudu sisään, ole kiltti.

Onko järkeä siirtää hpkg-järjestelmä Linuxiin?

• Kyllä

• Ei

• Jo toteutettu, kirjoitan kommentteihin

20 käyttäjää äänesti. 5 käyttäjää pidättyi äänestämästä.

Lähde: will.com