Min sjätte dag med Haiku: en mängd resurser, ikoner och paket under huven

TL;DR: Haiku — ett operativsystem speciellt utvecklat för PC, vilket ger det flera knep som gör dess arbetsmiljö mycket bättre än andra. Men hur fungerar det?

Nyligen Jag upptäckte Haiku, ett oväntat bra system. Jag är fortfarande förvånad över hur smidigt det fungerar, särskilt jämfört med arbetsmiljöer på Linux. Idag ska jag titta under huven. Där det är nödvändigt för en djupare förståelse kommer jag att göra jämförelser med den ursprungliga Macintosh, Mac OS X och Linux-arbetsmiljöer (standard XDG från freedesktop.org).

Resurser i ELF-filer

Igår fick jag veta att IconOMatic kan spara ikoner i rdef-resurser i ELF-körbara filer. Idag vill jag se hur det egentligen fungerar.

Resurser? Citat från Bruce Horn, den ursprungliga skaparen av Macintosh Finder och "fadern" till Macintosh Resource Manager:

Jag oroar mig för det styva sättet att skriva kod på. För mig är själva idén om en applikation fryst i kod, utan möjlighet att förändra något dynamiskt — en avskyvärd galenskap. Det bör finnas en möjlighet att ändra så mycket som möjligt vid körningstid. Naturligtvis kan själva koden för applikationen inte ändras, men visst går det att förändra något utan att recompilera koden?

På den ursprungliga Macintosh gjorde man så att dessa filer hade en "datasektion" och en "resurssektion", vilket oerhört underlättade lagring av olika saker, till exempel ikoner, översättningar och så vidare i körbara filer.

På Mac används detta ResEdit, ett grafiskt program för — överraskande nog — att redigera resurser.

ResEdit på den ursprungliga Macintosh

Som ett resultat blev det möjligt att redigera ikoner, menyval, översättningar och så vidare ganska enkelt, men de "reser" ändå tillsammans med applikationerna.
Hur som helst hade detta tillvägagångssätt en stor nackdel: det fungerade endast på Apples filsystem, vilket blev en av anledningarna till att Apple övergav "resurssektionen" när de övergick till Mac OS X.
På Mac OS X ville Apple ha en lösning oberoende av filsystemet, så de använde konceptet paket (från NeXT), kataloger som hanteras av filhanteraren som "opaka objekt", liknande filer, snarare än kataloger. Varje paket med en applikation i formatet .*.app innehåller, bland annat, en fil Info.plist (i något motsvarande JSON eller YAML från Apple), som innehåller metadata för applikationen.

Nycklarna i Info.plist-filen från Mac OS X-applikationspaketet.

Resurser som ikoner, UI-filer och andra lagras i paketet som filer. Konceptet har i stort sett återgått till sina rötter i NeXT.

Mathematica.app på NeXTSTEP 1.0 år 1989: visas som en katalog med filer i terminalen, men som ett enda objekt i den grafiska filhanteraren.

Låt oss gå tillbaka till BeOS, som Haiku är baserat på. Dess utvecklare bestämde sig vid övergången från PEF (PowerPC) till ELF (x86) (samma som används på Linux) för att lägga till en resurssektion i slutet av ELF-filer. Ingen egen lämplig ELF-sektion användes, den skrivs helt enkelt till slutet av ELF-filen. Resultatet var att program strip och andra från binutils, som inte kände till detta, helt enkelt klippte bort den. Därför, för att lägga till resurser i ELF-filer på BeOS, bör man undvika att arbeta med dem med Linux-verktyg.

Vad händer nu med Haiku? I princip ganska samma sak.

Teoretiskt sett skulle det vara möjligt att placera resurser i den lämpliga ELF-sektionen. Enligt utvecklarna på #haiku-kanalen på irc.freenode.net:

Med ELF skulle sektionen ha mer mening... den enda anledningen till att vi inte gör det är att så gjordes i BeOS.
Och det är inte värt att ändra nu.

Resurshantering

Resurser skrivs i ett strukturerat "resurs"-format: i grunden en lista av resurser med storlekar och sedan deras innehåll. Jag tänker på formatet ar..
Hur kan man kontrollera resurser i Haiku? Finns det något som ResEdit?
Enligt dokumentationen:

För att visa resurser som levereras i applikationspaketet kan man dra den körbara filen till ett program som Resourcer.Du kan också gå in i terminalen och köra kommandot listres filnamn..

Resourcer finns i HaikuDepot, men jag får bara programmet att krascha.

