🥇Mia sesa tago kun Hajko: sub la kapuĉo de rimedoj, ikonoj kaj pakoj

TL; DR: Haiku estas operaciumo specife desegnita por komputiloj, do ĝi havas plurajn lertaĵojn kiuj faras sian labortablan medion multe pli bona ol aliaj. Sed kiel ĝi funkcias?

Ĵus Mi malkovris Hajkon, neatendite bonan sistemon. Mi ankoraŭ miras kiel glate ĝi funkcias, precipe kompare kun Linukso-tablaj medioj. Hodiaŭ mi rigardos sub la kapuĉo. Kie necese por profunda kompreno, mi faros komparojn kun la originalaj Makintoŝoj, Mac OS X kaj Linuksaj labortablaj medioj (XDG-normo de freedesktop.org).

Rimedoj en ELF-dosieroj

Hieraŭ mi eksciis, ke IconOMatic povas konservi ikonojn en rdef-resursoj en ELF-ekzekuteblaj. Hodiaŭ mi volas vidi kiel ĝi vere funkcias.

Rimedoj? citaĵo el Bruce Horn, la origina verkinto de la Makintoŝa Trovilo kaj la "patro" de la Makintoŝo-Rimedo-Manaĝero:

Mi zorgas pri la rigida naturo de tradicia kodigo. Por mi, la ideo mem de aplikaĵo frostigita en kodo, sen la kapablo ŝanĝi ion ajn dinamike, estas la plej sovaĝa sovaĝeco. Devus ebli ŝanĝi kiel eble plej multe ĉe rultempo. Kompreneble, la aplika kodo mem ne povas esti ŝanĝita, sed certe io povas esti ŝanĝita sen rekompili la kodon?

Sur la originala Makintoŝo, ili igis ĉi tiujn dosierojn havi "sekcion de datumoj" kaj "sekcion de rimedoj", kio faciligis konservi aferojn kiel ikonojn, tradukojn kaj similajn. en ruleblaj dosieroj.

En Mac ĉi tio estas uzata Reredakti, grafika programo por - subite - redakti rimedojn.

Reredaktu sur la originala Makintoŝo

Kiel rezulto, eblis redakti ikonojn, menueroj, tradukojn ktp. sufiĉe facilaj, sed ili ankoraŭ "vojaĝas" kun la aplikaĵoj.
Ĉiukaze, ĉi tiu aliro havis grandan malavantaĝon: ĝi funkciis nur sur Apple-dosiersistemoj, kio estis unu el la kialoj, kial Apple forlasis la "rimedan sekcion" dum moviĝado al Mac OS X.
Sur Mac OS X, Apple deziris dosiersistemon-sendependan solvon, tiel ke ili adoptis la koncepton de pakaĵoj (de NeXT), dosierujoj kiuj estas traktitaj kiel "maldiafanaj objektoj" fare de la dosiermanaĝero, kiel dosieroj prefere ol dosierujoj. Ajna pako kun aplikaĵo en la formato .app havas interalie dosieron Info.plist (en iu speco de la ekvivalento de Apple de JSON aŭ YAML) enhavante aplikaĵmetadatenojn.

Ŝlosiloj por la dosiero Info.plist el la aplikaĵpakaĵo de Mac OS X.

Rimedoj, kiel ikonoj, UI-dosieroj kaj aliaj, estas konservitaj en la pakaĵo kiel dosieroj. La koncepto fakte revenis al siaj radikoj en NeXT.

Mathematica.app sur NeXTSTEP 1.0 en 1989: aperas kiel dosierujo de dosieroj en la terminalo, sed kiel ununura objekto en la grafika dosieradministranto.

Ni revenu al BeOS, la konceptoj sur kiuj baziĝas Hajko. Ĝiaj programistoj, ŝanĝante de PEF (PowerPC) al ELF (x86) (la sama kiel uzata en Linukso), decidis aldoni rimedan sekcion al la fino de la ELF-dosieroj. Ĝi ne uzis sian propran ELF-sekcion, ĝi estis simple almetita al la fino de la ELF-dosiero. Kiel rezulto de la programo strip kaj aliaj de binutils, ne konsciaj pri tio, simple fortranĉis ĝin. Tial, kiam oni aldonas rimedojn al ELF-dosiero en BeOS, estas pli bone ne manipuli ĝin per Linukso-iloj.

Kio nun okazas kun Hajko? Esence, pli-malpli same.

En teorio, eblus meti rimedojn en la deziratan sekcion de la ELF. Laŭ la programistoj ĉe la kanalo #haiku ĉe irc.freenode.net:

Kun ELF la sekcio havus pli da senco ... la nura kialo ni ne faras ĝin tiel estas ĉar ĝi estis farita tiel en BeOS."
Kaj ne utilas ŝanĝi ĉi tion nun.

Administrado de rimedoj

Rimedoj estas skribitaj en strukturita "rimedo" formato: esence listo de rimedoj kun grandecoj kaj poste ilia enhavo. mi memoris ar formato.
Kiel kontroli rimedojn en Hajko? Ĉu ekzistas io kiel ResEdit?
Laŭ dokumentado:

Por vidi la rimedojn provizitajn en la aplikaĵo, vi povas treni la ruleblan dosieron al programo kiel Risurtanto. Vi ankaŭ povas iri al la terminalo kaj ruli la komandon listres имя_файла.

