🥇Något mer: applikationspaket för Haiku?

TL;DR: kan Haiku få ordentligt stöd för apppaket, till exempel applikationskataloger (som .*.app i Mac) och/eller applikationsavbilder (Linux AppImage)? Jag tror att det skulle vara ett värdefullt tillägg som är lättare att implementera än i andra system, eftersom merparten av infrastrukturen redan finns.

För en vecka sedan upptäckte jag Haiku, ett oväntat bra system. Och eftersom jag länge har varit intresserad av kataloger och avbilder för appar (inspirerad av enkelheten hos Macintosh), är det inte konstigt att jag kom att tänka på en idé...

För full förståelse: jag är skaparen och författaren av AppImage, ett format för distribution av Linux-appar som fokuserar på Mac-enkelhet och ger full kontroll till appförfattare och slutanvändare (vill du veta mer - se. wiki och dokumentationen).

Vad händer om vi gör AppImage för Haiku?

Låt oss tänka lite, rent teoretiskt: vad behövs för att få AppImage, eller något liknande, på Haiku? Det är inte nödvändigt att skapa något just nu, eftersom systemet som redan finns i Haiku fungerar otroligt bra, men den föreställda experimentet skulle vara intressant. Det skulle också visa på finheten i Haiku, i kontrast till Linux-skrivbordsmiljöer där sådana saker är fruktansvärt svåra (jag har rätt att säga så: jag har kämpat med det i 10 år).

På Macintosh System 1 var varje applikation enskilda filer, 'hanterade' i Finder. Med AppImage försöker jag återskapa den samma användarupplevelsen på Linux.

Först och främst, vad är AppImage? Det är ett system för att publicera applikationer från tredjepartsutvecklare (till exempel, Ultimaker Cura), vilket gör att applikationer kan släppas när och hur de vill: de behöver inte känna till olika distributions specifikationer, byggpolicyer eller bygginfrastruktur, de behöver inte stödja uppdateringar och de säger inte till användarna vad som (inte) kan installeras på deras datorer. Tänk på AppImage som något liknande ett paket för Mac i formatet .*.app inuti diskläget .dmg. Den största skillnaden är att applikationerna inte kopieras, utan förblir inuti AppImage permanent, ungefär som Haiku-paketen .hpkg monteras, och installeras aldrig i den vanliga bemärkelsen.

AppImage har under sina mer än 10 år av existens blivit ganska attraktiv och populär: Linus Torvalds har offentligt godkänt den, och populära projekt (som LibreOffice, Krita, Inkscape, Scribus, ImageMagick) har anammat den som sitt huvudsakliga sätt att distribuera kontinuerliga eller nattliga byggen utan att störa användarnas installerade eller icke-installerade program. Dock tenderar arbetsmiljöer och Linux-distributioner ofta att hålla fast vid den traditionella, centraliserade distributionsmodellen baserad på följande och/eller främjar sina egna företags- och/eller ingenjörsprogram baserade på Flatpak (RedHat, Fedora, GNOME) och Snappy (Canonical, Ubuntu). Det blir snart löjligt.

Hur allt fungerar

Varje AppImage innehåller 2 delar: en liten körbar ELF-fil som kan köras genom dubbelklick (kallad runtime.c), följt av en filsystemavbildning SquashFS.

SquashFS-filsystemet innehåller nyttolasten i form av applikationen och allt som behövs för att köra den, vilket inte rimligt kan betraktas som en del av standardinstallationen för varje någorlunda ny målsystem (Linux-distribution). Den innehåller också metadata, till exempel applikationsnamn, ikoner, MIME-typer och så vidare.

Vid körning använder runtime FUSE och squashfuse för att montera filsystemet, varefter det hanterar körningen av en viss ingångspunkt (så kallad AppRun) inuti den monterade AppImage.
Filsystemet avmonteras efter att processen har avslutats.

Det verkar alla är enkla.

Men dessa saker gör allt mer komplicerat:

Med en så stor variation av Linux-distributioner kan inget "i sunt förnuft" kallas "del av standardinstallationen för varje ny målsystem". Vi kringgår detta problem genom att skapa en excludelist, som möjliggör att definiera vad som ska packas in i AppImage och vad som behöver hämtas någon annanstans. Ibland missar vi dock målet, trots att allt fungerar utmärkt. Av den anledningen rekommenderar vi paketproducenter att testa AppImages på alla målsystem (distributioner).
Applikationer när det gäller utrymmesnyttja bör vara flyttbara i filsystemet. Tyvärr har många applikationer hårdkodade absoluta sökvägar till resurser i /usr/share. Det måste åtgärdas på något sätt. Utöver detta måste antingen exportera LD_LIBRARY_PATH, eller fixa rpath så att bootloadern kan hitta de relaterade biblioteken. Den första metoden har sina nackdelar (som hanteras med komplicerade metoder), medan den andra är helt enkelt otymplig.
Den största UX-fällan för användare är att de måste ange exekveringsbit för AppImage-filen efter nedladdning. Vill du tro det eller ej, men för vissa är det en verklig barriär. Kravet på att ange exekveringsbiten är otympligt även för erfarna användare. Som en workaround har vi föreslagit att installera en liten tjänst som håller reda på AppImage-filer och sätter exekveringsbiten. I ren form är det inte den bästa lösningen, eftersom det inte fungerar "ur lådan". Linux-distributioner levererar inte denna tjänst, så användarna har det "ur lådan" dåligt.
Linux-användare förväntar sig att det nya programmet ska ha en ikon i startmenyn. Man kan inte säga till systemet: "Titta, där är det nya programmet, kör det". Istället, enligt XDG-specifikationen, måste man kopiera filen .desktop till rätt plats i /usr för systeminstallation, eller i $HOME för individuell installation. Ikoner av specifika storlekar, enligt XDG-specifikationen, behöver placeras på specifika ställen i usr eller $HOME, varefter man måste köra kommandon i arbetsmiljön för att uppdatera ikonkatalogen, eller hoppas att skrivbordsmiljöförvaltaren förstår och automatiskt upptäcker allt. På samma sätt med MIME-typer. Som en workaround föreslås att använda samma tjänst som förutom att ställa in exekveringsbiten kommer att kopiera ikoner och annat från AppImage till rätt platser enligt XDG. Vid borttagning eller flytt förväntas tjänsten städa upp allt. Självklart finns det skillnader i beteende mellan olika skrivbordsmiljöer, i format för grafiska filer, deras storlekar, lagringsplatser och sätt att uppdatera kataloger, vilket skapar problem. Kort sagt, den här metoden är en nödlösning.
Om inget av ovanstående är tillräckligt, så finns det inte ens en AppImage-ikon i filhanteraren. I Linuxvärlden har man fortfarande inte kommit fram till en lösning för att införa elficon (trots att det har varit en diskussion och om implementering)), vilket gör det omöjligt att lägga in ikonen direkt i applikationen. Således har applikationerna i filhanteraren inga egna ikoner (oavsett om det är AppImage eller något annat), de finns endast i startmenyn. Som en lösning använder vi miniatyrer — en mekanism som ursprungligen utvecklades för att skrivbordshanterare skulle kunna visa miniatyrbilder för en förhandsvisning av grafiska filer som deras ikoner. Därmed fungerar tjänsten för att sätta exekverbars rättigheter också som en „miniatyrskapare“, som skapar och sparar miniatyrer av ikoner på rätt platser. /usr och $HOME. Dessutom utför denna tjänst städning om AppImage tas bort eller flyttas. Eftersom varje skrivbordshanterare beter sig något olika, till exempel i vilka format de accepterar ikoner, i vilka storlekar eller platser, är detta verkligen besvärligt.
Applikationen kraschar bara vid exekvering om det uppstår fel (till exempel finns det ett bibliotek som inte är en del av det grundläggande systemet och inte levereras i AppImage), och ingen informerar användaren i GUI:et om vad som egentligen händer. Vi har börjat kringgå detta genom att använda meddelanden på skrivbordet, vilket innebär att vi behöver fånga upp fel från kommandoraden, omvandla dem till användarvänliga meddelanden som sedan måste visas på skrivbordet. Och naturligtvis hanterar varje arbetsmiljö dem lite annorlunda.
För närvarande (september 2019, — anm. övers. ) har jag inte hittat ett enkelt sätt att säga till systemet att filen 1.png ska öppnas med Krita, och 2.png — med GIMP.

