🥇Minu kuues päev Haikus: ressursid, ikoonid ja paketid kapoti all

TL;DR: Haiku — operatsioonisüsteem, mis on spetsiaalselt loodud arvutitele, seetõttu on sellel mõned nipid, mis muudavad selle töökeskkonna oluliselt paremaks kui teistel. Kuidas see aga töötab?

Hiljuti Avastasin Haiku, üllatavalt hea süsteemi. Olen jätkuvalt hämmingus, kui sujuvalt see töötab, eriti võrreldes Linuxi töökeskkondadega. Täna heidan pilgu selle alla. Seal, kus on vajalik sügavam mõistmine, teen võrdlusi originaalse Macintosh'i, Mac OS X ja Linuxi töökeskkondadega (freedesktop.org’i XDG standard).

Ressursid ELF-failides

Eile sain teada, et IconOMatic suudab salvestada ikoone rdef-resurssidena ELF-täidesaatevates failides. Täna tahan vaadata, kuidas see tegelikult töötab.

Ressursid? Tsitaat alates Bruce Horn, originaalne Macintosh Finderi looja ja „isa“ Macintosh Resource Manager'ile:

Mind ajab, et traditsiooniline koodikirjutamise stiil on nii jäik. Minu jaoks on idee rakendusest, mis on koodis külmutatud, ilma et oleks võimalik midagi dünaamiliselt muuta – äärmiselt ebaefektiivne. Peab olema võimalus muuta nii palju kui võimalik käitusaja jooksul. Loomulikult ei saa rakenduskoodi muuta, kuid kas midagi ei saaks siiski muuta ilma koodi taas kompileerimata?

Originaalsel Macintoshil oli võimalus, et nendel failidel on „andmesection” ja „ressursside section”, mis tegi erinevate asjade, näiteks ikoonide ja tõlgete salvestamise, erakordselt lihtsaks.exe faile.

Macil kasutatakse selleks ResEdit, graafikaprogrammi jaoks – ootamatult – ressursside redigeerimiseks.

ResEdit originaalsel Macintoshil