Resourcer disponeblas en HaikuDepot, sed ĝi nur kraŝas por mi.

Kiel administri rimedojn en ELF-dosieroj? Uzanta rsrc и rdef. rdef dosieroj estas kolektitaj en rsrc. Dosiero rdef estas konservita en simpla teksta formato, do estas multe pli facile labori kun ĝi. Dosierformato rsrc almetita al la fino de la ELF-dosiero. Ni provu ludi:

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

Vi povas uzi la programon xres por kontrolo kaj kontrolo:

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

Bone, ni provu?

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

Pli pri rimedoj kaj formato rdef vi povas legi tie.

Normaj rimedoj tipoj

Kvankam vi povas meti ion ajn en rimedojn, ekzistas kelkaj difinitaj normaj tipoj:

app_signature: MIME-aplikaĵospeco, por dosiero malferma mapado, lanĉo, IPC, ktp.
app_name_catalog_entry: Ĉar la nomo de la aplikaĵo kutime estas en la angla, ĉi tie vi povas specifi la lokojn, kie troviĝas la tradukitaj nomoj, por ke uzantoj de malsamaj lingvoj vidu la tradukitan nomon de la aplikaĵo, se vi volas.
app_version: ĝuste kion vi pensis
app_flags: indikas registrar kiel prilabori la kandidatiĝon. Mi pensas, ke estas pli ol ĝi vidas. Ekzemple, ekzistas B_SINGLE_LAUNCH, kiu devigas la sistemon lanĉi novan aplikan procezon ĉiufoje kiam la uzanto petas ĝin (la sama principo estas uzata por plej multaj aplikoj en Linukso). Manĝu B_MULTIPLE_LAUNCH, igante la procezon kuri por ĉiu dosiero. Fine ekzistas B_EXCLUSIVE_LAUNCH, kiu devigas la sistemon lanĉi nur unu procezon samtempe, negrave kiom ofte uzantoj lanĉas ĝin (ekzemple, jen kiel Firefox funkcias en Linukso; la sama rezulto povas esti atingita en Qt-aplikoj uzante la funkcion). QtSingleApplication). Aplikoj kun B_EXCLUSIVE_LAUNCH estas sciigitaj kiam la uzanto provas ruli ilin denove: ekzemple, ili ricevas la vojon de la dosiero, kiun la uzanto volas malfermi kun sia helpo.
vector_icon: Vektora aplikikono (BeOS ne havis vektorajn ikonojn, plej multaj aplikoj anstataŭe havis du rastrumajn ikonojn en siaj ruleblaj dosieroj).

Kompreneble, vi povas aldoni rimedojn kun ajnaj dezirataj identigiloj kaj tipoj, kaj poste legi ilin en la aplikaĵo mem aŭ en aliaj aplikaĵoj uzante la klason. BResources. Sed unue, ni rigardu la fascinan temon de ikonoj.

Vektoraj ikonoj en hajka stilo

Kompreneble, ne nur Haiku elektis la plej bonan ikonformaton; en ĉi tiu parto, la situacio kun Linuksaj labortablaj medioj estas malproksima de ideala:

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

Rigardante ĉi tion vi jam povas senti, kia peco ĝi estas.

Kompreneble, ekzistas skalebla, kiu enhavas, kiel vi povas kompreni, vektorajn ikonojn. Kial do estas io alia? Ĉar la rezulto de desegnado de vektoraj grafikaĵoj en malgrandaj grandecoj povas esti malpli ol ideala. Mi ŝatus havi malsamajn opciojn optimumigitaj por malsamaj grandecoj. En Linuksaj labortablaj medioj, tio estas atingita disigante ikonojn de malsamaj grandecoj tra la dosiersistemo.

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

Bonvolu noti: ne ekzistas koncepto pri malsamaj versioj de Firefox. Tiel, ne eblas gracie trakti la situacion havi plurajn versiojn de aplikaĵo en la sistemo.

Malsamaj ikonoj de Firefox en malsamaj versioj. Nuntempe estas neeble trakti ĉi tion en Linukso sen diversaj lambastonoj.

Mac OS X pritraktas ĝin iom pli subtile:

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

Oni povas vidi, ke estas unu dosiero firefox.icns en la pakaĵo Firefox.app, enhavante ĉiujn grandecojn tiel ke malsamaj versioj de la sama aplikaĵo havas malsamajn ikonojn.
Multe pli bone! Ikonoj vojaĝas kun la aplikaĵo, ĉiuj rimedoj estas en unu dosiero.

Ni revenu al Hajko. Sensacia solvo, sen esceptoj. Laŭ dokumentado:

Speciala HVIF-formato, tre optimumigita por malgrandaj grandecoj kaj rapida bildigo, estis evoluigita. Tial niaj ikonoj plejparte estas multe pli malgrandaj ol en rastrumo aŭ en la vaste uzata SVG-formato.

Kaj ili ankoraŭ estas optimumigitaj:

Ikongrandoj en HVIF kompare kun aliaj formatoj.

La diferenco estas grandordo!

Sed la magio ne finiĝas ĉi tie. La sama HVIF povas montri malsamajn nivelojn de detalo depende de la grandeco montrita, kvankam ĝi estas vektora formato.

Malsamaj niveloj de detalo (LOD) depende de bildigo