Platsen för lagring av cross-desktop specifikationer som används i GNOME, KDE och Xfce är freedesktop.org

Att uppnå en nivå av förfining som är djupt intrasslad i arbetsmiljön Haiku är försvårat, om inte omöjligt, på grund av specifikationerna XDG från freedesktop.org för cross-desktop, samt implementationerna av skrivbordshanterare baserade på dessa specifikationer. Som exempel kan vi nämna en allmän ikon för Firefox: tydligen har inte XDG:s skapare ens tänkt på att användaren kan ha flera versioner av samma applikation installerad.

Ikoner för olika versioner av Firefox

Jag var nyfiken på vad världen av Linux skulle kunna lära sig av Mac OS X, för att undvika misslyckanden vid systemintegration. Om du har tid och arbetar med sådant – läs absolut vad Arno Gourdol, en av de första ingenjörerna bakom Mac OS X, hade att säga:

Vi ville att installationen av en applikation skulle vara lika enkel som att dra och släppa applikationsikonen från någonstans (server, extern enhet) till din dators hårddisk. För detta så sparas all information i applikationspaketet, inklusive ikoner, version, bearbetad filtyp, och typ av URL-schema som systemet behöver veta för att kunna hantera applikationen. Detta inkluderar även information för 'centraliserad lagring' i databasen Icon Services och Launch Services. För att stödja applikationens prestanda så 'upptäckts' den på flera 'välkända' platser: i systemkatalogen och användarkatalogen Applications, samt på några andra ställen automatiskt, om användaren navigerar i Finder till katalogen som innehåller applikationen. I praktiken har detta fungerat mycket bra.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 session 144 – Mac OS X: paketering av applikationer och utskrift av dokument.

Det finns inget liknande i denna infrastruktur för Linux arbetsmiljöer, så vi letar efter lösningar för de strukturella begränsningarna i AppImage-projektet.

Skynda Haiku till hjälp?

Och dessutom: plattformar av Linux som grund för arbetsmiljöer är oftast så underdefinierade att många saker som är ganska enkla i ett konsekvent system med fullständig stack, frustrerar med sin fragmentering och komplexitet i Linux. Jag ägnade en hel presentation åt frågorna kring Linux-plattformar för arbetsmiljöer (kunniga utvecklare bekräftade: det kommer att förbli så väldigt länge framöver).

Mitt föredrag om problem med Linux arbetsmiljöer 2018

Även Linus Torvalds erkände att det var på grund av fragmenteringen som idén om arbetsmiljöer misslyckades.

Det är trevligt att se Haiku!

Med Haiku blir allt fantastiskt enkelt

Även om den naiva metoden att "överföra" AppImage till Haiku handlar om att enkelt försöka bygga (främst runtime.c och tjänsten) dess komponenter (vilket kanske till och med är möjligt!), kommer det inte att ge mycket nytta för Haiku. Eftersom de flesta av dessa problem faktiskt har lösts i Haiku och är konceptuellt grundade. Haiku tillhandahåller just de byggstenar för systeminfrastrukturen som jag länge har sökt i arbetsmiljöer på Linux och inte kunnat tro att de inte fanns där. Nämligen:

Tro det eller ej, men detta är något som många Linux-användare inte kan övervinna. På Haiku görs allt automagiskt!

