🥇Noget mere: Haiku applikationspakker?

TL;DR: Kan Haiku modtage ordentlig understøttelse af applikationspakker, som for eksempel applikationskataloger (som .app på Mac) og/eller applikationsbilleder (Linux AppImage)? Jeg mener, det ville være et værdifuldt supplement, som det er lettere at implementere ordentligt end i andre systemer, da det meste af infrastrukturen allerede er til stede.

For en uge siden opdagede jeg Haiku, et overraskende godt system. Da jeg længe har været interesseret i kataloger og applikationsbilleder (inspireret af Macintoshs enkelhed), er det ikke overraskende, at ideen kom til mig…

For at give et fuldendt billede: jeg er skaber og forfatter af AppImage, et format til distribution af Linux-applikationer, der fokuserer på Mac's enkelhed og giver fuld kontrol til applikationsudviklere og slutbrugere (vil du vide mere - se. wiki og dokumentationen).

Hvad hvis vi laver AppImage til Haiku?

Lad os teoretisere lidt om, hvad der skal gøres for at få AppImage, eller noget lignende, til Haiku? Det er ikke nødvendigt at skabe noget lige nu, for det system, der allerede findes i Haiku, fungerer fantastisk, og det tænkte eksperiment ville være interessant. Det ville også demonstrere Haikus styrke sammenlignet med Linux-skriveborde, hvor sådanne ting er frygteligt vanskelige (jeg har ret til at sige det: jeg har kæmpet med fejlfinding i 10 år).

På Macintosh System 1 var hver applikation en separat fil, 'administreret' i Finder. Ved at bruge AppImage forsøger jeg at genskabe denne brugeroplevelse på Linux.

For det første, hvad er AppImage? Det er et system til udgivelse af tredjepartsapplikationer (som for eksempel Ultimaker Cura), der giver mulighed for at udgive applikationer, når og hvordan man ønsker: man behøver ikke at vide noget om forskellige distributioners særpræg, bygningspolitikker eller bygningsinfrastruktur, man har ikke brug for support fra vedligeholdere, og de fortæller ikke brugerne, hvad der (ikke) kan installeres på deres computere. AppImage kan forstås som noget, der ligner en pakke til Mac i formatet .app inden i diskbilledet .dmg. Den største forskel er, at applikationer ikke kopieres, men forbliver inde i AppImage altid, på en måde som pakkerne i Haiku .hpkg monteres, og aldrig installeres i almindelig forstand.

AppImage har opnået en vis tiltrækningskraft og popularitet i de mere end 10 år, det har eksisteret: selv Linus Torvalds har offentligt godkendt det, og udbredte projekter (for eksempel LibreOffice, Krita, Inkscape, Scribus, ImageMagick) har taget det til sig som den primære metode til distribution af kontinuerlige eller natlige builds, som ikke griber ind i brugerens installerede eller ikke-installerede apps. Dog hænger de fleste Linux-miljøer og distributioner stadig fast i den traditionelle, centraliserede distributionsmodel baseret på følgetilskud og/eller promoverer deres egne kommercielle forretnings- og/eller ingeniørprogrammer baseret på Flatpak (RedHat, Fedora, GNOME) og Snappy (Canonical, Ubuntu). Det er blevet komisk.

Hvordan det fungerer

Hver AppImage indeholder to dele: en lille eksekverbar ELF, der kan køres med et dobbeltklik (kaldet runtime.c), efterfulgt af et filsystem SquashFS.

Filsystemet SquashFS indeholder nyttelasten i form af applikationen og alt nødvendigt for dens kørsel, som ikke med rette kan betragtes som en del af standardinstallationen for hver tilstrækkeligt moderne målte distributionssystem (Linux-distribution). Det indeholder også metadata, for eksempel applikationsnavn, ikoner, MIME-typer, osv.

Når brugeren starter programmet, bruger runtime FUSE og squashfuse til at montere filsystemet, hvorefter den håndterer opstarten af en indgangspunkt (den såkaldte AppRun) inden for den monterede AppImage.
Filsystemet afmonteres, efter at processen er afsluttet.

Det virker til at være enkelt.

Men disse ting komplicerer alt:

med så mange forskellige Linux-distributioner kan intet i 'sund fornuft' kaldes 'en del af standardinstallationen for hver moderne målte distribution'. Vi omgår dette problem ved at samle excludelist, som definerer, hvad der skal pakkes i AppImage, og hvad der skal hentes andetsteds. På den måde rammer vi nogle gange ved siden af, selvom det overordnet set fungerer rigtig godt. Derfor anbefaler vi pakkeudviklere at teste AppImages på alle målte systemer (distributioner).
Applikationerne i form af nyttelasten skal være flyttbare på filsystemet. Desværre er mange applikationer hårdt kodet med absolutte stier til for eksempel ressourcer i /usr/share. Dette skal der findes en løsning på. Udover dette skal der enten eksporteres LD_LIBRARY_PATH, eller rettes rpath for at bootloaderen kan finde de tilknyttede biblioteker. Den første metode har sine ulemper (som omgås på komplicerede måder), mens den anden blot er uhåndterlig.
Den største UX-fælde for brugerne er, at man skal angive det eksekverbare bit til AppImage-filen efter download. Tro det eller ej, men for nogle er det en reel barriere. Kravet om at sætte eksekverbarhed er besværligt, selv for erfarne brugere. Som en løsning foreslog vi at installere en lille service, der overvåger AppImage-filerne og sætter eksekverbarhed på dem. Rent ud sagt, ikke den bedste løsning, da den ikke vil fungere "out of the box". Linux-distributioner leverer ikke denne service, derfor er alt "out of the box" ikke godt for brugerne.
Linux-brugere forventer, at den nye applikation får et ikon i opstartsmenuen. Man kan ikke sige til systemet: "Se, der er en ny applikation, lad os arbejde". I stedet, i henhold til XDG-specifikationen, skal man kopiere filen .desktop til det rette sted i /usr til installation på tværs af systemet, eller i $HOME til individuel. Ikoner af bestemte størrelser, ifølge XDG-specifikationen, skal placeres på bestemte steder i usr eller $HOME, hvorefter man skal køre kommandoer i arbejdsomgivelserne for at opdatere cache for ikonerne, eller håbe på, at skrivebordshåndtereren kan finde og automatisk registrere dem. Det samme gælder for MIME-typer. Som en alternativ løsning foreslås det at bruge den samme service, der udover at sætte eksekverbarhed også vil, hvis der er ikoner osv. i AppImage, kopiere dem fra AppImage til de rette steder i henhold til XDG. Ved sletning eller flytning antages det, at servicen fjerner alt. Selvfølgelig er der forskelle i opførsel hos hver skrivebordsmiljø, i grafiske filformater, deres størrelser, lagringssteder og metoder til opdatering af caches, hvilket skaber problemer. Kort sagt, denne metode er en nødløsning.
Hvis ovennævnte ikke er tilstrækkeligt, er der heller ingen ikon for AppImage i filhåndtereren. I Linux-verdenen er der endnu ikke truffet beslutning om implementering af elficon (på trods af diskussionen og implementering), så det er umuligt at indbygge ikoner direkte i applikationen. Det resulterer i, at applikationer i filhåndteringen ikke har deres egne ikoner (uanset om det er AppImage eller andet), de findes kun i startmenuen. Som en løsning bruger vi miniaturebilleder — en mekanisme, der oprindeligt blev udviklet, så skrivebordsledere kunne vise nedsatte billeder til forhåndsvisning af grafiske filer som deres ikoner. Derfor fungerer tjenesten til at sætte udførelsesbit også som en „miniaturizer“, der opretter og gemmer miniatureikoner på de relevante steder /usr og $HOME. Denne tjeneste udfører også oprydning, hvis AppImage fjernes eller flyttes. Da hver skrivebordsleder opfører sig lidt forskelligt, for eksempel hvilke formater den accepterer ikoner i, hvilke størrelser eller placeringer, kan det være ret besværligt.
Applikationen crasher simpelthen ved udførsel, hvis der opstår fejl (for eksempel hvis der er et bibliotek, der ikke er en del af det basale system og ikke leveres i AppImage), og ingen informerer brugeren i GUI om, hvad der præcist sker. Vi begyndte at omgå dette ved at bruge notifikationer på skrivebordet, hvilket betyder, at vi skal fange fejl fra kommandolinjen, omdanne dem til brugervenlige beskeder, som derefter skal vises på skrivebordet. Og selvfølgelig håndterer hvert skrivebords-miljø dem lidt forskelligt.
I øjeblikket (september 2019, bemærk redaktøren) har jeg ikke fundet en simpel måde at fortælle systemet, at filen 1.png skal åbnes med Krita, og 2.png — med GIMP.

