Minu kuues päev Haikuga: ressursside, ikoonide ja pakettide kapoti all

TL; DR: Haiku on spetsiaalselt personaalarvutite jaoks loodud operatsioonisüsteem, seega on sellel mitmeid nippe, mis muudavad selle töölauakeskkonna teistest palju paremaks. Aga kuidas see toimib?

Hiljuti Avastasin Haiku, üllatavalt hea süsteemi. Olen siiani hämmastunud, kui sujuvalt see töötab, eriti võrreldes töölauakeskkondadega LinuxTäna heidan pilgu kapoti alla. Vajadusel teen sügavama arusaamise huvides võrdlusi algse Macintoshi, Mac OS X-i ja töölauakeskkondadega. Linux (XDG standard saidilt freedesktop.org).

Ressursid ELF-i failides

Eile sain teada, et IconOMatic saab salvestada ikoone ELF-i käivitatavates failides rdef-ressurssidesse. Täna tahan näha, kuidas see tegelikult töötab.

Ressursid? Tsiteerima pärit Bruce Horn, Macintoshi Finderi algne autor ja Macintoshi ressursihalduri "isa":

Olen mures traditsioonilise kodeerimise jäikuse pärast. Minu jaoks on juba idee koodiga külmutatud rakendusest ilma võimaluseta midagi dünaamiliselt muuta kõige metsikum. Käitusajal peaks olema võimalik võimalikult palju muuta. Rakenduse koodi ennast muidugi muuta ei saa, aga kindlasti saab midagi muuta ilma koodi uuesti kompileerimata?

Algses Macintoshis tegid nad nendele failidele andmejaotise ja ressursside sektsiooni, mis muutis selliste asjade salvestamise nagu ikoonid, tõlked jms uskumatult lihtsaks. käivitatavates failides.

Macis kasutatakse seda ResEdit, graafiline programm ressursside ootamatuks redigeerimiseks.

ResEdit algsel Macintoshil

Tänu sellele sai võimalikuks muuta ikoone, menüüelemente, tõlkeid jne. piisavalt lihtne, kuid nad siiski "reisivad" koos rakendustega.
Igal juhul oli sellel lähenemisviisil suur puudus: see töötas ainult Apple'i failisüsteemides, mis oli üks põhjusi, miks Apple loobus Mac OS X-ile üleminekul "ressursside sektsioonist".
Mac OS X-is soovis Apple failisüsteemist sõltumatut lahendust, mistõttu nad võtsid kasutusele pakettide kontseptsiooni (alates NeXT-st), kataloogidest, mida failihaldur käsitleb "läbipaistmatute objektidena", nagu failid, mitte kataloogid. Iga pakett, millel on vormingus rakendus .app on muu hulgas ka fail Info.plist (mingis Apple'i ekvivalendis JSON-ile või YAML-ile), mis sisaldab rakenduse metaandmeid.

Võtmed faili Info.plist jaoks Mac OS X rakenduspaketist.

Ressursid, nagu ikoonid, kasutajaliidese failid ja muud, salvestatakse paketti failidena. Kontseptsioon naasis tegelikult NeXTis oma juurteni.

Mathematica.app versioonis NeXTSTEP 1.0 1989. aastal: kuvatakse terminalis failide kataloogina, kuid graafilises failihalduris ühe objektina.

Naaskem BeOS-i juurde, kontseptsioonide juurde, millel Haiku põhineb. Selle arendajad, kui nad PEF-ilt (PowerPC) ELF-ile (x86) (sama, mida kasutati...) lülitusid Linux) otsustasid ELF-failide lõppu lisada ressursisektsiooni. Selleks ei kasutanud nad omaenda ELF-sektsiooni, vaid lisasid selle lihtsalt ELF-faili lõppu. Selle tulemusel programm strip ja teised binutils'i utiliidid, sellest teadmata, lihtsalt kärpisid seda. Seetõttu on pärast ELF-failile ressursside lisamist BeOS-is kõige parem seda tööriistadega mitte manipuleerida. Linux.

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

Teoreetiliselt oleks võimalik paigutada ressursse ELFi soovitud sektsiooni. Irc.freenode.net kanali #haiku arendajate sõnul:

ELFi puhul oleks sektsioon mõttekam... ainus põhjus, miks me seda nii ei tee, on see, et me tegime seda BeOS-is."
Ja seda pole mõtet praegu muuta.

Ressursside haldamine

Ressursid on kirjutatud struktureeritud "ressursside" vormingus: sisuliselt ressursside loend koos suuruste ja seejärel nende sisuga. Mulle meenus ar formaadis.
Kuidas kontrollida Haiku ressursse? Kas on midagi sellist nagu ResEdit?
Vastavalt dokumentatsioon:

Rakenduspaketis pakutavate ressursside vaatamiseks saate käivitatava faili lohistada mõnele programmile nagu Vahendaja. Võite minna ka terminali ja käivitada käsu listres имя_файла.

