Kuudes päiväni Haikun kanssa: resurssien, ikonien ja pakettien alla

TL; DR: Haiku on erityisesti PC-tietokoneille suunniteltu käyttöjärjestelmä, joten siinä on useita temppuja, jotka tekevät sen työpöytäympäristöstä paljon muita paremman. Mutta miten se toimii?

äskettäin Löysin Haikun, odottamattoman hyvän järjestelmän. Olen edelleen hämmästynyt siitä, kuinka sujuvasti se toimii, etenkin verrattuna Linux-työpöytäympäristöihin. Tänään katson konepellin alle. Teen vertailuja alkuperäisiin Macintosh-, Mac OS X- ja Linux-työpöytäympäristöihin (XDG-standardi osoitteesta freedesktop.org).

Resurssit ELF-tiedostoissa

Eilen sain tietää, että IconOMatic voi tallentaa kuvakkeita RDF-resursseihin ELF-suoritustiedostoissa. Tänään haluan nähdä, kuinka se todella toimii.

Resurssit? lainaus alkaen Bruce Horn, Macintosh Finderin alkuperäinen kirjoittaja ja Macintosh Resource Managerin "isä":

Olen huolissani perinteisen koodauksen jäykkyydestä. Minulle ajatus sovelluksesta, joka on jäädytetty koodiin, ilman kykyä muuttaa mitään dynaamisesti, on villiintä julmuutta. Ajon aikana pitäisi olla mahdollista muuttaa niin paljon kuin mahdollista. Itse sovelluskoodia ei tietenkään voi muuttaa, mutta jotain voi varmasti muuttaa ilman koodin uudelleenkääntämistä?

Alkuperäisessä Macintoshissa he tekivät näistä tiedostoista "tietoosion" ja "resurssiosion", mikä teki uskomattoman helpoksi asioiden, kuten kuvakkeiden, käännösten ja vastaavien tallentamisesta. suoritettavissa tiedostoissa.

Macissa tätä käytetään ResEdit, graafinen ohjelma - yhtäkkiä - resurssien muokkaamiseen.

ResEdit alkuperäisessä Macintoshissa

Tämän seurauksena tuli mahdolliseksi muokata kuvakkeita, valikkokohtia, käännöksiä jne. tarpeeksi helppoa, mutta ne silti "matkustavat" sovellusten kanssa.
Joka tapauksessa tällä lähestymistavalla oli suuri haittapuoli: se toimi vain Applen tiedostojärjestelmissä, mikä oli yksi syy siihen, miksi Apple hylkäsi "resurssiosion" siirtyessään Mac OS X:ään.
Mac OS X:ssä Apple halusi tiedostojärjestelmästä riippumattoman ratkaisun, joten he ottivat käyttöön pakettien käsitteen (NeXT:stä), hakemistoista, joita tiedostonhallinta käsittelee "läpinäkymättöminä objekteina", kuten tiedostot hakemistojen sijaan. Mikä tahansa paketti, jossa on sovellus muodossa .app on muun muassa tiedosto Info.plist (jonkinlainen Applen JSON- tai YAML-vastine), joka sisältää sovelluksen metatiedot.

Info.plist-tiedoston avaimet Mac OS X -sovelluspaketista.

Resurssit, kuten kuvakkeet, käyttöliittymätiedostot ja muut, tallennetaan pakettiin tiedostoina. Konsepti itse asiassa palasi juurilleen NeXT:ssä.

Mathematica.app NeXTSTEP 1.0:ssa vuonna 1989: näkyy tiedostojen hakemistona päätteessä, mutta yhtenä kohteena graafisessa tiedostonhallinnassa.

Palataan BeOS:iin, konsepteihin, joihin Haiku perustuu. Sen kehittäjät vaihtaessaan PEF:stä (PowerPC) ELF:ään (x86) (sama kuin Linuxissa) päättivät lisätä resurssiosion ELF-tiedostojen loppuun. Se ei käyttänyt omaa oikeaa ELF-osiota, se yksinkertaisesti liitettiin ELF-tiedoston loppuun. Ohjelman seurauksena strip ja muut binutilsista, jotka eivät ole tietoisia tästä, yksinkertaisesti katkaisivat sen. Siksi, kun lisäät resursseja ELF-tiedostoon BeOS:ssa, on parempi olla manipuloimatta sitä Linux-työkaluilla.

Mitä Haikulle nyt tapahtuu? Periaatteessa enemmän tai vähemmän sama.

Teoriassa resurssit olisi mahdollista sijoittaa haluttuun ELF:n osioon. Irc.freenode.net-sivuston #haiku-kanavan kehittäjien mukaan:

ELF:n kanssa osio olisi järkevämpi... ainoa syy, miksi emme tee sitä niin, on se, mitä teimme BeOSissa."
Eikä tätä nyt kannata muuttaa.

Resurssienhallinta

Resurssit kirjoitetaan jäsennellyssä "resurssi"-muodossa: olennaisesti luettelo resursseista, niiden koosta ja sitten niiden sisällöstä. Muistelin ar muodossa.
Kuinka tarkistaa resurssit Haikussa? Onko jotain ResEditin kaltaista?
Mukaan dokumentointi:

Voit tarkastella sovelluspaketin sisältämiä resursseja vetämällä suoritettavan tiedoston esimerkiksi ohjelman päälle Resurssitoimittaja. Voit myös mennä terminaaliin ja suorittaa komennon listres имя_файла.

Resourcer on saatavilla HaikuDepotissa, mutta se vain kaatuu minulle.

Kuinka hallita ELF-tiedostojen resursseja? Käyttämällä rsrc и rdef. rdef tiedostot kerätään rsrc. Tiedosto rdef on tallennettu vain tekstimuodossa, joten sen kanssa on paljon helpompi työskennellä. Tiedosto muoto rsrc liitetään ELF-tiedoston loppuun. Yritetään pelata:

~> rc -h
Haiku Resource Compiler 1.1To compile an rdef script into a resource file:
    rc [options] [-o <file>] <file>...To convert a resource file back into an rdef script:
    rc [options] [-o <file>] -d <file>...Options:
    -d --decompile       create an rdef script from a resource file
       --auto-names      construct resource names from ID symbols
    -h --help            show this message
    -I --include <dir>   add <dir> to the list of include paths
    -m --merge           do not erase existing contents of output file
    -o --output          specify output file name, default is out.xxx
    -q --quiet           do not display any error messages
    -V --version         show software version and license

Voit käyttää ohjelmaa xres tarkastusta ja valvontaa varten:

/> xres
Usage: xres ( -h | --help )
       xres -l <file> ...
       xres <command> ...The first form prints this help text and exits.The second form lists the resources of all given files.The third form manipulates the resources of one or more files according to
the given commands.
(...)

Okei, yritetään?

/> xres -l /Haiku/system/apps/WebPositive/Haiku/system/apps/WebPositive resources:type           ID        size  name
------ ----------- -----------  --------------------
'MIMS'           1          36  BEOS:APP_SIG
'APPF'           1           4  BEOS:APP_FLAGS
'MSGG'           1         421  BEOS:FILE_TYPES
'VICN'         101        7025  BEOS:ICON
'VICN'         201          91  kActionBack
'VICN'         202          91  kActionForward
'VICN'         203         300  kActionForward2
'VICN'         204         101  kActionStop
'VICN'         206         243  kActionGoStart
'MSGG'         205        1342  kActionGo
'APPV'           1         680  BEOS:APP_VERSION

Lisää resursseista ja muodosta rdef osaa lukea täällä.

Vakioresurssityypit

Vaikka resursseihin voi laittaa mitä tahansa, on olemassa muutamia määriteltyjä vakiotyyppejä:

• app_signature: MIME-sovellustyyppi, tiedoston avaamiseen, käynnistämiseen, IPC:hen jne.
• app_name_catalog_entry: Koska sovelluksen nimi on yleensä englanninkielinen, voit määrittää paikat, joissa käännetyt nimet sijaitsevat, jotta eri kielten käyttäjät näkevät haluttaessa käännetyn sovelluksen nimen.
• app_version: juuri sitä mitä ajattelit
• app_flags: osoittaa registrar miten hakemus käsitellään. Luulen, että siinä on enemmän kuin miltä näyttää. Esimerkiksi on olemassa B_SINGLE_LAUNCH, joka pakottaa järjestelmän käynnistämään uuden sovellusprosessin joka kerta, kun käyttäjä sitä pyytää (samaa periaatetta käytetään useimmissa Linux-sovelluksissa). Syödä B_MULTIPLE_LAUNCH, jolloin prosessi suoritetaan jokainen tiedosto. Lopulta löytyy B_EXCLUSIVE_LAUNCH, joka pakottaa järjestelmän käynnistämään vain yhden prosessin kerrallaan riippumatta siitä, kuinka usein käyttäjät käynnistävät sen (esimerkiksi näin Firefox toimii Linuxissa; sama tulos voidaan saavuttaa Qt-sovelluksissa funktiolla QtSingleApplication). Sovellukset kanssa B_EXCLUSIVE_LAUNCH saavat ilmoituksen, kun käyttäjä yrittää suorittaa ne uudelleen: he saavat esimerkiksi sen tiedoston polun, jonka käyttäjä haluaa avata heidän avullaan.
• vector_icon: Vektorisovelluksen kuvake (BeOS:ssa ei ollut vektorikuvakkeita, useimpien sovellusten suoritustiedostoissa oli sen sijaan kaksi rasterikuvaketta).

Tietenkin voit lisätä resursseja haluamillasi tunnuksilla ja tyypeillä ja lukea ne sitten itse sovelluksessa tai muissa luokkaa käyttävissä sovelluksissa BResources. Mutta ensin, katsotaanpa kiehtovaa kuvakkeiden aihetta.

Vektorikuvakkeet haiku-tyyliin

Ei tietenkään vain Haiku valinnut parasta kuvakemuotoa, vaan tässä osassa tilanne Linuxin työpöytäympäristöissä on kaukana ihanteellisesta:

me@host:~$ ls /usr/share/icons/hicolor/
128x128  256x256  512x512           index.theme
160x160  28x28    64x64             scalable
16x16    32x32    72x72             symbolic
192x192  36x36    8x8
22x22    42x42    96x96
24x24    48x48    icon-theme.cache

Tätä katsoessa voi jo aistia, mikä kappale se on.

Tietenkin on skaalautuva, joka sisältää, kuten ymmärrät, vektorikuvakkeet. Miksi sitten on jotain muuta? Koska tulos piirtämällä vektorigrafiikkaa pienissä koossa voi olla vähemmän kuin ihanteellinen. Haluaisin eri kokoja varten optimoituja vaihtoehtoja. Linux-työpöytäympäristöissä tämä saavutetaan sirottamalla erikokoisia kuvakkeita koko tiedostojärjestelmään.

me@host:~$ find /usr/share/icons/ -name 'firefox.*'
/usr/share/icons/HighContrast/16x16/apps/firefox.png
/usr/share/icons/HighContrast/22x22/apps/firefox.png
/usr/share/icons/HighContrast/24x24/apps/firefox.png
/usr/share/icons/HighContrast/256x256/apps/firefox.png
/usr/share/icons/HighContrast/32x32/apps/firefox.png
/usr/share/icons/HighContrast/48x48/apps/firefox.png
/usr/share/icons/elementary-xfce/apps/128/firefox.png
/usr/share/icons/elementary-xfce/apps/16/firefox.png
/usr/share/icons/elementary-xfce/apps/22/firefox.png
/usr/share/icons/elementary-xfce/apps/24/firefox.png
/usr/share/icons/elementary-xfce/apps/32/firefox.png
/usr/share/icons/elementary-xfce/apps/48/firefox.png
/usr/share/icons/elementary-xfce/apps/64/firefox.png
/usr/share/icons/elementary-xfce/apps/96/firefox.png
/usr/share/icons/hicolor/128x128/apps/firefox.png