Hur hanterar man resurser i ELF-filer? Med hjälp av rsrc. och rdef.. rdef. Filerna kompileras till rsrc.. Filen rdef. lagras i ett vanligt textformat, så det är mycket enklare att arbeta med. Filer i formatet rsrc. lägger till något i slutet av ELF-filen. Låt oss prova att leka lite:

~> rc -h
Haiku Resurskompilator 1.1 För att kompilera ett rdef-skript till en resursfil:
    rc [alternativ] [-o ] ... För att konvertera en resursfil tillbaka till ett rdef-skript:
    rc [alternativ] [-o ] -d ... Alternativ:
    -d --dekompilera       skapa ett rdef-skript från en resursfil
       --auto-namn       konstruera resursnamn från ID-symboler
    -h --hjälp            visa detta meddelande
    -I --inkludera    lägg till  i listan över inkluderingsvägar
    -m --sammanfoga       radera inte befintligt innehåll i utdatafilen
    -o --utdata          specificera namn på utdatafil, standard är out.xxx
    -q --tyst           visa inga felmeddelanden
    -V --version         visa programvaruversion och licens.

Programmet kan användas xres för att kontrollera och hantera:

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

Okej, ska vi prova?

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

Mer om resurser och format rdef. kan läsas här.

Standardtyper av resurser

Även om man kan lägga vad som helst i resurser, finns det några specifika standardtyper:

• app_signature: MIME-typen för applikationen, för att matcha öppningsbara filer, start, IPC osv.
• app_name_catalog_entry: Eftersom applikationens namn vanligtvis är på engelska, kan man här ange platser där översatta namn finns, så att användare av olika språk kan se det översatta namnet vid behov.
• app_version: precis det du tänker på
• app_flags: anger registrar hur applikationen ska behandlas. Jag tror att det finns mer än det verkar vid första anblicken. Till exempel finns det B_SINGLE_LAUNCH, vilket får systemet att starta en ny applikationsprocess varje gång, på begäran av användaren (samma princip används för de flesta applikationer på Linux). Det finns B_MULTIPLE_LAUNCH, vilket tvingar att starta en process för varje fil. Slutligen finns det B_EXCLUSIVE_LAUNCH, vilket får systemet att starta endast en process åt gången, oavsett hur ofta användare försöker starta den (till exempel, så startar Firefox på Linux; samma resultat kan uppnås i Qt-applikationer med hjälp av funktionen QtSingleApplication). Applikationer med B_EXCLUSIVE_LAUNCH informeras när användaren försöker starta dem igen: till exempel får de sökvägen till den fil som användaren vill öppna med hjälp av dem.
• vector_icon: Vektorikon för applikationen (I BeOS fanns det inga vektorikoner, de flesta applikationer hade istället två rasterikoner i exekverbara filer).

Självklart kan man lägga till resurser med valfria ID och typer, och sedan läsa dem i själva applikationen eller andra applikationer med hjälp av klassen BResources. Men låt oss först pausa vid det intressanta ämnet ikoner.

Vektorikoner i Haiku-stil

Självklart valde inte bara Haiku det bästa formatet för ikoner, situationen med skrivbordsmiljöerna i Linux är långt ifrån perfekt:

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

Att se något sådant kan man redan känna vad det här stycket handlar om.

Självklart finns det skalbara, vilket man kan förstå, vektorikoner. Varför finns det då något annat? För att resultatet av rendering av vektorgrafik i små storlekar kan vara sämre än perfekt. Man vill ha olika alternativ, optimerade för olika storlekar. I Linux-miljöer uppnås detta genom att sprida ut ikoner med olika storlekar över filsystemet.

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

Observera: det finns inget begrepp för olika versioner av Firefox. Därför kan man inte sofistikerat hantera situationen med närvaron av flera versioner av applikationen i systemet.

Olika ikoner för Firefox i olika versioner. För nu är det omöjligt att hantera detta i Linux utan olika nödlösningar.

Mac OS X hanterar detta något mer sofistikerat:

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

Det syns att det finns en fil firefox.icns i paketet Firefox.app, som innehåller alla storlekar, så att olika versioner av samma applikation har olika ikoner.
Mycket bättre! Ikonerna reser med applikationen, alla resurser i en fil.

Låt oss återkomma till Haiku. En fantastisk lösning, utan undantag. Enligt dokumentationen:

Det har utvecklats ett särskilt, högoptimerat format för små storlekar och snabb rendering, HVIF. Därför är våra ikoner för det mesta mycket mindre än i raster- eller det allmänt använda SVG-formatet.

Och de är faktiskt optimerade:

Storlekarna på ikonerna i HVIF jämfört med andra format.

Skillnaden är en ordning!

Men magin slutar inte här. Samma HVIF kan visa olika detaljnivåer beroende på den visade storleken, trots att det är ett vektorformat.

Olika detaljnivåer (LOD) beroende på storleken på rendering

Nu om nackdelarna: man kan inte bara ta SVG, slänga den i ImageMagick och vara klar, man måste gå igenom flera cykler för att skapa en ikon i HVIF-format. Här förklaringar. Men IconOMatic kan ganska ofullständigt importera SVG; omkring 90% av detaljrikedomen i SVG importeras med viss sannolikhet, de resterande 10% måste justeras och ändras manuellt. Läs mer om hur HVIF gör sin magi kan i bloggen Lea Genson

Att lägga till en ikon i applikationen

Nu kan jag lägga till ikonen till paketet som skapades förra gången, med tanke på all information som har mottagits.
Eftersom jag för närvarande inte har något som helst intresse av att rita en egen ikon för min "Hej, Värld" QtQuickApp — tar jag den från 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

Låt oss kontrollera att ikonen har kopierats:

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

Ser bra ut, men varför visas inte den nya ikonen när den har kopierats?

Den kopierade VICN:101:BEOS:ICON används fortfarande inte som ikon för applikationen i filhanteraren.

Vad har jag missat?

Utvecklarens kommentar:

Jag behöver skapa en fil rdef. med alla resurser, sedan köra kommandot rc namn.rdef, det kommer att skapa en fil .rsrc. Sedan behöver jag köra kommandot resattr -o namn_binär namn.rsrc. Åtminstone använder jag liknande kommandon för att lägga till ikoner till mina skript.

Men, jag ville ju skapa en resurs, inte en attribut. Jag är verkligen förvirrad.

Intelligent caching med hjälp av filsystemet.

Att öppna och läsa attribut från ELF fungerar långsamt. Som jag skrev ovan, skrivs ikonen som en resurs i själva filen. Denna metod är mer pålitlig och klarar av att överleva kopiering till ett annat filsystem. Men den kopieras också till filsystemattributet, till exempel BEOS:ICON. Detta fungerar endast på vissa filsystem, som BFS. Ikoner som visas av systemet (i Tracker och Deskbar) läses från detta utökade attribut, eftersom en sådan lösning fungerar snabbt. På vissa ställen (där hastighet inte spelar någon roll, som i det vanliga "Om-programmet"-fönstret) får systemet ikonen direkt från resursen i filen. Men det är inte slutet. Kom ihåg, på Mac kunde användare ersätta ikoner för applikationer, mappar, dokument med sina egna, eftersom Mac har möjlighet att göra dessa "viktiga" saker, till exempel att byta den nya Slack-ikonen mot den tidigare.I Haiku bör resursen (i filen) ses som den ursprungliga ikonen som levereras med applikationen, medan attributet (i BFS-filsystemet) är något som gör att användaren kan göra ändringar efter eget val (även om,tips, det grafiska gränssnittet för att sätta en användarikon ovanpå standardikonen ännu inte är implementerat).

Kontroll av filsystemets attribut.

Med hjälp av resaddr möjligheten att kontrollera och ställa in filsystemets attribut.

/> 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 grunden handlar det om ett "klister" som utför omvandling fram och tillbaka mellan (pålitliga) resurser och (snabba) attribut hos filsystemet. Och eftersom systemet är utformat för att hämta resurser och automatiskt utföra kopiering, behöver jag inte längre oroa mig för detta.

Magin med hpkg-paket

För närvarande används paket oftast för att få program på Haiku .hpkg. Låt dig inte luras av det enkla namnet: .hpkg-formatet fungerar helt annorlunda än andra format med liknande namn som du kan ha stött på, det har verkliga superkrafter.

Med traditionella paketformat har jag länge varit frustrerad över den här faktorn: du laddar ner en (paket), men i systemet installeras något annat (filer inne i paketet). Det är ganska svårt att hantera filer (till exempel att ta bort dem) när en paketinstallation görs på det traditionella sättet. Anledningen till detta är att innehållet i paketet sprids ut över hela filsystemet, inklusive platser där en vanlig användare kanske inte har skrivåtkomst. Detta ger upphov till en helt ny klass av program — paketförvaltare. Att flytta redan installerad programvara, till exempel till en annan dator, extern enhet eller filserver, blir ännu svårare, om inte helt omöjligt. I ett vanligt Linux-baserat system kan det lätt finnas från flera hundratusen till miljontals separata filer. Självklart är detta samtidigt både skört och långsamt, till exempel vid den första installationen av systemet, vid installation, uppdatering och borttagning av vanliga paket, samt vid kopiering av en startpartition (rotpartition) till en annan lagringsenhet.

