TL; DR: Haiku är ett operativsystem speciellt designat för PC, så det har flera knep som gör dess skrivbordsmiljö mycket bättre än andra. Men hur fungerar det?
Jag upptäckte Haiku, ett oväntat bra system. Jag är fortfarande förvånad över hur smidigt det går, särskilt jämfört med Linux-skrivbordsmiljöer. Idag ska jag ta en titt under huven. Där det är nödvändigt för en fördjupad förståelse kommer jag att göra jämförelser med de ursprungliga Macintosh-, Mac OS X- och Linux-skrivbordsmiljöerna (XDG-standard 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 verkligen fungerar.
Resurser? från , den ursprungliga författaren till Macintosh Finder och "fadern" till Macintosh Resource Manager:
Jag är orolig över den stela karaktären hos traditionell kodning. För mig är själva idén med en applikation frusen i kod, utan möjlighet att ändra något dynamiskt, den vildaste vildigheten. Det ska vara möjligt att ändra så mycket som möjligt under körning. Själva applikationskoden kan naturligtvis inte ändras, men visst kan något ändras utan att kompilera om koden?
På den ursprungliga Macintosh gjorde de att dessa filer hade en "datasektion" och en "resurssektion", vilket gjorde det otroligt enkelt att spara saker som ikoner, översättningar och liknande. i körbara filer.
På Mac används detta , ett grafiskt program för - plötsligt - att redigera resurser.
Redigera om på original Macintosh
Som ett resultat blev det möjligt att redigera ikoner, menyalternativ, översättningar etc. lätt nog, men de "resor" fortfarande med applikationerna.
Hur som helst hade detta tillvägagångssätt en stor nackdel: det fungerade bara på Apples filsystem, vilket var en av anledningarna till att Apple övergav "resurssektionen" när de flyttade till Mac OS X.
På Mac OS X ville Apple ha en filsystemoberoende lösning, så de antog konceptet med paket (från NeXT), kataloger som behandlas som "ogenomskinliga objekt" av filhanteraren, som filer snarare än kataloger. Alla paket med en applikation i formatet .app har bland annat en fil Info.plist (i någon sorts Apples motsvarighet till JSON eller YAML) som innehåller applikationsmetadata.
Nycklar för Info.plist-filen från Mac OS X-programpaketet.
Resurser, såsom ikoner, UI-filer och andra, lagras i paketet som filer. Konceptet gick faktiskt tillbaka till sina rötter i NeXT.
Mathematica.app på NeXTSTEP 1.0 1989: visas som en katalog med filer i terminalen, men som ett enda objekt i den grafiska filhanteraren.
Låt oss återvända till BeOS, de koncept som Haiku bygger på. Dess utvecklare, när de bytte från PEF (PowerPC) till ELF (x86) (samma som används på Linux), bestämde sig för att lägga till en resurssektion i slutet av ELF-filerna. Den använde inte sin egen rätta ELF-sektion, den lades helt enkelt till i slutet av ELF-filen. Som ett resultat av programmet strip och andra från Binutils, som inte är medvetna om detta, klippte helt enkelt av det. När du lägger till resurser till en ELF-fil på BeOS är det därför bättre att inte manipulera den med Linux-verktyg.
Vad händer med Haiku nu? I grund och botten, mer eller mindre samma.
I teorin skulle det vara möjligt att placera resurser i den önskade delen av ELF. Enligt utvecklarna på #haiku-kanalen på irc.freenode.net:
Med ELF skulle avsnittet vara mer vettigt... den enda anledningen till att vi inte gör det på det sättet är för att det är vad vi gjorde i BeOS."
Och det är ingen idé att ändra på detta nu.
Resurshantering
Resurser skrivs i ett strukturerat "resurs"-format: i huvudsak en lista över resurser med storlekar och sedan deras innehåll. jag kom ihåg .
Hur kontrollerar man resurser i Haiku? Finns det något liknande ResEdit?
Enligt :
För att se resurserna i applikationspaketet kan du dra den körbara filen till ett program som . Du kan också gå till terminalen och köra kommandot
listres имя_файла.
Resourcer är tillgänglig i HaikuDepot, men det bara kraschar för mig.
Hur hanterar man resurser i ELF-filer? Använder sig av rsrc и rdef. rdef filer samlas in rsrc. Fil rdef lagras i vanligt textformat, så det är mycket lättare att arbeta med. Filformat rsrc bifogas i slutet av ELF-filen. Låt oss försöka spela:
~> rc -h
Haiku Resource Compiler 1.1To compile an rdef script into a resource file:
rc [options] [-o <file>] <file>...To convert a resource file back into an rdef script:
rc [options] [-o <file>] -d <file>...Options:
-d --decompile create an rdef script from a resource file
--auto-names construct resource names from ID symbols
-h --help show this message
-I --include <dir> add <dir> to the list of include paths
-m --merge do not erase existing contents of output file
-o --output specify output file name, default is out.xxx
-q --quiet do not display any error messages
-V --version show software version and licenseDu kan använda programmet xres för kontroll och kontroll:
/> 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, låt oss försöka?
/> 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_VERSIONMer om resurser och format rdef du kan läsa .
Standardresurstyper
Även om du kan lägga vad som helst i resurser, finns det några definierade standardtyper:
app_signature: MIME-applikationstyp, för filöppningsmappning, start, IPC, etc.app_name_catalog_entry: Eftersom applikationsnamnet vanligtvis är på engelska kan du ange platserna där de översatta namnen finns, så att användare av olika språk kommer att se det översatta applikationsnamnet om så önskas.app_version: precis vad du troddeapp_flags: pekar påregistrarhur man behandlar ansökan. Jag tror att det finns mer i det än vad man ser. Det finns till exempelB_SINGLE_LAUNCH, vilket tvingar systemet att starta en ny applikationsprocess varje gång användaren begär det (samma princip används för de flesta applikationer på Linux). ÄtaB_MULTIPLE_LAUNCH, vilket gör att processen körs varje fil. Äntligen finns detB_EXCLUSIVE_LAUNCH, vilket tvingar systemet att bara starta en process åt gången, oavsett hur ofta användare startar den (det är till exempel så här Firefox körs på Linux; samma resultat kan uppnås i Qt-applikationer med funktionen ). Applikationer medB_EXCLUSIVE_LAUNCHaviseras när användaren försöker köra dem igen: till exempel får de sökvägen till filen som användaren vill öppna med sin hjälp.vector_icon: Vektorprogramikon (BeOS hade inga vektorikoner, de flesta program hade istället två rasterikoner i sina körbara filer).
Naturligtvis kan du lägga till resurser med valfri ID och typ, och sedan läsa dem i själva applikationen eller andra applikationer med hjälp av klassen BResources. Men först, låt oss titta på det fascinerande ämnet ikoner.
Vektor ikoner i Haiku stil
Naturligtvis valde inte bara Haiku det bästa ikonformatet; i den här delen är situationen med Linux-skrivbordsmiljöer långt ifrån idealisk:
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.cacheNär du tittar på detta kan du redan känna vilken bit det är.
Naturligtvis finns det skalbart, som innehåller, som ni förstår, vektorikoner. Varför finns det något annat då? Eftersom resultatet av att rita vektorgrafik i små storlekar kan vara mindre än idealiskt. Jag skulle vilja ha olika alternativ optimerade för olika storlekar. I Linux-skrivbordsmiljöer uppnås detta genom att sprida ikoner av olika storlekar i 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.pngObservera: det finns inget koncept för olika versioner av Firefox. Det är alltså inte möjligt att på ett elegant sätt hantera situationen att ha flera versioner av en applikation på systemet.
Olika Firefox-ikoner i olika versioner. Det är för närvarande omöjligt att hantera detta i Linux utan olika kryckor.
Mac OS X hanterar det lite mer subtilt:
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.icnsDet kan ses 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! Ikoner reser med applikationen, alla resurser finns i en fil.
Låt oss återvända till Haiku. En häpnadsväckande lösning, inga undantag. Enligt :
Ett speciellt HVIF-format, mycket optimerat för små storlekar och snabb rendering, utvecklades. Därför är våra ikoner för det mesta mycket mindre än i raster eller i det allmänt använda SVG-formatet.
Och de är fortfarande optimerade:
Ikonstorlekar i HVIF jämfört med andra format.
Skillnaden är en storleksordning!
Men magin slutar inte här. Samma HVIF kan visa olika detaljnivåer beroende på vilken storlek som visas, även om det är ett vektorformat.
Olika detaljnivåer (LOD) beroende på renderingsstorlek
Nu om nackdelarna: du kan inte ta SVG, kasta in det i ImageMagick och kalla det en dag; du måste gå igenom flera cykler för att skapa en ikon i HVIF-format. förklaringar. IconOMatic kan dock importera SVG ganska ofullständigt; cirka 90 % av SVG-detaljerna importeras med viss sannolikhet, de återstående 10 % måste konfigureras och ändras manuellt. Läs mer om hur HVIF gör sin magi i bloggen
Lägga till en ikon i programmet
Nu kan jag lägga till en ikon till det skapade paketet , med hänsyn till all mottagen information.
Tja, eftersom jag inte är särskilt sugen på att rita min egen ikon för min "Hello, World" QtQuickApp just nu, drar jag ut 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 CreatorLå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:ICONSer bra ut, men varför dyker den inte upp när den nya ikonen kopieras?
De kopierade VICN:101:BEOS:ICONs används ännu inte som en programikon i filhanteraren
Vad missade jag?
Utvecklarens kommentar:
Vi måste skapa en fil
rdefmed alla resurser, kör sedan kommandotrc имя.rdef, kommer detta att skapa filen.rsrc. Sedan måste du köra kommandotresattr -o имя_бинарника имя.rsrc. Som ett minimum använder jag kommandon som dessa för att lägga till ikoner till mina skript.
Tja, jag ville skapa en resurs, inte ett attribut. Jag är verkligen förvirrad.
Smart cachning med filsystemet
Det går långsamt att öppna och läsa ELF-attribut. Som jag skrev ovan är ikonen skriven som en resurs i själva filen. Denna metod är mer tillförlitlig och låter dig överleva kopiering till ett annat filsystem. Men det kopieras då också till filsystemattributet, till exempel BEOS:ICON. Detta fungerar bara på vissa filsystem, såsom BFS. Ikonerna som visas av systemet (i Tracker och Deskbar) läses från detta utökade attribut, eftersom denna lösning fungerar snabbt. På vissa ställen (där hastighet inte är viktig, till exempel ett typiskt "Om"-fönster), tar systemet emot ikonen direkt från resursen i filen. Men detta är inte slutet. Kom ihåg att på Mac kan användare ersätta ikoner för applikationer, kataloger, dokument med sina egna, eftersom det på Mac är möjligt att göra dessa "viktiga" saker, till exempel . På Haiku bör du tänka på resursen (i filen) som den ursprungliga ikonen som följer med applikationen, och attributet (i BFS-filsystemet) som något som låter användaren göra ändringar efter behag (även om, tips, GUI för att infoga en anpassad ikon ovanpå ikonen är valfritt). ännu inte implementerat som standard).
Kontrollera filsystemattribut
Med resaddr Det är möjligt att kontrollera och ställa in filsystemattribut.
/> 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.
(...)Det är i huvudsak "limmet" som utför konverteringen fram och tillbaka mellan (pålitliga) resurser och (snabba) filsystemattribut. Och eftersom systemet förväntar sig att ta emot resurser och kopierar automatiskt kommer jag inte att oroa mig för det längre.
Magin med hpkg-paket
För närvarande (oftast) används paket 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 du har stött på, det har riktiga superkrafter.
Med traditionella paketformat var jag upprörd länge på grund av detta faktum: du laddar ner en sak (paket), och en annan är installerad på systemet (filer inuti paketet). Det är ganska svårt att hantera filer (till exempel ta bort dem) när man installerar ett paket på traditionellt sätt. Och allt på grund av innehållet i förpackningen utspridda i filsystemet, inklusive platser där den genomsnittliga användaren kanske inte har skrivåtkomst. Detta ger upphov till en hel klass av program - pakethanterare. Men att överföra redan installerad programvara, till exempel, till en annan maskin, flyttbar disk eller filserver blir ännu svårare, för att inte säga helt omöjligt. På ett typiskt Linux-baserat system kan det lätt finnas flera hundra tusen till miljoner enskilda filer. Naturligtvis är detta både ömtåligt och långsamt, till exempel när man initialt installerar ett system, när man installerar, uppdaterar och avinstallerar vanliga paket och när man kopierar startvolymen (rotpartitionen) till ett annat medium.
Jag jobbar på AppImage-projektet, en partiell krycka för slutanvändarapplikationer. Detta är ett programvarudistributionsformat som samlar en applikation och alla dess beroenden i en enda filsystemsbild som monteras när applikationen startar. Förenklar saker och ting avsevärt, eftersom samma ImageMagick plötsligt förvandlas till en enda fil, som hanteras i en filhanterare av enbart dödliga. Den föreslagna metoden fungerar bara för mjukvara, vilket återspeglas i projektets namn, och har också sina egna problem, eftersom personer som är involverade i att leverera mjukvara för Linux alltid pekar med pilen mot mig.
Låt oss återvända till Haiku. Har det varit möjligt att hitta den optimala balansen mellan traditionella paketsystem och bildbaserad mjukvaruleverans? Hennes paket .hpkg faktiskt komprimerade filsystembilder. När systemet startar, monterar kärnan alla installerade och aktiva paket med ungefär följande kärnmeddelanden:
KERN: package_daemon [16042853: 924] active package: "gawk-4.2.1-1-x86_64.hpkg"
KERN: package_daemon [16043023: 924] active package: "ca_root_certificates_java-2019_01_23-1-any.hpkg"
KERN: package_daemon [16043232: 924] active package: "python-2.7.16-3-x86_64.hpkg"
KERN: package_daemon [16043405: 924] active package: "openjdk12_default-12.0.1.12-1-x86_64.hpkg"
KERN: package_daemon [16043611: 924] active package: "llvm_libs-5.0.0-3-x86_64.hpkg"Coolt, eller hur? Håll ut, det blir ännu coolare!
Det finns ett mycket speciellt paket:
KERN: package_daemon [16040020: 924] active package: "haiku-r1~beta1_hrev53242-1-x86_64.hpkg"Den innehåller ett mycket minimalistiskt operativsystem, inklusive kärnan. Tro det eller ej, inte ens själva kärnan tas bort från startvolymen (rotpartitionen), utan laddas försiktigt på sin plats från paketet .hpkg. Wow! Jag har redan nämnt att jag tror att en del av Haikus övergripande sofistikering och konsistens kommer från det faktum att hela systemet, från kärnan och kärnanvändarutrymmet till pakethantering och runtime-infrastruktur, utvecklas i samarbete av ett team. Föreställ dig hur många olika grupper och team det skulle ta för att köra något sånt här på Linux [Jag föreställer mig PuppyLinux-projektet - ca. översättare]. Föreställ dig sedan hur lång tid det kommer att ta för detta tillvägagångssätt att införas i distributioner. De säger: ta ett enkelt problem, dela upp det mellan olika utförare, så blir det så komplicerat att det inte längre går att lösa det. Haiku i det här fallet öppnade mina ögon. Jag tror att det är precis vad som händer på Linux nu (Linux är i det här fallet en samlingsbeteckning för Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu-stacken).
Systemåterställning med hpkg
Hur ofta inträffar följande situation: uppdateringen lyckades och sedan visar det sig att något inte fungerar som det ska? Om du använder konventionella pakethanterare är det svårt att återställa systemets tillstånd till en tidpunkt innan nya paket installerades (till exempel i händelse av att något gick fel). Vissa system erbjuder lösningar i form av ögonblicksbilder av filsystemet, men de är ganska besvärliga och används inte på alla system. Haiku löser detta med hjälp av paket .hpkg. Närhelst paket ändras i systemet, raderas inte de gamla paketen, utan lagras i systemet i underkataloger som /Haiku/system/packages/administrative/state-<...>/ ständigt. Oavslutade operationer lagrar sina data i underkataloger /Haiku/system/packages/administrative/transaction-<...>/.
Innehåll /Haiku/system/packages/administrative. Katalogen "tillstånd..." innehåller textfiler med namnen på aktiva paket, och "transaktions..."-katalogerna innehåller själva paketen.
"Gammalt aktivt tillstånd", d.v.s. lista .hpkg paket som är aktiva innan ändringar registreras efter varje operation i filhanteraren i en textfil /Haiku/system/packages/administrative/state-<...>/activated-packages. På liknande sätt skrivs ett nytt "aktivt tillstånd" i en textfil /Haiku/system/packages/administrative/activated-packages.
Katalog /Haiku/system/packages/administrative/state-<...>/ innehåller endast en textfil med en lista över aktiva paket av detta tillstånd (vid installation av paket utan borttagning), och om paket togs bort eller uppdaterades - tillståndskatalogen innehåller gamla versioner av paket.
När systemet startar, baserat på listan över paket, fattas ett beslut om att aktivera (montera) paket. Det är så enkelt! Om något går fel under nedladdningen kan du be nedladdningshanteraren att använda en annan, äldre lista. Problemet löst!
Ladda ner Haiku. Varje ingångspunkt visar ett motsvarande "aktivt tillstånd"
Jag gillar tillvägagångssättet att ha enkla textfiler som listan "aktivt tillstånd", med namn som är lätta att förstå .hpkg. Detta står i skarp kontrast till att vara byggd-för-maskiner-inte-för-människor. från OSTree eller Flatpak i filsystemet (i samma nivå som Microsoft GUID).
Lista över aktiva paket för varje tidpunkt
Konfigurationsdata
Tydligen i katalogen /Haiku/system/packages/administrative/writable-files innehåller konfigurationsfiler för paket, men de är skrivbara. När allt kommer omkring, som du minns, .hpkg monterad skrivskyddad. Så dessa filer måste kopieras från paketen innan du skriver. Har betydelsen.
GUI-integration för .hpkg-systemet
Låt oss nu se hur dessa glänsande påsar .hpkg klara av integration i användarens arbetsmiljö (UX). Trots allt är Haiku avsedd för personligt bruk, trots allt. Personligen sätter jag ribban högt när jag jämför användarupplevelse med paket .app på Macintosh med samma upplevelse på .hpkg. Jag kommer inte ens jämföra situationen med arbetsmiljöer på Linux, eftersom det är helt fruktansvärt jämfört med alla andra.
Följande scenarier kommer att tänka på:
- Jag vill se innehållet i ett paket
.hpkg - Jag vill installera ett paket
- Jag vill ta bort paketet
- Jag vill ta bort något som kom in i systemet som en del av ett paket
- Jag vill kopiera något som kom in i systemet som en del av ett paket
- Jag vill ladda ner alla beroenden för ett paket, som kanske inte är en del av varje Haiku-installation (till exempel har jag en fysiskt isolerad maskin utan internetåtkomst.)
- Jag vill flytta mina paket (eller delar av dem) separat till en annan plats, separat från startvolymen (rotpartitionen) (eftersom jag till exempel inte har tillräckligt med utrymme på den).
Detta bör täcka de flesta av de större fallen från mitt dagliga arbete. Nåväl, låt oss börja.
Kontrollera paketets innehåll
På Mac Jag högerklickar helt enkelt på paketet för att öppna det och se innehållet i Finder. När allt kommer omkring, i verkligheten är det bara en förklädd katalog! (Jag vet att det finns paket .pkg för en del av systemet som inte är applikationer, men vanliga användare oftast inte interagerar med dem).
På Haiku Jag högerklickar på paketet och klickar sedan på "Innehåll" för att se vad som finns inuti. Men här är bara en lista över filer utan möjlighet att öppna dem genom att dubbelklicka.
Det skulle vara mycket bättre om det fanns ett sätt att (tillfälligt) montera paketet .hpkg att ses via en filhanterare, och användaren skulle inte behöva oroa sig för implementeringsdetaljer. (Du kan förresten öppna .hpkg packa in Expander, som kan packa upp det som vilket annat arkiv som helst).
HaikuDepots gränssnitt låter dig se en lista med paketfiler, men det finns inget sätt att se innehållet genom att till exempel dubbelklicka på README.md
Mac vinner i denna kategori, men att lägga till HaikuDepot-funktionaliteten du vill ha borde inte vara alltför svårt.
Installera ett paket via GUI
På Mac, de flesta diskbilder .dmg innehålla paket .app. Dubbelklicka på diskavbildningen och kopiera sedan paketet, till exempel genom att dra in det /Applications i Finder. Detta säger sig självt för mig, men jag har hört att vissa nybörjare kanske inte kan hantera detta. Som standard "föreslår" Apple en systemomfattande katalog /Applications (på NeXT var det nätverksanslutet såväl som individuellt), men du kan enkelt lägga dina applikationer på en filserver eller i en underkatalog $HOME/Applications, om du gillar det så.
På Haiku, dubbelklicka på paketet och klicka sedan på "Installera", det kunde inte vara enklare. Jag undrar vad som händer om ett paket har beroenden som är tillgängliga i HaikuPorts men som ännu inte är installerade. På Linux vet de verkligen inte vad de ska göra i den här situationen, men lösningen är uppenbar - fråga användaren om de behöver ladda ner och installera beroenden. Precis vad Haiku gör.
Jag laddade ner "sanity"-paketet manuellt och klickade på det, pakethanteraren vet var de kan hämta sina beroenden ifrån (förutsatt att förråden redan är registrerade i systemet). Inte varje Linux-distribution kan göra detta.
Ett annat sätt är att använda en filhanterare, bara dra och släpp .hpkg paket eller i /Haiku/system/packages (för en systemomfattande installation, som standard), eller i /Haiku/home/config/packages (för individuell installation; inte tillgängligt vid dubbelklickning - jag irriterar mig fortfarande på ordet "config" på denna plats, vilket för mig i det här fallet är synonymt med "inställningar"). Och konceptet med flera användare är inte ens tillgängligt för Haiku än (det är förmodligen därför det är så enkelt - jag vet inte, kanske kommer fleranvändarfunktioner att komplicera saker och ting i onödan för en skrivbordsmiljö).
Haiku vinner i den här kategorin eftersom den inte bara kan fungera med applikationer utan även med systemprogram.
Ta bort ett paket från GUI
På Mac, måste du dra programikonen till papperskorgen, och det är allt. Lätt!
På Haiku, för det första måste du hitta var paketet finns på systemet, eftersom du sällan installerar det på rätt plats (systemet gör allt). Oftast behöver man titta in /Haiku/system/packages (med en systemomfattande standardinstallation), eller i /Haiku/home/config/packages (Nämnde jag att "config" är en felaktig benämning?). Sedan dras programmet helt enkelt till papperskorgen, och det är allt.
Lätt! Jag skulle dock inte säga det. Här är vad som verkligen händer:
Detta är vad som händer om du drar ett program till papperskorgen från /Haiku/system/packages
Försökte precis flytta min gårdagens "Hello World"-applikation på QtQuickApp till papperskorgen. Jag försökte inte flytta systemkatalogen, och eftersom alla paket är installerade i systemkatalogen är det omöjligt att ta bort paketet .hpkg utan förändring "dess innehåll". En vanlig användare skulle bli rädd och trycka på knappen "Avbryt" som tilldelas som standard.
Förklarar :
Det här inlägget är över 10 år gammalt. Troligtvis måste vi konfigurera det så att varningen endast visas när själva paketet flyttas. Vanliga användare behöver inte göra detta ändå.
Okej, jag kanske borde göra det här med HaikuDepot? Jag dubbelklickar på paketet i /Haiku/system/packages, väntar på att knappen "Avinstallera" ska visas. Nej, det finns (endast) "Installera". "Avinstallera", var är du?
Bara för skojs skull försökte jag se vad som skulle hända om jag klickade på "Installera" på ett redan installerat paket. Det blir så här:
Detta händer om du försöker installera ett redan installerat paket.
Nästa visas:
Om du klickar på "Använd ändringar" i föregående fönster kommer det att se ut så här
Jag antar att detta är ett programvarufel; länken till applikationen finns redan där. [författaren gav ingen länk - ca. översättare]
Snabb lösning: Lägg till en "Avinstallera"-knapp om paketet redan finns i
/Haiku/system/packages, eller i/Haiku/home/config/packages.
När jag visar listan över paket installerade i HaikuDepot ser jag mitt paket i listan och kan ta bort det.
Mac vinner i denna kategori. Men jag kan föreställa mig att med rätt inställning kommer användarupplevelsen på Haiku att bli bättre än på Mac. (En av utvecklarna betygsatte det så här: "Mindre än en timme att lägga till den angivna funktionen till HaikuDepot, om du kan lite C++", några frivilliga?)
Ta bort något från ett paket
Låt oss försöka ta bort själva applikationen, inte paketet .hpkg, varifrån det kom (jag tvivlar på att det för "bara dödliga" är någon skillnad).
På Mac, brukar användaren faktiskt arbeta med filen .dmgvar kommer applikationspaketet ifrån .app. Oftast bilder .dmg ackumuleras i nedladdningskatalogen och paket kopieras av användaren till /Applications. Man tror att många användare själva inte vet vad de gör, denna hypotes bekräftas av en tidigare Apple-anställd. (En av de saker jag inte gillar på Mac. Och till exempel med AppImage är det ingen skillnad mellan applikationen och paketet den var i. Dra ikonen till papperskorgen = det är det. Enkelt!)
På Haiku, det finns också en uppdelning mellan apps/ и packages/, så jag tvivlar på att detta gjorde det tydligare för användarna. Men vad händer om du drar en applikation från apps/ Lägg till i kundvagn:
Detta är vad som händer när du försöker ta bort ett program som tagits från en fil .hpkg
Tekniskt sett är det korrekt (till att börja med är applikationen värd på ett skrivskyddat filsystem), men det är inte särskilt användbart för användaren.
Snabb lösning: föreslå att du använder GUI för att ta bort istället
.hpkg
Bara för skojs skull försökte jag duplicera programmet genom att trycka på Alt+D. Jag fick meddelandet "Det går inte att flytta eller kopiera objekt på en skrivskyddad volym." Och allt för att /system (Förutom /system/packages и /system/settings) är packagefs monteringspunkt (kom ihåg hur det visas i utdata df?). Tyvärr, resultatet av kommandot mount klargör inte situationen (som sades i en av de tidigare artiklarna), mountvolume visar inte vad du letar efter (uppenbarligen paket monterade via loop .hpkg anses inte vara "volymer"), och jag glömde också de alternativa kommandona.
Ingen vann i den här kategorin förutom AppImage (men detta är, för att vara helt ärlig, en partisk åsikt). Man kan dock föreställa sig att efter tweaking kommer användarupplevelsen på Haiku att bli bättre än på Mac.
Notera: du måste ta reda på vad en "volym" är i förhållande till en "sektion". Detta är förmodligen liknande förhållandet mellan "mapp" och "katalog": de flesta kataloger visas som mappar i filhanteraren, men inte alla (paket behandlas som filer, till exempel). Gör den här typen av visning mig till en officiell nörd?
Kopiera innehållet i ett paket till ett annat system
På Mac, jag drar dumt paketet .app, och eftersom beroenden finns inuti paketet flyttar de ihop sig.
På Haiku, jag drar applikationen, men beroenden bearbetas inte alls.
Snabb lösning: Låt oss istället föreslå att du drar hela `.hpkg-paketet, tillsammans med eventuella beroenden.
Mac vinner klart i denna kategori. Åtminstone för mig, en älskare av deras paradigm. Jag borde kopiera den till Haiku .hpkg istället för en applikation, men systemet erbjuder mig inte detta...
Ladda ner ett paket med alla dess beroenden
Alla maskiner är inte anslutna till nätverket hela tiden. Tvärtom, vissa maskiner (ja, jag tittar på dig, moderna Windows, Mac och Linux) glömmer detta. Det är viktigt för mig att jag till exempel kan gå till ett internetcafé, ladda ner mjukvara till en flyttbar enhet, sätta in den här enheten i min hemdator och vara säker på att allt kommer att fungera [riskig kille, gör detta på Windows... - cirka. översättare].
Som ett resultat tenderar jag att sluta med ouppfyllda beroenden på Windows och Linux lite oftare än vanligt.
På Mac detta är vanligtvis en fil, allt du behöver göra är att ladda ner .dmg. Oftast har den inga andra beroenden än de som tillhandahålls av MacOS självt som standard. Ett undantag är komplexa applikationer som kräver en lämplig exekveringsmiljö, till exempel java.
På Haiku ladda ner paket .hpkg för, säg, samma applikation i java kanske inte räcker, eftersom java kanske finns på målmaskinen eller inte. Finns det något sätt att ladda ner alla beroenden för ett givet paket .hpkg, andra än de som är installerade som standard i Haiku och därför borde finnas på alla Haiku-system?
Mac vinner denna kategori med liten marginal.
Kommentarer Mr. waddlesplash:
Att skriva ett program för att samla alla beroenden för en applikation som en uppsättning paket
.hpkgför någon som är bekant med Haikus inre funktioner räcker cirka 15 minuter. Att lägga till stöd för detta är inte så svårt om det finns ett verkligt behov av det. Men för mig är detta en sällsynt situation.
Låt oss hålla andan tills nästa artikel i den här serien.
Flytta paket till en separat plats
Som jag skrev tidigare så vill jag lägga ut mina paket .hpkg (tja, eller en del av dem) till en speciell plats, skild från den vanliga placeringen på startvolymen (rotpartitionen). I det vanliga (inte så teoretiska) fallet är anledningen till detta att jag ständigt får ont om ledigt utrymme på mina (inbyggda) diskar, oavsett hur stora de är. Och jag brukar ansluta externa enheter eller nätverksresurser där mina applikationer finns.
På Mac Jag ska bara flytta paket .app till en flyttbar enhet eller nätverkskatalog i Finder, och det är allt. Jag kan fortfarande dubbelklicka för att öppna programmet som jag normalt skulle göra från startvolymen. Bara!
På Haiku, som jag fick höra, kan detta uppnås genom att flytta min .hpkg paket till en flyttbar enhet eller nätverkskatalog, men då måste du använda några odokumenterade kommandon i konsolen för att montera dem på systemet. Jag vet inte hur man gör detta med enbart GUI.
Mac vinner i denna kategori.
Enligt mr. waddlesplash:
Detta är en optimering baserad på normal användning. Om det finns efterfrågan från mer än en användare kommer vi att implementera det. Det finns i alla fall möjlighet till tredjepartsimplementering.
Vi kommer att prata om detta i nästa artikel.
På tal om nätverkskataloger skulle det vara bra (jag gissar på LAN-parter) att ha enkla, upptäckbara, nätverksomfattande applikationer (som Zeroconf) som kan kopieras till den lokala datorn eller köras direkt från det lokala nätverket. Självklart har utvecklare möjlighet att välja bort via app_flags.
Slutrapport om integrationen av hpkg-systemet med GUI
Jag tror att det främst beror på integrationens relativa nyhet .hpkg GUI lämnar fortfarande mycket övrigt att önska. Hur som helst, det finns några saker som kan förbättras när det gäller UX...
En sak till: Kernel Debug Land
Det skulle vara bra att kunna ange kommandon under kärnpanik, till exempel syslog | grep usb. Tja, på Haiku är det möjligt tack vare Kernel Debug Land. Hur kan du se denna magi i aktion om allt fungerar som det ska utan att hamna i kärnpanik? Enkelt genom att trycka Alt+PrintScn+D (Debug mnemonic). Jag minns genast , som tillät de ursprungliga Macintosh-utvecklarna att gå in i felsökaren (om en sådan var installerad, förstås).
Slutsats
Jag börjar förstå att det sofistikerade i Haiku-systemet kommer från det faktum att arbetet utförs av ett litet team med tydligt fokus på arbetsmiljön, med alla lager i systemet tillgängliga.
En skarp kontrast mot världen av Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu, där allt är sönderdelat i småbitar i en sådan utsträckning att abstraktionen sitter på abstraktionen och driver med kryckor.
Det fanns också en förståelse för hur systemet .hpkg kombinerar de bästa tillvägagångssätten från traditionella pakethanterare, Snappy, Flatpak, AppImage, till och med btrfs, och blandar dem med Mac:s "bara funkar"-metod.
Det var som om något "växlade" i mitt huvud, och jag förstod hur systemet .hpkg vet hur man rullar iväg, bara genom att titta på henne. Men det är inte jag, utan systemets skönhet och enkelhet. Mycket av detta är inspirerat av andan i den ursprungliga Macen.
Ja, surfandet i webbläsaren kan vara ryckigt och köras som en snigel, applikationer kan saknas (ingen Gtk, Electron - utvecklarna har kommit fram till att de inte går bra med sofistikering), video och 3d-acceleration kan vara helt frånvarande, men jag gillar fortfarande det här systemet. Dessa saker kan trots allt korrigeras och de kommer att dyka upp förr eller senare. Det är bara en tidsfråga och kanske lite röda ögon.
Jag kan inte erbjuda hjälp, men jag tror att det börjar från och med nu år av Haiku på skrivbordet.
Slumpmässiga problem
Kanske finns det redan förfrågningar, eller ska jag öppna dem?
- BeScreenCapture borde kunna exportera till GIF som Peek. Detta kan göras med hjälp av ffmpeg, som redan finns tillgängligt för Haiku. .
- Skärmdumpsprogramvaran lyckas inte fånga ett modalt fönster, istället fångar hela skärmen
- Du kan inte beskära skärmdumpar med WonderBrushs beskärningsverktyg och sedan spara resultatet till en fil
- Jag gillar inte speciellt handmarkören i Haiku, men jag tror att det har med den varma nostalgiska känslan att göra. Detta är särskilt irriterande när du använder beskärningsverktyget i Krita, eftersom det resulterar i felaktig beskärning (se skärmdumpar av modala dialoger i den här artikeln). En hårkorsmarkör skulle vara underbart. .
Prova själv! När allt kommer omkring ger Haiku-projektet bilder för uppstart från DVD eller USB, genererade . För att installera, ladda bara ner bilden och skriv den till en flashenhet med hjälp av
Har du några frågor? Vi inbjuder dig till den rysktalande .
Felöversikt:
Från översättning: detta är den sjätte artikeln i serien om Haiku.
Lista över artiklar:
Källa: will.com