Huomaa: Firefoxin eri versioista ei ole käsitystä. Näin ollen ei ole mahdollista käsitellä sulavasti tilannetta, jossa sovelluksesta on useita versioita järjestelmässä.

Erilaiset Firefox-kuvakkeet eri versioissa. Tätä on tällä hetkellä mahdotonta käsitellä Linuxissa ilman erilaisia ​​kainalosauvoja.

Mac OS X käsittelee sitä hieman hienovaraisemmin:

Mac:~ me$ find /Applications/Firefox.app | grep icns
/Applications/Firefox.app/Contents/MacOS/crashreporter.app
/Contents/Resources/crashreporter.icns
/Applications/Firefox.app/Contents/MacOS/updater.app/Contents/Resources/updater.icns
/Applications/Firefox.app/Contents/Resources/document.icns
/Applications/Firefox.app/Contents/Resources/firefox.icns

Voidaan nähdä, että siellä on yksi tiedosto firefox.icns paketissa Firefox.app, joka sisältää kaikki koot, joten saman sovelluksen eri versioissa on eri kuvakkeet.
Paljon parempi! Kuvakkeet kulkevat sovelluksen mukana, kaikki resurssit ovat yhdessä tiedostossa.

Palataan Haikuan. Mieleenpainuva ratkaisu, ei poikkeuksia. Mukaan dokumentointi:

Kehitettiin erityinen HVIF-muoto, joka on optimoitu pienille kokoille ja nopealle renderöinnille. Siksi kuvakkeet ovat suurimmaksi osaksi paljon pienempiä kuin rasterissa tai yleisesti käytetyssä SVG-muodossa.

Ja ne ovat edelleen optimoituja:

HVIF-kuvakkeiden koot muihin muotoihin verrattuna.

Ero on suuruusluokkaa!

Mutta taikuus ei lopu tähän. Sama HVIF voi näyttää eri yksityiskohtaisia ​​tasoja näytettävän koon mukaan, vaikka se on vektorimuoto.

Eri yksityiskohdat (LOD) renderöinnin koosta riippuen

Nyt haitoista: et voi ottaa SVG:tä, heittää sitä ImageMagickiin ja kutsua sitä päiväksi; sinun on käytävä läpi useita jaksoja luodaksesi kuvakkeen HVIF-muodossa. Täällä selityksiä. IconOMatic voi kuitenkin tuoda SVG:tä melko epätäydellisesti; noin 90 % SVG-tiedoista tuodaan jollain todennäköisyydellä, loput 10 % on määritettävä ja muutettava manuaalisesti. Lue lisää siitä, kuinka HVIF tekee taikuutensa voidaan muodostaa blogissa Leah Ganson

Kuvakkeen lisääminen sovellukseen

Nyt voin lisätä kuvakkeen luotuun pakettiin viime kerta, ottaen huomioon kaikki saadut tiedot.
No, koska en ole erityisen innokas piirtämään omaa kuvaketta "Hello, World" QtQuickApp -sovellukselleni juuri nyt, vedän sen pois Qt Creatorista.

/Haiku/home> xres /Haiku/system/apps/QtCreator/bin/Qt Creator  -o /Haiku/home/QtQuickApp/QtQuickApp  -a VICN:101:BEOS:ICON /Haiku/system/apps/QtCreator/bin/Qt Creator

Tarkistetaan, että kuvake on kopioitu:

/Haiku/home> xres -l /Haiku/home/QtQuickApp/QtQuickApp/Haiku/home/QtQuickApp/QtQuickApp
resources:type           ID        size  name
------ ----------- -----------  --------------------
'VICN'         101      152238  BEOS:ICON

Näyttää hyvältä, mutta miksi uusi kuvake ei näy, kun se kopioidaan?

Kopioitua VICN:101:BEOS:ICONs ei ole vielä käytössä sovelluskuvakkeena tiedostonhallinnassa

Mitä minulta meni ohi?

Kehittäjän kommentti:

Meidän on luotava tiedosto rdef kaikilla resursseilla ja suorita komento rc имя.rdef, tämä luo tiedoston .rsrc. Sitten sinun on suoritettava komento resattr -o имя_бинарника имя.rsrc. Käytän vähintään tällaisia ​​komentoja lisätäkseni kuvakkeita komentosarjoihini.

No, halusin luoda resurssin, en attribuutin. Olen todella hämmentynyt.

Älykäs välimuisti tiedostojärjestelmän avulla

ELF-attribuuttien avaaminen ja lukeminen on hidasta. Kuten edellä kirjoitin, kuvake on kirjoitettu resurssiksi itse tiedostoon. Tämä menetelmä on luotettavampi ja mahdollistaa kopioinnin toiseen tiedostojärjestelmään. Se kuitenkin kopioidaan sitten myös esimerkiksi tiedostojärjestelmän attribuutille BEOS:ICON. Tämä toimii vain tietyissä tiedostojärjestelmissä, kuten BFS. Järjestelmän näyttämät kuvakkeet (Trackerissa ja Deskbarissa) luetaan tästä laajennetusta määritteestä, koska tämä ratkaisu toimii nopeasti. Joissakin paikoissa (joissa nopeus ei ole tärkeä, esimerkiksi tyypillinen "Tietoja"-ikkuna) järjestelmä vastaanottaa kuvakkeen suoraan tiedostossa olevasta resurssista. Mutta tämä ei ole loppu. Muista, että Macissa käyttäjät voivat korvata sovellusten, hakemistojen, asiakirjojen kuvakkeet omilla, sillä Macilla on mahdollista tehdä näitä "tärkeitä" asioita mm. uuden Slack-kuvakkeen korvaaminen edellisellä. Haikussa sinun tulee ajatella resurssia (tiedostossa) alkuperäisenä kuvakkeena, joka tulee sovelluksen mukana, ja attribuuttia (BFS-tiedostojärjestelmässä) joksikin, jonka avulla käyttäjä voi tehdä muutoksia haluamallaan tavalla (tosin, vihje, graafinen käyttöliittymä mukautetun kuvakkeen lisäämiseksi kuvakkeen päälle on valinnainen). ei ole vielä käytössä).