Nun pri la malavantaĝoj: vi ne povas preni SVG, ĵeti ĝin en ImageMagick kaj nomi ĝin tage; vi devas trapasi plurajn ciklojn por krei ikonon en HVIF-formato. tie klarigoj. Tamen, IconOMatic povas importi SVG tute neperfekte; ĉirkaŭ 90% de SVG-detaloj estas importitaj kun iu verŝajneco, la ceteraj 10% devos esti agordita kaj ŝanĝita permane. Legu pli pri kiel HVIF faras sian magion povas en la blogo Leah Ganson

Aldonante ikonon al la aplikaĵo

Nun mi povas aldoni ikonon al la kreita pako lastfoje, konsiderante ĉiujn ricevitajn informojn.
Nu, ĉar mi ne precipe deziras desegni mian propran ikonon por mia "Saluton, Mondo" QtQuickApp nun, mi eltiras ĝin el Qt Creator.

/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

Ni kontrolu, ke la ikono estas kopiita:

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

Aspektas bone, sed kial kiam la nova ikono estas kopiita, ĝi ne aperas?

La kopiita VICN:101:BEOS:ICONs ankoraŭ ne estas uzata kiel aplikaĵa ikono en la dosieradministranto

Kion mi mankis?

Komento de la programisto:

Ni devas krei dosieron rdef kun ĉiuj rimedoj, tiam plenumu la komandon rc имя.rdef, ĉi tio kreos la dosieron .rsrc. Tiam vi devas ruli la komandon resattr -o имя_бинарника имя.rsrc. Minimume, mi uzas komandojn kiel ĉi tiujn por aldoni ikonojn al miaj skriptoj.

Nu, mi volis krei rimedon, ne atributon. Mi estas vere konfuzita.

Inteligenta kaŝmemoro uzante la dosiersistemon

Malfermo kaj legado de ELF-atributoj malrapidas. Kiel mi skribis supre, la ikono estas skribita kiel rimedo en la dosiero mem. Ĉi tiu metodo estas pli fidinda kaj permesas vin postvivi kopiadon al alia dosiersistemo. Tamen, ĝi tiam ankaŭ estas kopiita al la dosiersistema atributo, ekzemple BEOS:ICON. Ĉi tio funkcias nur en certaj dosiersistemoj, kiel BFS. La piktogramoj montritaj de la sistemo (en Spurilo kaj Deskbar) estas legitaj de ĉi tiu etendita atributo, ĉar ĉi tiu solvo funkcias rapide. En iuj lokoj (kie rapideco ne gravas, ekzemple tipa fenestro "Pri"), la sistemo ricevas la ikonon rekte de la rimedo en la dosiero. Sed ĉi tio ne estas la fino. Memoru, en Mac, uzantoj povus anstataŭigi ikonojn de aplikoj, dosierujoj, dokumentoj per siaj propraj, ĉar en Mac eblas fari ĉi tiujn "gravajn" aferojn, ekzemple anstataŭigante novan Slack-ikonon kun la antaŭa. Sur Hajku, vi devus pensi pri la rimedo (en la dosiero) kiel la originala ikono kiu venas kun la aplikaĵo, kaj la atributo (en la BFS-dosiersistemo) kiel io, kio permesas al la uzanto fari ŝanĝojn laŭvole (kvankam, sugesto, la GUI por enmeti kutiman ikonon sur la piktogramon estas nedeviga).ankoraŭ ne efektivigita defaŭlte).

Kontrolado de atributoj de dosiersistemo

Kun la helpo de resaddr Eblas kontroli kaj agordi dosiersistemajn atributojn.

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

Ĝi estas esence la "gluo" kiu faras la konvertiĝon tien kaj reen inter (fidindaj) resursoj kaj (rapidaj) dosiersistemaj atributoj. Kaj ĉar la sistemo atendas ricevi rimedojn kaj aŭtomate faras la kopiadon, mi ne plu zorgos pri tio.

La magio de hpkg-pakaĵoj

Nuntempe (plej ofte) pakaĵoj estas uzataj por akiri programojn pri Hajko .hpkg. Ne trompu la simpla nomo: la formato .hpkg funkcias tute malsame ol aliaj formatoj kun similaj nomoj kiujn vi renkontis, ĝi havas verajn superpotencojn.

Kun tradiciaj pakformatoj, mi estis ĉagrenita dum longa tempo pro ĉi tiu fakto: oni elŝutas unu aferon (pakaĵo), kaj alia estas instalita en la sistemo (dosieroj ene de la pako). Estas sufiĉe malfacile administri dosierojn (ekzemple forigi ilin) kiam oni instalas pakaĵon laŭ la tradicia maniero. Kaj ĉio ĉar la enhavo de la pako disigitaj tra la dosiersistemo, inkluzive de lokoj kie la meza uzanto eble ne havas skribaliron. Ĉi tio estigas tutan klason da programoj - pakaĵadministrantoj. Sed translokigi jam instalitan programaron, ekzemple, al alia maŝino, forprenebla disko aŭ dosierservilo fariĝas eĉ pli malfacila, se ne tute neebla. Sur tipa Linukso-bazita sistemo, facile povas esti kelkcent mil ĝis milionoj da individuaj dosieroj. Ne necesas diri, ke ĉi tio estas kaj delikata kaj malrapida, ekzemple kiam oni komence instalas sistemon, kiam oni instalas, ĝisdatigas kaj malinstalas regulajn pakaĵojn, kaj kiam oni kopias la ekfunkciigon (radikdisko) al alia medio.