Resourcer on HaikuDepotis saadaval, kuid minu jaoks jookseb see lihtsalt kokku.

Kuidas hallata ELF-failides olevaid ressursse? Kasutades rsrc и rdef. rdef failid on kogutud rsrc. Fail rdef on salvestatud lihtteksti vormingus, nii et sellega on palju lihtsam töötada. Failiformaat rsrc lisatud ELF faili lõppu. Proovime mängida:

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

Saate programmi kasutada xres kontrollimiseks ja kontrollimiseks:

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

Olgu, 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

Lisateavet ressursside ja vormingu kohta rdef sa oskad lugeda siin.

Standardsed ressursitüübid

Kuigi saate ressurssidesse lisada mida iganes, on olemas mõned määratletud standardtüübid:

• app_signature: MIME-rakenduse tüüp, faili avamise kaardistamiseks, käivitamiseks, IPC-ks jne.
• app_name_catalog_entry: Kuna rakenduse nimi on tavaliselt inglise keeles, saate määrata kohad, kus tõlgitud nimed asuvad, et erinevate keelte kasutajad näeksid soovi korral tõlgitud rakenduse nime.
• app_version: täpselt see, mida sa arvasid
• app_flags: näitab registrar kuidas taotlust menetleda. Ma arvan, et selles on rohkem kui esmapilgul paistab. Näiteks on olemas B_SINGLE_LAUNCH, mis sunnib süsteemi käivitama uue rakendusprotsessi iga kord, kui kasutaja seda taotleb (sama põhimõtet kasutatakse enamiku rakenduste puhul) Linux). Söö B_MULTIPLE_LAUNCH, mis põhjustab protsessi käivitamise iga faili. Lõpuks on olemas B_EXCLUSIVE_LAUNCH, mis sunnib süsteemi korraga käivitama ainult ühte protsessi, olenemata sellest, kui tihti kasutajad seda käivitavad (näiteks töötab Firefox nii Linux; sama tulemuse saab saavutada Qt rakendustes funktsiooni abil QtSingleApplication). Rakendused koos B_EXCLUSIVE_LAUNCH saavad teate, kui kasutaja proovib neid uuesti käivitada: näiteks saavad nad faili tee, mida kasutaja soovib nende abiga avada.
• vector_icon: Vektorrakenduse ikoon (BeOS-il ei olnud vektorikoone, enamiku rakenduste käivitatavates failides oli selle asemel kaks rasterikooni).

Loomulikult saate lisada soovitud ID-de ja tüüpidega ressursse ning seejärel lugeda neid rakenduses endas või teistes klassi kasutavates rakendustes BResources. Kuid kõigepealt vaatame ikoonide põnevat teemat.

Haiku stiilis vektorikoonid

Muidugi pole ainult Haiku see, mis on valinud parima ikoonivormingu, ka töölauakeskkondadega on olukord selles osas erinev. Linux 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 vaadates on juba tunda, mis tükk see on.

Muidugi on olemas skaleeritav, mis, nagu arvata võib, sisaldab vektorikoone. Miks siis midagi muud on? Sest vektorgraafika renderdamine väikeste suuruste korral ei pruugi olla ideaalne. Soovitav on, et erinevate suuruste jaoks oleksid optimeeritud erinevad valikud. Töölauakeskkondades Linux See saavutatakse erineva suurusega ikoonide hajutamisega kogu 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 kontseptsioon puudub. Seega ei ole võimalik graatsiliselt käsitleda olukorda, kus süsteemis on mitu rakenduse versiooni.

Firefoxi ikoonid on eri versioonides erinevad. Seda pole veel võimalik Firefoxis hallata. Linux ilma mitmesuguste karkudeta.

Mac OS X käsitleb seda veidi peenemalt:

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 on üks fail firefox.icns pakendis Firefox.app, mis sisaldab kõiki suurusi, nii et sama rakenduse erinevatel versioonidel on erinevad ikoonid.
Palju parem! Ikoonid liiguvad koos rakendusega, kõik ressursid on ühes failis.

Tuleme tagasi Haiku juurde. Hämmastav lahendus, eranditeta. Vastavalt dokumentatsioon:

Töötati välja spetsiaalne HVIF-vorming, mis on optimeeritud väikeste suuruste ja kiire renderdamise jaoks. Seetõttu on meie ikoonid enamasti palju väiksemad kui raster- või laialdaselt kasutatavas SVG-vormingus.

Ja need on endiselt optimeeritud:

Ikoonide suurused HVIF-is võrreldes teiste vormingutega.

Erinevus on suurusjärgus!

Kuid maagia ei lõpe siin. Sama HVIF võib sõltuvalt kuvatavast suurusest näidata erinevat detailsuse taset, kuigi tegemist on vektorvorminguga.

Erinevad detailsuse tasemed (LOD) olenevalt renderdamise suurusest