Tarkistetaan tiedostojärjestelmän attribuutteja

Kanssa resaddr On mahdollista tarkistaa ja asettaa tiedostojärjestelmän attribuutteja.

/> resattr
Usage: resattr [ <options> ] -o <outFile> [ <inFile> ... ]

Reads resources from zero or more input files and adds them as attributes
to the specified output file, or (in reverse mode) reads attributes from
zero or more input files and adds them as resources to the specified output
file. If not existent the output file is created as an empty file.
(...)

Se on pohjimmiltaan "liima", joka suorittaa muunnoksen edestakaisin (luotettavien) resurssien ja (nopeiden) tiedostojärjestelmän attribuuttien välillä. Ja koska järjestelmä odottaa saavansa resursseja ja kopioi automaattisesti, en huolehdi siitä enempää.

hpkg-pakettien taika

Tällä hetkellä (useimmiten) paketteja käytetään Haiku-ohjelmien hankkimiseen .hpkg. Älä anna yksinkertaisen nimen hämätä: .hpkg-muoto toimii täysin eri tavalla kuin muut samannimiset tiedostot, joita olet kohdannut, sillä siinä on todellisia supervoimia.

Perinteisten pakettimuotojen kanssa olin pitkään järkyttynyt tästä tosiasiasta: lataat yhden asian (paketti), ja toinen asennetaan järjestelmään (tiedostot paketin sisällä). Tiedostojen hallinta (esimerkiksi poistaminen) on melko vaikeaa, kun paketti asennetaan perinteisellä tavalla. Ja kaikki pakkauksen sisällön takia hajallaan koko tiedostojärjestelmään, mukaan lukien paikat, joissa keskivertokäyttäjällä ei ehkä ole kirjoitusoikeutta. Tämä synnyttää kokonaisen luokan ohjelmia - pakettien ylläpitäjät. Mutta jo asennettujen ohjelmistojen siirtäminen esimerkiksi toiselle koneelle, siirrettävälle levylle tai tiedostopalvelimelle tulee vielä vaikeammaksi, ellei täysin mahdottomaksi. Tyypillisessä Linux-pohjaisessa järjestelmässä yksittäisiä tiedostoja voi helposti olla useista sadoista tuhansista miljooniin. Sanomattakin on selvää, että tämä on sekä hauras että hidas, esimerkiksi kun järjestelmää asennetaan aluksi, kun asennat, päivität ja poistat tavallisia paketteja sekä kopioitaessa käynnistyslevyä (juuriosio) toiselle tallennusvälineelle.

Työskentelen AppImage-projektin parissa, osittaisena kainalosauvan loppukäyttäjien sovelluksille. Tämä on ohjelmiston jakelumuoto, joka kerää sovelluksen ja kaikki sen riippuvuudet yhdeksi tiedostojärjestelmäkuvaksi, joka liitetään sovelluksen käynnistyessä. Yksinkertaistaa asioita huomattavasti, koska sama ImageMagick muuttuu yhtäkkiä yhdeksi tiedostoksi, jota kuolevaiset hallitsevat tiedostohallinnassa. Ehdotettu menetelmä toimii vain ohjelmistoille, kuten projektin nimi näkyy, ja siinä on myös omat ongelmansa, koska Linux-ohjelmiston toimittamiseen osallistuvat ihmiset osoittavat aina nuolen minua.

Palataan Haikuan. Onko optimaalinen tasapaino perinteisten paketoitujen järjestelmien ja kuvapohjaisten ohjelmistotoimitusten välillä onnistuttu löytämään? Hänen pakettejaan .hpkg itse asiassa pakatut tiedostojärjestelmän kuvat. Kun järjestelmä käynnistyy, ydin liittää kaikki asennetut ja aktiiviset paketit suunnilleen seuraavilla ydinviesteillä:

KERN: package_daemon [16042853:   924] active package: "gawk-4.2.1-1-x86_64.hpkg"
KERN: package_daemon [16043023:   924] active package: "ca_root_certificates_java-2019_01_23-1-any.hpkg"
KERN: package_daemon [16043232:   924] active package: "python-2.7.16-3-x86_64.hpkg"
KERN: package_daemon [16043405:   924] active package: "openjdk12_default-12.0.1.12-1-x86_64.hpkg"
KERN: package_daemon [16043611:   924] active package: "llvm_libs-5.0.0-3-x86_64.hpkg"

Siistiä, vai? Pidä kiinni, siitä tulee vielä viileämpää!

Siellä on erityinen paketti:

KERN: package_daemon [16040020:   924] active package: "haiku-r1~beta1_hrev53242-1-x86_64.hpkg"

Se sisältää erittäin minimalistisen käyttöjärjestelmän, mukaan lukien ytimen. Usko tai älä, edes itse ydintä ei poisteta käynnistyslevyltä (root-osio), vaan se ladataan varovasti paikalleen paketista .hpkg. Vau! Olen jo maininnut, että mielestäni osa Haikun yleisestä hienostuneisuudesta ja johdonmukaisuudesta johtuu siitä, että koko järjestelmä ytimestä ja ydinkäyttäjätilasta pakettien hallintaan ja ajonaikaiseen infrastruktuuriin on kehitetty yhteistyössä yhden tiimin toimesta. Kuvittele kuinka monta eri ryhmää ja tiimiä tarvitsisi suorittaakseen jotain tällaista Linuxissa [Kuvittelen PuppyLinux-projektia - noin. kääntäjä]. Kuvittele sitten, kuinka kauan kestää, että tämä lähestymistapa otetaan käyttöön jakeluissa. He sanovat: ota yksinkertainen ongelma, jaa se eri esiintyjien kesken, niin siitä tulee niin monimutkainen, että sitä ei enää voida ratkaista. Haiku tässä tapauksessa avasi silmäni. Luulen, että tämä on juuri sitä, mitä nyt tapahtuu Linuxissa (Linux on tässä tapauksessa yhteistermi Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu-pinolle).