Jag arbetar på projektet AppImage, en delvis lösning för slutanvändarprogram. Det är ett distributionsformat för programvara som samlar applikationen och alla dess beroenden i en enda filsystemavbild, som monteras vid körning av applikationen. Det förenklar saker avsevärt, eftersom samma ImageMagick plötsligt blir en enda fil som hanteras i filhanteraren av vanliga dödliga. Det föreslagna sättet fungerar endast för programvara, som namnet på projektet återspeglar, och har också en egen uppsättning problem, eftersom människor som arbetar med att distribuera programvara för Linux alltid skyller på mig.

Låt oss återkomma till Haiku. Har vi lyckats hitta en optimal balans mellan traditionella paketbaserade system och programvaruleverans baserad på avbildningar? Dess paket .hpkg är i praktiken komprimerade avbildningar av filsystemet. Vid systemstart monterar kärnan alla installerade och aktiva paket med följande kärnmeddelanden:

KERN: package_daemon [16042853:   924] aktivt paket: "gawk-4.2.1-1-x86_64.hpkg"
KERN: package_daemon [16043023:   924] aktivt paket: "ca_root_certificates_java-2019_01_23-1-any.hpkg"
KERN: package_daemon [16043232:   924] aktivt paket: "python-2.7.16-3-x86_64.hpkg"
KERN: package_daemon [16043405:   924] aktivt paket: "openjdk12_default-12.0.1.12-1-x86_64.hpkg"
KERN: package_daemon [16043611:   924] aktivt paket: "llvm_libs-5.0.0-3-x86_64.hpkg"

Coolt, eller hur? Håll i er, det kommer att bli ännu bättre!

Det finns ett mycket speciellt paket:

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

Det innehåller ett ganska minimalistiskt operativsystem, inklusive kärnan. Trots att det låter otroligt, så extraheras inte ens kärnan från startvolymen (rotpartitionen) utan laddas noggrant på sin plats från paketet. .hpkg. Tänk på det! Jag har redan nämnt att, enligt mig, en del av den övergripande elegansen och enheten av Haiku beror på att hela systemet, från kärnan och det grundläggande användarutrymmet till paketförvaltningen och arbetsmiljöinfrastrukturen, utvecklas tillsammans av ett enda team. Tänk på hur många olika grupper och team som skulle behövas för att få något liknande att fungera baserat på Linux. [jag föreställer mig projektet PuppyLinux, — anm. översättaren]. Tänk sedan på hur lång tid det skulle ta att implementera detta till distros. Man säger ju: ta en enkel uppgift, fördela den mellan olika utförare, så blir den så komplicerad att den inte går att lösa längre. Haiku har i det här fallet öppnat mina ögon. Jag tror att det precis är vad som händer med Linux just nu (Linux är här en samlande term för Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu).

Systemåterställning med hpkg

Hur ofta uppstår följande situation: uppdateringen har genomförts utan problem, men sen visar det sig att något inte fungerar som det ska? När man använder vanliga paketshanterare är det svårt att återställa systemets tillstånd till tiden innan de nya paketen installerades (till exempel när något går fel). Vissa system erbjuder lösningar i form av avbilder av filsystemet, men de är ganska skrymmande och används långt ifrån i alla system. I Haiku löser vi detta med paket. .hpkg. Varje gång paket ändras i systemet tas inte gamla paket bort, utan de lagras i systemet i underkataloger av typen /Haiku/system/packages/administrative/state-<...>/ konstant. Ofullständiga operationer lagrar sina data i underkataloger /Haiku/system/packages/administrative/transaction-<...>/.

Innehåll /Haiku/system/packages/administrative. Katalogerna "state..." innehåller textfiler med namn på aktiva paket, "transaction..." — själva paketen.

"Gammalt aktivt tillstånd", dvs. listan .hpkg över paket som var aktiva innan ändringarna skrivs efter varje operation i filhanteraren i en textfil /Haiku/system/packages/administrative/state-<...>/activated-packages. På liknande sätt skrivs det nya "aktiva tillståndet" i en textfil /Haiku/system/packages/administrative/activated-packages.

Katalog /Haiku/system/packages/administrative/state-<...>/ innehåller endast en textfil med listan över aktiva paket i detta tillstånd (vid installation av paket utan borttagning), och om paket raderades eller uppdaterades, så innehåller state-katalogen gamla versioner av paketen.