Nüüd miinustest: te ei saa võtta SVG-d, visata seda ImageMagicki ja kutsuda seda päevaks; HVIF-vormingus ikooni loomiseks peate läbima mitu tsüklit. Siin selgitused. Kuid IconOMatic suudab SVG-d importida üsna ebatäiuslikult; umbes 90% SVG üksikasjadest imporditakse teatud tõenäosusega, ülejäänud 10% tuleb käsitsi konfigureerida ja muuta. Lugege lähemalt, kuidas HVIF oma võlu teeb keegi ei saa blogis Leah Ganson

Ikooni lisamine rakendusele

Nüüd saan loodud paketile ikooni lisada viimane kord, võttes arvesse kogu saadud teavet.
Kuna ma ei soovi praegu oma QtQuickAppi "Tere, maailm" jaoks oma ikooni joonistada, tõmban selle Qt Creatorist välja.

/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

Kontrollime, 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, aga miks on nii, et uue ikooni kopeerimisel seda ei kuvata?

Kopeeritud VICN:101:BEOS:ICONs ei ole veel failihalduris rakenduse ikoonina kasutusel

Millest ma ilma jäin?

Arendaja kommentaar:

Peame looma faili rdef kõigi ressurssidega, seejärel käivitage käsk rc имя.rdef, loob see faili .rsrc. Seejärel peate käsu käivitama resattr -o имя_бинарника имя.rsrc. Vähemalt kasutan selliseid käske oma skriptidele ikoonide lisamiseks.

Noh, ma tahtsin luua ressurssi, mitte atribuuti. Ma olen tõesti segaduses.

Nutikas vahemällu salvestamine failisüsteemi abil

ELF-i atribuutide avamine ja lugemine on aeglane. Nagu ma eespool kirjutasin, on ikoon kirjutatud ressursina faili endasse. See meetod on usaldusväärsem ja võimaldab teil teise failisüsteemi kopeerimise üle elada. Seejärel kopeeritakse see aga ka näiteks failisüsteemi atribuuti BEOS:ICON. See töötab ainult teatud failisüsteemides, nagu BFS. Süsteemi kuvatavad ikoonid (Trackeris ja Deskbaris) loetakse sellest laiendatud atribuudist, kuna see lahendus töötab kiiresti. Mõnes kohas (kus kiirus pole oluline, näiteks tüüpiline “Teave” aken) saab süsteem ikooni otse failis olevast ressursist. Kuid see pole veel lõpp. Pidage meeles, et Macis võivad kasutajad asendada rakenduste, kataloogide, dokumentide ikoonid enda omadega, kuna Macis on võimalik teha näiteks neid "olulisi" asju. uue Slacki ikooni asendamine eelmisega. Haiku puhul peaksite käsitlema ressurssi (failis) kui rakendusega kaasas olevat algset ikooni ja atribuuti (BFS-failisüsteemis) kui midagi, mis võimaldab kasutajal teha soovi korral muudatusi (kuigi vihje, GUI kohandatud ikooni ikooni ülaossa lisamiseks on valikuline). pole veel vaikimisi rakendatud).

Failisüsteemi atribuutide kontrollimine

Koos resaddr Failisüsteemi atribuute on võimalik kontrollida ja seadistada.

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

See on sisuliselt "liim", mis teostab (usaldusväärsete) ressursside ja (kiirete) failisüsteemi atribuutide vahelise edasi-tagasi teisendamise. Ja kuna süsteem eeldab ressursside vastuvõtmist ja kopeerib automaatselt, siis ma selle pärast enam ei muretse.

hpkg pakettide võlu

Praegu kasutatakse (enamasti) Haiku programmide hankimiseks pakette .hpkg. Ärge laske end eksitada lihtsast nimest: .hpkg-vorming toimib täiesti erinevalt teistest sarnaste nimedega vormingutest, mida olete kohanud, sellel on tõelised supervõimed.

Traditsiooniliste paketivormingute puhul olin ma pikka aega ärritunud selle asjaolu pärast: laadite alla ühe asja (paketi) ja süsteemi installitakse teine ​​​​(paketi sees olevad failid). Traditsioonilisel viisil paketi installimisel on failide haldamine (näiteks kustutamine) üsna keeruline. Ja seda kõike pakendi sisu tõttu laiali kogu failisüsteemis, sealhulgas kohad, kus tavakasutajal ei pruugi olla kirjutamisõigust. See tekitab terve klassi programme - paketihalduridKuid juba installitud tarkvara ülekandmine näiteks teisele masinale, eemaldatavale draivile või failiserverisse muutub veelgi keerulisemaks, kui mitte täiesti võimatuks. Tavapärases süsteemis, mis põhineb Linux Süsteemis võib kergesti eksisteerida sadu tuhandeid kuni miljoneid eraldi faile. Loomulikult on see nii habras kui ka aeglane, näiteks süsteemi esmase installimise ajal, tavaliste pakettide installimisel, värskendamisel ja eemaldamisel ning alglaadimismahu (juurpartitsiooni) teisele kettale kopeerimisel.