Järjestelmän palautus käyttämällä hpkg:ta

Kuinka usein tapahtuu seuraava tilanne: päivitys onnistui, ja sitten käy ilmi, että jokin ei toimi niin kuin pitäisi? Jos käytät perinteisiä paketinhallintaohjelmia, on vaikea palauttaa järjestelmän tilaa ajankohtaan ennen uusien pakettien asentamista (esimerkiksi siinä tapauksessa, että jokin meni pieleen). Jotkut järjestelmät tarjoavat kiertotapoja tiedostojärjestelmän tilannekuvien muodossa, mutta ne ovat melko hankalia, eikä niitä käytetä kaikissa järjestelmissä. Haiku ratkaisee tämän pakettien avulla .hpkg. Aina kun paketit muuttuvat järjestelmässä, vanhoja paketteja ei poisteta, vaan ne tallennetaan järjestelmään alihakemistoihin, esim. /Haiku/system/packages/administrative/state-<...>/ jatkuvasti. Keskeneräiset toiminnot tallentavat tietonsa alihakemistoihin /Haiku/system/packages/administrative/transaction-<...>/.

Sisältö /Haiku/system/packages/administrative. "State..."-hakemistot sisältävät tekstitiedostoja aktiivisten pakettien nimillä ja "transaction..."-hakemistot sisältävät itse paketit.

"Vanha aktiivinen tila", ts. lista .hpkg ennen muutoksia aktiiviset paketit tallennetaan jokaisen tiedostonhallinnan toiminnon jälkeen tekstitiedostoon /Haiku/system/packages/administrative/state-<...>/activated-packages. Samalla tavalla uusi "aktiivinen tila" kirjoitetaan tekstitiedostoon /Haiku/system/packages/administrative/activated-packages.

Hakemisto /Haiku/system/packages/administrative/state-<...>/ sisältää vain tekstitiedoston, jossa on luettelo tämän tilan aktiivisista paketeista (jos paketteja asennetaan ilman poistamista), ja jos paketteja on poistettu tai päivitetty - tilahakemisto sisältää pakettien vanhat versiot.

Kun järjestelmä käynnistyy, pakettiluettelon perusteella tehdään päätös pakettien aktivoimisesta (liittämisestä). Se on niin yksinkertaista! Jos jokin menee pieleen latauksen aikana, voit pyytää lataushallintaa käyttämään toista, vanhempaa luetteloa. Ongelma ratkaistu!

Haiku-latausohjelma. Jokainen tulopiste näyttää vastaavan "aktiivisen tilan"

Pidän lähestymistavasta, jossa "aktiivisen tilan" luettelona on yksinkertaiset tekstitiedostot, joiden nimet on helppo ymmärtää .hpkg. Tämä on jyrkässä ristiriidassa koneille-ei-ihmisiä varten rakennetulle. kimppu OSTreestä tai Flatpakista tiedostojärjestelmässä (samalla tasolla kuin Microsoft GUID).

Luettelo kunkin ajankohdan aktiivisista paketeista

Asetustiedot

Ilmeisesti luettelossa /Haiku/system/packages/administrative/writable-files sisältää pakettien asetustiedostoja, mutta ne ovat kirjoitettavissa. Loppujen lopuksi, kuten muistat, .hpkg asennettu vain luku -tilassa. Nämä tiedostot on siis kopioitava paketeista ennen kirjoittamista. On merkitystä.

GUI-integrointi .hpkg-järjestelmään

Katsotaan nyt, miten nämä kiiltävät laukut .hpkg selviytyä integroinnista käyttäjän työympäristöön (UX). Loppujen lopuksi Haiku on tarkoitettu henkilökohtaiseen käyttöön. Henkilökohtaisesti asetan riman korkealle, kun vertaan käyttökokemusta paketeihin .app Macintoshissa samalla kokemuksella .hpkg. En edes vertaa tilannetta Linuxin työympäristöihin, koska se on aivan kauhea verrattuna muihin.

Seuraavat skenaariot tulevat mieleen:

• Haluan nähdä paketin sisällön .hpkg
• Haluan asentaa paketin
• Haluan poistaa paketin
• Haluan poistaa jotain, joka tuli järjestelmään osana pakettia
• Haluan kopioida jotain, joka tuli järjestelmään osana pakettia
• Haluan ladata kaikki paketin riippuvuudet, jotka eivät välttämättä ole osa jokaista Haiku-asennusta (esimerkiksi minulla on fyysisesti eristetty kone, jolla ei ole Internet-yhteyttä.)
• Haluan siirtää pakettini (tai osan niistä) erikseen toiseen paikkaan, erilleen käynnistystaltiosta (juuriosiosta) (koska minulla ei esimerkiksi ole tarpeeksi tilaa siinä).

Tämän pitäisi kattaa useimmat tärkeät tapaukset päivittäisestä työstäni. No, aloitetaan.

Pakkauksen sisällön tarkistaminen

Macissa Napsautan pakettia hiiren kakkospainikkeella avatakseni sen ja tarkastellaksesi sen sisältöä Finderissa. Loppujen lopuksi se on todellisuudessa vain naamioitu hakemisto! (Tiedän, että paketteja on .pkg järjestelmän osalle, joka ei ole sovelluksia, mutta tavalliset käyttäjät eivät useimmiten ole vuorovaikutuksessa niiden kanssa).

Haikulla Napsautan pakettia hiiren kakkospainikkeella ja napsautan sitten "Sisältö" nähdäkseni mitä sisällä on. Mutta tässä on vain luettelo tiedostoista ilman mahdollisuutta avata niitä kaksoisnapsauttamalla.
Olisi paljon parempi, jos paketti olisi mahdollista (tilapäisesti) asentaa .hpkg nähdäksesi tiedostonhallinnan kautta, ja käyttäjän ei tarvitse huolehtia toteutuksen yksityiskohdista. (Muuten, voit avata .hpkg pakata sisään Expander, joka voi purkaa sen kuten minkä tahansa muun arkiston).