Mi laboras pri la projekto AppImage, parta lambastono por finuzantaj aplikaĵoj. Ĉi tio estas programara distribua formato, kiu kolektas aplikaĵon kaj ĉiujn ĝiajn dependecojn en ununuran dosiersisteman bildon, kiu estas muntita kiam la aplikaĵo komenciĝas. Signife simpligas aferojn, ĉar la sama ImageMagick subite iĝas unuopa dosiero, administrita en dosieradministranto de nuraj mortontoj. La proponita metodo funkcias nur por programaro, kiel reflektite en la nomo de la projekto, kaj ankaŭ havas sian propran aron da problemoj, ĉar homoj implikitaj en liverado de programaro por Linukso ĉiam indikas la sagon al mi.

Ni revenu al Hajko. Ĉu eblis trovi la optimuman ekvilibron inter tradiciaj pakaĵsistemoj kaj bild-bazita programaro livero? Ŝiaj pakoj .hpkg efektive kunpremitaj dosiersistemaj bildoj. Kiam la sistemo ekfunkciigas, la kerno muntas ĉiujn instalitajn kaj aktivajn pakaĵojn kun proksimume la sekvaj kernaj mesaĝoj:

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"

Bonege, ĉu? Pensu tie, estos eĉ pli malvarme!

Estas tre speciala pako:

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

Ĝi enhavas tre minimumisman operaciumon, inkluzive de la kerno. Kredu aŭ ne, eĉ la kerno mem ne estas forigita de la ekfunkciigo (radikdisko), sed estas zorge ŝarĝita en sian lokon de la pakaĵo. .hpkg. Ŭaŭ! Mi jam menciis, ke mi pensas, ke parto de la ĝenerala sofistikeco kaj konsekvenco de Hajko venas de la fakto, ke la tuta sistemo, de la kerno kaj kerna uzantspaco ĝis pakaĵadministrado kaj rultempa infrastrukturo, estas kunlabore evoluigita de unu teamo. Imagu kiom da malsamaj grupoj kaj teamoj necesus por funkcii ion tian en Linukso [Mi imagas la projekton PuppyLinux - ĉ. tradukisto]. Tiam imagu kiom da tempo daŭros por ke ĉi tiu aliro estos adoptita en distribuojn. Ili diras: prenu simplan problemon, dividu ĝin inter diversaj interpretistoj, kaj ĝi fariĝos tiel komplika, ke ne plu eblos solvi ĝin. Hajko ĉi-kaze malfermis miajn okulojn. Mi pensas, ke ĉi tio estas ĝuste kio nun okazas en Linukso (Linukso ĉi-kaze estas kolektiva termino por la stako Linukso/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu).

Sistemmalfunkciigo uzante hpkg

Kiom ofte okazas la sekva situacio: la ĝisdatigo sukcesis, kaj tiam evidentiĝas, ke io ne funkcias kiel ĝi devus? Se vi uzas konvenciajn pakaĵadministrilojn, estas malfacile revenigi la staton de la sistemo al momento antaŭ ol novaj pakaĵoj estis instalitaj (ekzemple, en la okazo ke io misfunkciis). Iuj sistemoj ofertas solvojn en formo de dosiersistemaj momentfotoj, sed ili estas sufiĉe ĝenaj kaj ne estas uzataj en ĉiuj sistemoj. Hajko solvas ĉi tion uzante pakaĵojn .hpkg. Kiam ajn pakaĵoj ŝanĝiĝas en la sistemo, la malnovaj pakaĵoj ne estas forigitaj, sed estas konservitaj en la sistemo en subdosierujoj kiel /Haiku/system/packages/administrative/state-<...>/ konstante. Nefinitaj operacioj konservas siajn datumojn en subdosierujoj /Haiku/system/packages/administrative/transaction-<...>/.

Enhavo /Haiku/system/packages/administrative. La dosierujoj "ŝtato..." enhavas tekstajn dosierojn kun la nomoj de aktivaj pakaĵoj, kaj la dosierujoj "transakcio..." enhavas la pakaĵojn mem.

"Malnova aktiva stato", t.e. listo .hpkg pakoj aktivaj antaŭ ol ŝanĝoj estas registritaj post ĉiu operacio en la dosieradministranto en tekstdosiero /Haiku/system/packages/administrative/state-<...>/activated-packages. Simile, nova "aktiva stato" estas skribita en tekstdosiero /Haiku/system/packages/administrative/activated-packages.

Gvidlibro /Haiku/system/packages/administrative/state-<...>/ enhavas nur tekstdosieron kun listo de aktivaj pakaĵoj de ĉi tiu stato (kaze de instalado de pakaĵoj sen forigo), kaj se pakoj estis forigitaj aŭ ĝisdatigitaj - la ŝtata dosierujo enhavas malnovajn versiojn de pakaĵoj.

Kiam la sistemo ekfunkciigas, surbaze de la listo de pakaĵoj, oni decidos aktivigi (munti) pakaĵojn. Estas tiel simple! Se io misfunkcias dum la elŝuto, vi povas diri al la elŝuta administranto uzi alian pli malnovan liston. Problemo solvita!

Haiku-elŝutilo. Ĉiu enirpunkto montras respondan "aktivan staton"