Vid systemstart fattas beslut om aktivering (montering) av paket baserat på listan över paket. Så enkelt är det! Om något går fel vid uppstart kan man ange att bootloadern ska använda en annan, äldre lista. Problemet är löst!

Haikus bootloader. Varje inmatningspunkt representerar motsvarande "aktiva tillstånd".

Jag gillar tillvägagångssättet med enkla textfiler som lista över "aktiva tillstånd", där begripliga namn skrivs. .hpkgDetta står i skarp kontrast till den maskinskapade röran från OSTree eller Flatpak i filsystemet (i samma nivå som Microsoft GUID). Listan över aktiva paket för varje tidpunkt

Konfigurationsdata

Tycks finnas i katalogen

innehåller inställningsfiler för paketen, men tillgängliga för skrivning. Eftersom, som ni minns, /Haiku/system/packages/administrative/writable-files monteras endast för läsning. Därför måste dessa filer kopieras från paketen innan de skrivs. Det är meningsfullt. .hpkg GUI-integration för systemet .hpkg

GUI-integration för systemet .hpkg

Låt oss nu titta på hur dessa fantastiska paket .hpkg hanterar integrationen i användarens arbetsmiljö (UX). Haiku är ju avsett för personligt bruk, trots allt. Jag har ställt en hög standard genom att jämföra användarupplevelsen med paket .*.app på Macintosh med samma erfarenhet på .hpkg. Jag kommer inte ens att jämföra situationen med arbetsmiljöer på Linux, eftersom den är helt förfärlig i jämförelse med andra.

Följande scenarier kommer att tänka på:

• Jag vill se innehållet i paketet .hpkg
• Jag vill installera paketet
• Jag vill ta bort paketet
• Jag vill ta bort något som kom in i systemet som en del av paketet
• Jag vill kopiera något som kom in i systemet som en del av paketet
• Jag vill ladda ner alla beroenden för paketet som kanske inte ingår i varje Haiku-installation (till exempel har jag en fysiskt isolerad maskin utan internetåtkomst).
• Jag vill flytta mina paket (eller en del av dem) till en annan plats, skilt från startvolymen (roten) (eftersom jag till exempel har ont om utrymme där).

Detta borde täcka de flesta grundläggande fallen från mitt dagliga arbete. Nåväl, låt oss sätta igång.

Kontroll av paketets innehåll

På Mac högerklickar jag enkelt på paketet för att öppna det och se innehållet i Finder. För det är ju egentligen bara en maskerad katalog! (Jag vet att det finns paket .pkg för delar av systemet som inte är applikationer, men vanliga användare interagerar sällan med dem).

På Haiku högerklickar jag på paketet, sedan klickar jag på 'Innehåll' för att se vad som finns inuti. Men här är det bara en lista med filer utan möjlighet att öppna dem med dubbelklick.
Det skulle vara mycket bättre om det fanns ett sätt att (temporärt) montera paketet .hpkg för att se genom filhanteraren, utan att användaren behövde bekymra sig om implementationsdetaljer. (För övrigt, man kan öppna .hpkg paketet i Expander, som kan packa upp det precis som en vanlig arkivfil).

I gränssnittet HaikuDepot kan man se en lista med paketets filer, men det finns inget sätt att se innehållet, till exempel genom att dubbelklicka på README.md.

I denna kategori vinner Mac, men det borde inte vara särskilt svårt att lägga till den nödvändiga funktionaliteten i HaikuDepot.

Installera paketet via GUI

På Mac, de flesta diskavbilder .dmg innehåller paket .*.app. Vi öppnar diskavbilden med dubbelklick, och kopierar paketet, till exempel genom att dra det till /Applications Finder. För mig är det en självklarhet, men jag har hört att vissa nybörjare kan ha problem med det. Som standard "erbjuder" Apple en systemomfattande katalog /Applications (på NeXT var den nätverksbaserad, samt individuell), men man kan enkelt placera sina program på en filserver eller i underkatalogen $HOME/Applications, om det är vad du föredrar.

På Haiku, dubbelklicka på paketet, klicka sedan på "Installera", enklare än så blir det inte. Jag undrar vad som händer om paketet har beroenden som är tillgängliga i HaikuPorts, men som ännu inte är installerade. På Linux vet man faktiskt inte vad man ska göra i den situationen, men svaret är uppenbart — fråga användaren om de vill ladda ner och installera beroenden. Precis vad Haiku gör.

