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?
Avastasin Haiku, ootamatult hea süsteemi. Olen siiani üllatunud, kui sujuvalt see töötab, eriti võrreldes Linuxi töölauakeskkondadega. Täna vaatan kapoti alla. Kui põhjalikuks mõistmiseks on vaja, teen võrdlusi algsete Macintoshi, Mac OS X ja Linuxi töölauakeskkondadega (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? pärit , 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 , 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.
Tuleme tagasi BeOS-i juurde, kontseptsioonide juurde, millel Haiku põhineb. Selle arendajad otsustasid PEF-ilt (PowerPC) ELF-ile (x86) üle minnes (sama, mida kasutatakse Linuxis), lisada ELF-failide lõppu ressursside sektsiooni. See ei kasutanud oma korralikku ELF-i sektsiooni, see lisati lihtsalt ELF-faili lõppu. Programmi tulemusena strip ja teised binutillased, kes sellest teadlikud ei ole, lõikavad selle lihtsalt ära. Seetõttu on BeOS-is ELF-faili ressursside lisamisel parem mitte seda Linuxi tööriistadega manipuleerida.
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 .
Kuidas kontrollida Haiku ressursse? Kas on midagi sellist nagu ResEdit?
Vastavalt :
Rakenduspaketis pakutavate ressursside vaatamiseks saate käivitatava faili lohistada mõnele programmile nagu . 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 licenseSaate 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_VERSIONLisateavet ressursside ja vormingu kohta rdef sa oskad lugeda .
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 arvasidapp_flags: näitabregistrarkuidas taotlust menetleda. Ma arvan, et selles on rohkem kui esmapilgul paistab. Näiteks on olemasB_SINGLE_LAUNCH, mis sunnib süsteemi käivitama uut rakendusprotsessi iga kord, kui kasutaja seda nõuab (sama põhimõtet kasutatakse enamiku Linuxi rakenduste puhul). SöömaB_MULTIPLE_LAUNCH, mis põhjustab protsessi käivitamise iga faili. Lõpuks on olemasB_EXCLUSIVE_LAUNCH, mis sunnib süsteemi käivitama korraga ainult ühte protsessi, olenemata sellest, kui sageli kasutajad seda käivitavad (näiteks nii töötab Firefox Linuxis; sama tulemuse saab funktsiooni kasutades Qt rakendustes ). Rakendused koosB_EXCLUSIVE_LAUNCHsaavad 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 ei valinud parimat ikoonivormingut ainult Haiku, selles osas pole olukord Linuxi töölauakeskkondadega kaugeltki ideaalne:
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.cacheSeda vaadates on juba tunda, mis tükk see on.
Muidugi on olemas skaleeritav, mis sisaldab, nagu aru saate, vektorikoone. Miks on siis veel midagi? Kuna väikestes suurustes vektorgraafika joonistamise tulemus võib olla ideaalsest väiksem. Soovin saada erinevaid valikuid, mis on optimeeritud erinevate suuruste jaoks. Linuxi töölauakeskkondades saavutatakse see erineva suurusega ikoonide hajutamise teel kogu failisüsteemi.
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.pngPange tähele: Firefoxi erinevate versioonide kontseptsioon puudub. Seega ei ole võimalik graatsiliselt käsitleda olukorda, kus süsteemis on mitu rakenduse versiooni.
Erinevad Firefoxi ikoonid erinevates versioonides. Praegu on seda ilma erinevate karkudeta Linuxis võimatu teha.
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.icnsOn 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 :
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. 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 blogis
Ikooni lisamine rakendusele
Nüüd saan loodud paketile ikooni lisada , 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 CreatorKontrollime, 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:ICONNä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
rdefkõigi ressurssidega, seejärel käivitage käskrc имя.rdef, loob see faili.rsrc. Seejärel peate käsu käivitamaresattr -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. . 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 - paketihaldurid. Kuid juba installitud tarkvara teisaldamine näiteks teise masinasse, irdkettale või failiserverisse muutub veelgi keerulisemaks, kui mitte täiesti võimatuks. Tüüpilises Linuxi-põhises süsteemis võib üksikuid faile olla mitusada tuhat kuni miljoneid. Ütlematagi selge, et see on ühtaegu habras ja aeglane, näiteks süsteemi esmasel installimisel, tavaliste pakettide installimisel, värskendamisel ja desinstallimisel ning alglaadimisköite (juurpartitsiooni) kopeerimisel teisele andmekandjale.
Töötan AppImage projektiga, mis on lõppkasutajate rakenduste osaline tugi. See on tarkvara levitamise vorming, mis kogub rakenduse ja kõik selle sõltuvused ühte failisüsteemi kujutisse, mis paigaldatakse rakenduse käivitamisel. Lihtsustab asju oluliselt, kuna seesama ImageMagick muutub ühtäkki üheks failiks, mida failihalduris haldavad lihtsurelikud. Väljapakutud meetod töötab ainult tarkvara puhul, nagu kajastub projekti nimi, ja sellel on ka oma probleemid, kuna Linuxile tarkvara tarnimisega seotud inimesed osutavad alati noolega minu poole.
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 .hpkg. Vau! Olen juba maininud, et arvan, et osa Haiku üldisest keerukusest ja järjepidevusest tuleneb sellest, et kogu süsteemi tuumast ja kasutajaruumist kuni paketihalduse ja käitusaegse infrastruktuurini arendab üks meeskond koostöös. Kujutage ette, kui palju erinevaid rühmi ja meeskondi oleks vaja, et Linuxis midagi sellist käivitada [Kujutan ette PuppyLinuxi projekti – u. tõlkija]. Seejärel kujutage ette, kui kaua kulub selle lähenemisviisi kasutuselevõtuks distributsioonides. Öeldakse: võtke lihtne probleem, jagage see erinevate esitajate vahel ja see läheb nii keeruliseks, et seda pole enam võimalik lahendada. Haiku sel juhul avas mu silmad. Ma arvan, et see on täpselt see, mis praegu Linuxis toimub (Linux on antud juhul pinu Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu pinu koondnimetus).
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. 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 .hpkg. Ma ei hakka isegi võrdlema olukorda Linuxi töökeskkondadega, 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, seejärel klõpsake nuppu "Install", see ei saaks olla lihtsam. Ma mõtlen, mis juhtub, kui paketil on sõltuvusi, mis on HaikuPortsis saadaval, kuid mida pole veel installitud. Linuxis nad tõesti ei tea, mida selles olukorras teha, kuid lahendus on ilmne – küsige kasutajalt, kas neil on vaja sõltuvusi alla laadida ja installida. Täpselt see, mida Haiku teeb.
Laadisin 'sanity' paketi käsitsi alla ja vajutasin sellele, paketihaldur teab, kust selle sõltuvused võtta (eeldusel, et hoidlad on süsteemis juba registreeritud). Mitte iga Linuxi distributsioon ei saa 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 :
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 võrku ühendatud. Vastupidi, mõned masinad (jah, ma vaatan sind, tänapäevane Windows, Mac ja Linux) unustavad selle. Minu jaoks on oluline, et saaksin minna näiteks internetikohvikusse, laadida tarkvara irdkettale, sisestada selle draivi oma koduarvutisse ja olla kindel, et kõik töötab [riskantne mees, tehes seda Windowsis... - u. tõlkija].
Seetõttu on mul tavaliselt tavalisest veidi sagedamini Windowsi ja Linuxi osas lahendamata sõltuvused.
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
.hpkginimesele, 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 , 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 Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu maailmaga, kus kõik on sedavõrd väikesteks tükkideks purustatud, et abstraktsioon istub abstraktsioonile 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. .
- 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. .
Proovi ise! Lõppude lõpuks pakub Haiku projekt loodud pilte DVD-lt või USB-lt käivitamiseks . Installimiseks laadige lihtsalt pilt alla ja kirjutage see mälupulgale
Kas teil on küsimusi? Kutsume teid venekeelsesse .
Vea ülevaade:
Pärit tõlge: see on Haiku-teemalise sarja kuues artikkel.
Artiklite loend:
Allikas: www.habr.com