HaikuDepotin käyttöliittymässä voit tarkastella pakettitiedostojen luetteloa, mutta sisältöä ei voi tarkastella esimerkiksi kaksoisnapsauttamalla README.md.

Mac voittaa tässä kategoriassa, mutta halutun HaikuDepot-toiminnon lisäämisen ei pitäisi olla liian vaikeaa.

Paketin asennus graafisen käyttöliittymän kautta

Macissa, useimmat levykuvat .dmg sisältää paketteja .app. Kaksoisnapsauta levykuvaa ja kopioi sitten paketti esimerkiksi vetämällä se sisään /Applications Finderissa. Tämä on sanomattakin selvää minulle, mutta olen kuullut, että jotkut aloittelijat eivät ehkä pysty käsittelemään tätä. Oletuksena Apple "ehdottaa" koko järjestelmän kattavaa hakemistoa /Applications (NeXT:ssä se oli sekä verkotettu että yksittäinen), mutta voit helposti laittaa sovelluksesi tiedostopalvelimelle tai alihakemistoon $HOME/Applications, jos pidät siitä niin.

Haikulla, kaksoisnapsauta pakettia ja napsauta sitten "Asenna", se ei voisi olla helpompaa. Mietin, mitä tapahtuu, jos paketissa on riippuvuuksia, jotka ovat saatavilla HaikuPortsissa, mutta joita ei ole vielä asennettu. Linuxissa he eivät todellakaan tiedä mitä tehdä tässä tilanteessa, mutta ratkaisu on ilmeinen - kysy käyttäjältä, tarvitseeko hänen ladata ja asentaa riippuvuuksia. Juuri sitä mitä Haiku tekee.

Latasin 'sanity'-paketin manuaalisesti ja napsautin sitä, paketinhallinta tietää, mistä sen riippuvuudet saa (olettaen, että arkistot on jo rekisteröity järjestelmään). Jokainen Linux-jakelu ei pysty tähän.

Toinen tapa on käyttää tiedostonhallintaa vetämällä ja pudottamalla .hpkg paketissa tai sisällä /Haiku/system/packages (oletuksena koko järjestelmän laajuiselle asennukselle) tai sisään /Haiku/home/config/packages (yksittäiseen asennukseen; ei käytettävissä kaksoisnapsauttamalla - minua ärsyttää edelleen sana "config" tässä paikassa, joka tässä tapauksessa on minulle "asetukset" synonyymi). Ja usean käyttäjän konsepti ei ole vielä edes saatavilla Haikulle (siksi se on luultavasti niin yksinkertainen - en tiedä, ehkä usean käyttäjän ominaisuudet monimutkaistavat asioita tarpeettomasti työpöytäympäristössä).

Haiku voittaa tässä kategoriassa, koska se voi toimia paitsi sovellusten, myös järjestelmäohjelmien kanssa.

Paketin poistaminen graafisesta käyttöliittymästä

Macissa, sinun täytyy vetää sovelluskuvake roskakoriin, ja siinä kaikki. Helposti!

Haikulla, ensinnäkin sinun on selvitettävä, missä paketti sijaitsee järjestelmässä, koska asennat sen harvoin oikeaan paikkaan (järjestelmä tekee kaiken). Yleensä pitää katsoa sisään /Haiku/system/packages (järjestelmänlaajuisella oletusasennuksella) tai sisään /Haiku/home/config/packages (Maininko, että "config" on harhaanjohtava nimitys?). Sitten sovellus vedetään yksinkertaisesti roskakoriin, ja siinä se.
Helposti! En kuitenkaan sanoisi niin. Tässä on mitä todella tapahtuu:

Näin tapahtuu, jos vedät sovelluksen roskakoriin /Haiku/system/packages

Yritin juuri siirtää eilisen "Hello World" -sovellukseni QtQuickAppissa roskakoriin. En yrittänyt siirtää järjestelmähakemistoa, ja koska kaikki paketit on asennettu järjestelmähakemistoon, paketin poistaminen on mahdotonta .hpkg ilman muutosta "sen sisältö". Tavallinen käyttäjä pelästyisi ja painaisi oletusarvoisesti määritettyä "Peruuta"-painiketta.

selittää Herra. waddlesplish:

Tämä viesti on yli 10 vuotta vanha. Todennäköisesti meidän on määritettävä se niin, että varoitus tulee näkyviin vain, kun itse paketti siirretään. Tavallisten käyttäjien ei tarvitse tehdä tätä joka tapauksessa.

Okei, ehkä minun pitäisi tehdä tämä HaikuDepotilla? Kaksoisnapsautan pakettia /Haiku/system/packages, odottaa "Poista asennus" -painikkeen ilmestymistä. Ei, siellä on (vain) "Asenna". "Poista asennus", missä olet?

Ihan huvin vuoksi yritin nähdä, mitä tapahtuisi, jos napsautan "Asenna" jo asennetussa paketissa. Siitä tulee näin:

Tämä tapahtuu, jos yrität asentaa jo asennetun paketin.

Seuraava tulee näkyviin:

Jos napsautat "Käytä muutokset" edellisessä ikkunassa, se näyttää tältä

Oletan, että tämä on ohjelmistovirhe; linkki sovellukseen on jo olemassa. [kirjoittaja ei antanut linkkiä - noin. kääntäjä]

Nopea ratkaisu: Lisää "Poista"-painike, jos paketti on jo mukana /Haiku/system/packages, tai sisään /Haiku/home/config/packages.

Kun katson HaikuDepotiin asennettujen pakettien luetteloa, näen pakettini luettelossa ja voin poistaa sen.