Jag laddade ner paketet 'sanity' manuellt och klickade på det, paketmanagern vet var den ska hämta dess beroenden (förutsatt att repositoryn redan är konfigurerad i systemet). Inte alla Linux-distributioner kan göra detta.

Ett annat sätt är att använda filhanteraren, det räcker med att dra .hpkg paketet antingen till /Haiku/system/packages (för systemomfattande installation, som standard), eller till /Haiku/home/config/packages (för individuell installation; inte tillgänglig vid dubbelklick — jag stör mig fortfarande på ordet "config" här, som för mig i detta sammanhang är en synonym till "inställningar"). Och konceptet för flera användare är inte ens tillgängligt för Haiku (kanske därför är allt så enkelt — jag vet inte, kanske skulle fleranvändarfunktioner komplicera saker för arbetsmiljön på en personlig dator).

I denna kategori vinner Haiku eftersom den kan hantera inte bara program utan även systemprogram.

Borttagning av paket från GUI

På Mac, man behöver bara dra applikationsikonen till papperskorgen, så är det klart. Lätt!

På Haiku, för det första, man måste hitta var paketet är installerat i systemet, eftersom man sällan installerar det där det borde (systemet gör allt). Oftast måste man leta i /Haiku/system/packages (vid systemomfattande installation som standard), eller i /Haiku/home/config/packages (jag har redan sagt att "config" är ett felaktigt namn?). Sedan drar man bara applikationen till papperskorgen, så är det klart.
Lätt! Ändå skulle jag inte säga det. Här är vad som faktiskt händer:

Så här blir det om du drar en applikation till papperskorgen från /Haiku/system/packages

Jag försökte bara flytta min gårdagens applikation "Hej, värld" på QtQuickApp till papperskorgen. Jag försökte inte flytta systemkatalogen, och eftersom alla paket installeras i systemkatalogen går det inte att ta bort paketet .hpkg utan att ändra "dess innehåll".. En vanlig användare skulle bli skrämd, trycka på knappen "Avbryt" som är standardinställd.

Förklarar mr. waddlesplash:

Detta meddelande är över 10 år gammalt. Det är troligt att vi behöver ställa in det så att varningen bara visas när själva paketet flyttas. Vanliga användare behöver inte göra så.

Okej, kanske jag ska göra detta med HaikuDepot? Jag dubbelklickar på paketet i /Haiku/system/packages, och hoppas att knappen "Avinstallera" dyker upp. Nej, det finns (bara) "Installera". "Avinstallera", var är du?

För skojs skull försökte jag se vad som händer om jag trycker på "Installera" för ett redan installerat paket. Det blir så här:

Det blir så här om du försöker installera ett redan installerat paket.

Därefter dyker detta upp:

Om du trycker på "Tillämpa ändringar" i föregående fönster blir det så här

Jag misstänker att detta är en programvarubugg, en länk till en ärende finns redan. [författaren har inte tillhandahållit en länk, — anm. översättaren]

Snabb lösning: Lägg till en knapp "Avinstallera" om paketet redan finns i /Haiku/system/packages, eller i /Haiku/home/config/packages.

När jag tittar på listan över paket som är installerade i HaikuDepot ser jag mitt paket i listan och kan ta bort det.

I denna kategori vinner Mac. Men jag kan föreställa mig att med rätt inställningar skulle användarupplevelsen på Haiku vara bättre än på Mac. (En av utvecklarna bedömde detta så här: "Mindre än en timme för att lägga till den angivna funktionen i HaikuDepot, om du vet lite C++", finns det frivilliga?)

Att ta bort något från paketet

Låt oss försöka ta bort applikationen istället för paketet .hpkg, varifrån den kom (jag tvivlar på att det finns någon skillnad för "vanliga dödliga").

På Mac, användaren arbetar faktiskt vanligtvis med filen .dmg, där applikationspaketet kommer ifrån .*.app. Vanligtvis samlas bilder .dmg i nedladdningskatalogen, medan paket kopieras av användaren till /Applications. Det finns en åsikt om att många användare själva inte vet vad de gör, denna hypotes bekräftas av en tidigare anställd på Apple. (En av de saker jag inte gillar med Mac. Å andra sidan, med AppImage finns det ingen skillnad mellan applikationen och paketet som den kom i. Drag ikonen till papperskorgen = det är allt. Lätt!)

På Haiku, det finns också en uppdelning mellan apps/ och packages/, så jag tvivlar på att det har blivit tydligare för användarna. Men vad händer om man drar en applikation från apps/ till papperskorgen:

Så här ser det ut när man försöker ta bort en applikation som tagits från filen .hpkg