Ma töötan AppImage projekti kallal, mis on osaline lahendus lõppkasutaja rakendustele. See on tarkvara levitamise vorming, mis koondab rakenduse ja kõik selle sõltuvused ühte failisüsteemi kujutisesse, mis paigaldatakse rakenduse käivitamisel. See lihtsustab asju märkimisväärselt, kuna samast ImageMagickist saab järsku üks fail, mida saavad failihalduris hallata pelgalt surelikud. Kavandatud lähenemisviis töötab ainult tarkvara puhul, nagu projekti nimigi ütleb, ja sellel on ka omad probleemid, kuna inimesed, kes levitavad tarkvara... Linux, nad näitavad alati näpuga minu peale.

Tuleme tagasi Haiku juurde. Kas on suudetud leida optimaalne tasakaal traditsiooniliste paketisüsteemide ja pildipõhise tarkvara edastamise vahel? Tema pakid .hpkg tegelikult tihendatud failisüsteemi kujutised. Kui süsteem käivitub, ühendab kernel kõik installitud ja aktiivsed paketid ligikaudu järgmiste kerneliteadetega:

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"

Lahe, jah? Oodake, siis läheb veel lahedamaks!

Seal on väga eriline pakett:

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

See sisaldab väga minimalistlikku operatsioonisüsteemi, sealhulgas tuuma. Uskuge või mitte, isegi kernelit ennast ei eemaldata alglaadimisköitest (juurpartitsioonist), vaid laaditakse ettevaatlikult pakendist oma kohale .hpkgVau! Ma juba mainisin, et minu arvates tuleneb osa Haiku üldisest keerukusest ja sidususest asjaolust, et kogu süsteemi, alates kernelist ja aluseks olevast kasutajaruumist kuni paketihalduse ja töölaua infrastruktuurini, arendab ühiselt üks meeskond. Kujutage ette, kui palju erinevaid gruppe ja meeskondi oleks vaja millegi sellise käivitamiseks, mis põhineb... Linux [Ma kujutan ette kutsikaprojektiLinux, — tõlkija märkus]Seejärel kujutage ette, kui kaua aega võtab selle lähenemisviisi rakendamine distributsioonides. Öeldakse: võtke lihtne ülesanne, jagage see erinevate arendajate vahel ja see muutub nii keeruliseks, et seda pole enam võimalik lahendada. Haiku oli antud juhul minu jaoks silmiavav kogemus. Ma arvan, et just see toimubki. Linux сейчас (Linux sel juhul on see virna tähistav kollektiivne termin Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu).

Süsteemi tagasipööramine hpkg abil

Kui sageli juhtub järgmine olukord: värskendus õnnestus ja siis selgub, et midagi ei tööta nii nagu peaks? Kui kasutate tavalisi paketihaldureid, on keeruline taastada süsteemi olekut ajahetkele enne uute pakettide installimist (näiteks juhul, kui midagi läks valesti). Mõned süsteemid pakuvad lahendusi failisüsteemi hetktõmmiste kujul, kuid need on üsna tülikad ja neid ei kasutata kõigis süsteemides. Haiku lahendab selle pakettide abil .hpkg. Kui paketid süsteemis muutuvad, siis vanu pakette ei kustutata, vaid need salvestatakse süsteemi alamkataloogidesse nagu /Haiku/system/packages/administrative/state-<...>/ pidevalt. Lõpetamata toimingud salvestavad oma andmed alamkataloogidesse /Haiku/system/packages/administrative/transaction-<...>/.

Sisu /Haiku/system/packages/administrative. Kataloogid “State...” sisaldavad tekstifaile aktiivsete pakettide nimedega ja kataloogid “Tehing...” sisaldavad pakette endid.

"Vana aktiivne olek", s.o. nimekirja .hpkg enne muudatusi aktiivsed paketid salvestatakse pärast iga toimingut failihalduris tekstifailis /Haiku/system/packages/administrative/state-<...>/activated-packages. Sarnaselt kirjutatakse tekstifaili uus "aktiivne olek". /Haiku/system/packages/administrative/activated-packages.

Kataloog /Haiku/system/packages/administrative/state-<...>/ sisaldab ainult tekstifaili selle oleku aktiivsete pakettide loendiga (pakettide eemaldamiseta installimise korral) ja kui paketid eemaldati või värskendati, sisaldab olekukataloog pakettide vanu versioone.

Kui süsteem käivitub, tehakse pakettide loendi põhjal otsus pakettide aktiveerimise (ühendamise) kohta. Nii lihtne see ongi! Kui allalaadimise ajal läheb midagi valesti, võite allalaadimishalduril käskida kasutada teist, vanemat loendit. Probleem lahendatud!

Haiku allalaadija. Iga sisenemispunkt kuvab vastava "aktiivse oleku"