Mi ŝatas la aliron havi simplajn tekstajn dosierojn kiel la liston de "aktiva ŝtato", kun nomoj facile kompreneblaj .hpkg. Ĉi tio tute kontrastas al esti konstruita por maŝinoj-ne-por homoj. en aro de OSTree aŭ Flatpak en la dosiersistemo (en la sama nivelo kiel Microsoft GUID).

Listo de aktivaj pakaĵoj por ĉiu tempopunkto

Agordaj datumoj

Ŝajne, en la katalogo /Haiku/system/packages/administrative/writable-files enhavas agordajn dosierojn por pakaĵoj, sed ili estas skribeblaj. Post ĉio, kiel vi memoras, .hpkg muntita nurlegebla. Do ĉi tiuj dosieroj devas esti kopiitaj el la pakaĵoj antaŭ ol skribi. Havas la signifon.

GUI-integriĝo por .hpkg-sistemo

Ni nun vidu kiel ĉi tiuj brilaj sakoj .hpkg trakti integriĝon en la labormedio de la uzanto (UX). Post ĉio, Hajko estas destinita por persona uzo, finfine. Persone, mi starigas la stangon alta kiam komparas sperton de uzanto kun pakoj .app sur Makintoŝo kun la sama sperto sur .hpkg. Mi eĉ ne komparos la situacion kun labormedioj en Linukso, ĉar ĝi estas absolute terura kompare kun iuj aliaj.

Venas al la menso la sekvaj scenaroj:

Mi volas vidi la enhavon de pako .hpkg
Mi volas instali pakaĵon
Mi volas forigi la pakaĵon
Mi volas forigi ion, kio venis en la sistemon kiel parto de pakaĵo
Mi volas kopii ion, kio venis en la sistemon kiel parto de pakaĵo
Mi volas elŝuti ĉiujn dependecojn de pako, kiu eble ne estas parto de ĉiu instalaĵo de Hajko (ekzemple, mi havas fizike izolitan maŝinon sen interreta aliro.)
Mi volas movi miajn pakaĵojn (aŭ parton de ili) aparte al alia loko, aparte de la ekfunkciigo (radikdisko) (ĉar, ekzemple, mi ne havas sufiĉe da spaco sur ĝi).

Ĉi tio devus kovri la plej multajn el la ĉefaj kazoj de mia ĉiutaga laboro. Nu, ni komencu.

Kontrolante pakaĵenhavon

Sur Mac Mi simple dekstre alklakas la pakaĵon por malfermi ĝin kaj vidi la enhavon en Finder. Post ĉio, fakte ĝi estas nur kaŝvestita dosierujo! (Mi scias, ke estas pakaĵoj .pkg por parto de la sistemo, kiu ne estas aplikaĵoj, sed ordinaraj uzantoj plej ofte ne interagas kun ili).

Pri Hajko Mi dekstre alklakas la pakaĵon, poste alklakas "Enhavo" por vidi kio estas ene. Sed jen nur listo de dosieroj sen la kapablo malfermi ilin per duobla klako.
Estus multe pli bone se ekzistus maniero (provizore) munti la pakaĵon .hpkg por esti rigardata per dosieradministranto, kaj la uzanto ne devus zorgi pri efektivigdetaloj. (Cetere, vi povas malfermi .hpkg paki en Expander, kiu povas malpaki ĝin kiel ajna alia arkivo).

La interfaco de HaikuDepot permesas al vi vidi liston de pakdosieroj, sed ne ekzistas maniero vidi la enhavon per, ekzemple, duoble alklakante README.md.

La Mac gajnas en ĉi tiu kategorio, sed aldoni la HaikuDepot-funkciecon, kiun vi volas, ne devus esti tro malfacila.

Instalante pakaĵon per GUI

Sur Mac, la plej multaj diskobildoj .dmg enhavas pakaĵojn .app. Duoble alklaku la diskobildon kaj tiam kopiu la pakaĵon, ekzemple, trenante ĝin enen /Applications en Finder. Ĉi tio nepras por mi, sed mi aŭdis, ke iuj novuloj eble ne kapablas trakti tion. Defaŭlte, Apple "sugestas" tutsistema dosierujo /Applications (ĉe NeXT ĝi estis interreta same kiel individua), sed vi povas facile meti viajn aplikaĵojn en dosierservilon aŭ en subdosierujon $HOME/Applications, se vi ŝatas ĝin tiel.

Pri Hajko, duoble alklaku la pakaĵon, tiam alklaku "Instali", ĝi ne povus esti pli facila. Mi scivolas, kio okazas se pako havas dependecojn kiuj estas disponeblaj en HaikuPorts sed ankoraŭ ne instalitaj. En Linukso ili vere ne scias kion fari en ĉi tiu situacio, sed la solvo estas evidenta - demandu la uzanton ĉu ili bezonas elŝuti kaj instali dependecojn. Ĝuste kion Hajko faras.

Mi elŝutis la pakaĵon 'sanity' permane kaj klakis sur ĝi, la pakaĵadministrilo scias de kie akiri ĝiajn dependecojn (supoze ke la deponejoj jam estas registritaj en la sistemo). Ne ĉiu Linuksa distribuo povas fari tion.