Tulemusena tekkis võimalus redigeerida ikoone, menüüelemente, tõlkeid jne piisavalt lihtsalt, kuid nad liiguvad ikkagi rakendustega.
Igal juhul oli selle lähenemise suur puudus: see töötas ainult Apple’i failisüsteemidel, mis oli üks põhjusi, miks Apple loobus „ressursside section’ist”, kui nad läksid üle Mac OS X-ile.
Mac OS X-is soovis Apple lahendust, mis ei sõltu failisüsteemist, seega kasutati pakettide (NeXTist) kontsepti, katalooge, mida failihaldur käsitleb kui "läbipaistmatuid objekte", sarnaselt failidega, mitte katalogidega. Iga rakenduse paketiga seotud juhul .app on, muu hulgas, fail Info.plist (Apple'i mingi JSON või YAML analoog), mis sisaldab rakenduse metaandmeid.

Mac OS X rakenduse paketi Info.plist faili võtmed.

Ressursid, näiteks ikoonid, UI failid ja muud, salvestatakse paketti failidena. Kontseptsioon on tegelikult tagasi toonud juured NeXTist.

Mathematica.app NeXTSTEP 1.0-l 1989. aastal: kuvatakse terminalis kui kataloog failidega, kuid kui ühtne objekt graafilises failihalduris.

Tagasi BeOS-i, mille kontseptsioonide põhjal Haiku rajatud. Selle arendajad, kui nad läksid PEF (PowerPC) pealt ELF (x86) (sama, mida kasutatakse Linuxis), otsustasid lisada ressursside sektsiooni ELF-failide lõppu. Selleks ei kasutatud omaette ELF-i sektsiooni, see lihtsalt kirjutati ELF-faili lõppu. Tulemusena programmid strip ja muud binutils, kes sellest ei teadnud, lihtsalt kustutasid selle. Seetõttu, kui lisada ressursse ELF-faili BeOS-is, on parem mitte kasutada Linuxi tööriistu.

Mis praegu Haikuga toimub? Põhimõtteliselt enam-vähem sama.

Teoreetiliselt oleks võimalik ressursse paigutada ELF-i vajalikku sektsiooni. Vastavalt arendajatele #haiku kanalil irc.freenode.net-is:

ELF-i sektsioonil oleks rohkem mõtet... ainus põhjus, miks me seda ei tee, on see, et nii tehti BeOS-is.
Ja seda ei tasu nüüd muuta.

Ressursside haldamine

Ressursid kirjutatakse struktureeritud 'ressursi' formaadis: põhimõtteliselt on see ressursside nimekiri suurustega ja seejärel nende sisu. Meenub formaat ar.
Kuidas kontrollida ressursse Haikus? Kas on midagi sarnast ResEdit-ile?
Vastavalt dokumentatsioonis:

Rakenduse paketiga kaasnevaid ressursse saab vaadata, lohistades käivitatava faili programmi, nagu Resourcer. Samuti saab minna terminali ja käivitada käsu listres failinimi.

Resourcer on HaikuDepot-is, kuid mul see lihtsalt laguneb.

Kuidas hallata ressursse ELF-failides? Kasutades rsrc ja rdef. rdef failid kogutakse rsrc. Fail rdef on tavalises tekstiformaadis, seega on sellega palju lihtsam töötada. Fail formaadis rsrc lisatakse ELF-faili lõppu. Proovime mängida:

~> rc -h
Haiku Resursikompilaator 1.1Rdef skripti kompileerimiseks ressursifailiks:
    rc [valikud] [-o ] ... Ressursifaili tagasi rdef skriptiks teisendamiseks:
    rc [valikud] [-o ] -d ...Valikud:
    -d --decompile       loo rdef skript ressursifailist
       --auto-names      konstrueeri ressursi nimed ID sümbolitest
    -h --help            näita seda teadet
    -I --include    lisa  kaasaja teede loendisse
    -m --merge           ära kustuta väljundi faili olemasolevaid sisu
    -o --output          määrake väljundfaili nimi, vaikeväärtus on out.xxx
    -q --quiet           ärge kuvage ühtegi veateadet
    -V --version         näita tarkvara versiooni ja litsentsi

Saab kasutada programmi xres kontrollimiseks ja haldamiseks:

/> 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.
(...)

No hästi, proovime?

/> 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

Ressurssidest ja formaatidest rohkem rdef võib lugeda siit.

Standardsed ressursitüübid

Kuigi ressursidesse võib panna kõike, on mõned kindlad standardsed tüübid:

app_signature: rakenduse MIME-tüüp, faili avamise, käivitamise, IPC jne. vastavuse jaoks.
app_name_catalog_entry: Kuna rakenduse nimi on tavaliselt inglise keeles, siis siia saab märkida kohad, kus asuvad tõlgitud nimed, et erinevate keelte kasutajad saaksid soovikorral näha tõlgitud rakenduse nime.
app_version: täpselt see, mida sa mõtlesid
app_flags: näitab registrar kuidas rakendust töödelda. Ma arvan, et on midagi enam, kui see esmapilgul paistab. Näiteks on B_SINGLE_LAUNCH, mis sunnib süsteemi rakenduse uut protsessi käivitama iga kord, kui kasutaja seda küsib (sama põhimõtet kasutatakse enamikus Linuxi rakendustes). On B_MULTIPLE_LAUNCH, mis sunnib käivitama protsessi iga faili. Lõpuks on olemas B_EXCLUSIVE_LAUNCH, mis sunnib süsteemi käivitama ainult ühte protsessi korraga, olenemata sellest, kui sageli kasutajad seda käivitavad (näiteks käivitub Firefox Linuxis samamoodi; samu tulemusi võib saavutada Qt rakendustes, kasutades funktsiooni QtSingleApplication). Rakendused saavad B_EXCLUSIVE_LAUNCH teavitusi, kui kasutaja proovib neid uuesti käivitada: näiteks saavad nad faili tee, mida kasutaja soovib avada nende abiga.
vector_icon: Rakenduse vektoriikoon (BeOS-is ei olnud vektoriikoone, enamikul rakendustest olid selle asemel kaks rasterdatat ikooni käivitatavates failides).

Muidugi saate lisada ressursse mis tahes soovitud IDde ja tüüpidega ning seejärel lugeda neid rakenduses või teistes rakendustes klassi kaudu. BResources. Aga enne, kui liigume edasi, peatume põneval teemal ikoonidest.

Haiku stiilis vektorikoonid

Loomulikult ei valinud ainult Haiku parimat ikooniformaati. Linuxi töökeskkondade olukord on selles osas kaugel ideaalist:

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

Seda nähes võib juba tunda, millega on tegemist.

Muidugi on olemas scalable, mis sisaldab, nagu võib arvata, vektorikoone. Miks siis on midagi veel? Sest vektorgraafika joonistamise tulemused väikestes mõõtmetes võivad olla halvemad kui ideaalne. Soovime, et meil oleks erinevad variandid, mis on optimeeritud erinevate suuruste jaoks. Linuxi töökeskkondades saavutatakse see ikoonide erinevate suurustega hajutamisega failisüsteemis.

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

Pange tähele: Firefoxi erinevate versioonide mõisted ei eksisteeri. Seega ei saa olukorda, kus süsteemis on mitu versiooni rakendusest, peenelt käsitleda.

Firefoxi erinevad ikoonid erinevates versioonides. Hetkel ei ole võimalik seda Linuxis ilma erinevate lahendusteta käsitleda.

Mac OS X käsitleb seda veidi peenelt:

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

On näha, et üks fail firefox.icns pakendis Firefox.app, mis sisaldab kõiki mõõtmeid, seega on erinevatel versioonidel ühel rakendusel erinevad ikoonid.
Kaugel parem! Ikoonid reisivad koos rakendusega, kõik ressursid on ühes failis.

Naaseme Haiku juurde. Üks hämmastav lahendus, ilma eranditeta. Vastavalt dokumentatsioonis:

on loodud eriline, väikesemahuline ja kiirelt joonistatud HVIF-formaat. Seetõttu on meie ikoonid peamiselt palju väiksemad kui raster- või laialdaselt kasutatav SVG-formaat.

Ja nad on tõesti optimeeritud:

Ikooni suurused HVIF-s võrreldes teiste formaatidega.

Erinevus on kordades!

Kuid siin ei lõpe maagia. Üks ja sama HVIF võib näidata erinevaid detailitasemeid sõltuvalt kuvatavast suurusest, hoolimata sellest, et see on vektorig formaat.

Erinevad detailitasemed (LOD) sõltuvalt joonistuse suurusest

Nüüd puudutame puudusi: ei saa lihtsalt võtta SVG-d, visata selle ImageMagick'isse ja sellega lõpetada, tuleb läbida mitu tsüklit HVIF formaadis ikooni loomiseks. Siin selgitusi. Siiski võib IconOMatic SVG importida piisavalt ebaühtlaselt; umbes 90% SVG detailidest imporditakse teatud tõenäosusega, ülejäänud 10% tuleb seadistada ja muuta käsitsi. Loe lähemalt, kuidas HVIF oma maagia teostab saab blogis Lea Gensson

Ikooni lisamine rakendusse

Nüüd saan ma lisada ikooni paketti, mille olen loonud eelmisel korral, arvesse võttes kõiki saadud andmeid.
Kuna ma ei soovi praegu oma «Tere, maailm» QtQuickApp'i jaoks oma ikooni joonistada — tõmban selle Qt Creatorist.

/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

Vaatame, kas ikoon on kopeeritud:

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

Näeb hea välja, kuid miks ei kuvata uut ikooni pärast selle kopeerimist?

Kopeeritud VICN:101:BEOS:ICONs ei kasutata rakenduse ikoonina failihalduris

Mida ma olen maha maganud?

Arendaja kommentaar:

Pean looma faili rdef kõigi ressurssidega, seejärel käitama käsku rc nimi.rdef, see loob faili .rsrc. Siis pean käivitama käsu resattr -o nimi_binaar nime.rsrc. Ma kasutan vähemalt selliseid käske, et lisada ikoone oma skriptidele.

Aga ma tahtsin luua ressursi, mitte atributi. Olen tõeliselt segaduses.

Nutikas vahetamine failisüsteemi kasutamisega

ELFi atribuutide avamine ja lugemine on aeglane. Nagu juba varem mainisin, kirjutatakse ikoon ressursina faili endasse. See meetod on usaldusväärsem ja talub kopeerimist teise failisüsteemi. Kuid see kopeeritakse ka failisüsteemi atribuudiks, näiteks BEOS:ICON. See töötab ainult teatud failisüsteemides, näiteks BFS. Süsteem näitab ikoonid (Trackeris ja Deskbaris) sellest laiendatud atribuudist, kuna taoline lahendus toimib kiiresti. Mõnes kohas (seal, kus kiirus ei ole oluline, näiteks „Teave programmi” aken) saab süsteem ikooni otse failist. Kuid see ei ole veel lõpp. Pidage meeles, et Macis said kasutajad asendada rakenduste, kataloogide, dokumentide ikoone oma ikoonidega, kuna Mac pakub võimalust teha neid „olulisi” asju, näiteks Slacki uue ikooni asendamine varasema vastu. Haikus tuleks ressurssi (failis) käsitleda kui rakenduse tarnitavat algset ikoont, ja atribuudina (BFS failisüsteemis) kui midagi, mis lubab kasutajal soovi korral muudatusi teha (kuigi, vihje, graafiline liides kasutajaikooni lisamiseks vaikimisi ikoonile ei ole veel rakendatud).

Failisüsteemi atribuutide kontrollimine

Käesoleva abil resaddr on võimalik kontrollida ja seada failisüsteemi atribuute.

/> 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.
(...)

Sisuliselt on see "liim", mis teostab ümberkujundust usaldusväärsete ressursside ja kiirete failisüsteemi atribuutide vahel. Kuna süsteem eeldab ressursside hankimist ja teostab kopeerimist automaatselt, ei pea ma enam selle pärast muretsema.

hpkg pakettide maagia

Praegu (kõige sagedamini) kasutatakse Haiku programmide hankimiseks pakette .hpkg. Ärge laske end petta lihtsast nimest: .hpkg formaat töötab täiesti erinevalt kui teised sarnaste nimedega formaadid, millega olete kokku puutunud, sellel on reaalsed supervõimed.

Klassikaliste paketiformaatidega olin ma pikalt häiritud sellisest faktist: laadid alla ühe (paketi), kuid süsteemi installitakse midagi muud (failid paketi sees). Failidega on keeruline ümber käia (näiteks need kustutada), kui paketti installitakse traditsiooniliselt. Ja kõik see juhtus seetõttu, et paketi sisu jaotub kogu failisüsteemis, sealhulgas kohtadesse, kuhu tavaline kasutaja ei pruugi kirjutamisõigust omada. See tekitab terve klassi programme — paketihaldureid. Ja juba installitud tarkvara, näiteks teise arvutisse, välisele kõvakettale või failiserverisse edasiviimine muutub isegi keeruliseks või sootuks võimatuks. Tavalises Linuxi põhises süsteemis võib kergesti eksisteerida sadu tuhandeid kuni miljoneid isoleeritud faile. Loomulikult on see samal ajal ebastabiilne ja aeglane, näiteks süsteemi esmasel installimisel, tavaliste paketide installimisel, uuendamisel ja eemaldamisel, samuti käivitustsümboli (juurkatalooge) teisele kandjale kopeerimisel.

Ma töötan projekti AppImage kallal, mis on osaline lahendus lõppkasutajate rakenduste jaoks. See on tarkvara levitusformaadi, mis kogub rakenduse ja kõik selle sõltuvused ühte failisüsteemi pildisse, mida monteeritakse rakenduse käivitamisel. See lihtsustab asju märkimisväärselt, kuna sama ImageMagick muutub äkitselt üheks failiks, mida saavad tavalised inimesed failihalduris juhtida. Pakutud lähenemine töötab ainult tarkvara jaoks, nagu projektinimi näitab, ja tal on oma probleemide kogum, kuna Linuxi tarkvara tarnimisega tegelejad suunavad alati näpuga minu poole.

Jõuame tagasi Haiku juurde. Kas õnnestus leida optimaalne tasakaal traditsiooniliste paketisüsteemide ja pildipõhise tarkvarajagamise vahel? Selle paketid .hpkg on tegelikult tihendatud failisüsteemi pildid. Süsteemi käivitamisel monteerib ydas kogu paigaldatud ja aktiivsed paketid järgmiste tuumateadete põhjal:

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

Lahe, eks? Hoidke kinni, edasi läheb veelgi huvitavamaks!

On üks väga eriline pakett:

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

See sisaldab väga minimaliseeritud operatsioonisüsteemi, sealhulgas tuuma. Usuge või mitte, aga isegi tuum ei ekstraheerita käivitusmahtudest (juurdehõivatud osast), vaid laaditakse hoolikalt paketti oma kohale. .hpkg. See, I already mentioned that part of the overall refinement and consistency of Haiku comes from the fact that the entire system, from the kernel and the basic user space to the package management and the infrastructure of the working environment, is developed by a single team. Just imagine how many different groups and teams would be needed to launch something like this based on Linux. [I imagine the PuppyLinux project, — translator's note]. Then imagine how much time it would take for this approach to be implemented in distributions. They say: take a simple task, divide it among different performers, and it will become so complicated that it will no longer be solvable. Haiku opened my eyes in this case. I think this is exactly what is happening in Linux right now (Linux here is a collective term referring to the Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu stack).

System rollback using hpkg

Kui sageli juhtub järgmine olukord: uuendus läks edukalt, kuid seejärel selgub, et midagi ei tööta nii, nagu peaks? Tavaliste paketihalduritega on väga raske taastada süsteemi seisundit enne uute pakettide installimist (näiteks juhul, kui midagi läks valesti). Mõned süsteemid pakuvad lahendusi failisüsteemi koopiate näol, kuid need on üsna mahukad ja neid ei kasuta kõik süsteemid. Haikus on see lahendatud pakettide kaudu. .hpkgIga kord, kui süsteemis pakette muudetakse, ei kustutata vanu pakette, vaid need salvestatakse süsteemis alamkataloogidesse, mis näevad välja nagu. /Haiku/system/packages/administrative/state-<...>/ pidevalt. Katkised toimingud salvestavad oma andmed alamkataloogidesse. /Haiku/system/packages/administrative/transaction-<...>/.

Sisu /Haiku/system/packages/administrativeKataloogid "state…" sisaldavad tekstifaile aktiivsete paketide nimedega, "transaction…" – need on ise paketid.

"Vana aktiivne seisund", st loend .hpkg pakettidest, mis olid aktiivsed enne muudatusi, salvestatakse iga toimingu järel failihaldurisse tekstifaili. /Haiku/system/packages/administrative/state-<...>/activated-packagesSarnaselt kirjutatakse uus "aktiivne seisund" tekstifaili. /Haiku/system/packages/administrative/activated-packages.

Kataloog /Haiku/system/packages/administrative/state-<...>/ sisaldab ainult tekstifaili, kus on loetelu selle oleku aktiivsetest pakettidest (pakettide installimise korral ilma kustutamiseta), ja kui pakette on kustutatud või uuendatud, siis state kataloog sisaldab vanemaid versioone.

Süsteemi käivitamisel otsustatakse pakettide aktiveerimine (mountimine) pakettide loendi alusel. Just nii lihtsalt! Kui käivitamisel peaks midagi valesti minema, saab laadimishaldurile öelda, et kasutada teist, vanemat loendit. Probleem lahendatud!

Haiku laadija. Iga sisenemispunkt peegeldab vastavat "aktiivset olekut"

Mulle meeldib lähenemine, kus lihtsad tekstifailid on "aktiivse oleku" loendina, milles on arusaadavad nimed .hpkg. See on terav kontrast masinatele loodud, mitte inimestele. kogum OSTree või Flatpaki süsteemifailide seas (seal, kus on ka Microsofti GUID).

Iga hetke aktiivsete pakettide loetelu

Seaded

Tundub, et kataloogis /Haiku/system/packages/administrative/writable-files on seadistuste failid pakettide jaoks, kuid kirjutamiseks saadaval. Nagu me mäletame, .hpkg on ainult lugemiseks. Seega tuleb need failid enne kirjutamist paketist kopeerida. See on mõistlik.

GUI integreerimine süsteemile .hpkg

Vaatame nüüd, kuidas need säravad paketid .hpkg integreeruvad kasutaja töökeskkonda (UX). Lõppude lõpuks on Haiku mõeldud isiklikuks kasutamiseks. Isiklikult seadsin kõrge lati, võrreldes kasutajakogemust paketiga .app Macintoshes sama kogemusega .hpkg. Ma ei hakka isegi võrdlema olukorda Linuxi töökeskkondades, kuna see on absoluutselt kohutav võrreldes teistega.

Käivad järgmised stsenaariumid:

Soovin vaadata paketi sisu .hpkg
Soovin installida paketi
Soovin eemaldada paketi
Soovin eemaldada midagi, mis tuli süsteemi osana paketist
Soovin kopeerida midagi, mis tuli süsteemi osana paketist
Soovin alla laadida kõik paketi sõltuvused, mis ei saa olla osa igast Haiku installatsioonist (näiteks mul on füüsiliselt isoleeritud masin, millel ei ole internetiühendust.)
Soovin, et mu paketid (või nende osa) oleks eraldi teises kohas, eraldi laadimise mahust (juurkataloogist) (sest mul on näiteks seal ruumi vähe).

See peaks katma enamik põhijuhtumeid minu igapäevases töös. Alustame.

Paketi sisu kontrollimine

Macis klikin paketi peal hiire parema nupuga selle avamiseks ja sisu vaatamiseks Finderis. Tegelikult on see lihtsalt maskeeritud kataloog! (Tean, et on olemas pakette .pkg süsteemi osa jaoks, mis ei ole rakendused, aga tavalised kasutajad nendega üldiselt ei suhtle).

Haikus klikin paketti hiire parema nupuga, seejärel klikin "Contents" sisu vaatamiseks. Siin on lihtsalt failide loend, ilma et saaks neid kahekordse klõpsuga avada.
Oleks palju parem, kui oleks võimalik (ajutiselt) paketti monteerida .hpkg failihalduri kaudu vaatamiseks, nii et kasutaja ei peaks tegelema teostuse detailidega. (Muide, paketti saab avada .hpkg pakettis Expanderis, mis suudab selle välja pakkida nagu mis tahes muu arhiiv).

HaikuDepot liideses saab vaadata paketi failide loendit, kuid ei ole võimalik vaadata sisu, näiteks kahekordse klikiga README.md failile.

Selles kategoorias võidab Mac, kuid vajalike funktsioonide lisamine HaikuDepot ei tohiks olla suurem probleem.

Paketi installimine GUI kaudu

Macis, enamikketta pilte .dmg sisaldavad pakette. .appAvame kahekordse klikiga kettapildi, seejärel kopeerime paketi, näiteks lohistades selle /Applications Finderisse. Minu jaoks on see iseenesestmõistetav, kuid olen kuulnud, et mõned algajad võivad selle üle saada. Vaikimisi „soovitab” Apple üldsüsteemi katalooge /Applications (NeXT-is oli see võrgus ja individuaalne), kuid oma rakenduste paigutamine faili serverisse või alamkausta $HOME/Applications, kui see teile sobib.

Haikus, kahekordne klikk paketile, siis klikk „Install”, ei saa lihtsam olla. Mind huvitab, mis juhtub, kui paketil on sõltuvused, mis on HaikuPorts saadaval, kuid veel mitte installitud. Linuxi puhul ei teata, mida sellises olukorras teha, kuid lahendus on selge — küsida kasutajalt, kas ta soovib sõltuvusi alla laadida ja installida. Täpselt sellist asja teebki Haiku.

Laadin paketi 'sanity' käsitsi ja klõpsasin selle peale, paketihaldur teab, kust saada selle sõltuvusi (kui repositooriumid on juba süsteemis määratud). Mitte iga Linuxi jaotamine ei oska seda.

Teine võimalus on failihalduri kasutamine, piisab, kui lohistada .hpkg pakett või /Haiku/system/packages (üldiseks installimiseks, vaikimisi), või /Haiku/home/config/packages (isiklikuks installimiseks; ei ole saadaval kahekordse klõpsuga - mind häirib ikka veel sõna „config” siin, mis minu jaoks on sellel juhul sünonüüm sõnale „settings”). Ehkki mitme kasutaja kontseptsioon pole Haikus veel saadaval (võib-olla seetõttu on kõik nii lihtne - ma ei tea, võib-olla liitkasutajate võimalused muudavad asju isikliku arvuti töökeskkonna jaoks liiga keeruliseks).

Selles kategoorias võidab Haiku, kuna see suudab töötada mitte ainult rakendustega, vaid ka süsteemiprogrammidega.

Paketist GUI kaudu eemaldamine

Macis, peate lohistama rakenduse ikooni prügikasti, ja sellega on kõik. Lihtne!

Haikus, esmalt peate leidma, kus pakett süsteemis asub, kuna te harva installite selle õiges kohta (kõike hallab süsteem). Tavaliselt tuleb otsida /Haiku/system/packages (üldise süsteemi vaikeseade), või /Haiku/home/config/packages (ma juba ütlesin, et «config» ei ole õige nimetus?). Siis rakendus lohistatakse lihtsalt prügikasti ja sellega kõik.
Lihtne! Kuigi, ma ei ütleks niimoodi. Mis tegelikult juhtub:

Nii on tulemuseks, kui rakendus lohistada prügikasti /Haiku/system/packages

Proovisin lihtsalt oma eelmise päeva rakendust «Tere, maailm» QtQuickApp'ist prügikasti viia. Ma ei püüdnud süsteemikausta liigutada, ja kuna kõik paketid installitakse süsteemikausta - ei ole võimalik pakk .hpkg ilma selle «sisu». Tavaline kasutaja kardaks seda, vajutaks vaikimisi nuppu «Tühista».

Selgitab mr. waddlesplash:

Sellel teadetel on juba üle 10 aasta. Tõenäoliselt peame selle seadma nii, et hoiatust kuvatakse ainult siis, kui paketti liigutatakse. Tavalised kasutajad ei pea seda niikuinii tegema.

Hästi, võib-olla peaksin seda tegema HaikuDepot'iga? Topeltklõpsan pakettide peal /Haiku/system/packages, ootades, et tuleks nupp «Eemalda». Ei, on (ainult) «Install». «Eemalda», kus sa oled?

Naljaks proovisin vaadata, mis juhtub, kui ma klõpsan nuppu «Install» juba installitud paketi puhul. Tulemus on järgmine:

Nii juhtub, kui proovite installida juba installitud paketti.

Järgmiseks kuvatakse:

Kui eelmisel aknas klõpsate «Apply changes», siis tulemuseks on see

Eeldan, et see on tarkvaraline viga, link taotlusele on juba olemas. [autor linki ei esitanud, — tõlkija märk.]

Kiire lahendus: lisada nupp «Uninstall», kui pakett on juba /Haiku/system/packages, või /Haiku/home/config/packages.

Vaadates HaikuDepotis installitud paketid loendit, näen ma oma paketti ja saan selle eemaldada.

Selles kategoorias võidab Mac. Kuid ma suudan ette kujutada, et korraliku seadistusega on kasutajakogemus Haikus parem kui Macil. (Üks arendajatest hindas seda nii: «Alla tunni, et lisada määratud funktsionaalsust HaikuDepotisse, kui natuke C++-st tead,» on vabatahtlikke?)

Mingite asjade eemaldamine paketist

Proovime eemaldada ise rakenduse, mitte paketi .hpkg, kust see pärines (kahtlen, et «tavalistele surelikele» on mingit vahet).

Macis, tegelikult töötab kasutaja tavaliselt failiga .dmg, kust rakenduse pakett tuleb .app. Tavaliselt kujutised .dmg kogunevad allalaadimiskausta, paketid aga kopeerib kasutaja /Applications. On arvamus, et paljud kasutajad ei tea ise, mida nad teevad, seda hüpoteesi kinnitab endine Apple'i töötaja. (Üks asi, mis mulle Mac'is ei meeldi. Näiteks AppImage'i puhul pole vahet rakenduse ja selle sisaldava paketi vahel. Tõmbas ikooni prügikasti = ja see on kõik. Lihtne!)

Haikus, samuti on erinevus rakendustes/ ja pakettides/, nii et kahtlen, kas kasutajad saavad sellest selgemaks. Aga mis juhtub, kui tõmmata rakendus rakendustes/ prügikasti:

Nii see välja näeb, kui proovitakse eemaldada rakendust, mis on saadud failist .hpkg

Tehniliselt on see õige (sest rakendus on paigutatud ainult lugemiseks mõeldud failisüsteemi), kuid see ei ole kasutajale eriti kasulik.

Kiire lahendus: pakkuda selle asemel GUI kaudu eemaldamist .hpkg

Põnevuse mõttes proovisin rakendust dubleerida, vajutades Alt+D. Tulin vastu teate 'Objekte ei saa kirjutada või kopeerida ainult lugemiseks mõeldud jaosal'. Ja kõik sellepärast, et /system (peale /system/packages ja /system/settings) on packagefs-i mount-punkt (mäletate, kuidas see ilmub väljundis df?). К сожалению, вывод команды mount ei selgita olukorda (nagu juba ühes varasemas artiklis öeldud), mountvolume ei näita otsitavat (ilmselt loop'i kaudu monteeritud paketid .hpkg ei loeta «mahtudeks»), ning ma unustasin alternatiivsed käsud.

Selles kategoorias ei võitnud keegi peale AppImage'i (aga see on, kui aus olla, kaldu arvamus). Siiski võib ette kujutada, et pärast kohandamist on kasutajakogemus Haikus parem kui Mac'is.

Märkus: tuleb välja selgitada, mis on «maht» seoses «jaotusega». Tõenäoliselt on see sarnane «kausta» ja «katalooge» suhtega: enamik katalooge kuvatakse failihaldurites kaustadena, kuid mitte kõik neist (näiteks paketid, mida käsitletakse failidena). Kas sellised väidavad, et ma olen ametlikult nörd?

Paketi sisu kopeerimine teisele süsteemile

Macis, lihtsalt lohistan paketti .app, ja kuna sõltuvused paketi sees — need liiguvad koos.

Haikus, ma lohistan rakenduse, aga sõltuvusi ei töödeldud üldse.

Kiire lahendus: Las pakkuda pigem `hpkg` paketiga koos selle sõltuvustega, kui need on olemas.

Selles kategoorias võidab kindlasti Mac. Ig至少 olen mina, nende paradigmade armastaja. Haiku peaks selle kopeerima. .hpkg rakenduse asemel, kuid süsteem ei paku mulle seda…

Paketi allalaadimine koos kõigi selle sõltuvustega

Kaup iga masin ei ole alati internetiga ühendatud. Vastupidi, mõned masinad (jah, ma vaatan teie poole, tänapäeva Windows, Mac ja Linux) unustavad selle. Minu jaoks on oluline, et ma saaksin näiteks minna internetikohvikusse, laadida tarkvara mälupulgale, panna selle mälupulga kodutornist ja olla kindel, et kõik töötab [riskialti poiss, sellist asja Windowsis teha... — tõlkija märkus].

Tulemuseks on veidi sagedamini, kui alati, et ma tavaliselt saan rahulolematud sõltuvused Windowsi ja Linuxi puhul.

Macis see on tavaliselt üks fail, kõik, mis on vajalik — alla laadida .dmg. Enamasti pole tal sõltuvusi, välja arvatud need, mis on vaikimisi MacOS-i poolt esitatud. Erandina võib tuua keerulised rakendused, mis vajavad vastavat käivituskeskkonda, näiteks java.

Haikus alla laadida pakett .hpkg näiteks jaava rakenduse jaoks võib osutuda piisavaks, kuna jaavakeel võib sihtmasinas puududa. Kas on võimalik alla laadida kõik sõltuvused selle paketi jaoks? .hpkg, välja arvatud need, mis installitakse Haikus vaikimisi ja peaks seetõttu olema igas Haiku süsteemis?

Selles kategoorias võidab vaieldamatult Mac.

Kommenteerib hr. waddlesplash:

Selleks, et kirjutada programm, mis kogub kõik rakenduse sõltuvused pakettide kogumina .hpkg on kellelegi, kes tunneb Haiku sisemist toimimist, piisavalt umbes 15 minutit. Selle toetuse lisamine ei peaks olema liiga keeruline, kui see on tõeline vajadus. Kuid minu jaoks on see haruldane olukord.

Hoidke hinge kinni järgmise artikli ootuses selle sarja jooksul.

Pakettide liigutamine eraldi kohta

Nagu ma juba varem mainisin, tahan ma paigutada oma paketid .hpkg (või nende osa) eraldi kohta, mis on tavalisest allika koha pealt eraldatud (juurpartitsioon). Tavaline põhjus (mis ei ole sugugi teoreetiline) on see, et ruum minu (sisseehitatud) kõvaketastel lõpeb pidevalt, olgu need kui suured tahes. Ja tavaliselt ühendan ma välist kõvaketast või võrguressursse, kus asuvad minu rakendused.

Macis lihtsalt liigutame paketid .app välisele kettale või võrgu katalooge Finderis ja see ongi kõik. Ma saan endiselt kahekordse klõpsuga avada rakenduse nagu tavaliselt tegin laadimisruumis. Lihtne!

Haikus, nagu mulle öeldi, on seda võimalik saavutada muude pakettide liigutamise teel .hpkg välisele kettale või võrgu katalooge, kuid seejärel peab kasutama mõningaid dokumenteerimata käske terminalis, et neid süsteemis monteerida. Ma ei tea, kuidas seda teha, kasutades ainult GUI-d.

Selles kategoorias võidab Mac.

Kohas mr. waddlesplash:

Siin on optimeerimine tavalise kasutuse kriteeriumide järgi. Kui nõudlus ületab ühe kasutaja oma, siis me viib sellise lahenduse ellu. Igatahes on lisalahenduste võimalus olemas.

Sellega räägime järgmisel korral.

Kui rääkida võrgukataloogidest: oleks tore (eeldan LAN peo korral) omada lihtsaid, leitavaid, võrguülevaate rakendusi (nt Zeroconfi kaudu), mida saaks kohalikule arvutile kopeerida või otse kohalikust võrgust käivitada. Loomulikult on arendajatel võimalus sellele vastu seista app_flags.

HPKG süsteemi integreerimise lõpparuanne koos GUI-ga

Ma arvan, et eeskätt seoses suhtelise uudsusega jääb integreerimine .hpkg GUI-ga siiski soovida. Igal juhul on mitmeid asju, mida kasutajakogemuse osas saaks parandada…

Veel üks asi: Kernel Debug Land

Oleks suurepärane omad kernel panic'i korral võimalus sisestada käske, näiteks syslog | grep usb. Noh, Haikus on see võimalik tänu Kernel Debug Landile. Kuidas näha seda maagiat tegevuses, kui kõik töötab nagu peab, ilma kernel panic'ita? Lihtne, vajutades Alt+PrintScn+D (mnemoonika Debug). Tulekse kohe meelde Programmer’s Key, mis lubas algsetel Macintosh'i arendajatel siseneda tõrkeotsingu tööriistasse (kui see oli installitud, muidugi).

Kokkuvõte

Mina hakkan aru saama, et Haiku süsteemi peenust toob välja see, et tööd teeb väike meeskond, kes on selgelt orienteeritud töökeskkonnale, kus kõik süsteemi kihid on kergesti kättesaadavad.
Terav kontrast Linuxi/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu maailmaga, kus kõik on nii väikesteks tükkideks lõhustatud, et abstraktsioon seisab abstraktsiooni peal ning toimetab puudega.
Samuti tuli arusaam, kuidas süsteem .hpkg kombineerib traditsiooniliste pakihaldurite, Snappy, Flatpaki, AppImage’i, isegi btrfs parimaid praktikaid ning segab need kokku Mac'i põhimõttega «lihtsalt töötab».

Nagu midagi oleks peas «lülitunud» ja ma sain aru, kuidas süsteem .hpkg suudab tagasiviimist, — lihtsalt sellele pilgu heitmine. Kuid see ei ole mina, vaid süsteemi ilu ja lihtsus. Paljuski on siin tunda algse Mac'i vaimu.

Jah, lehevaatamine brauseris võib olla kohmakas ja toimida nagu sisalik, rakendustest võib puududa (GTK, Electron — arendajad on tulnud järeldusele, et need ei sobi hästi peenuse tõttu), video ja 3D kiirendust võidakse üldse mitte olla, aga mulle see süsteem siiski meeldib. Need asjad on parandatavad ja need tulevad varem või hiljem. See on vaid aja küsimus ja ehk veidi punaseid silmi.

Ma ei saa aidata, aga arvan, et sellest hetkest alates algab aasta Haiku töölaual.

Juhuslikud probleemid

Võib-olla on juba püsiküsimused, või peaksin need avama?

BeScreenCapture peaks suutma eksportida GIF-ina, nagu Peek. Seda saab teha ffmpeg'i abil, mis on Haiku jaoks juba olemas. Püsiküsimus.
Kuvapüüdja programm ei suuda teha ekraanipilti modaalaknast, hoopis jääb kinni kogu ekraanile
Ekraanipilte ei saa kärpida WonderBrush'i lõikamise tööriistaga ja seejärel salvestada tulemust faili
Mulle ei meeldi Haiku's käe kujuga kursori idee, aga ma arvan, et see on seotud sooja nostalgiaga. See on eriti häiriv Kritas lõikeriista kasutamisel, kuna tulemuseks on ebatäpne lõikus (vt ekraanipilte dialoogidest selles artiklis). Ristkursori kasutamine oleks imeline. Püsiküsimus.

Katsuge ise! Haiku projekt pakub allalaadimiseks pilte DVD või USB, mis on loodud igal päeval.. Paigaldamiseks piisab pildi allalaadimisest ja selle kirjutamisest USB-mälupulgale koos Etcher

Kas on küsimusi? Olete oodatud venekeelsesse telegrami kanalisse..

Vea ülevaade: Kuidas endale jalga tulistada C ja C++-ga. Haiku OS retseptide kogumik.

Alates autori Tõlge: see on kuues artikkel Haiku seeriast.

Artiklite nimekiri: Esimene Teine Kolmas Neljas Viies

Allikas: habr.com