Mulle meeldib lähenemine, et aktiivse oleku loendina on lihtsad tekstifailid, mille nimed on kergesti mõistetavad .hpkg. See on teravas kontrastis masinatele-mitte-inimestele ehitatud olemusega. hunnikus OSTree või Flatpak failisüsteemist (samal tasemel Microsoft GUID-iga).

Iga ajahetke aktiivsete pakettide loend

Konfiguratsiooniandmed

Ilmselt kataloogis /Haiku/system/packages/administrative/writable-files sisaldab pakettide konfiguratsioonifaile, kuid need on kirjutatavad. Lõppude lõpuks, nagu mäletate, .hpkg monteeritud kirjutuskaitstud. Seega tuleb need failid enne kirjutamist pakettidest kopeerida. Omab tähendust.

GUI integratsioon .hpkg süsteemi jaoks

Vaatame nüüd, kuidas need läikivad kotid .hpkg tulla toime kasutaja töökeskkonda (UX) integreerimisega. Haiku on ju mõeldud isiklikuks kasutamiseks. Isiklikult seadsin lati kõrgele, kui võrrelda kasutajakogemust pakettidega .app sama kogemusega Macintoshis .hpkgMa ei hakka seda olukorda isegi töökeskkondadega võrdlema. Linux, sest see on kõigi teistega võrreldes täiesti kohutav.

Meelde tulevad järgmised stsenaariumid:

• Soovin näha paki sisu .hpkg
• Soovin installida paketti
• Soovin pakendi eemaldada
• Ma tahan eemaldada midagi, mis tuli süsteemi osana paketist
• Ma tahan kopeerida midagi, mis tuli süsteemi paketi osana
• Soovin alla laadida kõik paketi sõltuvused, mis ei pruugi iga Haiku installi osaks olla (näiteks mul on füüsiliselt isoleeritud masin, millel puudub Interneti-ühendus.)
• Ma tahan oma paketid (või osa neist) eraldi teisaldada teise asukohta, eraldi alglaadimisköitest (juurpartitsioonist) (sest mul näiteks pole sellel piisavalt ruumi).

See peaks hõlmama enamikku minu igapäevase töö suurematest juhtumitest. Noh, alustame.

Pakendi sisu kontrollimine

Aga Mac Paremklõpsan lihtsalt pakendil, et see avada ja Finderis sisu vaadata. Lõppude lõpuks on see tegelikult lihtsalt varjatud kataloog! (Ma tean, et seal on pakid .pkg süsteemi osa jaoks, mis ei ole rakendused, kuid tavakasutajad nendega enamasti ei suhtle).

Haiku peal Paremklõpsan pakendil ja seejärel "Sisu", et näha, mis seal sees on. Kuid siin on ainult failide loend, ilma võimaluseta neid topeltklõpsuga avada.
Oleks palju parem, kui oleks võimalus (ajutiselt) pakett paigaldada .hpkg vaadata failihalduri kaudu ja kasutaja ei peaks juurutamise üksikasjade pärast muretsema. (Muide, saate avada .hpkg pakkida sisse Expander, mis saab selle lahti pakkida nagu mis tahes muu arhiivi).

HaikuDepoti liides võimaldab vaadata paketifailide loendit, kuid sisu pole võimalik vaadata näiteks topeltklõpsuga README.md

Mac võidab selles kategoorias, kuid soovitud HaikuDepoti funktsioonide lisamine ei tohiks olla liiga keeruline.

Paketi installimine GUI kaudu

Aga Mac, enamik kettakujutisi .dmg sisaldavad pakke .app. Topeltklõpsake ketta kujutist ja seejärel kopeerige pakett, näiteks lohistades selle sisse /Applications Finderis. See on minu jaoks ütlematagi selge, kuid olen kuulnud, et mõned algajad ei pruugi sellega hakkama saada. Vaikimisi "soovitab" Apple kogu süsteemi hõlmavat kataloogi /Applications (NeXT-is oli see nii võrgus kui ka individuaalne), kuid saate hõlpsalt oma rakendused failiserverisse või alamkataloogi panna $HOME/Applications, kui sulle nii meeldib.

Haiku peal, topeltklõpsake paketil ja seejärel klõpsake nuppu „Install” – see ei saaks olla lihtsam. Mind aga huvitab, mis juhtub, kui paketil on HaikuPortsis sõltuvused saadaval, aga see pole veel installitud. Linux Nad tõesti ei tea, mida sellises olukorras teha, aga lahendus on ilmne: küsida kasutajalt, kas ta peab sõltuvusi alla laadima ja installima. Just seda Haiku teebki.

Laadisin käsitsi alla paketi „sanity” ja klõpsasin sellel; paketihaldur teab, kust oma sõltuvused hankida (eeldusel, et repositooriumid on süsteemis juba registreeritud). Mitte iga distributsioon... Linux Ta saab seda teha.