Stedet for opbevaring af cross-desktop specifikationer, der anvendes i GNOME, KDE og Xfce er freedesktop.org

At nå et niveau af sofistikering, der er dybt indvejet i Haikus skrivebords-miljø, er vanskeligt, for ikke at sige "umuligt", på grund af specifikationerne XDG fra freedesktop.org for cross-desktop, samt implementeringerne af skrivebordsledere baseret på disse specifikationer. For eksempel kan man nævne et fælles systemikon for Firefox: tilsyneladende har forfatterne af XDG ikke tænkt over, at brugeren kan have flere versioner af den samme applikation installeret.

Ikoner for forskellige versioner af Firefox

Jeg var nysgerrig efter, hvad verden af Linux kunne lære af Mac OS X for at undgå problemer ved systemintegration. Hvis du har tid og arbejder med dette, så læs endelig, hvad Arno Gurdol, en af de første ingeniører bag Mac OS X, sagde:

Vi ønskede, at installationen af applikationen skulle være lige så enkel som at trække ikonet fra et sted (server, ekstern disk) til din computers harddisk. For dette indeholder applikationspakken al information, herunder ikoner, version, den behandlede filtype, den type URL-ski, som systemet skal kende for at håndtere applikationen. Dette omfatter også information til 'centraliseret opbevaring' i databasen Icon Services og Launch Services. For at understøtte applikationens ydeevne 'opdages' de i flere 'velkendte' steder: i system- og brugerkataloget Applications, samt automatisk i nogle andre, hvis brugeren har navigeret til Finder-mappen, der indeholder applikationen. I praksis har dette virket rigtig godt.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000, session 144 - Mac OS X: pakning af applikationer og udskrivning af dokumenter.

Der findes ikke noget lignende i denne infrastruktur på arbejdsomgivelserne i Linux, så vi leder efter alternative løsninger til de strukturelle begrænsninger i AppImage-projektet.

Sker der virkelig noget fra Haiku?

Og endnu en ting: Linux-platforme som grundlag for arbejdsomgivelser er generelt så under-specifiserede, at mange ting, der er ret enkle i et sammenhængende system med et komplet stack, skuffer med deres fragmentering og kompleksitet i Linux. Jeg har viet et helt oplæg til emner relateret til Linux-platformen for arbejdsomgivelser (kendsgerning erkendt af erfarne udviklere: det vil forblive sådan i lang tid fremover).

Mit oplæg om problemerne ved Linux-arbejdsmiljøer i 2018

Selv Linus Torvalds har erkendt, at det er fragmenteringen, der har forhindret idéen om arbejdsomgivelser i at lykkes.

Det er dejligt at se Haiku!

Med Haiku bliver alt fantastisk enkelt.

Selv om en naiv tilgang til "overførsel" af AppImage til Haiku er at forsøge at bygge (primært runtime.c og service) dets komponenter (hvilket måske endda er muligt!), vil det ikke bringe særlig meget værdi for Haiku. For de fleste af disse problemer er faktisk løst i Haiku og er konceptuelt begrundede. Haiku leverer netop de byggeklodser til systeminfrastrukturen, som jeg har ledt efter i arbejdsomgivelser på Linux og ikke kunne tro ikke fandtes der.

Tro det eller ej, men mange Linux-brugere kan ikke overvinde dette. På Haiku sker alt automatisk!