ELF-filer utan exekveringsbit får det automatiskt vid dubbelklick i filhanteraren.
Applikationer kan ha inbyggda resurser, till exempel ikoner, som visas i filhanteraren. Det behövs ingen kopiering av massor av bilder till speciella kataloger med ikoner, och därför behöver man inte städa upp dem efter borttagning eller flytt av applikationen.
Det finns en databas för att koppla applikationer med dokument, det behövs ingen kopiering av filer för detta.
Bland mappen lib/ letas bibliotek per standard vid sidan av den exekverbara filen.
Det finns inte många distributioner och skrivbordsmiljöer, allt som fungerar – fungerar överallt.
Det finns ingen separat modul för körning, som skiljer sig från katalogen Applications.
Applikationerna har inga inbyggda absoluta sökvägar till sina resurser, det finns speciella funktioner för att bestämma plats under exekvering.
Idén med komprimerade filsystembilder har införlivats: det är varje pakethpkg. Alla monteras av kärnan.
Varje fil öppnas av den applikation som skapade den, om inget annat uttryckligen anges. Vad häftigt det är!

Två png-filer. Observera de olika ikonerna som visar att de kommer att öppnas av olika applikationer vid dubbelklick. Observera också rullgardinsmenyn "Öppna med:", där användaren kan välja en specifik applikation. Så enkelt!

Det verkar som att många av de lösningar och genvägar som AppImage behöver på Linux blir onödiga på Haiku, som har enkelhet och sofistikering i sin grund och därför klarar av de flesta av våra behov.

Behöver Haiku applikationspaket, till slut?

Det leder till en stor fråga. Om det skulle vara betydligt enklare att skapa ett system liknande AppImage på Haiku än på Linux, borde man då satsa på det? Eller har Haiku med sitt paketssystem hpkg i praktiken eliminerat behovet av att utveckla en sådan idé? För att svara på detta behöver vi se på motivationen bakom existensen av AppImages.

En användares perspektiv

Låt oss titta på vår slutanvändare:

Jag vill installera ett program utan att behöva ange administratörslösenord (root). På Haiku finns inget begrepp för en administratör; användaren har full kontroll eftersom det är ett personligt system! (Man kan i princip tänka sig detta i en fleranvändarmiljö; jag hoppas att utvecklarna bevarar enkelheten)
Jag vill få de senaste och bästa versionerna av program, utan att vänta på att de dyker upp i min distribution (ofta betyder det "aldrig", åtminstone om man inte uppdaterar hela operativsystemet). På Haiku är detta "lösta" genom så kallade flytande utgåvor. Det innebär att det finns möjlighet att få senaste och bästa versioner av program, men för detta krävs ständiga uppdateringar av resten av systemet, vilket i praktiken gör det till ett "rörligt mål"..
Jag vill ha flera versioner av samma program bredvid varandra, eftersom man aldrig vet vad som kan ha gått fel i den senaste versionen, eller, som webbutvecklare, behöver jag testa mitt arbete med olika versioner av webbläsare. I Haiku är det första problemet löst, men inte det andra. Uppdateringar kan rullas tillbaka, men bara för hela systemet; det är omöjligt (såvitt jag vet) att köra flera versioner av WebPositive eller LibreOffice samtidigt.

En av utvecklarna skriver:

I grund och botten är motiveringen att användningsscenariet är så sällsynt att det inte är meningsfullt att optimera för det; att hantera det som ett specialfall i HaikuPorts verkar mer än acceptabelt.

Jag behöver kunna spara program där jag vill, inte på startdisken. På mina diskar tar ofta utrymmet slut, så jag måste koppla in en extern disk eller en nätverkskatalog för att lagra program (alla versioner som jag har laddat ner). Om jag kopplar in en sådan disk måste programmen kunna startas med dubbelklick. Haiku sparar gamla versioner av paket, men jag vet inte hur jag kan flytta dem till en extern disk, eller hur jag sedan kan starta program från där.

Utvecklarens kommentar:

Tekniskt sett är det redan möjligt med mount-kommandot. Naturligtvis kommer vi att skapa ett GUI för detta så snart tillräckligt många intresserade användare finns.

