TL;DR: Haiku — operačný systém navrhnutý špeciálne pre PC, takže má niekoľko trikov, ktoré robia jeho pracovné prostredie oveľa lepším ako u iných. Ale ako to funguje?
Objavil som Haiku, nečakaný dobrý systém. Stále som ohromený tým, ako hladko funguje, najmä v porovnaní s pracovnými prostrediami na Linuxe. Dnes sa pozriem pod kapotu. Tam, kde to bude potrebné pre hlboké porozumenie, vykonám porovnanie s pôvodným Macintoshom, Mac OS X a pracovnými prostrediami Linuxu (štandard XDG od freedesktop.org).
Zdroje v súboroch ELF
Včera som zistil, že IconOMatic dokáže uložiť ikony do zdrojov rdef v spustiteľných súboroch ELF. Dnes chcem vidieť, ako to vlastne funguje.
Zdroje? od , pôvodný autor programu Macintosh Finder a 'otec' Macintosh Resource Manager:
Obáva ma tvrdá povaha tradičného písania kódu. Pre mňa je samotná myšlienka aplikácie zmrznutej v kóde, bez možnosti zmeniť čokoľvek dynamicky — hrozná barbarstvo. Musí existovať možnosť meniť čo najviac v čase behu. Samozrejme, samotný kód aplikácie nemôže byť zmenený, ale veď niečo sa dá zmeniť aj bez prekompilovania kódu?
Na pôvodnom Macintosh bol tak, že tieto súbory mali 'sekciu dát' a 'sekciu zdrojov', čo mimoriadne uľahčilo ukladanie rôznych vecí, napríklad ikon, prekladov a podobne do spustiteľných súborov.
Na Mac sa na to používa , grafický program na — prekvapivo — úpravu zdrojov.
ResEdit na pôvodnom Macintosh
Vďaka tomu sa objavila možnosť jednoducho upravovať ikony, položky ponúk, preklady a podobne, avšak aj tak 'cestujú' s aplikáciami.
Tak či onak, tento prístup mal veľkú nevýhodu: fungoval len na súborových systémoch Apple, čo sa stalo jednou z príčin, prečo Apple opustila 'sekciu zdrojov' pri prechode na Mac OS X.
Na Mac OS X Apple chceli riešenie nezávislé od súborového systému, preto použili koncept balíkov (z NeXT), priečinkov, ktoré sú spracovávané správcom súborov ako 'nepriehľadné objekty', podobne ako súbory, a nie priečinky. Akýkoľvek balík s aplikáciou vo formáte .*app má, okrem iného, súbor Info.plist (v akomsi ekvivalentu JSON alebo YAML od Apple), obsahujúci metadáta aplikácie.
Kľúče súboru Info.plist z balíka aplikácie Mac OS X.
Resursy, ako napríklad ikony, súbory UI a podobne, sa uchovávajú v balíku vo forme súborov. Koncept sa vlastne vrátil k svojim koreňom v NeXT.
Mathematica.app na NeXTSTEP 1.0 v roku 1989: zobrazuje sa ako adresár so súbormi v termináli, ale ako jeden objekt v grafickom správci súborov.
Vráťme sa k BeOS, na ktorých konceptoch je založený Haiku. Jej vývojári pri prechode z PEF (PowerPC) na ELF (x86) (rovnaký, ktorý sa používa na Linuxe) sa rozhodli pridať sekciu resursov na koniec súborov ELF. Na tento účel nebola použitá žiadna vlastná platná sekcia ELF, len ju pripojili na koniec súboru ELF. V dôsledku toho programy strip a ďalšie z binutils, ktoré o tom nevedeli, ju jednoducho orezali. Preto, ak pridávate resursy do súboru ELF na BeOS, je lepšie s ním nepracovať pomocou nástrojov Linux.
A čo sa teraz deje s Haiku? V podstate, takmer to isté.
Teoreticky by bolo možné umiestniť resursy do požadovanej sekcie ELF. Podľa vývojárov na kanáli #haiku v sieti irc.freenode.net:
S ELF by sekcia mala väčší zmysel... jediný dôvod, prečo to tak nerobíme, je, že tak to robili v BeOS.
A nemení sa to teraz.
Správa resursov
Resursy sú zapísané v štruktúrovanom "resursnom" formáte: v podstate to je zoznam resursov s veľkosťami a potom už ich obsah. Pripomenul sa mi .
Ako môžeme skontrolovať resursy v Haiku? Existuje niečo ako ResEdit?
Podľa :
Na zobrazenie resursov dodávaných v balíku aplikácie je možné pretiahnuť vykonávací súbor na program typu Môžete tiež ísť do terminálu a spustiť príkaz
listres názov_súboru..
Resourcer je v HaikuDepot, ale mne jednoducho padá.
Ako spravovať resursy v súboroch ELF? Použitím rsrc a rdef.. rdef. Súbory sa zhromažďujú do rsrc. Súbor rdef. sa uchováva v bežnom textovom formáte, takže s ním je oveľa ľahšie pracovať. Súbor v formáte rsrc sa dopisuje na koniec súboru ELF. Poďme sa pokúsiť niečo skúsiť:
~> rc -h
Haiku Resource Compiler 1.1Aby ste skompilovali rdef skript do súboru resursov:
rc [options] [-o ] ...Aby ste konvertovali súbor resursov späť do rdef skriptu:
rc [options] [-o ] -d ...Možnosti:
-d --decompile vytvorí rdef skript zo súboru resursov
--auto-names vytvorí názvy resursov z ID symbolov
-h --help zobraziť túto správu
-I --include pridať do zoznamu ciest na zahrnutie
-m --merge nezmazať existujúci obsah výstupného súboru
-o --output určiť názov výstupného súboru, predvolený je out.xxx
-q --quiet nezobraziť žiadne chybové hlásenia
-V --version zobraziť verziu softvéru a licenciu.Programu je možné použiť xres na kontrolu a správu:
/> 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.
(...)Dobre, poďme to skúsiť?
/> 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_VERSIONViac o zdrojoch a formáte rdef. si môžete prečítať .
Štandardné typy zdrojov
Hoci do zdrojov môžete umiestniť čokoľvek, existuje niekoľko konkrétnych štandardných typov:
app_signature: MIME typ aplikácie na priradenie otváraných súborov, spustenie, IPC atď.app_name_catalog_entry: Keďže názov aplikácie je zvyčajne v angličtine, tu môžete uviesť miesta, kde sa nachádzajú preložené názvy, takže používateľom rôznych jazykov bude zobrazený preložený názov aplikácie, ak o to požiadajú.app_version: presne to, čo ste si mysleliapp_flags: uvádzaregistrarako spracovať aplikáciu. Myslím, že je tu niečo viac ako sa na prvý pohľad zdá. Napríklad existujeB_SINGLE_LAUNCH, ktorý núti systém spustiť nový proces aplikácie zakaždým, keď o to používateľ požiada (rovnaký princíp sa používa pre väčšinu aplikácií na Linuxe). ExistujeB_MULTIPLE_LAUNCH, ktorý spôsobuje, že sa proces spúšťa pre každý súbor. Nakoniec existujeB_EXCLUSIVE_LAUNCH, ktorý núti systém spúšťať len jeden proces naraz, bez ohľadu na to, ako často ho používatelia spúšťajú (napríklad takto sa spúšťa Firefox na Linuxe; rovnakého výsledku je možné dosiahnuť v aplikáciách Qt použitím funkcie ). Aplikácie sB_EXCLUSIVE_LAUNCHsú informované, keď sa používateľ pokúša znovu ich spustiť: napríklad dostanú cestu k súboru, ktorý chce používateľ otvoriť s ich pomocou.vector_icon: Vektorová ikona aplikácie (v BeOS neexistovali vektorové ikony, väčšina aplikácií mala namiesto nich dve rastrové ikony v spustiteľných súboroch).
Samozrejme je možné pridať zdroje s akýmikoľvek požadovanými ID a typmi, po ktorých ich môžete čítať v samotnej aplikácii alebo iných aplikáciách pomocou triedy BResources. Ale najprv sa zamerajme na zaujímavú tému ikon.
Vektorové ikony v štýle Haiku
Samozrejme, že nielen Haiku si zvolil najlepší formát ikon, situácia s pracovnými prostrediami Linuxu nie je v tejto oblasti ideálna:
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.cachePohľad na takéto už môže naznačovať, čo to je za kus.
Samozrejme, existuje scalable, ktorý obsahuje, ako možno pochopiť, vektorové ikony. Prečo je teda niečo ďalšie? Pretože výsledok vykreslenia vektorovej grafiky v malých rozmeroch môže byť horší ako ideálny. Chceli by sme mať rôzne varianty optimalizované pre rôzne veľkosti. V pracovných prostrediach Linuxu sa to dosahuje roztrúsením ikon po súborovom systéme s rôznymi rozmermi.
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.pngVšimnite si: neexistuje koncept rôznych verzií Firefoxu. Takže situáciu s prítomnosťou viacerých verzií aplikácie v systéme nemožno spracovať rafinovane.
Rôzne ikony Firefoxu v rôznych verziách. Zatiaľ nie je možné to spracovať v Linuxe bez rôznych obmietení.
Mac OS X to spracováva trochu rafinovanejšie:
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.icnsJe zjavné, že existuje jeden súbor firefox.icns v balíku Firefox.app, ktorý obsahuje všetky veľkosti, takže rôzne verzie tej istej aplikácie majú rôzne ikony.
Oveľa lepšie! Ikony putujú spolu s aplikáciou, všetky zdroje sú v jednom súbore.
Vráťme sa k Haiku. Ohromujúce riešenie, bez výnimiek. Podľa :
Bol vyvinutý osobitný, vysoko optimalizovaný formát HVIF pre malé veľkosti a rýchle vykreslenie. Preto sú naše ikony väčšinou oveľa menšie ako v rastrovom alebo široko používanom formáte SVG.
A sú skutočne optimalizované:
Veľkosti ikony v HVIF v porovnaní s inými formátmi.
Rozdiel o poriadok!
Ale mágii tu nekončí. Ten istý HVIF môže ukázať rôzne úrovne detailnosti v závislosti od zobrazeného rozmeru, aj keď ide o vektorový formát.
Rôzne úrovne detailnosti (LOD) v závislosti od veľkosti vykreslenia.
Teraz o nevýhodách: nie je možné vziať SVG, hodiť do ImageMagick a tým to skončiť, treba prejsť niekoľkými cyklami na vytvorenie ikony vo formáte HVIF. vysvetlenia. Avšak IconOMatic môže dosť nedokonalé importovať SVG; zhruba 90 % detailov SVG sa importuje s istou pravdepodobnosťou, zvyšných 10 % bude treba nastaviť a zmeniť manuálne. Prečítajte si viac o tom, ako HVIF robí svoju mágiu v blogu
Pridanie ikony do aplikácie
Teraz môžem pridať ikonu do balíka, ktorý bol vytvorený , so, considering all the obtained information.
Well, since I’m not particularly eager to draw my own icon for my 'Hello, World' QtQuickApp right now — I'm just pulling it from 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 CreatorLet's check if the icon has been copied:
/Haiku/home> xres -l /Haiku/home/QtQuickApp/QtQuickApp/Haiku/home/QtQuickApp/QtQuickApp
resources:type ID size name
------ ----------- ----------- --------------------
'VICN' 101 152238 BEOS:ICONLooks good, but why, when the new icon is copied, it doesn't display?
The copied VICN:101:BEOS:ICONs is still not used as an icon for the application in the file manager.
What have I missed?
Komentár vývojára:
I need to create a file
rdef.with all the resources, then execute the commandrc name.rdef, this will create the file.rsrc. Then I need to execute the commandresattr -o binary_name name.rsrc. At the very least, I use such commands to add icons to my scripts.
Well, I wanted to create a resource, not an attribute. I'm really confused.
Smart caching using the file system.
Opening and reading ELF attributes is slow. As I mentioned before, the icon is written as a resource in the file itself. This method is more reliable, allows surviving copying to another file system. However, it is also copied into the file system attribute, for example BEOS:ICON. This works only on certain file systems, for example BFS. The icons shown by the system (in Tracker and Deskbar) are read from this extended attribute because such a solution works quickly. In some places (where speed is not important, for example in the standard 'About' window) the system retrieves the icon directly from the resource in the file. But this is not the end. Remember, on Mac, users could replace application, folder, document icons with their own, as Mac has the ability to do these 'important' things, for example, . On Haiku, the resource (in the file) should be viewed as the original icon supplied with the application, while the attribute (in the BFS file system) is something that allows the user to make changes if desired (though, hint, the graphical interface for inserting a custom icon over the default one has not yet been implemented).
Checking file system attributes.
S pomocou resaddr there is a possibility to check and set file system attributes.
/> 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.
(...)V podstate ide o „lepidlo“, ktoré vykonáva prevody tam a späť medzi (spoľahlivými) zdrojmi a (rýchlymi) atribútmi súborového systému. Pretože systém predpokladá získavanie zdrojov a automaticky vykonáva kopírovanie, nebudem sa tým ďalej zaoberať.
Kúzlo hpkg balíkov
V súčasnosti (najčastejšie) sa na získanie programov pre Haiku používajú balíky .hpkg. Nepodceňujte jednoduché meno: formát .hpkg funguje úplne inak ako iné formáty so podobnými názvami, ktoré ste už stretli, má skutočné super schopnosti.
Dlho som sa frustroval s tradičnými formátmi balíkov kvôli tejto skutočnosti: stiahnete jeden (balík), a do systému sa nainštaluje niečo iné (súbory vo vnútri balíka). Dosť ťažko sa manipuluje so súbormi (napríklad ich odstrániť), keď sa balík inštaluje tradičným spôsobom. A to všetko preto, že obsah balíka sa rozptýli po celom súborovom systéme, vrátane miest, kde bežný používateľ nemusí mať prístup na zápis. To vyvoláva celý rad programov — správcov balíkov. A presun už nainštalovaného softvéru, napríklad na iný počítač, prenosný disk alebo súborový server, sa stáva ešte ťažším, ba dokonca nemožným. V bežnom systéme na báze Linuxu môže ľahko existovať od niekoľkých stotisíc po milióny samostatných súborov. Samozrejme, to je zároveň krehké a pomalé, napríklad pri počiatočnej inštalácii systému, pri inštalácii, aktualizácii a odinštalácii bežných balíkov, ako aj pri kopírovaní spúšťacieho zväzku (hlavného oddielu) na iné médium.
Pracujem na projekte AppImage, čiastočnom praktickom riešení pre aplikácie pre koncových používateľov. Je to formát distribúcie softvéru, ktorý zhromažďuje aplikáciu a všetky jej závislosti do jedného obrazu súborového systému, montovaného pri spustení aplikácie. Výrazne to zjednodušuje veci, pretože ten istý ImageMagick sa náhle mení na jeden súbor, s ktorým sa dá manipulovať v súborovom manažéri bežnými smrteľníkmi. Navrhnutý spôsob funguje len pre softvér, ako je uvedené v názve projektu, a má aj vlastný rad nedostatkov, pretože ľudia, ktorí sa zaoberajú dodávkou softvéru pre Linux, vždy prenášajú zodpovednosť na mňa.
Vráťme sa k Haiku. Podarilo sa nájsť optimálnu rovnováhu medzi tradičnými balíkovými systémami a dodávkou softvéru na základe obrazov? Jej balíky .hpkg sú v podstate komprimované obrazy súborového systému. Pri spúšťaní systému jadro montuje všetky nainštalované a aktívne balíky zhruba s nasledujúcimi hláseniami jadra:
KERN: package_daemon [16042853: 924] aktívny balík: "gawk-4.2.1-1-x86_64.hpkg"
KERN: package_daemon [16043023: 924] aktívny balík: "ca_root_certificates_java-2019_01_23-1-any.hpkg"
KERN: package_daemon [16043232: 924] aktívny balík: "python-2.7.16-3-x86_64.hpkg"
KERN: package_daemon [16043405: 924] aktívny balík: "openjdk12_default-12.0.1.12-1-x86_64.hpkg"
KERN: package_daemon [16043611: 924] aktívny balík: "llvm_libs-5.0.0-3-x86_64.hpkg"Super, že? Držte sa, bude to ešte lepšie!
Existuje naozaj zvláštny balík:
KERN: package_daemon [16040020: 924] aktívny balík: "haiku-r1~beta1_hrev53242-1-x86_64.hpkg"Obsahuje veľmi minimalistický operačný systém, vrátane jadra. Verte alebo nie, ale aj jadro sa neextrahuje zo zavádzacieho oddielu (korenného oddielu), ale starostlivo sa nahráva na svoje miesto z balíka .hpkg. To je úžasné! Už som spomínal, že, podľa môjho názoru, časť celkovej rafinovanosti a súdržnosti Haiku je spôsobená tým, že celý systém od jadra a základného používateľského prostredia, až po správu balíkov a infraštruktúru pracovného prostredia vyvíja spolu jeden tím. Predstavte si, koľko rôznych skupín a tímov by bolo potrebných na to, aby spustili niečo podobné na základe Linuxu. [predstavujem si projekt PuppyLinux, — pozn. prekladateľa]. Potom si predstavte, koľko času by trvalo implementovať tento prístup do distribúcií. Hovorí sa, vezmi jednoduchú úlohu, rozdeľ ju medzi rôznych vykonávateľov a stane sa tak zložitou, že ju už nebude možné vyriešiť. Haiku mi v tomto prípade otvorilo oči. Myslím, že presne to sa deje na Linuxe dnes (Linux je v tomto prípade súhrnný pojem, ktorý označuje stack Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu).
Rollback systému pomocou hpkg
Ako často sa objaví nasledujúca situácia: aktualizácia prebehla úspešne a potom sa zistí, že niečo nefunguje tak, ako by malo? Pri používaní bežných balíčkových manažérov je ťažké vrátiť stav systému do momentu pred inštaláciou nových balíkov (napríklad, ak niečo nevyšlo). Niektoré systémy ponúkajú obchádzajúce riešenia vo forme snímok súborového systému, ale tie sú pomerne ťažkopádne a navyše sa používajú len vo vybraných systémoch. V Haiku je to vyriešené pomocou balíkov. .hpkgKaždýkrát, keď sa v systéme menia balíky, staré balíky nie sú odstránené, ale uchovávajú sa v systéme v podpriečinkoch typu /Haiku/system/packages/administrative/state-<...>/ nepretržite. Nedokončené operácie uchovávajú svoje údaje v podpriečinkoch. /Haiku/system/packages/administrative/transaction-<...>/.
Obsah /Haiku/system/packages/administrativePriečinky „state…“ obsahujú textové súbory s názvami aktívnych balíkov, „transaction…“ — samotné balíky.
„Starý aktívny stav“, t.j. zoznam .hpkg balíkov, aktívnych pred zmenami, sa zapisuje po každej operácii do správcu súborov do textového súboru. /Haiku/system/packages/administrative/state-<...>/activated-packagesPodobným spôsobom sa zapisuje nový „aktívny stav“ do textového súboru. /Haiku/system/packages/administrative/activated-packages.
Adresár /Haiku/system/packages/administrative/state-<...>/ obsahuje iba textový súbor so zoznamom aktívnych balíkov tohto stavu (v prípade inštalácie balíkov bez odstránenia), a ak sa balíky odstraňovali alebo aktualizovali — priečinok state obsahuje staré verzie balíkov.
Pri spúšťaní systému sa na základe zoznamu balíkov prijíma rozhodnutie o aktivácii (mountovaní) balíkov. Takto jednoducho! Ak sa pri spúšťaní niečo pokazí — je možné povedať načítavaču, aby použil iný, starší zoznam. Úloha je vyriešená!
Načítavač Haiku. Každý vstupný bod zodpovedá príslušnému „aktívnemu stavu“.
Páči sa mi prístup s jednoduchými textovými súbormi ako zoznamom „aktívneho stavu“, v ktorých sú zapísané názvy, ktoré sú zrozumiteľné. .hpkgTo ostro kontrastuje s vytvorenou-pre-stroje-a-nie-pre-ľudí od OSTree alebo Flatpak v súborovom systéme (na úrovni podobnej Microsoft GUID).
Zoznam aktívnych balíkov pre každý okamih
Konfiguračné údaje
Podľa všetkého sa v priečinku /Haiku/system/packages/administrative/writable-files nachádzajú konfiguračné súbory pre balíky, ale dostupné na zápis. Veď, ako si pamätáte, .hpkg sú mountované iba na čítanie. Týmto spôsobom by sa tieto súbory mali skopírovať z balíkov pred zápisom. Má to zmysel.
Integrácia GUI pre systém .hpkg
Poďme sa teraz pozrieť, ako sa tieto skvelé balíky .hpkg vyrovnávajú s integráciou do používateľského pracovného prostredia (UX). Veď Haiku je určené na osobné použitie, nakoniec. Osobne som si nastavil vysokú latku, porovnávajúc používateľský zážitok s balíkmi .*app na Macintosh s rovnakým zážitkom na .hpkg. Nebudem ani porovnávať situáciu s pracovnými prostrediami na Linuxe, pretože je to absolútne hrozné v porovnaní s akýmikoľvek inými.
Na um prichádzajú nasledujúce scenáre:
- Chcem zobraziť obsah balíka
.hpkg - Chcem nainštalovať balík
- Chcem odinštalovať balík
- Chcem odstrániť niečo, čo prišlo do systému ako súčasť balíka
- Chcem skopírovať niečo, čo prišlo do systému ako súčasť balíka
- Chcem stiahnuť všetky závislosti balíka, ktoré nemusia byť súčasťou každej inštalácie Haiku (napríklad mám fyzicky izolovaný stroj bez prístupu na internet.)
- Chcem presunúť moje balíky (no, alebo ich časť) oddelene na iné miesto, oddelené od zavádzacieho objemu (korenej oblasti) (pretože, napríklad, mám nedostatok miesta na ňom).
To by malo pokryť väčšinu základných prípadov z mojej každodennej práce. No, poďme na to.
Kontrola obsahu balíka
Na Macu len kliknem pravým tlačidlom myši na balík, aby som ho otvoril a prezrel si obsah vo Finderi. Veď to v skutočnosti nie je nič iné ako zamaskovaný adresár! (Vieme, že existujú balíky .pkg pre časť systému, ktorá nie je aplikáciami, ale bežní používatelia sa s nimi väčšinou nestretávajú).
Na Haiku kliknem pravým tlačidlom myši na balík, potom kliknem na bdContentsc5, aby som videl, čo je vo vnútri. Ale tu je len zoznam súborov bez možnosti ich otvoriť dvojitým kliknutím.
Bolo by oveľa lepšie, keby existoval spôsob (dočasný) pripojenia balíka .hpkg na prezeranie cez správcu súborov, a používateľ sa nemusel zaoberať implementačnými detailmi. (Mimochodom, môžete otvoriť .hpkg balík v Expander, ktorý ho môže rozbaliť rovnako ako akýkoľvek iný archív).
V rozhraní HaikuDepot môžete prezerať zoznam súborov balíka, ale neexistuje spôsob, ako zobraziť obsah, napríklad dvojitým kliknutím na README.md.
V tejto kategórii vyhráva Mac, ale pridanie potrebnej funkčnosti do HaikuDepot by nemalo spôsobiť veľké problémy.
Inštalácia balíka cez GUI
Na Macu, väčšina diskových obrazov .dmg obsahuje balíky .*app. Otvoríme diskový obraz dvojitým kliknutím a skopírujeme balík napríklad tak, že ho potiahneme do /Applications Finderu. Pre mňa je to samozrejmosť, ale počul som, že niektorí nováčikovia to môžu nezvládnuť. Predvolený systém Apple "ponúka" systémový adresár /Applications (na NeXT bol sieťový a aj individuálny), ale svoje aplikácie si môžete jednoducho umiestniť na súborový server alebo do podadresára $HOME/Applications, ak sa vám to tak páči.
Na Haiku, stačí dvojitý klik na balík, potom kliknite na "Install", jednoduchšie to už nebude. Zaujímalo by ma, čo sa stane, ak balík má závislosti, ktoré sú dostupné v HaikuPorts, ale zatiaľ nie sú nainštalované. Na Linuxe naozaj nevedia, čo robiť v tejto situácii, ale riešenie je jasné — opýtať sa používateľa, či chce stiahnuť a nainštalovať závislosti. Presne to robí Haiku.
Stiahol som balík 'sanity' ručne a klikol naň, balíčkový manažér vie, odkiaľ získať jeho závislosti (za predpokladu, že repozitáre sú už zadané v systéme). Nie každý distribútor Linuxu to zvládne.
Ďalší spôsob — použitie súborového manažéra, stačí potiahnuť .hpkg balík buď do /Haiku/system/packages (pre systémovú inštaláciu, predvolené), alebo do /Haiku/home/config/packages (pre individuálnu inštaláciu; nie je dostupné pri dvojitom kliknutí — stále ma irituje slovo „config“ na tomto mieste, ktoré je pre mňa v tomto prípade synonymom „settings“). A myšlienka viacerých používateľov ešte nie je dostupná pre Haiku (asi preto je to všetko také jednoduché — neviem, možno by viac používateľských možností zbytočne skomplikovalo veci pre pracovné prostredie osobného počítača).
V tejto kategórii vyhráva Haiku, pretože dokáže pracovať nielen s aplikáciami, ale aj so systémovými programami.
Odstránenie balíka z GUI
Na Macu, stačí potiahnuť ikonu aplikácie do koša a tým to končí. Ľahké!
Na Haiku, po prvé, musíte nájsť, kde sa balík nachádza v systéme, pretože málo kedy ho nainštalujete kam treba (všetko robí systém). Zvyčajne sa hľadať musí v /Haiku/system/packages (pri systémovej inštalácii predvolene), alebo v /Haiku/home/config/packages (už som hovoril, že „config“ je nesprávny názov?). Potom sa aplikácia jednoducho potiahne do koša a tým to končí.
Ľahké! Avšak, tak by som to nepovedal. Toto je to, čo sa skutočne deje:
Tu je, čo sa stane, ak presuniete aplikáciu do koša z /Haiku/system/packages
Práve som sa pokúšal presunúť do koša svoju včerajšiu aplikáciu „Ahoj, svet“ na QtQuickApp. Nepokúsil som sa presunúť systémový adresár, a keďže všetky balíky sa inštalujú do systémového adresára — nemožno odstrániť balík .hpkg bez zmeny „jeho obsahu“. Bežný používateľ by sa zľakol, stlačil by tlačidlo „Zrušiť“, ktoré je predvolené.
Vysvetľuje :
Tomuto hláseniu je už viac ako 10 rokov. Pravdepodobne by sme ho mali nastaviť tak, aby varovanie vyšlo len pri presúvaní samotného balíka. Bežní používatelia to v každom prípade nepotrebujú robiť.
Dobre, možno to treba spraviť pomocou HaikuDepot? Dvakrát kliknem na balík v /Haiku/system/packages, očakávajúc, že sa objaví tlačidlo „Odstrániť“. Nie, je tu len „Inštalovať“. „Odstrániť“, kde si?
Pre zábavu som sa pokúsil zistiť, čo sa stane, ak stlačím „Inštalovať“ pre už nainštalovaný balík. Stalo sa toto:
Takto to vyzerá, ak sa pokúsite nainštalovať už nainštalovaný balík.
Nasleduje:
Ak stlačíte „Použiť zmeny“ v predchádzajúcom okne — stane sa toto
Predpokladám, že ide o softvérovú chybu, odkaz na žiadosť už existuje. [autor odkaz neposkytol, — pozn. prekl. ]
Rýchle riešenie: Pridať tlačidlo „Odstrániť“, ak je balík už v
/Haiku/system/packages, alebo v/Haiku/home/config/packages.
Pri prezeraní zoznamu balíkov, ktoré sú nainštalované v HaikuDepot, vidím svoj balík v zozname a môžem ho odstrániť.
V tejto kategórii vyhráva Mac. Ale môžem si predstaviť, že pri správnom nastavení bude používateľský zážitok na Haiku lepší ako na Macu. (Jeden z vývojárov to ohodnotil takto: „Menej ako hodina na pridanie uvedenej funkcie do HaikuDepot, ak trošku poznáte C++“, sú dobrovoľníci?)
Odstránenie niečoho z balíka
Skúsme odstrániť samotnú aplikáciu, nie balík .hpkg, z ktorého sa objavila (pochybujem, že pre „obyčajných smrteľníkov“ je tu akýkoľvek rozdiel).
Na Macu, používateľ v skutočnosti zvyčajne pracuje s súborom .dmg, odkiaľ prichádza balík aplikácie .*app. Obvykle sa obrazy .dmg zhromažďujú v adresári na stiahnutie, balíky sa však kopírujú používateľom do /Applications. Existuje názor, že mnohí používatelia sami nevedia, čo robia, a táto hypotéza bola potvrdená bývalým zamestnancom Apple. (Jedna z vecí, ktoré sa mi na Macu nepáčia. Na druhej strane, s AppImage nie je rozdiel medzi aplikáciou a balíkom, v ktorom sa nachádza. Pretiahli ste ikonu do koša = a to je všetko. Ľahké!)
Na Haiku, tiež existuje rozdelenie medzi apps/ a packages/, takže pochybujem, že to používateľom urobilo jasnejšie. A čo sa stane, ak pretiahnete aplikáciu z apps/ do koša:
Toto je výsledok pri pokuse o odstránenie aplikácie prevzatej zo súboru .hpkg
Technicky je to správne (veď aplikácia je umiestnená na súborovom systéme iba na čítanie, predovšetkým), ale nie je to príliš užitočné pre používateľa.
Rýchle riešenie: namiesto toho navrhnúť cez GUI odstrániť
.hpkg
Pre zábavu som sa pokúsil duplikovať aplikáciu stlačením Alt+D. Dostávam správu „Nie je možné presunúť alebo kopírovať objekty na zväzku iba na čítanie“. A to všetko preto, že /system (okrem /system/packages a /system/settings) je bod pripojenia packagefs (pamätáte si, ako sa objavuje vo výstupe df?). К сожалению, вывод команды mount neobjasňuje situáciu (ako už bolo povedané v jednom z predchádzajúcich článkov), mountvolume neukazuje požadované (zjavne pripojené cez loop balíky .hpkg nie sú považované za „zväzky“), a tiež som zabudol alternatívne príkazy.
V tejto kategórii nikto nevyhral, okrem AppImage (ale to je, ak mám byť úplne úprimný, predpojatý názor). Avšak môže to byť, že po prispôsobení bude užívateľská skúsenosť na Haiku lepšia ako na Macu.
Poznámka: je potrebné zistiť, čo znamená „zväzok“ v súvislosti s „partíciou“. Pravdepodobne to súvisí s vzťahom „zložky“ k „adresáru“: väčšina adresárov sa zobrazuje v súborovom manažéri ako zložky, ale nie všetky (napríklad balíky, ktoré sa spracovávajú ako súbory). Robia ma podobné úvahy oficiálne nerdom?
Kopírovanie obsahu balíka na iný systém
Na Macu, jednoducho pretiahujem balík .*app, a pretože závislosti v balíku – pohybujú sa spolu.
Na Haiku, pretiahnem aplikáciu, ale závislosti sa vôbec nespracovávajú.
Rýchle riešenie: Nech sa namiesto toho navrhuje pretiahnuť balík „.hpkg“ úplne, spolu so závislosťami, ak sú nejaké.
V tejto kategórii jednoznačne vyhráva Mac. Aspoň pre mňa, milovníka ich paradigmy. Na Haiku by ste mali skopírovať .hpkg namiesto aplikácie, ale systém mi to neponúka…
Stiahnutie balíka so všetkými jeho závislosťami
Nie každý počítač je neustále pripojený na sieť. Naopak, niektoré počítače (áno, pozerám sa na vás, moderné Windows, Mac a Linux) na to zabúdajú. Pre mňa je dôležité, že môžem ísť napríklad do internetovej kaviarne, stiahnuť softvér na prenosné médium, vložiť toto médium do domáceho počítača a byť si istý, že všetko bude fungovať [riskantný chlapík, robiť to na Windows… — pozn. prekladateľa].
V dôsledku toho, o niečo častejšie ako obvykle, zvyčajne dostávam nespokojné závislosti na Windows a Linux.
Na Macu je to zvyčajne jeden súbor, všetko, čo treba, je stiahnuť .dmg. Najčastejšie nemá žiadne závislosti, okrem tých, ktoré poskytuje sama MacOS predvolene. Ako výnimku možno uviesť zložené aplikácie, ktoré vyžadujú príslušné prostredie, napríklad java.
Na Haiku stiahnuť balík .hpkg pre, povedzme, tú istú aplikáciu na java, môže byť nedostatočné, pretože java môže byť prítomná aj neprítomná na cieľovom počítači. Existuje spôsob, ako sťahovať všetky závislosti pre daný balík .hpkg, okrem tých, ktoré sa inštalujú v Haiku predvolene a teda by mali byť v každom systéme Haiku?
V tejto kategórii s malým odstupom víťazí Mac.
Komentuje mr. waddlesplash:
Aby som napísal program na zhromažďovanie všetkých závislostí aplikácie vo forme súboru balíkov
.hpkgpre niekoho, kto je oboznámený s vnútornou štruktúrou Haiku, stačí asi 15 minút. Pridanie podpory pre to nie je až také zložité, ak je v tom skutočná potreba. Ale pre mňa je to zriedkavá situácia.
Zadržíme dych do nasledujúceho článku v tomto cykle.
Premiestnenie balíkov do oddelenej lokality
Ako som už písal skôr, chcem umiestniť moje balíky .hpkg (no, alebo ich časť) na osobitné miesto, oddelené od bežného umiestnenia na spúšťacom objeme (korennom oddiele). V bežnom prípade (nie tak teoretickom) je dôvodom to, že sa mi neustále míňa voľné miesto na mojich (vnútorných) diskoch, bez ohľadu na to, aké sú veľké. A zvyčajne pripájame externé disky alebo sieťové zdroje, kde sú moje aplikácie.
Na Macu ja jednoducho presúvam balíky .*app na externý disk alebo sieťový priečinok v Prieskumníkovi a tým to končí. Stále môžem dvojitým kliknutím otvoriť aplikáciu, ako som to robil s bootovacím diskom. Jednoducho!
Na Haiku, ako mi povedali, tohto možno dosiahnuť presunutím mojich .hpkg balíčkov na externý disk alebo sieťový priečinok, ale potom je potrebné využiť niektoré nedokumentované príkazy v konzole na ich pripojenie do systému. Neviem, ako to urobiť len pomocou GUI.
V tejto kategórii víťazí Mac.
Podľa mr. waddlesplash:
Tu je optimalizácia z hľadiska bežného použitia. Ak sa však dopyt zvýši nad rámec jedného používateľa, implementujeme to. V každom prípade existuje možnosť externého uskutočnenia.
O tom sa dozviete v ďalšom článku.
Pokiaľ ide o sieťové priečinky: bolo by skvelé (predpokladám LAN party) mať jednoduché, objaviteľné, sieťové aplikácie (napríklad cez Zeroconf), ktoré môžete skopírovať na miestny počítač alebo spustiť priamo zo siete. Samozrejme, vývojári majú možnosť odmietnuť cez app_flags.
Záverečná správa o integrácii systému hpkg s GUI
Myslím si, že predovšetkým kvôli relatívnej novosti integrácia .hpkg s GUI stále zaostáva. V každom prípade existuje niekoľko vecí, ktoré je možné zlepšiť v oblasti UX…
Ešte jedna vec: Kernel Debug Land
Bolo by skvelé mať pri kernel panic možnosť zadávať príkazy, napríklad syslog | grep usb. No, na Haiku to je možné vďaka Kernel Debug Land. Ako vidieť túto mágiu v akcii, ak všetko funguje správne bez vstupu do kernel panic? Ľahko, stlačením Alt+PrintScn+D (mnemonika Debug). Okamžite mi prichádza na myseľ , ktorá umožňovala pôvodným vývojárom Macintosh vstúpiť do debuggeru (ak bol samozrejme nainštalovaný).
Záver
Začínam chápať, že sofistikovanosť systému Haiku pramení z toho, že práca prebieha jedným malým tímom so zameraním na pracovné prostredie pri dostupnosti všetkých vrstiev systému.
Ostrý kontrast so svetom Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu, kde je všetko rozdelené na malé kúsky do takej miery, že abstrakcia sedí na abstrakcii a je podopieraná pomocou barlôčikov.
Prišlo tiež pochopenie toho, ako systém .hpkg kombinuje najlepšie praktiky tradičných správcov balíčkov, Snappy, Flatpak, AppImage, dokonca btrfs, a mieša ich s princípom „proste funguje“ od Mac.
Akoby sa v hlave 'prepínalo' a ja som pochopil, ako systém .hpkg dokáže sa vrátiť späť, len na ňu pozrem. Ale to nie som ja, to je krása a jednoduchosť systému. Mnohé je tu preniknuté duchom pôvodného Macu.
Áno, prezeranie stránok v prehliadači môže byť trhané a fungovať ako slimák, možno chýbajú aplikácie (nie je Gtk, Electron – vývojári dospeli k záveru, že sa zlúčenie s eleganciou nepodarilo), zrýchlenie videa a 3D môže úplne chýbať, ale aj tak sa mi tento systém páči. Tieto veci sa dajú opraviť a skôr či neskôr sa objavia. Je to len otázka času a možno trocha červených očí.
Nemôžem ponúknuť pomoc, ale myslím, že od tohto okamihu sa začne rok Haiku na ploche.
Náhodné problémy
Možno už existujú požiadavky, alebo ich mám otvoriť ja?
- BeScreenCapture by mal mať schopnosť exportovať do GIF, ako v Peek. To sa dá urobiť pomocou ffmpeg, ktorý už existuje pre Haiku. .
- Program na snímanie obrazovky nemôže zachytiť snímku modálneho okna, namiesto toho zachytáva celý obrazovku
- Nie je možné orezať snímky obrazovky pomocou nástroja na orezávanie vo WonderBrush a potom uložiť výsledok do súboru
- Neveľmi sa mi páči kurzor v tvare ruky v Haiku, ale myslím, že to súvisí s teplými nostalgickými pocitmi. Je to obzvlášť obťažujúce pri použití nástroja na orezávanie v Krita, keďže to spôsobuje nepresné orezanie (pozri snímky obrazovky s modálnymi dialógmi v tomto článku). Kurzorský tvar kríža by bol skvelý. .
Vyskúšajte sami! Projekt Haiku poskytuje obrazy na stiahnutie z DVD alebo USB, generované . Na inštaláciu stačí stiahnuť obraz a napáliť ho na USB kľúč pomocou
Vyskytli sa otázky? Pozývame vás do ruského .
Prehľad chýb:
Od prekladu: toto je šiesty článok zo série o Haiku.
Zoznam článkov:
Zdroj: habr.com