Alia maniero estas uzi dosieradministranton, simple treni kaj faligi .hpkg pakaĵo aŭ en /Haiku/system/packages (por tutsistemo, defaŭlte), aŭ en /Haiku/home/config/packages (por individua instalo; ne disponebla dum duobla klako - mi ankoraŭ ĝenas la vorton "config" en ĉi tiu loko, kiu por mi ĉi-kaze estas sinonimo de "agordoj"). Kaj la koncepto de multnombraj uzantoj ankoraŭ ne disponeblas por Hajko (verŝajne tial ĝi estas tiel simpla - mi ne scias, eble pluruzantaj kapabloj nenecese malfaciligos aferojn por labortabla medio).

Hajko gajnas en ĉi tiu kategorio ĉar ĝi povas funkcii ne nur kun aplikoj, sed ankaŭ kun sistemaj programoj.

Forigante pakaĵon de la GUI

Sur Mac, vi devas treni la aplikaĵikonon al la rubujo, kaj jen ĉio. Facile!

Pri Hajko, unue, vi devas trovi kie la pako troviĝas en la sistemo, ĉar vi malofte instalas ĝin en la ĝusta loko (la sistemo faras ĉion). Kutime vi devas enrigardi /Haiku/system/packages (kun tutsistema defaŭlta instalo), aŭ en /Haiku/home/config/packages (Ĉu mi menciis, ke "config" estas misnomo?). Tiam la aplikaĵo estas simple trenita al la rubujo, kaj jen ĝi.
Facile! Tamen mi ne dirus tion. Jen kio vere okazas:

Jen kio okazas se vi trenas aplikaĵon al la rubujo el /Haiku/system/packages

Nur provis movi mian hieraŭan aplikaĵon "Saluton Mondo" ĉe QtQuickApp al la rubujo. Mi ne provis movi la sisteman dosierujon, kaj ĉar ĉiuj pakaĵoj estas instalitaj en la sistema dosierujo, estas neeble forigi la pakaĵon .hpkg sen ŝanĝo "ĝia enhavo". Ordinara uzanto ektimus kaj premus la butonon "Nuligi" asignitan defaŭlte.

Klarigas s-ro. waddlesplash:

Ĉi tiu afiŝo havas pli ol 10 jarojn. Plej verŝajne ni devas agordi ĝin tiel ke la averto aperu nur kiam la pako mem estas movita. Regulaj uzantoj ne bezonas fari ĉi tion ĉiuokaze.

Bone, eble mi faru ĉi tion uzante HaikuDepot? Mi duoble alklakas la pakaĵon enen /Haiku/system/packages, atendante la butonon "Malinstali" aperos. Ne, ekzistas (nur) "Instali". "Malinstali", kie vi estas?

Nur por amuzo, mi provis vidi kio okazus se mi klakus "Instali" sur jam instalita pakaĵo. Ĝi rezultas jene:

Ĉi tio okazas se vi provas instali jam instalitan pakaĵon.

Poste aperas:

Se vi alklakas "Apliki ŝanĝojn" en la antaŭa fenestro, ĝi aspektos tiel

Mi supozas, ke ĉi tio estas programara eraro; la ligo al la aplikaĵo jam estas tie. [la aŭtoro ne disponigis ligilon - ĉ. tradukisto]

Rapida solvo: Aldonu butonon "Malinstali" se la pakaĵo jam estas enigita /Haiku/system/packages, aŭ en /Haiku/home/config/packages.

Vidante la liston de pakaĵoj instalitaj en HaikuDepot, mi vidas mian pakaĵon en la listo kaj povas forigi ĝin.

La Mac gajnas en ĉi tiu kategorio. Sed mi povas imagi, ke kun taŭga agordo, la uzantsperto sur Hajko estos pli bona ol ĉe Mac. (Unu el la programistoj taksis ĝin jene: "Malpli ol horo por aldoni la specifitan funkcion al HaikuDepot, se vi konas iomete C++", ĉu volontuloj?)

Forigi ion el pako

Ni provu forigi la aplikaĵon mem, ne la pakaĵon .hpkg, el kiu ĝi venis (mi dubas, ke por "nuraj mortuloj" ekzistas ia diferenco).

Sur Mac, la uzanto fakte kutime laboras kun la dosiero .dmgde kie venas la aplikaĵa pako .app. Kutime bildoj .dmg estas akumulitaj en la elŝuta dosierujo, kaj pakaĵoj estas kopiitaj de la uzanto al /Applications. Oni kredas, ke multaj uzantoj mem ne scias, kion ili faras, ĉi tiu hipotezo estas konfirmita de iama Apple-oficisto. (Unu el la aferoj, kiujn mi ne ŝatas en Mac. Kaj, ekzemple, kun AppImage ne estas diferenco inter la aplikaĵo kaj la pako en kiu ĝi estis. Trenu la piktogramon al la rubujo = jen ĝi. Facile!)

Pri Hajko, ekzistas ankaŭ divido inter apps/ и packages/, do mi dubas, ke tio igis ĝin pli klara al uzantoj. Sed kio okazas se vi trenas aplikaĵon de apps/ Aldonu al la korbo:

Jen kio okazas kiam vi provas forigi aplikaĵon prenitan de dosiero .hpkg

Teknike ĝi estas ĝusta (finfine, la aplikaĵo estas gastigita en nurlegebla dosiersistemo unue), sed ĝi ne estas precipe utila al la uzanto.