Jag vill inte ha miljontals filer spridda över filsystemet som jag själv inte kan hantera manuellt. Jag vill ha en fil per applikation som jag lätt kan ladda ner, flytta eller ta bort. I Haiku har detta problem lösts genom paket .hpkg, som samlar exempelvis python, från tusentals filer till en. Men om det finns, till exempel, Scribus, som använder python, måste jag hantera minst två filer. Och jag måste se till att jag behåller versioner som fungerar tillsammans.

Många versioner av AppImages som körs bredvid varandra på samma Linux

Perspektiv från en applikationsutvecklare

Låt oss se ur ett applikationsutvecklarperspektiv:

Jag vill ha full kontroll över användarupplevelsen. Jag vill inte vara beroende av operativsystemet som säger till mig när och hur jag ska släppa applikationer. I Haiku kan utvecklare arbeta med sina egna hpkg-repositorier, men det innebär att användare måste konfigurera dem manuellt, vilket gör den idén "mindre attraktiv".
Jag har en nedladdningssida på min webbplats där jag distribuerar .exe för Windows, .dmg för Mac och .AppImage för Linux. Och kanske vill jag monetisera tillgången till denna sida, vad som helst kan hända? Vad behöver jag lägga där för Haiku? Tillräckligt med en fil .hpkg med beroenden som bara kommer från HaikuPorts.
Min programvara behöver specifika versioner av annan programvara. Till exempel är det känt att Krita behöver en korrigerad version av Qt, eller Qt som är exakt anpassad för en viss version av Krita, åtminstone tills korrigeringarna kommer tillbaka i Qt. Jag kan paketera min egen Qt för applikationen i paketet .hpkg, men det kommer troligen inte att välkomnas.

En vanlig nedladdningssida för applikationen. Vad ska jag lägga här för Haiku?

Kommer kit (som finns i form av programkataloger som AppDir eller .*.app i Apple-stil) och/eller avbildningar (i form av starkt modifierade AppImages eller .dmg är en användbar tillägg för arbetsmiljön Haiku från Apple? Eller kommer det att bryta den helhetsbild och leda till fragmentering, vilket i sin tur gör det mer komplicerat? Jag är kluven: å ena sidan, skönheten och elegansen i Haiku bygger på att det oftast finns ett sätt att göra något, inte flera. Å andra sidan är en stor del av infrastrukturen för kataloger och/eller applikationspaket redan på plats, så systemet anropar att även de kvarstående procenten får sina platser.

Enligt utvecklaren mr. waddlesplash

På Linux är de (kataloger och applikationspaket, anm. översättaren) förmodligen en teknisk lösning på systemproblem. På Haiku föredrar vi att bara lösa systemproblemen.

Vad tycker du?

Innan du svarar...

Vänta, låt oss göra en snabb verklighetskontroll: i praktiken applikationskataloger är redan en del av Haiku:

Applikationskataloger finns redan på Haiku, men stöds ännu inte i filhanteraren.

De stöds helt enkelt inte så bra som, säg, i Macintosh Finder. Hur coolt skulle det vara om QtCreator-katalogen hade namnet och ikonen 'QtCreator' i det övre vänstra hörnet som startar applikationen vid dubbelklick?

Tidigare har jag redan frågat:

Är du säker på att du kommer att kunna köra dina tioåriga applikationer idag, när alla applikationsbutiker och distributionslager har glömt bort dem och deras beroenden? Är du säker på att du fortfarande kommer att kunna komma åt ditt nuvarande arbete i framtiden?

Har Haiku redan ett svar, eller kan kataloger och applikationspaket hjälpa till här? Jag tror att de kan.

Enligt mr. waddlesplash:

Ja, vi har ett svar på frågan: vi kommer helt enkelt att stödja dessa applikationer så länge som behövs, tills någon kan läsa deras filformat korrekt eller säkerställa en funktionalitet ett till ett. Vår strävan att stödja BeOS R5-applikationer på Haiku är ett direkt bevis på detta…

Det stämmer!

Vilken handlingsplan bör Haiku följa?

Jag kan föreställa mig ett fredligt samexisterande av hpkg, kataloger och applikationsbilder:

Systemprogramvaran använder .hpkg
För den mest frekvent använda programvaran (särskilt för de som behöver planera flytande släpp) används .hpkg (ungefär 80% av alla fall)
Vissa program, installerade via .hpkg, kommer att gynnas av att gå över till en infrastruktur med applikationskataloger (till exempel QtCreator): de kommer att distribueras som .hpkg, precis som tidigare.

mr. waddlesplash skriver:

Om allt som behövs är att visa applikationer i /system/apps, istället bör katalogerna i Deskbar göras mer hanterbara för användarna, eftersom /system/apps inte är avsett för att användare regelbundet ska öppna och titta på det (till skillnad från MacOS). För sådana situationer har Haiku en annan paradigm, men det här alternativet är, i teorin, acceptabelt.

Haiku får infrastrukturen för att köra applikationsavbilder, nattsmålningar, kontinuerliga och testbyggnader av mjukvara, samt för fall när användaren vill 'frysa det i tiden', för privat och internt mjukvara, och andra speciella användningsfall (ungefär 20% av allt). Dessa avbilder innehåller filerna som krävs för att köra applikationen .hpkg, monterade med systemets medel, och efter att applikationen avslutats — avmonterade. (Kanske skulle filhanteraren kunna placera filer .hpkg i applikationsavbilder, automatiskt eller på begäran av användaren — som när man drar en applikation till en nätverkskatalog eller extern disk. Det är verkligen en sång! Eller kanske mer en dikt — haiku.) Å andra sidan kan användaren vilja installera innehållet i avbilden som filer.hpkg, efter vilket de kommer att uppdateras och hanteras på exakt samma sätt som om de hade installerats via HaikuDepot... Det krävs en idébollning).