Teine võimalus on kasutada failihaldurit, lihtsalt lohistades .hpkg pakendis või sisse /Haiku/system/packages (vaikimisi kogu süsteemi hõlmava installi jaoks) või sisse /Haiku/home/config/packages (individuaalseks paigalduseks; topeltklõpsamisel pole saadaval – mind ikka ajab närvi selles kohas olev sõna "config", mis minu jaoks on antud juhul "seadete" sünonüüm). Ja mitme kasutaja kontseptsioon pole isegi Haiku jaoks veel saadaval (tõenäoliselt sellepärast see nii lihtne ongi – ma ei tea, võib-olla teevad mitme kasutaja võimalused töölaua töökeskkonna jaoks asja asjatult keeruliseks).

Haiku võidab selles kategoorias, sest see võib töötada mitte ainult rakendustega, vaid ka süsteemiprogrammidega.

Paketi eemaldamine GUI-st

Aga Mac, peate rakenduse ikooni prügikasti lohistama ja see on kõik. Lihtsalt!

Haiku peal, esiteks peate leidma, kus pakett süsteemis asub, kuna installite selle harva õigesse kohta (süsteem teeb kõik). Tavaliselt peate sisse vaatama /Haiku/system/packages (ülesüsteemi hõlmava vaikeinstalliga) või sisse /Haiku/home/config/packages (Kas ma mainisin, et "config" on vale nimetus?). Seejärel lohistatakse rakendus lihtsalt prügikasti ja ongi kõik.
Lihtsalt! Seda ma siiski ei ütleks. Siin on see, mis tegelikult toimub:

See juhtub, kui lohistate rakenduse prügikasti /Haiku/system/packages

Üritasin just oma eilse QtQuickAppi rakenduse "Tere maailm" prügikasti teisaldada. Ma ei proovinud süsteemikataloogi teisaldada, ja kuna kõik paketid on installitud süsteemikataloogi, on paketti võimatu eemaldada .hpkg ilma muutusteta "selle sisu". Tavakasutaja ehmuks ja vajutaks vaikimisi määratud nuppu "Tühista".

Selgitab härra. waddlespllash:

See postitus on üle 10 aasta vana. Tõenäoliselt peame selle konfigureerima nii, et hoiatus ilmuks ainult siis, kui pakett ise teisaldatakse. Tavakasutajad ei pea seda niikuinii tegema.

Olgu, võib-olla peaksin seda tegema HaikuDepotiga? Ma topeltklõpsan pakendil /Haiku/system/packages, oodates nupu „Desinstalli” ilmumist. Ei, seal on (ainult) "Install". "Desinstalli", kus sa oled?

Lõbu pärast proovisin näha, mis juhtuks, kui klõpsan juba installitud paketil "Install". See selgub nii:

See juhtub siis, kui proovite installida juba installitud paketti.

Ilmub järgmine:

Kui klõpsate eelmises aknas "Rakenda muudatused", näeb see välja selline

Eeldan, et tegemist on tarkvaraveaga, rakenduse link on juba olemas. [autor linki ei andnud - u. tõlkija]

Kiire lahendus: lisage nupp "Desinstalli", kui pakett on juba sees /Haiku/system/packagesvõi sisse /Haiku/home/config/packages.

HaikuDepotis installitud pakettide loendit vaadates näen nimekirjas oma paketti ja saan selle eemaldada.

Selles kategoorias võidab Mac. Kuid ma kujutan ette, et õige häälestuse korral on Haiku kasutajakogemus parem kui Macis. (Üks arendajatest hindas seda nii: "Vähem kui tund aega HaikuDepotile määratud funktsionaalsuse lisamiseks, kui oskate natuke C++-i, kas on vabatahtlikke?)

Millegi pakendist eemaldamine

Proovime eemaldada rakendust ennast, mitte paketti .hpkg, millest see tuli (ma kahtlen, et "lihtsurelike" jaoks on vahet).

Aga Mac, töötab kasutaja tavaliselt failiga .dmgkust rakenduspakett pärineb .app. Tavaliselt pildid .dmg kogutakse allalaadimiste kataloogi ja kasutaja kopeerib paketid sinna /Applications. Arvatakse, et paljud kasutajad ise ei tea, mida nad teevad, seda hüpoteesi kinnitab endine Apple'i töötaja. (Üks asi, mis mulle Macis ei meeldi. Ja näiteks AppImage'i puhul pole rakendusel ja paketil, milles see oli, vahet. Lohistage ikoon prügikasti = see on kõik. Lihtne!)

Haiku peal, on ka jaotus apps/ и packages/, seega kahtlen, kas see muutis selle kasutajatele selgemaks. Aga mis juhtub, kui lohistate rakenduse sealt apps/ Lisa ostukorvi:

See juhtub, kui proovite failist võetud rakendust eemaldada .hpkg

Tehniliselt on see õige (rakendus majutatakse ju esiteks kirjutuskaitstud failisüsteemis), kuid see pole kasutajale eriti kasulik.