Tekniskt sett är det korrekt (eftersom applikationen endast är placerad på en skrivskyddad filsystem till att börja med), men det är inte särskilt användbart för användaren.

Snabb lösning: istället erbjud en GUI-alternativ för att ta bort .hpkg

Som ett experiment försökte jag duplicera applikationen genom att trycka på Alt+D. Jag fick meddelandet "Det går inte att flytta eller kopiera objekt på en skrivskyddad volym". Och allt på grund av /system (utöver /system/packages och /system/settings) är en punkt för montering av packagefs (minns hur den visas i utdata från df?). К сожалению, вывод команды mount klargör inte situationen (som nämnts i en av tidigare artiklar), mountvolume visar inte det sökta (uppenbarligen räknas paket som monteras via loop .hpkg inte som "volymer"), och så glömde jag de alternativa kommandona.

Ingen har vunnit i denna kategori förutom AppImage (men det är, om vi ska vara helt ärliga, en partisk åsikt). Men man kan tänka sig att efter justeringar, kommer användarupplevelsen på Haiku vara bättre än på Mac.

Observera: det måste avgöras vad en "volym" innebär i förhållande till "partitionen". Sannolikt är det relaterat till förhållandet mellan "mapp" och "katalog": de flesta kataloger visas i filhanteraren som mappar, men inte alla av dem (till exempel paket, hanteras som filer). Gör sådana slutsatser mig officiellt till en nörd?

Att kopiera innehållet i ett paket till ett annat system

På Mac, jag drar bara paketet .*.app, och eftersom beroenden inuti paketet flyttas med.

På Haiku, drar jag applikationen, men beroenden hanteras överhuvudtaget inte.

Snabb lösning: Låt istället föreslås att dra paketet "`.hpkg helt och hållet, tillsammans med dess beroenden, om de finns.

I denna kategori vinner Mac utan tvekan. Åtminstone för mig, som älskar deras paradigm. På Haiku borde det kopieras .hpkg istället för appen, men systemet erbjuder mig inte ett sådant…

Nedladdning av paketet med alla dess beroenden

Inte varje maskin är ansluten till nätverket hela tiden. Tvärtom, vissa maskiner (ja, jag tittar på er, moderna Windows, Mac och Linux) glömmer bort det. För mig är det viktigt att jag kan gå till exempelvis ett internetcafé, ladda ner programvara på ett USB-minne, plugga in det i min hemmadator och vara säker på att allt kommer att fungera [riskabel kille, gör det här på Windows… — anm. översättaren].

Som ett resultat får jag lite oftare än vanligt olösta beroenden på Windows och Linux.

På Mac det är vanligtvis en fil, allt som behövs — ladda ner .dmg. Oftast har det inga beroenden, förutom de som tillhandahålls av MacOS som standard. Ett undantag kan vara komplicerade program som kräver en specifik körmiljö, till exempel Java.

På Haiku ladda ner paketet .hpkg för, låt oss säga, samma Java-applikation kan visa sig vara otillräckligt, eftersom Java kan finnas eller inte finnas på den målmaskinen. Finns det något sätt att ladda ner alla beroenden för detta paket .hpkg, förutom de som installeras i Haiku som standard och därför bör finnas i varje Haiku-system?

I den här kategorin vinner Mac med en liten marginal.

Kommenterar mr. waddlesplash:

För att skriva ett program som samlar alla beroenden av en applikation i form av en uppsättning paket .hpkg för någon som är bekant med Haikus interna struktur, räcker det med cirka 15 minuter. Att lägga till stöd för detta är inte så svårt om det finns ett verkligt behov. Men för mig är det en sällsynt situation.

Vi håller andan till nästa artikel i den här serien.

Flytta paket till en avskild plats

Som jag nämnde tidigare vill jag lägga mina paket .hpkg (ja, eller en del av dem) på en särskild plats, åtskild från den vanliga placeringen på startpartitionen (rotpartitionen). I vanliga fall (inte så teoretiskt) beror anledningen på att mitt (inbyggda) utrymme ständigt tar slut, oavsett hur stora de är. Jag kopplar ofta externa diskar eller nätverksresurser där mina program finns.

På Mac jag flyttar bara paketen .*.app till en extern enhet eller nätverkskatalog i Finder, och det är allt. Jag kan fortfarande öppna appen med dubbelklick som jag vanligtvis gjorde med startvolymen. Enkelt!

På Haiku, som jag fick veta, kan detta uppnås genom att flytta mina .hpkg paket till en extern enhet eller nätverkskatalog, men då måste man använda några icke-dokumenterade kommandon i terminalen för att montera dem i systemet. Jag vet inte hur jag gör det enbart med GUI.

