TL;DR: Haiku — operační systém speciálně navržený pro PC, který má několik triků, díky nimž je jeho pracovní prostředí mnohem lepší než u ostatních. Jak to vlastně funguje?
Objevil jsem Haiku, překvapivě dobrý systém. Stále jsem ohromen, jak plynule funguje, zejména ve srovnání s pracovními prostředími na Linuxu. Dnes nakouknu pod kapotu. Tam, kde bude potřeba pro hlubší pochopení, provedu srovnání s původním Macintosh, Mac OS X a pracovními prostředími Linuxu (standard XDG od freedesktop.org).
Zdroje ve formátech ELF
Včera jsem zjistil, že IconOMatic umí ukládat ikony do zdrojů rdef v spustitelných souborech ELF. Dnes chci zjistit, jak to vlastně funguje.
Zdroje? od , původní autor programu Macintosh Finder a "otec" Macintosh Resource Manager:
Obává mě tvrdá povaha tradičního psaní kódu. Pro mě je samotná myšlenka aplikace, zmrazené v kódu, bez možnosti něco změnit dynamicky — naprostá šílenost. Měla by existovat možnost měnit co nejvíce v době běhu. Samozřejmě, že samotný kód aplikace nelze měnit, ale přece něco lze změnit i bez rekompilace kódu?
Na původním Macintosh bylo uděláno to, že tyto soubory mají "sekci dat" a "sekci zdrojů", což neobyčejně usnadnilo ukládání různých věcí, například ikonek, překladů a podobně do spustitelných souborů.
Na Macu se k tomu používá , grafický program pro — překvapivě — editaci zdrojů.
ResEdit na původním Macintosh
Díky tomu se objevila možnost editovat ikony, položky nabídek, překlady a další poměrně snadno, avšak stále "cestují" s aplikacemi.
V každém případě mělo toto řešení velkou nevýhodu: fungovalo pouze na souborových systémech Apple, což se stalo jedním z důvodů, proč Apple opustila "sekci zdrojů" při přechodu na Mac OS X.
Na Mac OS X chtěla Apple řešení nezávislé na souborovém systému, proto zavedli koncept balíčků (z NeXT), adresářů, které jsou spravovány správcem souborů jako „neprůhledné objekty“, podobně jako soubory, nikoli adresáře. Každý balíček s aplikací ve formátu .*.app má mimo jiné soubor Info.plist (v jakési analogii JSON nebo YAML od Apple), obsahující metadat aplikace.
Klíče souboru Info.plist z balíčku aplikace Mac OS X.
Zdroje, např. ikony, soubory UI a další, jsou uloženy v balíčku jako soubory. Koncepce se vlastně vrátila ke kořenům v NeXT.
Mathematica.app na NeXTSTEP 1.0 v roce 1989: zobrazuje se jako adresář se soubory v terminálu, ale jako jediný objekt v grafickém správci souborů.
Vraťme se k BeOS, jehož koncepty tvoří základ Haiku. Její vývojáři při přechodu z PEF (PowerPC) na ELF (x86) (stejné, které se používá na Linuxu) se rozhodli přidat sekci zdrojů na konec souborů ELF. K tomu nebyla použita vlastní sekce ELF, jednoduše ji zapsali na konec souboru ELF. V důsledku toho programy strip a další z binutils, které o tom nevědí, ji jednoduše ořezaly. Proto, pokud přidáte zdroje do souboru ELF na BeOS, je lepší s ním nepracovat nástroji pro Linux.
Co se vlastně nyní děje s Haiku? V podstatě to samé.
Teoreticky by bylo možné umisťovat zdroje do požadované sekce ELF. Podle vývojářů na kanálu #haiku v síti irc.freenode.net:
Se sekcí ELF by to mělo větší smysl... jediný důvod, proč to tak neděláme, je, že to tak dělali v BeOS“
A teď to není třeba měnit.
Správa zdrojů
Zdroje jsou zapisovány ve strukturovaném „zdrojovém“ formátu: v podstatě jde o seznam zdrojů s jejich velikostí a poté jejich obsahem. Připomněl se .
Jak lze zkontrolovat zdroje v Haiku? Existuje něco jako ResEdit?
Podle :
Pro zobrazení zdrojů dodávaných v balíčku aplikace můžete přetáhnout spustitelný soubor na program typu . Také můžete vstoupit do terminálu a spustit příkaz
listres jméno_souboru.
Resourcer je v HaikuDepot, ale u mě prostě padá.
Jak spravovat zdroje v souborech ELF? Použitím rsrc a rdef. rdef soubory se shromažďují v rsrc. Soubor rdef je uložen v běžném textovém formátu, takže je s ním mnohem snazší pracovat. Soubor ve formátu rsrc je zapsán na konec souboru ELF. Pojďme si s tím trochu pohrát:
~> rc -h
Haiku Resource Compiler 1.1K zkompilovat skript rdef do souboru se zdroji:
rc [možnosti] [-o ] ...Pro převod souboru se zdroji zpět do skriptu rdef:
rc [možnosti] [-o ] -d ...Možnosti:
-d --decompile vytvoří skript rdef ze souboru se zdroji
--auto-names sestavení názvů zdrojů ze symbolů ID
-h --help zobrazí tuto zprávu
-I --include přidat do seznamu cest pro zahrnutí
-m --merge neodstraňujte existující obsah výstupního souboru
-o --output specifikujte název výstupního souboru, výchozí je out.xxx
-q --quiet nezobrazovat žádné chybové zprávy
-V --version zobrazit verzi softwaru a licenciMůžete použít program xres pro 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.
(...)Dobře, zkusíme to?
/> 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_VERSIONVíce o zdrojích a formátu rdef si můžete přečíst .
Standardní typy zdrojů
I když můžete do zdrojů umístit cokoliv, existuje několik konkrétních standardních typů:
app_signature: MIME typ aplikace, pro přiřazení otevíraných souborů, spuštění, IPC atd.app_name_catalog_entry: Protože název aplikace je obvykle v angličtině, zde můžete uvést místa, kde se nacházejí přeložené názvy, takže uživatelé různých jazyků uvidí podle potřeby přeložený název aplikace.app_version: přesně to, co si myslíteapp_flags: určujeregistrar: jak zpracovávat aplikaci. Myslím, že je tu něco víc, než se na první pohled zdá. Například existujeB_SINGLE_LAUNCH, který přinutí systém spustit nový proces aplikace pokaždé, když uživatel žádá (stejný princip se používá pro většinu aplikací v Linuxu). ExistujeB_MULTIPLE_LAUNCH, který způsobí, že se proces spustí pro každý soubor. Nakonec existujeB_EXCLUSIVE_LAUNCH, který přinutí systém spustit pouze jeden proces najednou, bez ohledu na to, jak často jej uživatelé spouštějí (například takto se spouští Firefox v Linuxu; stejného výsledku lze dosáhnout v aplikacích Qt použitím funkce ). Aplikace sB_EXCLUSIVE_LAUNCHjsou informovány, když se uživatel pokusí je znovu spustit: například obdrží cestu k souboru, který se uživatel pokouší otevřít pomocí nich.vector_icon: Vektorová ikona aplikace (V BeOS nebyly vektorové ikony, většina aplikací místo toho měla dvě rastrové ikony v spustitelných souborech).
Samozřejmě můžete přidat zdroje s jakýmikoli požadovanými ID a typy, po kterých je číst v samotné aplikaci nebo jiných aplikacích pomocí třídy BResources. Ale nejprve se zastavme u fascinujícího tématu ikon.
Vektorové ikony ve stylu Haiku
Samozřejmě, že nejen Haiku zvolil nejlepší formát ikon, situace s pracovními prostředími Linuxu je v této části daleko od ideální:
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.cacheKdyž se na to podíváte, už můžete cítit, co to je za kus.
Samozřejmě, existují škálovatelné, které obsahují, jak je možno pochopit, vektorové ikony. Proč tedy existuje něco jiného? Protože výsledek vykreslení vektorové grafiky v malých velikostech může být horší než ideální. Chceme mít různé varianty optimalizované pro různé velikosti. V pracovních prostředích Linux se to dosahuje rozptýlením ikon s různými velikostmi po souborovém systému.
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šimněte si: neexistuje pojem různých verzí Firefoxu. Tím pádem není možné jemně zpracovat situaci s přítomností několika verzí aplikace v systému.
Různé ikony Firefoxu v různých verzích. Zatím není možné to zpracovat v Linuxu bez různých workaroundů.
Mac OS X to zpracovává o něco důmyslněji:
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 vidět, že existuje jeden soubor firefox.icns v balíčku Firefox.app, obsahující všechny velikosti, takže různé verze jedné aplikace mají různé ikony.
Mnohem lepší! Ikony cestují spolu s aplikací, všechny zdroje v jednom souboru.
Vraťme se k Haiku. Úžasné řešení, bez výjimek. Podle :
Byl vyvinut zvláštní, vysoce optimalizovaný formát pro malé velikosti a rychlé vykreslení, HVIF. Proto jsou naše ikony většinou mnohem menší než ve rastrovém nebo široce používaném formátu SVG.
A jsou skutečně optimalizovány:
Velikosti ikon v HVIF ve srovnání s jinými formáty.
Rozdíl je řádově!
Ale kouzlo zde nekončí. Stejný HVIF může ukázat různé úrovně detailů v závislosti na zobrazované velikosti, přestože je to vektorový formát.
Různé úrovně detailů (LOD) v závislosti na velikosti vykreslení.
Teď o nevýhodách: nelze vzít SVG, hodit do ImageMagick a tím to skončit, je potřeba projít několika cykly pro vytvoření ikony ve formátu HVIF. vysvětlení. Nicméně IconOMatic může dost neúplně importovat SVG; asi 90 % detailů SVG je importováno s určitou pravděpodobností, dalších 10 % bude třeba upravit a změnit ručně. Přečíst více o tom, jak HVIF dělá své kouzlo. v blogu
Přidání ikony do aplikace
Teď mohu přidat ikonu k balíčku, který byl vytvořen , s ohledem na všechny získané informace.
No a protože teď nemám příliš chuť kreslit si vlastní ikonu pro svou aplikaci „Ahoj, světe“ QtQuickApp — vytáhnu ji z 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 CreatorZkontrolujme, zda byla ikona zkopírována:
/Haiku/home> xres -l /Haiku/home/QtQuickApp/QtQuickApp/Haiku/home/QtQuickApp/QtQuickApp
resources:type ID size name
------ ----------- ----------- --------------------
'VICN' 101 152238 BEOS:ICONVypadá to dobře, ale proč se nová ikona nezobrazuje, když je zkopírována?
Zkopírovaná VICN:101:BEOS:ICONs zatím není používána jako ikona pro aplikaci ve správci souborů
Co jsem ale přehlédl?
Komentář vývojáře:
Je potřeba vytvořit soubor
rdefse všemi zdroji, pak spustit příkazrc jméno.rdef, to vytvoří soubor.rsrc. Pak je třeba spustit příkazresattr -o jméno_binarika jméno.rsrc. Minimálně používám podobné příkazy pro přidání ikon k mým skriptům.
No, chtěl jsem vytvořit zdroj, ne atribut. Jsem úplně zmatený.
Inteligentní cachování pomocí souborového systému
Otevírání a čtení atributů ELF probíhá pomalu. Jak jsem již zmínil výše, ikona je zapisována jako zdroj do samotného souboru. Tento způsob je spolehlivější, umožňuje přežít kopírování na jiný souborový systém. Nicméně později je také zkopírována do atributu souborového systému, například BEOS:ICON. To funguje pouze na určitých souborových systémech, například BFS. Ikony zobrazené systémem (v Trackeru a Deskbaru) se čtou z tohoto rozšířeného atributu, protože takové řešení funguje rychle. Na některých místech (kde rychlost není důležitá, například typové okno „O programu“) systém získává ikonu přímo ze zdroje v souboru. Ale to ještě není konec. Vzpomínáte, že na Macu mohli uživatelé nahradit ikony aplikací, složek a dokumentů svými, protože na Macu je možné udělat tyto „důležité“ věci, například . Na Haiku bychom měli vnímat zdroj (v souboru) jako výchozí ikonu dodávanou s aplikací a atribut (v souborovém systému BFS) jako něco, co umožňuje uživateli provádět úpravy podle přání (i když, tip, grafické rozhraní pro vložení uživatelské ikony přes ikonu ve výchozím nastavení zatím není realizováno).
Kontrola atributů souborového systému
Pomocí resaddr je možnost zkontrolovat a nastavit atributy souborového systému.
/> 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 podstatě je to „lepidlo“, které provádí převod tam a zpět mezi (spolehlivými) zdroji a (rychlými) atributy souborového systému. A protože systém počítá s přijímáním zdrojů a automaticky provádí kopírování, už se tím nebudu dál zabývat.
Kouzlo hpkg balíčků
V současnosti (nejčastěji) se pro získání aplikací na Haiku používají balíčky .hpkg. Nenechte se oklamat jednoduchým názvem: formát .hpkg funguje zcela jinak než jiné formáty se podobnými názvy, se kterými jste se setkali, má totiž skutečné super schopnosti.
S tradičními formáty balíčků jsem se dlouho trápil kvůli takové skutečnosti: stáhnete jeden (balíček), a v systému se nainstaluje něco jiného (soubory uvnitř balíčku). Je docela těžké se s těmito soubory (například je odstranit) vypořádat, když je instalace balíčku provedena tradičním způsobem. A to proto, že obsah balíčku se rozptýlí po celé souborové struktuře, včetně míst, kde běžný uživatel nemusí mít přístup k zápisu. To pak vytváří celou třídu programů — správců balíčků. A přitom přenést již nainstalovaný software, například na jiný počítač, externí disk nebo souborový server, se stává ještě obtížnějším, nebo dokonce nemožným. V běžném systému postaveném na Linuxu může snadno existovat od několika stovek tisíc až po miliony oddělených souborů. Samozřejmě, že to je zároveň křehké a pomalé, například při prvotním nastavení systému, při instalaci, aktualizaci a odinstalaci běžných balíčků, stejně jako při kopírování spouštěcí oblasti (kořenového oddílu) na jiný nosič.
Pracuji na projektu AppImage, částečného workaroundu pro aplikace pro koncové uživatele. Je to formát distribuce softwaru, který shromažďuje aplikaci a všechny její závislosti do jednoho obrazu souborového systému, který se připojuje při spuštění aplikace. Výrazně to zjednodušuje věci, protože ten stejný ImageMagick se najednou promění v jeden soubor, spravovaný v souborovém správci obyčejnými smrtelníky. Navrhovaný způsob funguje pouze pro software, jak název projektu naznačuje, a má také vlastní sadu problémů, protože lidé, kteří se zabývají dodávkami softwaru pro Linux, vždy přehazují odpovědnost na mě.
Vraťme se k Haiku. Podařilo se najít optimální rovnováhu mezi tradičními balíčkovými systémy a dodáváním softwaru na základě obrazů? Její balíčky .hpkg v podstatě zkomprimované obrazy souborového systému. Při spuštění systému jádro montuje všechny nainstalované a aktivní balíčky přibližně s následujícími zprávami jádra:
KERN: package_daemon [16042853: 924] aktivní balíček: "gawk-4.2.1-1-x86_64.hpkg"
KERN: package_daemon [16043023: 924] aktivní balíček: "ca_root_certificates_java-2019_01_23-1-any.hpkg"
KERN: package_daemon [16043232: 924] aktivní balíček: "python-2.7.16-3-x86_64.hpkg"
KERN: package_daemon [16043405: 924] aktivní balíček: "openjdk12_default-12.0.1.12-1-x86_64.hpkg"
KERN: package_daemon [16043611: 924] aktivní balíček: "llvm_libs-5.0.0-3-x86_64.hpkg"Super, že? Držte se, bude to ještě lepší!
Existuje velmi speciální balíček:
KERN: package_daemon [16040020: 924] aktivní balíček: "haiku-r1~beta1_hrev53242-1-x86_64.hpkg"Obsahuje velmi minimalistický operační systém, včetně jádra. Věříte nebo ne, ale samotné jádro se nevytahuje z bootovacího svazku (kořenového oddílu), ale pečlivě se načítá na své místo z balíčku. .hpkgTo je něco! Už jsem zmínil, že podle mě část celkové jemnosti a soudržnosti Haiku pramení z toho, že celý systém od jádra a základního uživatelského prostoru až po správu balíčků a infrastrukturu pracovního prostředí je vyvíjen společně jedním týmem. Představte si, kolik různých skupin a týmů by bylo potřeba k tomu, aby podobné něco spustili na základě Linuxu. [představuji si projekt PuppyLinux, — pozn. překladatele]. A pak si představte, kolik času by bylo potřeba, aby byl tento přístup implementován do distribucí. Říká se: vezmi jednoduchý úkol, rozděl ho mezi různé vykonavatele, a tak se zkomplikuje, že už nebude možné jej vyřešit. Haiku mi v tomto ohledu otevřela oči. Myslím, že právě toto se teď děje na Linuxu (Linux v tomto případě je souhrnný termín pro Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu).
Rollback systému pomocí hpkg
Jak často se stává následující situace: aktualizace proběhla úspěšně, ale pak se ukáže, že něco nefunguje tak, jak má? Při používání běžných balíčkových manažerů je obtížné vrátit stav systému na bod před instalací nových balíčků (například v případě, že něco nevyšlo). Některé systémy nabízejí obvyklé postupy ve formě snímků souborového systému, ale ty jsou poměrně objemné a také se nepoužívají ve všech systémech. V Haiku je to vyřešeno pomocí balíčků. .hpkgKaždý čas, kdy se mění balíčky v systému, staré balíčky nejsou odstraněny, ale uchovávány v systému v podadresářích typu /Haiku/system/packages/administrative/state-<...>/ trvale. Nedokončené operace uchovávají svá data v podadresářích /Haiku/system/packages/administrative/transaction-<...>/.
Obsah /Haiku/system/packages/administrative. Adresáře „state…“ obsahují textové soubory se jmény aktivních balíčků, „transaction…“ – samotné balíčky.
„Starý aktivní stav“, tj. seznam .hpkg balíčků, aktivních před změnami, se zapisuje po každé operaci do textového souboru v souborovém manažeru /Haiku/system/packages/administrative/state-<...>/activated-packages. Podobným způsobem se zapisuje nový „aktivní stav“ do textového souboru /Haiku/system/packages/administrative/activated-packages.
Katalog /Haiku/system/packages/administrative/state-<...>/ obsahuje pouze textový soubor se seznamem aktivních balíčků tohoto stavu (v případě instalace balíčků bez odstranění), a pokud byly balíčky odstraňovány nebo aktualizovány – adresář state obsahuje staré verze balíčků.
Při spuštění systému se na základě seznamu balíčků rozhoduje o aktivaci (připojení) balíčků. Tak jednoduše! Pokud při spuštění něco neproběhne správně – můžete správci zavádění říci, aby použil jiný, starší seznam. Úkol je vyřešen!
Zavaděč Haiku. Každý vstup zobrazuje odpovídající „aktivní stav“
Líbí se mi přístup s jednoduchými textovými soubory jakožto seznamem „aktivního stavu“, ve kterých jsou zapsána srozumitelná jména .hpkg. To ostře kontrastuje se stvořenou-pro-stroje-a-ne-pro-lidi od OSTree nebo Flatpak v souborovém systému (na stejné úrovni, jako je Microsoft GUID).
Seznam aktivních balíčků pro každý okamžik
Konfigurační data
Zdá se, že v adresáři /Haiku/system/packages/administrative/writable-files jsou soubory nastavení pro balíčky, ale dostupné pro zápis. Vždyť, jak víte, .hpkg se připojují pouze pro čtení. Takže tyto soubory by měly být zkopírovány z balíčků před zápisem. Dává smysl.
Integrace GUI pro systém .hpkg
Nyní se podívejme, jak si tyto skvělé balíčky vedou .hpkg s integrací do uživatelského pracovního prostředí (UX). Haiku je přece určeno pro osobní použití. Osobně jsem si nastavil vysokou laťku, když jsem porovnával uživatelskou zkušenost s balíčky .*.app na Macintoshu s podobným zážitkem na .hpkg. Ani nebudu srovnávat situaci s pracovními prostředími v Linuxu, protože je to v porovnání s čímkoli jiným naprosto hrozné.
Napadají mě následující scénáře:
- Chci si prohlédnout obsah balíčku
.hpkg - Chci nainstalovat balíček
- Chci odstranit balíček
- Chci odstranit něco, co přišlo do systému jako součást balíčku
- Chci zkopírovat něco, co přišlo do systému jako součást balíčku
- Chci stáhnout všechny závislosti balíčku, které nemohou být součástí každé instalace Haiku (například mám fyzicky izolovaný stroj bez přístupu k internetu).
- Chci přesunout své balíčky (nebo jejich část) odděleně na jiné místo, mimo spouštěcí svazek (kořenovou část) (protože například mám na něm nedostatek místa).
To by mělo pokrýt většinu základních případů z mé každodenní práce. No, začněme.
Kontrola obsahu balíčku
Na Macu stačí kliknout pravým tlačítkem na balíček pro jeho otevření a prohlížení obsahu ve Finderu. Vždyť je to ve skutečnosti jen zamaskovaný adresář! (Vím, že existují balíčky .pkg pro část systému, která není aplikacemi, ale běžní uživatelé s nimi většinou ani nekomunikují).
Na Haiku kliknu pravým tlačítkem na balíček, poté kliknu na «Contents» pro zobrazení toho, co je uvnitř. Ale tady je jen seznam souborů bez možnosti je otevřít dvojitým kliknutím.
Bylo by mnohem lepší, kdyby existoval způsob (dočasného) připojení balíčku .hpkg pro prohlížení přes správce souborů, aniž by se uživatel musel starat o detaily implementace. (Mimochodem, balíček lze otevřít .hpkg v Expander, který jej může rozbalit jako jakýkoli jiný archiv).
V rozhraní HaikuDepot lze zobrazit seznam souborů balíčku, ale není způsob, jak prohlížet obsah, například dvojitým kliknutím na README.md.
V této kategorii vyhrává Mac, ale přidání potřebné funkčnosti do HaikuDepot by nemělo představovat velké potíže.
Instalace balíčku přes GUI
Na Macu, většina diskových obrazů .dmg obsahuje balíčky .*.app. Otevřeme diskový obraz dvojitým kliknutím a poté kopírujeme balíček, například přetahováním do /Applications Finderu. Pro mě je to samozřejmě, ale slyšel jsem, že někteří nováčci by to mohli nezvládnout. Ve výchozím nastavení Apple "navrhuje" systémový adresář /Applications (na NeXT byl síťový a také individuální), ale lze snadno umístit své aplikace na souborový server nebo do podsložky $HOME/Applications, pokud se vám to tak líbí.
Na Haiku, dvojitým kliknutím na balíček, pak kliknutím na „Install“, jednodušší to být nemůže. Zajímalo by mě, co se stane, pokud má balíček závislosti dostupné v HaikuPorts, které zatím nejsou nainstalovány. Na Linuxu si opravdu neví rady, co s tím dělat, ale řešení je zřejmé — zeptat se uživatele, zda chce stáhnout a nainstalovat závislosti. Přesně to dělá Haiku.
Stáhl jsem balíček 'sanity' ručně a klepnul na něj, správce balíčků ví, odkud vzít jeho závislosti (pokud jsou repozitáře již nastaveny v systému). Ne každý distribuce Linuxu tohle umí.
Další způsob — použití správce souborů, stačí přetáhnout .hpkg balíček buď do /Haiku/system/packages (pro systémovou instalaci, ve výchozím nastavení), nebo do /Haiku/home/config/packages (pro individuální instalaci; není dostupné při dvojitém kliknutí — stále mě rozčiluje slovo „config“ na tomto místě, které pro mě v tomto případě je synonymem „settings“). Ačkoli koncept více uživatelů není pro Haiku zatím dostupný (možná proto je všechno tak snadné — nevím, možná víc uživatelské možnosti by zkomplikovaly věci pro pracovní prostředí osobního počítače).
V této kategorii vyhrává Haiku, protože umí pracovat nejen s aplikacemi, ale také se systémovými programy.
Odstranění balíčku z GUI
Na Macu, stačí přetáhnout ikonu aplikace do koše a tím to končí. Snadné!
Na Haiku, za prvé, je potřeba najít, kde se balíček nachází v systému, protože ho zřídka instalujete tam, kam byste měli (všechno dělá systém). Obvykle je třeba hledat v /Haiku/system/packages (při systémové instalaci ve výchozím nastavení), nebo v /Haiku/home/config/packages (už jsem říkal, že „config“ je špatný název?). Pak se aplikace jednoduše přetáhne do koše, a tím to končí.
Snadné! Přesto bych to tak neřekl. Takhle to ve skutečnosti vypadá:
Co se stane, když přetáhnete aplikaci do koše z /Haiku/system/packages
Jednoduše jsem zkusil přesunout svou včerejší aplikaci „Ahoj, světe“ na QtQuickApp do koše. Nepokoušel jsem se přesunout systémový adresář, a protože všechny balíčky se instalují do systémového adresáře – není možné odstranit balíček .hpkg bez změny „jeho obsahu“. Běžný uživatel by se vyděsil, klikl by na tlačítko „Zrušit“, které je nastaveno jako výchozí.
Vysvětluje :
Tomu oznámení je už více než 10 let. Pravděpodobně bychom ho měli nastavit tak, aby upozornění vyšlo pouze při přesunu samotného balíčku. Běžní uživatelé to v každém případě nepotřebují dělat.
Dobře, možná bych to měl udělat pomocí HaikuDepotu? Dvakrát kliknu na balíček v /Haiku/system/packages, očekávám, že se objeví tlačítko „Odinstalovat“. Ne, je tam (jen) „Nainstalovat“. „Odinstalovat“, kde jsi?
Pro srandu jsem zkusil zjistit, co se stane, když kliknu na „Nainstalovat“ pro již nainstalovaný balíček. Vypadá to takto:
To se stane, když se pokusíte nainstalovat již nainstalovaný balíček.
Poté se objeví:
Pokud kliknete na „Použít změny“ v předchozím okně – stane se tohle
Předpokládám, že to je softwarová chyba, odkaz na žádost už existuje. [autor odkaz neposkytl, — pozn. překladatele]
Rychlé řešení: Přidat tlačítko „Odinstalovat“, pokud je balíček již v
/Haiku/system/packages, nebo v/Haiku/home/config/packages.
Při prohlížení seznamu balíčků nainstalovaných v HaikuDepotu vidím svůj balíček v seznamu a mohu jej odstranit.
V této kategorii vyhrává Mac. Ale mohu si představit, že s řádným nastavením bude uživatelský zážitek na Haiku lepší než na Macu. (Jeden z vývojářů to ocenil takto: „Méně než hodinu na přidání uvedené funkce do HaikuDepotu, pokud znáte trochu C++“, jsou dobrovolníci?)
Odstranění něčeho z balíčku
Zkusme odstranit samotnou aplikaci, nikoli balíček .hpkg, ze kterého vzešla (pochybuji, že pro „obyčejné smrtelníky“ je nějaký rozdíl).
Na Macu, uživatel ve skutečnosti obvykle pracuje s souborem .dmg, odkud pochází balíček aplikace .*.app. Obvykle obrázky .dmg se hromadí v adresáři stažení, balíčky jsou však kopírovány uživateli do /Applications. Existuje názor, že mnoho uživatelů si ani neuvědomuje, co dělají, a tuto hypotézu potvrzuje bývalý zaměstnanec Apple. (Jedna z věcí, která se mi na Macu nelíbí. Na druhou stranu, s AppImage není rozdíl mezi aplikací a balíčkem, ve kterém byla. Přetáhnout ikonu do koše = to je vše. Snadné!)
Na Haiku, také existuje dělení mezi apps/ a packages/, takže pochybuji, že by to uživatelům například objasnilo. Co se však stane, když přetáhnete aplikaci z apps/ do koše:
Toto je výsledek pokusu o odstranění aplikace stažené z .hpkg
Technicky to je správně (vždyť aplikace je umístěna na souborovém systému jen pro čtení), ale není to pro uživatele příliš užitečné.
Rychlé řešení: místo toho nabídnout odstranění prostřednictvím GUI
.hpkg
Pro zábavu jsem zkusil zdvojnásobit aplikaci stisknutím Alt+D. Zobrazil se mi zpráva „Není možné přesunout nebo zkopírovat objekty na disku jen pro čtení“. A to všechno proto, že /system kromě /system/packages a /system/settings) je bodem připojení packagefs (pamatujete, jak se objevuje v výstupu df?). К сожалению, вывод команды mount neobjasňuje situaci (jak bylo uvedeno v jednom z předchozích článků), mountvolume nezobrazuje hledané (zřejmě montované přes loop balíčky .hpkg nejsou považovány za „disky“), a navíc jsem zapomněl alternativní příkazy.
V této kategorii nikdo nevyhrál, kromě AppImage (ale to je, abych byl zcela upřímný, zaujatý názor). Můžeme však představit, že po úpravě bude uživatelský zážitek na Haiku lepší než na Macu.
Poznámka: Je třeba zjistit, co znamená „disk“ ve vztahu k „oddílu“. Pravděpodobně je to obdobné vztahu „složky“ k „adresáři“: většina adresářů se zobrazuje ve správci souborů jako složky, ale ne všechny z nich (například balíčky, zpracovávané jako soubory). Dělá mě to oficiálně nerdem?
Kopírování obsahu balíčku na jiný systém
Na Macu, jednoduše přetahuji balíček .*.app, a protože závislosti uvnitř balíčku — ty se přesouvají spolu.
Na Haiku, přetahuji aplikaci, ale závislosti se vůbec nezpracovávají.
Rychlé řešení: Nechť je místo toho nabídnuto přetáhnout balíček „`.hpkg“ sám, spolu se závislostmi, pokud nějaké existují.
V této kategorii jednoznačně vyhrává Mac. Alespoň pro mě, milovníka jejich paradigmatu. Na Haiku by mělo být něco zkopírováno. .hpkg místo aplikačního rozhraní, ale systém mi nic takového nenabízí...
Stahování balíčku se všemi jeho závislostmi
Ne každé zařízení je neustále připojeno k síti. Naopak, některá zařízení (ano, dívám se na vás, moderní Windows, Mac a Linux) na to zapomínají. Pro mě je důležité, že mohu jít například do internetové kavárny, stáhnout software na přenosné médium, vložit toto médium do domácího počítače a být si jistý, že všechno bude fungovat [odvážný chlapík, dělat to na Windows... - pozn. překladatele].
V důsledku toho se o něco častěji, než obvykle, setkávám s neuspokojenými závislostmi na Windows a Linuxu.
Na Macu obvykle se jedná o jeden soubor, vše, co je potřeba, je stáhnout .dmg. Nejčastěji nemá žádné závislosti, kromě těch, které poskytuje samotný MacOS jako výchozí. Jako výjimku lze uvést složité aplikace, které vyžadují odpovídající prostředí pro běh, například java.
Na Haiku stáhnout balíček .hpkg pro, řekněme, tu samou aplikaci na java, se může ukázat jako nedostatečné, protože java může být buď přítomna, nebo nepřítomna na cílovém zařízení. Existuje způsob, jak stáhnout všechny závislosti pro tento balíček .hpkg, kromě těch, které jsou instalovány v Haiku jako výchozí a tudíž by měly být v každém systému Haiku?
V této kategorii s malým náskokem vítězí Mac.
Komentuje mr. waddlesplash:
Abych napsal program pro shromažďování všech závislostí aplikace ve formě sady balíčků
.hpkgpro někoho, kdo je obeznámen s vnitřním fungováním Haiku, to zabere asi 15 minut. Přidat podporu pro to není tak složité, pokud je na tom skutečná potřeba. Ale pro mě je to vzácná situace.
Zadržíme dech na další článek v této sérii.
Přesun balíčků na vyhrazené místo
Jak jsem již zmínil, chci umístit své balíčky .hpkg (no, nebo jejich část) na zvláštní místo, oddělené od běžného umístění na spouštěcím oddílu (kořenu). V běžném případě (ne tak teoretickém) je důvodem, že mi trvale dochází volné místo na mých (vestavěných) discích, bez ohledu na to, jak jsou velké. A obvykle připojuji externí disky nebo síťové zdroje, kde mám své aplikace.
Na Macu jen přesouvám balíčky .*.app na externí disk nebo síťový adresář ve Finderu, a to je vše. Stále mohu dvakrát kliknout na aplikaci, jak jsem to dříve dělal s bootovacím svazkem. Jednoduché!
Na Haiku, jak mi bylo řečeno, toho lze dosáhnout přesunutím mých .hpkg balíčků na externí disk nebo síťový adresář, ale pak musím využít některé nedokumentované příkazy v terminálu k tomu, abych je namontoval do systému. Nevím, jak to udělat, jen s GUI.
V této kategorii vítězí Mac.
Podle pana waddlesplashe:
Zde se optimalizuje na základě obvyklého použití. Pokud však bude poptávka vyšší než od jednoho uživatele, realizujeme to. V každém případě existuje možnost třetí strany.
O tom budeme informovat v dalším článku.
Pokud mluvíme o síťových adresářích: bylo by skvělé (předpokládám LAN večírky) mít jednoduché, objevitelné, síťové aplikace (např. přes Zeroconf), které lze zkopírovat na místní počítač nebo spustit přímo z místní sítě. Samozřejmě, že vývojáři mají možnost odmítnutí prostřednictvím app_flags.
Závěrečná zpráva o integraci systému hpkg s GUI
Myslím, že především kvůli relativní novosti integrace .hpkg s GUI stále zaostává. V každém případě je několik věcí, které lze zlepšit v oblasti UX…
Ještě jedna věc: Kernel Debug Land
Bylo by skvělé mít při kernel panic možnost zadávat příkazy, například syslog | grep usb. No, na Haiku to možné díky Kernel Debug Land. Jak vidět tuto magii v akci, když vám všechno funguje, jak má bez vyvolání kernel panic? Snadno, stisknutím Alt+PrintScn+D (mnemonika Debug). Ihned si vzpomínám na , která umožnila původním vývojářům Macintosh vstoupit do ladicího programu (pokud byl samozřejmě nainstalován).
Závěr
Začínám chápat, že rafinovanost systému Haiku pochází z toho, že na něm pracuje malý tým s jasnou orientací na pracovní prostředí při dostupnosti všech vrstev systému.
Ostrý kontrast s světem Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu, kde je vše rozděleno na malé kousky až do té míry, že abstrakce sedí na abstrakci a zahání ji berlemi.
Také jsem došel k pochopení, jak systém .hpkg kombinuje nejlepší praktiky tradičních správce balíčků, Snappy, Flatpak, AppImage, dokonce i btrfs, a míchá je s principem „prostě to funguje“ od Mac.
Najednou jako by se v hlavě něco „přepnulo“ a já jsem pochopil, jak systém .hpkg umí vracet zpět, — stačilo se na něj podívat. Ale to nejsem já, to je krása a jednoduchost systému. Mnohé zde je prosáklé duchem původního Macu.
Ano, prohlížení stránek v prohlížeči může být trhané a fungovat jako hlemýžď, aplikací může být nedostatek (chybí Gtk, Electron — vývojáři vyvodili závěry, že se špatně kombinují s vytříbeností), zrychlení videa a 3D může úplně chybět, ale i tak se mi tento systém líbí. Vždyť tyto problémy lze opravit a dříve či později se objeví. Je to jen otázka času a možná trochu červených očí.
Nemohu nabídnout pomoc, ale myslím, že od tohoto okamžiku to začne rok Haiku na pracovní ploše.
Náhodné problémy
Možná už existují žádosti, nebo je mám otevřít?
- BeScreenCapture by měl mít možnost exportu do GIF, jako Peek. To lze provést pomocí ffmpeg, který již existuje pro Haiku. .
- Program pro pořizování snímků obrazovky nemůže pořídit snímek modálního okna, místo toho snímá celý obrazovku
- Není možné ořezávat snímky obrazovky pomocí nástroje pro ořezávání ve WonderBrush, a pak uložit výsledek do souboru
- Není mi příliš sympatický ruční kurzor v Haiku, ale myslím, že to souvisí s teplými nostalgickými pocity. To je obzvlášť frustrující při používání ořezávacího nástroje v Kritě, protože ořezávka vychází nepřesná (viz snímky obrazovky s modálními dialogy v tomto článku). Křížový kurzor by byl skvělý. .
Vyzkoušejte to sami! Projekt Haiku poskytuje obrazy pro spuštění z DVD nebo USB, které jsou vytvářeny . Pro instalaci stačí stáhnout obraz a zapsat ho na flash disk pomocí
Máte otázky? Zveme vás do rusky mluvícího .
Přehled chyb:
Od překlad: to je šestý článek z cyklu o Haiku.
Seznam článků:
Zdroj: habr.com