ELF-filer, der ikke har udførelsesbit, får det automatisk ved dobbelklik i filhåndtereren.
Applikationer kan have indbyggede ressourcer, såsom ikoner, der vises i filhåndtereren. Der er ikke behov for at kopiere en masse billeder til særlige ikonmapper, så det er heller ikke nødvendigt at rydde op efter at have slettet eller flyttet applikationen.
Der er en database til at knytte applikationer til dokumenter, så det er ikke nødvendigt at kopiere filer til dette.
I mappen lib/ bliver biblioteker som standard søgt tæt på den kørende eksekverbare fil.
Der er ikke mange distributioner og skrivebordsomgivelser, alt hvad der fungerer, fungerer overalt.
Der findes ikke en separat modul til start, der adskiller sig fra mappen Applications.
Applikationer har ikke indbyggede absolutte stier til deres ressourcer, der er særlige funktioner til at bestemme placeringen under kørsel.
Idéen med komprimerede filsystembilleder er implementeret: ethvert hpkg-pakke. Alle bliver monteret af kernen.
Hver fil bliver åbnet af den applikation, der har oprettet den, medmindre der udtrykkeligt er angivet noget andet. Det er bare fantastisk!

To png-filer. Bemærk de forskellige ikoner, der viser, at de åbnes af forskellige applikationer ved dobbelklik. Bemærk også dropdown-menuen "Åbn med:", hvor brugeren kan vælge en bestemt applikation. Så enkelt!

Det ser ud til, at mange af de hacks og omveje, der er nødvendige for AppImage på Linux, bliver unødvendige på Haiku, som har en enkelhed og raffinement i sin kerne, der gør det i stand til at klare de fleste af vores behov.

Har Haiku brug for applikationspakker, i sidste ende?

Dette fører til et stort spørgsmål. Hvis det ville være meget lettere at skabe et system som AppImage på Haiku end på Linux, ville det så være værd at forfølge? Eller har Haiku med sit pakkehåndteringssystem hpkg reelt elimineret behovet for at udvikle en sådan idé? Nå, for at få svar skal vi se på motivationen bag eksistensen af AppImages.

Brugerens perspektiv

Lad os se på vores slutbruger:

Jeg vil installere en applikation uden at skulle indtaste en administratoradgangskode (root). På Haiku er der ikke noget begreb om administrator; brugeren har fuld kontrol, da det er et personligt system! (I princippet kan man forestille sig dette i en flerbrugermode, håber jeg, at udviklerne vil bevare enkelheden)
Jeg vil have de nyeste og bedste versioner af applikationer uden at skulle vente på, at de kommer til min distribution (oftest betyder det "aldrig", medmindre hele operativsystemet opdateres). På Haiku er dette "løst" med flydende udgivelser. Det betyder, at der er mulighed for at få de nyeste og bedste versioner af applikationer, men for dette skal man konstant opdatere resten af systemet, hvilket faktisk gør det til et "bevægeligt mål"..
Jeg ønsker at have flere versioner af den samme applikation ved siden af hinanden, da jeg ikke kan vide, hvad der blev brudt i den seneste version, eller lad os sige, at jeg som webudvikler skal teste mit arbejde på forskellige versioner af browsere. I Haiku er det første problem løst, men ikke det andet. Opdateringer kan rulles tilbage, men kun for hele systemet; det er (så vidt jeg ved) umuligt at køre flere versioner af WebPositive eller LibreOffice samtidig.

En af udviklerne skriver:

I bund og grund er begrundelsen denne: anvendelsesscenariet er så sjældent, at optimering for det ikke giver mening; behandling af det som et specielt tilfælde i HaikuPorts synes mere end acceptabelt.

Jeg skal kunne gemme applikationer, hvor jeg ønsker, ikke kun på opstartsdisketten. På mine diske løber jeg ofte tør for plads, så jeg skal tilslutte en ekstern disk eller en netværksmappe til lagring af applikationer (alle versioner, jeg har downloadet). Hvis jeg tilslutter en sådan disk — skal applikationerne kunne startes med et dobbeltklik. Haiku gemmer gamle versioner af pakker, men jeg ved ikke, hvordan man flytter dem til en ekstern disk, og hvordan man derefter starter applikationer derfra.

Udviklerens kommentar:

Teknisk set er det allerede muligt med mount-kommandoen. Selvfølgelig vil vi lave en GUI til dette, så snart der er tilstrækkeligt mange interesserede brugere.