Kiire lahendus: soovitage kustutamiseks kasutada GUI-d .hpkg

Lõbu pärast proovisin rakendust dubleerida, vajutades Alt+D. Sain teate "Kirjutuskaitstud köitel objekte ei saa teisaldada ega kopeerida." Ja kõik sellepärast /system (Pealegi /system/packages и /system/settings) on packagefsi ühenduspunkt (pidage meeles, kuidas see väljundis kuvatakse df?). Kahjuks käsu väljund mount ei selgita olukorda (nagu ühes eelmises artiklis öeldi), mountvolume ei näita seda, mida otsite (ilmselt silmuse kaudu paigaldatud paketid .hpkg ei peeta "köideteks") ja unustasin ka alternatiivsed käsud.

Selles kategoorias ei võitnud keegi peale AppImage'i (aga kui täiesti aus olla, on see kallutatud arvamus). Siiski võib ette kujutada, et pärast näpistamist on Haiku kasutajakogemus parem kui Macil.

Märkus: peate välja selgitama, mis on "maht" seoses jaotisega. See on ilmselt sarnane "kausta" ja "kataloogi" suhtega: enamik katalooge kuvatakse failihalduris kaustadena, kuid mitte kõik (näiteks failidena käsitletavad paketid). Kas selline väljapanek teeb minust ametliku nohiku?

Paketi sisu kopeerimine teise süsteemi

Aga Mac, lohistan pakki rumalalt .app, ja kuna sõltuvused on pakendi sees, liiguvad need koos.

Haiku peal, lohistan rakendust, kuid sõltuvusi ei töödelda üldse.