Rapida solvo: sugestu uzi GUI por forigi anstataŭe .hpkg

Nur por amuzo, mi provis duobligi la aplikaĵon premante Alt+D. Mi ricevis la mesaĝon "Ne eblas movi aŭ kopii objektojn sur nurlegebla volumo." Kaj ĉio ĉar /system (krom /system/packages и /system/settings) estas la munta punkto de packagefs (memoru kiel ĝi aperas en la eligo df?). Bedaŭrinde, la eligo de la komando mount ne klarigas la situacion (kiel estis dirite en unu el la antaŭaj artikoloj), mountvolume ne montras tion, kion vi serĉas (ŝajne pakoj muntitaj per buklo .hpkg ne estas konsiderataj "volumoj"), kaj mi ankaŭ forgesis la alternativajn ordonojn.

Neniu gajnis en ĉi tiu kategorio krom AppImage (sed ĉi tio, por esti tute honesta, estas partia opinio). Tamen, oni povas imagi, ke post tajlado, la uzantsperto sur Hajko estos pli bona ol ĉe Mac.

Noto: vi devas ekscii, kio estas "volumo" rilate al "sekcio". Ĉi tio verŝajne similas al la rilato de "dosierujo" al "dosierujo": plej multaj dosierujoj aperas kiel dosierujoj en la dosieradministranto, sed ne ĉiuj (pakoj traktataj kiel dosieroj, ekzemple). Ĉu ĉi tia ekrano igas min oficiala nerdo?

Kopiante la enhavon de pako al alia sistemo

Sur Mac, mi stulte trenas la pakaĵon .app, kaj ĉar la dependecoj estas ene de la pako, ili moviĝas kune.

Pri Hajko, mi trenas la aplikaĵon, sed la dependecoj tute ne estas prilaboritaj.