Mac voittaa tässä kategoriassa. Mutta voin kuvitella, että oikealla asennuksella Haiku-käyttökokemus on parempi kuin Macissa. (Yksi kehittäjistä arvioi sen näin: "Alle tunti määritetyn toiminnon lisäämiseen HaikuDepotiin, jos osaatte vähän C++:aa, onko vapaaehtoisia?)

Jotain poistaminen paketista

Yritetään poistaa itse sovellus, ei paketti .hpkg, josta se tuli (epäilen, että "pelkät kuolevaiset" ovat eroja).

Macissa, käyttäjä itse asiassa yleensä työskentelee tiedoston kanssa .dmgmistä sovelluspaketti tulee .app. Yleensä kuvia .dmg kerätään lataushakemistoon, ja käyttäjä kopioi paketit sinne /Applications. Uskotaan, että monet käyttäjät eivät itse tiedä mitä he tekevät, entinen Applen työntekijä vahvistaa tämän hypoteesin. (Yksi asioista, joista en pidä Macissa. Ja esimerkiksi AppImagen kanssa ei ole eroa sovelluksen ja paketin välillä, jossa se oli. Vedä kuvake roskakoriin = siinä se. Helppoa!)

Haikulla, välillä on myös jako apps/ и packages/, joten epäilen, että tämä selvensi asiaa käyttäjille. Mutta mitä tapahtuu, jos vedät sovelluksen apps/ Lisää ostoskoriin:

Näin tapahtuu, kun yrität poistaa tiedostosta otettua sovellusta .hpkg

Teknisesti se on oikein (sovellus on loppujen lopuksi isännöity vain luku -tiedostojärjestelmässä), mutta se ei ole erityisen hyödyllinen käyttäjälle.

Nopea ratkaisu: suosittele sen sijaan GUI:n käyttöä poistamiseen .hpkg

Ihan huvin vuoksi yritin kopioida sovelluksen painamalla Alt+D. Sain viestin "Ei voi siirtää tai kopioida objekteja vain luku -taltiolla." Ja kaikki siksi /system (sitä paitsi /system/packages и /system/settings) on packagefs-liitoskohta (muista, kuinka se näkyy tulosteessa df?). Valitettavasti komennon tulos mount ei selvennä tilannetta (kuten eräässä edellisessä artikkelissa todettiin), mountvolume ei näytä etsimääsi (ilmeisesti paketit, jotka on asennettu silmukan kautta .hpkg ei pidetä "volyymeina"), ja unohdin myös vaihtoehtoiset komennot.

Kukaan ei voittanut tässä kategoriassa paitsi AppImage (mutta ollakseni täysin rehellinen, tämä on puolueellinen mielipide). Voidaan kuitenkin kuvitella, että säätämisen jälkeen käyttökokemus Haikulla on parempi kuin Macissa.

Huomautus: sinun on selvitettävä, mikä "volyymi" on suhteessa "osaan". Tämä muistuttaa todennäköisesti "kansion" ja "hakemiston" suhdetta: useimmat hakemistot näkyvät kansioina tiedostonhallinnassa, mutta eivät kaikki (esimerkiksi tiedostoina käsitellyt paketit). Tekeekö tällainen näyttö minusta virallisen nörtin?

Paketin sisällön kopioiminen toiseen järjestelmään

Macissa, Vedän tyhmästi pakettia .app, ja koska riippuvuudet ovat paketin sisällä, ne liikkuvat yhdessä.

Haikulla, Vedän sovellusta, mutta riippuvuuksia ei käsitellä ollenkaan.

Nopea ratkaisu: ehdotetaan sen sijaan koko `.hpkg-paketin vetämistä mahdollisten riippuvuuksien kanssa.

Mac voittaa selvästi tässä kategoriassa. Ainakin minulle, heidän paradigman rakastajalle. Minun pitäisi kopioida se Haikulle .hpkg sovelluksen sijaan, mutta järjestelmä ei tarjoa minulle tätä...

Lataa paketti kaikkine riippuvuuksineen

Kaikki koneet eivät ole jatkuvasti yhteydessä verkkoon. Päinvastoin, jotkut koneet (kyllä, katson sinua, moderni Windows, Mac ja Linux) unohtavat tämän. Minulle on tärkeää, että voin mennä esimerkiksi nettikahvilaan, ladata ohjelmiston siirrettävälle asemalle, laittaa tämän aseman kotikoneeseeni ja olla varma, että kaikki toimii [riskimies, tekee tätä Windowsissa... - noin kääntäjä].

Tämän seurauksena minulla on tapana päätyä tyydyttämättömiin riippuvuuksiin Windowsista ja Linuxista hieman tavallista useammin.

Macissa tämä on yleensä yksi tiedosto, sinun tarvitsee vain ladata .dmg. Useimmiten sillä ei ole muita riippuvuuksia kuin ne, jotka MacOS itse tarjoaa oletuksena. Poikkeuksen muodostavat monimutkaiset sovellukset, jotka vaativat sopivan suoritusympäristön, esimerkiksi Java.

Haikulla lataa paketti .hpkg vaikkapa samalle sovellukselle javassa, se ei välttämättä riitä, koska java voi olla tai ei ehkä ole läsnä kohdekoneessa. Onko mahdollista ladata kaikki tietyn paketin riippuvuudet .hpkg, muut kuin ne, jotka on asennettu oletuksena Haikuon ja joiden pitäisi siksi olla jokaisessa Haiku-järjestelmässä?

Mac voittaa tämän kategorian pienellä erolla.

Kommentit Mr. waddlespllash:

Kirjoittaa ohjelman, joka kerää kaikki sovelluksen riippuvuudet paketteina .hpkg Haikun sisäiseen toimintaan perehtyneelle noin 15 minuuttia riittää. Tuen lisääminen tähän ei ole niin vaikeaa, jos sille on todellinen tarve. Mutta minulle tämä on harvinainen tilanne.

Pidätetään hengitystä tämän sarjan seuraavaan artikkeliin asti.

Pakettien siirtäminen eri paikkaan

Kuten aiemmin kirjoitin, haluan laittaa pakettini .hpkg (tai osa niistä) erityiseen paikkaan, erilleen tavallisesta paikasta käynnistystaltiolla (juuriosio). Tavallisessa (ei niin teoreettisessa) tapauksessa syynä tähän on se, että (sisäänrakennetuilla) levyilläni loppuu jatkuvasti vapaa tila, olivatpa ne kuinka suuria tahansa. Ja yleensä yhdistän ulkoiset asemat tai verkko-osuudet sinne, missä sovellukseni sijaitsevat.

Macissa Siirrän vain paketteja .app siirrettävälle asemalle tai verkkohakemistoon Finderissa, ja siinä kaikki. Voin silti avata sovelluksen kaksoisnapsauttamalla normaalisti käynnistystaltiolla. Vain!

Haikulla, kuten minulle kerrottiin, tämä voidaan saavuttaa siirtämällä minun .hpkg paketit siirrettävälle asemalle tai verkkohakemistoon, mutta silloin sinun on käytettävä joitain dokumentoimattomia komentoja konsolissa liittääksesi ne järjestelmään. En tiedä miten tämä tehdään pelkällä graafisella käyttöliittymällä.

Mac voittaa tässä kategoriassa.

Mr. waddlespllash:

Tämä on normaalikäyttöön perustuva optimointi. Jos kysyntää on useammalta kuin yhdeltä käyttäjältä, toteutamme sen. Joka tapauksessa on olemassa mahdollisuus kolmannen osapuolen toteuttamiseen.

Puhumme tästä seuraavassa artikkelissa.

Verkkohakemistoista puheen ollen, olisi hienoa (arvelen LAN-osapuolet) omaa yksinkertaisia, löydettäviä, verkon laajuisia sovelluksia (kuten Zeroconf), jotka voidaan kopioida paikalliseen tietokoneeseen tai ajaa suoraan paikallisverkosta. Tietenkin kehittäjillä on mahdollisuus kieltäytyä käytöstä kautta app_flags.

Loppuraportti hpkg-järjestelmän integroinnista graafiseen käyttöliittymään

Luulen, että se johtuu ennen kaikkea integraation suhteellisesta uutuudesta .hpkg GUI jättää vielä paljon toivomisen varaa. Joka tapauksessa on joitain asioita, joita voitaisiin parantaa käyttökokemuksen suhteen...

Vielä yksi asia: Kernel Debug Land

Olisi hienoa pystyä syöttämään komentoja esimerkiksi ytimen paniikin aikana syslog | grep usb. No, Haikulla se on mahdollista Kernel Debug Landin ansiosta. Kuinka voit nähdä tämän taikuuden toiminnassa, jos kaikki toimii niin kuin pitääkin joutumatta ytimen paniikkiin? Helppoa painamalla Alt+PrintScn+D (debug-muistomerkki). muistan heti Ohjelmoijan avain, jonka avulla alkuperäiset Macintosh-kehittäjät pääsivät debuggeriin (jos sellainen oli tietysti asennettu).

Johtopäätös

Olen alkanut ymmärtää, että Haiku-järjestelmän hienostuneisuus tulee siitä, että työn tekee yksi pieni tiimi, joka keskittyy selkeästi työympäristöön ja jossa järjestelmän kaikki kerrokset ovat käytettävissä.
Terävä kontrasti Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntun maailmaan, jossa kaikki on hajotettu pieniksi paloiksi siinä määrin, että abstraktio istuu abstraktion päällä ja ajaa kainalosauvoilla.
Siellä oli myös ymmärrys siitä, miten järjestelmä .hpkg yhdistää perinteisten paketinhallintaohjelmien, Snappyn, Flatpakin, AppImagen, jopa btrfs:n, parhaat käytännöt ja yhdistää ne Macin "vain toimii" -lähestymistapaan.

Tuntui kuin jokin "muuttuisi" päässäni, ja ymmärsin kuinka järjestelmä .hpkg tietää kuinka rullata pois, vain katsomalla häntä. Mutta se en ole minä, vaan järjestelmän kauneus ja yksinkertaisuus. Suuri osa tästä on saanut inspiraationsa alkuperäisen Macin hengestä.

Kyllä, selaimessa selaaminen voi olla nykivää ja toimia kuin etana, sovelluksia saattaa puuttua (ei Gtk, Electron - kehittäjät päättelivät, että ne eivät sovi hienostuneeseen), video ja 3D-kiihdytys voivat puuttua kokonaan, mutta silti tykkää tästä järjestelmästä. Loppujen lopuksi nämä asiat voidaan korjata ja ne näkyvät ennemmin tai myöhemmin. Se on vain ajan kysymys ja ehkä hieman punasilmäisyyttä.

En voi tarjota apua, mutta uskon, että se alkaa tästä lähtien Haiku-vuosi työpöydällä.

Satunnaisia ​​ongelmia

Ehkä pyyntöjä on jo, vai pitäisikö minun avata ne?

• BeScreenCapturen pitäisi pystyä viemään GIF-muotoon, kuten Peek. Tämä voidaan tehdä käyttämällä ffmpegiä, joka on jo saatavilla Haikulle. Pyyntö.
• Kuvakaappausohjelmisto ei pysty kaappaamaan modaalista ikkunaa, vaan se kaappaa koko näytön
• Et voi rajata kuvakaappauksia WonderBrushin rajaustyökalulla ja tallentaa tulosta tiedostoon
• En erityisemmin pidä käsikursorista Haikussa, mutta luulen sen liittyvän lämpimään nostalgiseen tunteeseen. Tämä on erityisen ärsyttävää käytettäessä rajaustyökalua Kritassa, koska se johtaa epätarkkaan rajaukseen (katso tämän artikkelin kuvakaappauksia modaalisista valintaikkunoista). Hiusristikkokohdistin olisi ihana. Pyyntö.

Kokeile itse! Loppujen lopuksi Haiku-projekti tarjoaa kuvia käynnistettäväksi DVD- tai USB-levyltä päivittäin. Asentaaksesi lataa vain kuva ja kirjoita se flash-asemaan käyttämällä etsaaja

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 kuudes artikkeli Haikua käsittelevässä sarjassa.

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

Lähde: will.com