Denna kategori vinner Mac.

Enligt mr. waddlesplash:

Här är optimeringen baserad på vanlig användning. Om efterfrågan skulle vara större än vad en användare kan hantera, så kommer vi att implementera det. I vilket fall som helst finns det möjlighet till tredjepartsimplementation.

Detta kommer vi att berätta mer om i nästa artikel.

När det kommer till nätverkskataloger: det skulle vara fantastiskt (jag förmodar LAN-partyn) att ha enkla, upptäckbara, nätverksapplikationer (till exempel via Zeroconf) som man kan kopiera till den lokala datorn eller köra direkt från det lokala nätverket. Självklart har utvecklarna möjlighet att avstå genom app_flags.

Slutrapport om systemintegration av hpkg med GUI

Jag tror att det främst beror på den relativa nyheten av integrationen .hpkg med GUI som fortfarande lämnar en del att önska. I vilket fall som helst finns det flera aspekter som kan förbättras när det gäller UX...

En annan sak: Kernel Debug Land

Det skulle vara fantastiskt att kunna skriva kommandon vid kernel panic, till exempel syslog | grep usb. Nåväl, på Haiku är detta möjligt tack vare Kernel Debug Land. Hur kan man se denna magi i aktion om allt fungerar som det ska utan att hamna i kernel panic? Enkelt, genom att trycka på Alt+PrintScn+D (mnemonik Debug). Jag tänker genast på Programmer’s Key, som tillät de ursprungliga utvecklarna av Macintosh att komma in i debuggern (om den var installerad, naturligtvis).

Slutsats

Jag börjar förstå att Haikus sofistikering kommer från att arbetet utförs av ett litet team med tydligt fokus på arbetsmiljö och tillgång till alla systemlag.
En skarp kontrast mot världen av Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu, där allt är splittrat i så små delar att abstraktionen står på abstraktion och klamrar sig fast med provisorier.
Det har också blivit tydligt hur systemet .hpkg kombinerar bästa praxis från traditionella paketförvaltare, Snappy, Flatpak, AppImage, till och med btrfs, och blandar dem med principen "bara fungerar" från Mac.

Som om något har "slått till" i huvudet och jag förstod hur systemet .hpkg kan återställas, - bara genom att titta på det. Men det är inte jag, utan systemets skönhet och enkelhet. Mycket här är genomdrängt av den ursprungliga Macens anda.

Ja, att bläddra genom sidor i webbläsaren kan vara hackigt och fungera långsamt, det kan saknas appar (det finns ingen Gtk, Electron - utvecklarna har dragit slutsatsen att de inte passar ihop med subtiliteten), videouppspelning och 3d kan helt saknas, men jag gillar ändå detta system. För dessa saker kan åtgärdas och de kommer förr eller senare att dyka upp. Det är bara en tidsfråga och, eventuellt, lite röda ögon.

Jag kan inte erbjuda hjälp, men jag tror att det här ögonblicket kommer att markera året Haiku på skrivbordet.

Slumpproblem

Finns det redan förfrågningar, eller ska jag öppna dem?

• BeScreenCapture bör ha möjlighet att exportera till GIF, precis som i Peek. Detta kan göras med hjälp av ffmpeg, som redan finns för Haiku. Förfrågan.
• Programmet för att ta skärmdumpar kan inte ta en bild av ett modalt fönster, utan tar istället en bild av hela skärmen.
• Det går inte att beskära skärmdumpar med beskärningsverktyget i WonderBrush och sedan spara resultatet i en fil.
• Jag gillar inte särskilt muspekaren i handform i Haiku, men jag tror att det är kopplat till varma nostalgiska känslor. Det är särskilt frustrerande när jag använder beskärningsverktyget i Krita, eftersom det ger en otillräcklig beskärning (se skärmdumpar med modala dialoger i den här artikeln). En korspekare skulle vara fantastisk. Förfrågan.

Prova själv! Eftersom Haiku-projektet tillhandahåller bilder för nedladdning från DVD eller USB, som skapas dagligen. För installationen räcker det med att ladda ner en bild och skriva den på ett USB-minne med hjälp av Etcher

Har du frågor? Välkommen till vår svenskspråkiga telegramkanal.

Felkod: Hur man skjuter sig själv i foten i C och C++. En samling recept för Haiku OS

Från författare översättning: detta är den sjätte artikeln i serien om Haiku.

Artikellista: Första Andra Tredje Fjärde Femte

Källa: habr.com