Citat från mr. waddlesplash:

Att köra applikationer från externa diskar eller nätverkskataloger kan potentiellt vara användbart. Och att lägga till möjligheten att konfigurera fler 'zoner' för pkgman skulle verkligen bli en bra funktion.

Ett sådant system kommer att utnyttja fördelarna med hpkg, kataloger och applikationsavbilder. De är bra var för sig, men tillsammans kommer de att bli oslagbara.

Slutsats

För Haiku finns det en infrastruktur som erbjuder ett enkelt och sofistikerat användargränssnitt för PC, och det sträcker sig långt bortom vad som vanligtvis erbjuds för PC på Linux. Paketsystemet .hpkg — ett av dessa exempel, men de andra delarna av systemet är också genomsyra av finess. Ändå skulle Haiku vinna på rätt stöd för kataloger och applikationspaket. Hur man bäst går tillväga bör diskuteras med människor som känner Haiku, dess filosofi och arkitektur mycket bättre än jag. Slutligen har jag använt Haiku i lite mer än en vecka. Men jag anser ändå att denna nya perspektiv kommer att vara till nytta för designers, utvecklare och arkitekter av Haiku. Åtminstone ser jag gärna mig själv som en "sparringpartner" för dem. Jag har över 10 års praktisk erfarenhet av kataloger och applikationspaket för Linux, och jag skulle vilja hitta tillämpningar för Haiku, för vars koncept, enligt min mening, de passar perfekt. De potentiella lösningar jag föreslår är inte de enda rätta för de problem jag beskrivit, och om Haiku-teamet beslutar sig för att hitta andra, mer eleganta lösningar — så är det jag helt och hållet för. I princip funderar jag redan på hur man kan göra systemet hpkg ännu mer imponerande, utan att ändra på hur det fungerar. Det visar sig att Haiku-teamet har tänkt på applikationspaket under införandet av paketförvaltningssystemet, men tyvärr, (det verkar som) idén har blivit "föråldrad". Kanske är det dags att återuppliva den?

Prova själv! Eftersom Haiku-projektet tillhandahåller bilder för nedladdning från DVD eller USB, som skapas dagligen.
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 åttonde och sista artikeln i serien om Haiku.

Artikellista: Första Andra Tredje Fjärde Femte Sjätte Sjunde

Endast registrerade användare kan delta i omröstningen. Logga in, tack.