Jeg har ikke brug for millioner af filer spredt på filsystemet, som jeg ikke selv kan håndtere. Jeg ønsker én fil per applikation, som jeg nemt kan downloade, flytte og slette. På Haiku er dette problem løst ved hjælp af pakker .hpkg, som f.eks. flytter python fra tusindvis af filer til én. Men hvis der er f.eks. Scribus, der bruger python, så må jeg håndtere mindst to filer. Og jeg skal sørge for at holde dem i fungerende versioner sammen.

Adskillige versioner af AppImages, der kører side om side på én Linux

Et perspektiv fra applikationsudviklerens side

Lad os se på det fra applikationsudviklerens synspunkt:

Jeg vil styre brugeroplevelsen helt. Jeg vil ikke være afhængig af operativsystemet, der dikterer, hvornår og hvordan jeg skal udgive applikationer. På Haiku kan udviklere arbejde med deres egne hpkg-repositorier, men det betyder, at brugerne skal konfigurere dem manuelt, hvilket gør denne idé "mindre attraktiv".
Jeg har en downloadside på min hjemmeside, hvor jeg distribuerer .exe til Windows, .dmg til Mac og .AppImage til Linux. Og måske ønsker jeg at tjene penge på adgangen til denne side; hvad skal jeg så sætte der for Haiku? Det er nok med en fil .hpkg med afhængigheder kun fra HaikuPorts
Mit software kræver specifikke versioner af andet software. F.eks. er det kendt, at Krita kræver en korrigeret version af Qt, eller Qt der er præcist tilpasset den specifikke version af Krita, i det mindste indtil rettelserne kommer tilbage i Qt. Man kan pakke sin egen Qt til applikationen i pakken .hpkg, men det vil sandsynligvis ikke blive set med gode øjne.

En almindelig downloadside for applikationen. Hvad skal jeg sætte her for Haiku?

Vil sæt (der eksisterer som applikationskataloger, som AppDir eller .app i Apple-stil) og/eller billeder (i form af stærkt modificerede AppImages eller .dmg er Apple) applikationer en nyttig tilføjelse til Haiku's arbejdsområde? Eller vil det svække helheden og føre til fragmentering, hvilket gør alt mere kompliceret? Jeg er splittet: På den ene side er skønheden og raffineringen i Haiku baseret på, at der normalt er én måde at gøre noget på, ikke mange. På den anden side er en stor del af infrastrukturen til kataloger og/eller applikationspakker allerede på plads, så systemet råber på, at de sidste par procent også skal falde på plads.

Ifølge udvikleren mr. waddlesplash

På Linux er de (kataloger og applikationspakker, - redaktørens bemærkning) sandsynligvis en teknisk løsning på systemproblemer. På Haiku foretrækker vi blot at løse systemproblemerne.

Hvad tænker du?

Før du svarer...

Vent, lad os lave en hurtig virkelighedstest: Faktisk applikationskataloger er allerede en del af Haiku:

Applikationskataloger findes allerede på Haiku, men er ikke understøttet i filhåndtereren.

De understøttes bare ikke så godt som for eksempel i Macintosh Finder. Hvor fedt ville det ikke være, hvis kataloget QtCreator havde navnet og ikonet 'QtCreator' øverst til venstre, der starter applikationen ved dobbeltklik?

Lidt tidligere har jeg allerede spørgt:

Er du sikker på, at du kan køre dine applikationer fra for et årti siden i dag, når alle applikationsbutikker og distributions-arkiver glemmer dem og deres afhængigheder? Er du sikker på, at du stadig vil kunne få adgang til dit nuværende arbejde i fremtiden?

Er der allerede et svar fra Haiku, eller vil kataloger og applikationspakker kunne hjælpe her? Jeg mener, de kunne.

Ifølge hr. waddlesplash:

Ja, vi har et svar på spørgsmålet: Vi vil simpelthen støtte disse applikationer, så længe som nødvendigt, indtil nogen kan læse deres filformater korrekt eller sikre funktionaliteten én til én. Vores stræben efter at støtte applikationer fra BeOS R5 på Haiku er et direkte bevis på dette...

Det er helt sikkert!

Hvilken handlingsplan bør Haiku tage?

Jeg kan forestille mig fredeligt sameksistens mellem hpkg, kataloger og applikationsbilleder:

Systemsoftware bruger .hpkg
Til den mest anvendte software (især den, der skal planlægge flydende udgivelser) anvendes .hpkg (omtrent 80% af alle tilfælde)
Nogle, der er installeret via .hpkg, applikationer vil drage fordel af overgangen til en infrastruktur med applikationskataloger (f.eks. QtCreator): de vil blive distribueret i form af .hpkg, som før.

mr. waddlesplash skriver:

Hvis alt hvad der er nødvendigt, er at gennemse applikationer i /system/apps, skal katalogerne i Deskbar gøres mere håndterbare for brugerne, da /system/apps ikke er beregnet til at brugerne regelmæssigt åbner og ser på det (i modsætning til MacOS). For sådanne situationer har Haiku en anden tilgang, men denne mulighed er, ifølge ideen, acceptabel.

Haiku får en infrastruktur til at køre applikationsbilleder, natlige, kontinuerlige og testbyggerier af software, samt i situationer, hvor brugeren ønsker at "fryse det i tiden", til privat og internt software og andre specifikke brugssituationer (ca. 20 % af alt). Disse billeder indeholder de nødvendige filer til at køre applikationen .hpkg, der monteres af systemet, og efter afslutningen af applikationen - afmonteres. (Måske kunne filhåndterer placere filer .hpkg i applikationsbilleder, automatisk eller efter brugerens anmodning - ligesom når man trækker en applikation til et netværkskatalog eller en ekstern disk. Det er simpelthen en sang! Mere præcist en poesi - haiku.) På den anden side kan brugeren ønske at installere indholdet af billedet som filer.hpkg, hvorefter de vil blive opdateret og behandlet præcist som hvis de var installeret via HaikuDepot... Det er tid til at brainstorme).

Citat fra mr. waddlesplash:

Kørsel af applikationer fra eksterne diske eller netværk kataloger kan være nyttigt. Og at tilføje muligheden for at konfigurere flere "zoner" for pkgman vil bestemt være en god funktion.

Et sådant system vil udnytte fordelene ved hpkg, kataloger og applikationsbilleder. De er gode hver for sig, men sammen vil de være uovervindelige.

Konklusion

For Haiku er der en infrastruktur, der giver en enkel og raffineret brugergrænseflade til pc'er, som rækker langt ud over hvad der normalt tilbydes til pc'er på Linux. Pakkesystem. .hpkg — et af disse eksempler, men systemets øvrige dele er også præget af raffinement. Ikke desto mindre ville Haiku have gavn af ordentligt support til kataloger og applikationspakker. Hvordan det bedst kan gøres, bør diskuteres med folk, der kender Haiku, dens filosofi og arkitektur meget bedre end jeg. Jeg har trods alt kun brugt Haiku lidt over en uge. Alligevel mener jeg, at dette friske perspektiv vil være nyttigt for designere, udviklere og arkitekter inden for Haiku. I det mindste er jeg glad for at agere som deres 'sparringspartner'. Jeg har over 10 års praktisk erfaring med kataloger og applikationspakker til Linux, og jeg vil gerne finde anvendelse for dem i Haiku, hvor jeg mener, de passer perfekt til konceptet. De potentielle løsninger, jeg foreslår, er ikke de eneste korrekte for de problemer, jeg har beskrevet, og hvis Haiku-teamet beslutter sig for at finde andre, mere elegante løsninger — så er jeg helt med på det. Grundlæggende overvejer jeg allerede idéen om, hvordan man kan gøre systemet hpkg endnu mere fantastisk uden at ændre måden, det fungerer på. Det viser sig, at Haiku-teamet længe har tænkt på applikationspakker i implementeringen af pakkestyringssystemet, men desværre (efter min mening) blev idéen 'forældet'. Måske er det tid til at genoplive den?

Prøv selv! Haiku-projektet tilbyder billeder til download fra DVD eller USB, der genereres dagligt.
Har du spørgsmål? Vi inviterer dig til vores russisktalende telegram-kanal.

Fejloversigt: Hvordan man skyder sig selv i foden i C og C++. En opskriftsamling fra Haiku OS

Fra forfatter til oversættelse: dette er den ottende og afsluttende artikel i serien om Haiku.

Liste over artikler: Den første Anden Tredje Fjerde Femte Sjette Syvende

Kun registrerede brugere kan deltage i undersøgelsen. Log ind, please.