Rapida solvo: Ni anstataŭe sugestu treni la tutan pakaĵon `.hpkg, kune kun iuj dependecoj, se ekzistas.

La Mac klare gajnas en ĉi tiu kategorio. Almenaŭ por mi, amanto de ilia paradigmo. Mi devus kopii ĝin al Hajko .hpkg anstataŭ aplikaĵo, sed la sistemo ne proponas al mi ĉi tion...

Elŝutu pakaĵon kun ĉiuj ĝiaj dependecoj

Ne ĉiu maŝino estas konektita al la reto la tutan tempon. Male, iuj maŝinoj (jes, mi rigardas vin, modernaj Vindozo, Mac kaj Linukso) forgesas pri tio. Gravas por mi, ke mi povas iri, ekzemple, al retkafejo, elŝuti programaron sur forprenebla disko, enigi ĉi tiun diskon en mian hejman komputilon kaj esti certa, ke ĉio funkcios [riska ulo, farante tion en Vindozo... - ĉ. tradukisto].

Kiel rezulto, mi emas fini kun nekontentaj dependecoj de Vindozo kaj Linukso iom pli ofte ol kutime.

Sur Mac ĉi tio estas kutime unu dosiero, vi nur bezonas elŝuti .dmg. Plej ofte, ĝi havas neniujn dependecojn krom tiuj provizitaj de MacOS mem defaŭlte. Escepto estas kompleksaj aplikoj kiuj postulas taŭgan ekzekutmedion, ekzemple java.

Pri Hajko elŝutu pakon .hpkg ĉar, ekzemple, la sama aplikaĵo en java eble ne sufiĉas, ĉar java povas aŭ ne ĉeesti sur la celmaŝino. Ĉu ekzistas maniero elŝuti ĉiujn dependecojn por donita pako .hpkg, krom tiuj kiuj estas instalitaj defaŭlte en Hajko kaj tial devus esti sur ĉiu Hajko-sistemo?

La Mac gajnas ĉi tiun kategorion per malgranda marĝeno.

Komentoj Mr. waddlesplash:

Verki programon por kolekti ĉiujn dependecojn de aplikaĵo kiel aro da pakaĵoj .hpkg por iu konata kun la interna funkciado de Hajko, proksimume 15 minutoj sufiĉas. Aldoni subtenon por ĉi tio ne estas tiom malfacila se ekzistas vera bezono de ĝi. Sed por mi ĉi tio estas malofta situacio.

Ni retenu nian spiron ĝis la sekva artikolo en ĉi tiu serio.

Movante pakaĵojn al aparta loko

Kiel mi skribis pli frue, mi volas meti miajn pakaĵojn .hpkg (nu, aŭ parto de ili) al speciala loko, aparta de la kutima lokigo sur la ekfunkciigo (radika sekcio). En la kutima (ne tiom teoria) kazo, la kialo de tio estas, ke mi senĉese elĉerpas liberan spacon sur miaj (enkonstruitaj) diskoj, kiom ajn grandaj ili estas. Kaj mi kutime konektas eksterajn diskojn aŭ retajn akciojn kie troviĝas miaj aplikaĵoj.

Sur Mac Mi nur movas pakaĵojn .app al forprenebla disko aŭ reta dosierujo en Finder, kaj jen ĝi. Mi ankoraŭ povas duoble alklaki por malfermi la aplikaĵon kiel mi kutime farus de la ekfunkciigo. Nur!

Pri Hajko, kiel oni diris al mi, tion oni povas atingi movante mian .hpkg pakaĵojn al forprenebla disko aŭ reta dosierujo, sed tiam vi devas uzi kelkajn nedokumentitajn komandojn en la konzolo por munti ilin en la sistemo. Mi ne scias kiel fari tion uzante nur la GUI.

La Mac gajnas en ĉi tiu kategorio.

Laŭ s-ro. waddlesplash:

Ĉi tio estas optimumigo bazita sur normala uzo. Se estas postulo de pli ol unu uzanto, ni efektivigos ĝin. Ĉiukaze, ekzistas la ebleco de triaparta efektivigo.

Ni parolos pri tio en la sekva artikolo.

Parolante pri retaj dosierujoj, estus bonege (mi supozas LAN-partiojn) havi simplajn, malkovreblajn, tut-retajn aplikaĵojn (kiel Zeroconf), kiuj povas esti kopiitaj al la loka komputilo aŭ ruliĝi rekte de la loka reto. Kompreneble, programistoj havas la eblon forigi per app_flags.

Fina raporto pri la integriĝo de la hpkg-sistemo kun la GUI

Mi pensas tion ĉefe pro la relativa noveco de la integriĝo .hpkg la GUI ankoraŭ lasas multon por deziri. Ĉiuokaze, estas kelkaj aferoj plibonigeblaj laŭ UX...

Unu plia afero: Kernel Debug Land

Estus bonege povi enigi komandojn dum kernelpaniko, ekzemple syslog | grep usb. Nu, ĉe Hajko eblas danke al Kernel Debug Land. Kiel vi povas vidi ĉi tiun magion en ago, se ĉio funkcias kiel ĝi devus sen eniri kernan panikon? Facile premante Alt+PrintScn+D (Elimigi mnemonikon). Mi tuj memoras Ŝlosilo de Programisto, kiu permesis al la originalaj Makintoŝoj programistoj eniri la erarseĉilon (se oni estis instalita, kompreneble).

konkludo

Mi komencas kompreni, ke la sofistikeco de la Haiku-sistemo venas de la fakto, ke la laboro estas farita de unu malgranda teamo kun klara fokuso sur la labormedio, kun ĉiuj tavoloj de la sistemo alireblaj.
Akra kontrasto kun la mondo de Linukso/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu, kie ĉio estas rompita en malgrandajn pecojn ĝis tia grado, ke abstraktado sidas sur abstraktado kaj veturas per lambastonoj.
Estis ankaŭ kompreno de kiel la sistemo .hpkg kombinas la plej bonajn praktikojn de tradiciaj pakaĵadministrantoj, Snappy, Flatpak, AppImage, eĉ btrfs, kaj miksas ilin kun la "nur funkcias" aliro de la Mac.

Estis kvazaŭ io "ŝanĝus" en mia kapo, kaj mi komprenis kiel la sistemo .hpkg scias ruliĝi for, nur rigardante ŝin. Sed ĝi ne estas mi, sed la beleco kaj simpleco de la sistemo. Multo de ĉi tio estas inspirita de la spirito de la originala Mac.

Jes, foliumado en la retumilo povas esti saka kaj funkcii kiel heliko, eble mankas aplikaĵoj (ne Gtk, Electron - la programistoj konkludis, ke ili ne taŭgas kun sofistikeco), video kaj 3d-akcelo eble tute forestas, sed mi ankoraŭ ŝatas ĉi tiun sistemon. Post ĉio, ĉi tiuj aferoj povas esti korektitaj kaj ili aperos frue aŭ malfrue. Estas nur demando de tempo kaj eble iom ruĝa okulo.

Mi ne povas proponi helpon, sed mi pensas, ke ĝi komenciĝos ekde nun jaro de Hajko sur labortablo.

Hazardaj problemoj

Eble jam estas petoj, aŭ ĉu mi malfermu ilin?

BeScreenCapture devus povi eksporti al GIF kiel Peek. Ĉi tio povas esti farita per ffmpeg, jam disponebla por Hajko. Apliko.
Ekrankopa programaro ne sukcesas kapti modalan fenestron, anstataŭe kaptante la tutan ekranon
Vi ne povas tondi ekrankopiojn uzante la tondilon de WonderBrush kaj poste konservi la rezulton al dosiero
Mi ne precipe ŝatas la mankursonon en Hajko, sed mi pensas, ke ĝi rilatas al la varma nostalgia sento. Ĉi tio estas precipe ĝena kiam oni uzas la kultivilon en Krita, ĉar ĝi rezultas en malpreciza tondado (vidu ekrankopiojn de modalaj dialogoj en ĉi tiu artikolo). Kruckursoro estus mirinda. Apliko.

Provu ĝin mem! Post ĉio, la Haiku-projekto provizas bildojn por ekfunkciigo de DVD aŭ USB, generitaj ĉiutaga. Por instali, simple elŝutu la bildon kaj bruligu ĝin al USB-memorilo uzante Etcher

Ĉu vi havas demandojn? Ni invitas vin al la ruslingva telegramkanalo.

Superrigardo de eraroj: Kiel pafi vin en la piedon en C kaj C++. Kolekto de Receptoj de Haiku OS

el la verkisto traduko: jen la sesa artikolo en la serio pri Hajko.

Listo de artikoloj: La unua La dua La tria Kvara Kvina

fonto: www.habr.com

Mia sesa tago kun Hajko: sub la kapuĉo de rimedoj, ikonoj kaj pakoj