Kiire lahendus: selle asemel soovitame lohistada kogu pakett `.hpkg koos võimalike sõltuvustega.

Mac võidab selles kategoorias selgelt. Vähemalt minu jaoks, nende paradigma armastaja jaoks. Peaksin selle Haikule kopeerima .hpkg rakenduse asemel, aga süsteem mulle seda ei paku...

Laadige alla pakett koos kõigi selle sõltuvustega

Mitte iga masin pole kogu aeg internetiga ühendatud. Tegelikult on mõned masinad (jah, ma vaatan teid, moodsad) Windows, Mac ja Linux) unusta see ära. Minu jaoks on oluline, et saaksin minna näiteks internetikohvikusse, laadida tarkvara eemaldatavale draivile, sisestada selle draivi oma koduarvutisse ja olla kindel, et kõik töötab [riskantne tüüp, et sellist asja teha Windows… — tõlkija märkus].

Selle tulemusel satun ma tavapärasest veidi sagedamini rahulolematutesse sõltuvustesse Windows и Linux.

Aga Mac see on tavaliselt üks fail, peate vaid alla laadima .dmg. Enamasti pole sellel muid sõltuvusi peale nende, mille MacOS ise pakub vaikimisi. Erandiks on keerulised rakendused, mis nõuavad sobivat täitmiskeskkonda, näiteks java.

Haiku peal paketi allalaadimine .hpkg Näiteks sama rakenduse jaoks javas ei pruugi piisata, kuna java võib sihtmasinas olemas olla või mitte. Kas antud paketi kõiki sõltuvusi on võimalik kuidagi alla laadida? .hpkg, välja arvatud need, mis on vaikimisi installitud Haikusse ja peaksid seetõttu olema igas Haiku süsteemis?

Mac võidab selle kategooria väikese ülekaaluga.

Kommentaarid Mr. waddlesplash:

Programmi kirjutamine, mis kogub pakettidena kõik rakenduse sõltuvused .hpkg inimesele, kes tunneb Haiku sisemist tööd, piisab umbes 15 minutist. Selle toetuse lisamine polegi nii keeruline, kui selleks on reaalne vajadus. Kuid minu jaoks on see haruldane olukord.

Hoiame hinge kinni kuni selle sarja järgmise artiklini.

Pakkide teisaldamine eraldi kohta

Nagu ma varem kirjutasin, tahan oma pakid paigutada .hpkg (hästi või osa neist) spetsiaalsesse kohta, mis on tavapärasest alglaadimismahu (juurpartitsiooni) paigutusest eraldi. Tavalisel (mitte nii teoreetilisel) juhul on selle põhjuseks see, et mul saab (sisseehitatud) ketastelt pidevalt vaba ruumi, ükskõik kui suured need ka poleks. Ja tavaliselt ühendan välised draivid või võrgujagamised seal, kus minu rakendused asuvad.

Aga Mac Ma lihtsalt kolin pakke .app irdkettale või võrgukataloogile Finderis ja ongi kõik. Saan endiselt topeltklõpsata, et rakendus avada, nagu tavaliselt alglaadimismahust. Lihtsalt!

Haiku peal, nagu mulle öeldi, saab seda saavutada minu liigutamisega .hpkg paketid irdkettale või võrgukataloogile, kuid siis peate kasutama konsoolis mõnda dokumenteerimata käsku, et need süsteemi ühendada. Ma ei tea, kuidas seda teha ainult GUI-ga.

Selles kategoorias võidab Mac.

Vastavalt hr. waddlesplash:

See on tavakasutusel põhinev optimeerimine. Kui nõudlust on rohkem kui ühelt kasutajalt, siis rakendame seda. Igal juhul on kolmanda osapoole juurutamise võimalus.

Sellest räägime järgmises artiklis.

Võrgukataloogidest rääkides oleks tore (ma arvan, et LAN-i osapooled), kui oleks olemas lihtsad, leitavad, kogu võrku hõlmavad rakendused (nagu Zeroconf), mida saab kopeerida kohalikku arvutisse või käivitada otse kohalikust võrgust. Loomulikult on arendajatel võimalus loobuda kaudu app_flags.

Lõpparuanne hpkg süsteemi integreerimise kohta GUI-ga

Arvan, et eelkõige lõimumise suhtelise uudsuse tõttu .hpkg GUI jätab endiselt soovida. Igatahes on paar asja, mida saaks UX-i osas parandada...

Veel üks asi: Kerneli silumismaa

Oleks tore, kui saaks näiteks kerneli paanika ajal käske sisestada syslog | grep usb. Noh, haikul on see võimalik tänu Kernel Debug Landile. Kuidas näete seda maagiat tegevuses, kui kõik töötab nii, nagu peab, ilma tuumapaanikasse sattumata? Lihtne, vajutades Alt+PrintScn+D (silumismnemoonika). kohe meenub Programmeerija võti, mis võimaldas algsetel Macintoshi arendajatel silurisse siseneda (muidugi, kui see oli installitud).

Järeldus

Hakkan mõistma, et Haiku süsteemi keerukus tuleneb sellest, et tööd teeb üks väike meeskond, keskendudes selgelt töökeskkonnale, kusjuures kõik süsteemi kihid on ligipääsetavad.
Terav kontrast maailmaga Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu, kus kõik on sedavõrd väikesteks tükkideks purustatud, et abstraktsioon istub abstraktsiooni peal ja sõidab karkudega.
Samuti oli arusaamine, kuidas süsteem .hpkg ühendab traditsiooniliste paketihaldurite, Snappy, Flatpaki, AppImage'i ja isegi btrfsi parimad tavad ja ühendab need Maci "lihtsalt töötab" lähenemisviisiga.

Miski justkui "lülitus" mu peas ja ma sain aru, kuidas süsteem .hpkg teab, kuidas minema veereda, lihtsalt talle otsa vaadates. Kuid see pole mina, vaid süsteemi ilu ja lihtsus. Suur osa sellest on inspireeritud algse Maci vaimust.

Jah, brauseris sirvimine võib olla tõmblev ja töötada nagu tigu, rakendused võivad puududa (ei ole Gtk, Electron - arendajad järeldasid, et need ei lähe hästi keerukaks), video ja 3D-kiirendus võivad täiesti puududa, kuid ma siiski meeldib see süsteem. Neid asju saab ju parandada ja need ilmnevad varem või hiljem. See on ainult aja küsimus ja võib-olla ka pisut punasilm.

Abi pakkuda ei oska, aga ma arvan, et see hakkab nüüdsest peale aasta haiku töölaual.

Juhuslikud probleemid

Võib-olla on taotlused juba olemas või peaksin need avama?

• BeScreenCapture peaks saama eksportida GIF-i nagu Peek. Seda saab teha ffmpeg-iga, mis on juba Haiku jaoks saadaval. Taotlus.
• Ekraanipildi tarkvara ei suuda jäädvustada modaalset akent, vaid jäädvustab kogu ekraani
• Ekraanipilte ei saa kärpida WonderBrushi kärpimistööriistaga ja seejärel tulemust faili salvestada
• Mulle ei meeldi Haiku käsikursor eriti, aga arvan, et see on seotud sooja nostalgilise tundega. See on eriti tüütu Kritas kärpimistööriista kasutamisel, kuna selle tulemuseks on ebatäpne kärpimine (vt käesoleva artikli modaaldialoogide ekraanipilte). Ristkursor oleks suurepärane. Taotlus.

Proovi ise! Lõppude lõpuks pakub Haiku projekt loodud pilte DVD-lt või USB-lt käivitamiseks iga päev. Installimiseks laadige lihtsalt pilt alla ja kirjutage see mälupulgale Etcher

Kas teil on küsimusi? Kutsume teid venekeelsesse telegrammi kanal.

Vea ülevaade: Kuidas tulistada endale jalga C ja C++ keeles. Haiku OS retseptide kogu

Pärit autor tõlge: see on Haiku-teemalise sarja kuues artikkel.

Artiklite loend: Esimene Teine kolmas Neljas Viies

Allikas: www.habr.com