🥇Noget andet: Haiku-applikationspakker?

TL; DR: Kan Haiku få ordentlig support til applikationspakker, såsom applikationsmapper (som .app i Mac) og/eller programbilleder (Linux AppImage)? Jeg tror, at dette ville være en værdig tilføjelse, der er lettere at implementere korrekt end andre systemer, da det meste af infrastrukturen allerede er på plads.

En uge siden Jeg opdagede Haiku, et uventet godt system. Nå, da jeg længe har været interesseret i mapper og applikationsbilleder (inspireret af Macintosh'ens enkelhed), er det ikke overraskende, at jeg fik en idé...

Til orientering, jeg er skaberen og forfatteren af AppImage, et distributionsformat til applikationer. Linux, som har til formål at gøre Mac'en enklere og give app-udviklere og slutbrugere fuld kontrol (se mere nedenfor). wiki и dokumentation).

Hvad hvis vi laver et AppImage til Haiku?

Lad os tænke lidt, rent teoretisk: hvad skal der gøres for at få AppImage, eller noget lignende, på Haiku? Der er ingen grund til at oprette noget lige nu, da det system, Haiku allerede har, fungerer fantastisk, men et imaginært eksperiment ville være rart. Det demonstrerer også Haikus sofistikering sammenlignet med skrivebordsmiljøer. Linux, hvor den slags ting er frygtelig vanskelige (jeg har ret til at sige dette: Jeg har kæmpet med fejlfinding i 10 år allerede).

På Macintosh System 1 var hvert program en separat fil, "administreret" i Finder. Ved hjælp af AppImage forsøger jeg at genskabe den samme brugeroplevelse på Linux.

For det første, hvad er et AppImage? Dette er et system til frigivelse af tredjepartsapplikationer (f.eks. Ultimaker Cure), hvilket gør det muligt for programmer at blive frigivet, når og hvordan de vil: der er ingen grund til at kende detaljerne for forskellige distributioner, byggepolitikker eller opbygge infrastruktur, ingen vedligeholdelsessupport er nødvendig, og de fortæller ikke brugerne, hvad (ikke) de kan installere på deres computere. AppImage skal forstås som noget, der ligner en Mac-pakke i formatet .app inde i diskbilledet .dmg. Den største forskel er, at applikationer ikke kopieres, men forbliver inde i AppImage for evigt, meget det samme som Haiku-pakker .hpkg monteret, og aldrig installeret i sædvanlig forstand.

I løbet af sine mere end 10 års eksistens har AppImage vundet en vis popularitet: Linus Torvalds har selv offentligt godkendt det, og populære projekter (f.eks. LibreOffice, Krita, Inkscape, Scribus, ImageMagick) har taget det til sig som den primære metode til at distribuere kontinuerlige eller natlige builds, der ikke forstyrrer brugernes installerede eller afinstallerede applikationer. Desktopmiljøer og distributioner Linux klamrer sig oftest stadig til den traditionelle, centraliserede distributionsmodel baseret på vedligeholdere og/eller promoverer deres egen virksomhedsforretning og/eller ingeniørprogrammer baseret på Flatpak (RedHat, Fedora, GNOME) og Snappy (Kanonisk, UbuntuDet er på vej dertil. latterligt.

Hvordan det hele fungerer

Hvert AppImage indeholder 2 dele: et lille dobbeltklik ELF (såkaldt. runtime.c), efterfulgt af et filsystembillede SquashFS.

SquashFS-filsystemet indeholder en nyttelast i form af et program og alt, hvad der er nødvendigt for at køre det, hvilket med rette kan betragtes som en del af standardinstallationen for alle tilstrækkeligt nye målsystemer (distributioner). LinuxDen indeholder også metadata, såsom programnavn, ikoner, MIME-typer osv.

Når den køres af brugeren, bruger runtime FUSE og squashfuse til at montere filsystemet og håndterer derefter at køre et eller andet indgangspunkt (aka AppRun) inde i det monterede AppImage.
Filsystemet afmonteres, når processen er fuldført.

Alt virker simpelt.

Og disse ting komplicerer alt:

med så mange forskellige distributioner Linux Intet, man ved sine fulde fem kan længere kaldes "en del af standardinstallationen for hvert nyt målsystem". Vi omgår dette problem ved at bygge ekskluderingsliste, så du kan bestemme, hvad der vil blive pakket i AppImage, og hvad der skal tages et andet sted. Samtidig savner vi nogle gange, på trods af at alt generelt fungerer glimrende. Af denne grund anbefaler vi, at pakkeskabere tester AppImages på alle målsystemer (distributioner).
Programnyttelast skal kunne flyttes på tværs af filsystemet. Desværre har mange applikationer hårdkodede absolutte stier til for eksempel ressourcer i /usr/share. Dette skal rettes på en eller anden måde. Derudover skal du enten eksportere LD_LIBRARY_PATH, eller rette rpath så indlæseren kan finde relaterede biblioteker. Den første metode har sine ulemper (som overvindes på komplekse måder), og den anden er simpelthen besværlig.
Den største UX faldgrube for brugere er det sæt eksekverbar bit AppImage-filen efter download. Tro det eller ej, men dette er en reel barriere for nogle. Det er besværligt at indstille den eksekverbare bit, selv for erfarne brugere. Som en løsning har vi foreslået at installere en lille tjeneste, der overvåger AppImage-filer og indstiller deres eksekverbare bit. I sin rene form er dette ikke den bedste løsning, da det ikke vil virke lige fra starten. Distributioner Linux De tilbyder ikke denne service, så brugerne får en dårlig oplevelse lige fra starten.
Medlemmer Linux De forventer, at en ny app har et ikon i launcheren. Du kan ikke bare sige til systemet: "Se, der er en ny app, lad os komme i gang." I stedet skal du ifølge XDG-specifikationen kopiere filen. .desktop til det rigtige sted i /usr for en systemdækkende installation eller i $HOME for individuelle. Ikoner af bestemte størrelser, i henhold til XDG-specifikationen, skal placeres bestemte steder i usr eller $HOME, og kør derefter kommandoer i arbejdsmiljøet for at opdatere ikoncachen, eller håb på, at arbejdsmiljølederen finder ud af det og automatisk registrerer alt. Det samme med MIME-typer. Som en løsning foreslås det at bruge samme service, som udover at sætte eksekverbarhedsflaget vil, hvis der er ikoner mv. i AppImage, kopier dem fra AppImage til de rigtige steder ifølge XDG. Når den slettes eller flyttes, forventes tjenesten at rydde alt. Selvfølgelig er der forskelle i adfærden i hvert arbejdsmiljø, i grafiske filformater, deres størrelser, lagerplaceringer og metoder til opdatering af caches, hvilket skaber et problem. Kort sagt er denne metode en krykke.
Hvis det ikke var nok, er der stadig intet AppImage-ikon i filhåndteringen. Linux har stadig ikke taget en beslutning om implementering af elficon (på trods af diskussion и implementering), så det er umuligt at integrere ikonet direkte i applikationen. Så det viser sig, at applikationer i filhåndteringen ikke har deres egne ikoner (ingen forskel, AppImage eller noget andet), de er kun i startmenuen. Som en løsning bruger vi thumbnails, en mekanisme, der oprindeligt blev designet til at give desktop-administratorer mulighed for at vise thumbnail-eksempelbilleder af grafiske filer som deres ikoner. Følgelig fungerer tjenesten til indstilling af eksekverbarhedsbitten også som en "miniaturizer", der skaber og skriver ikonminiaturebilleder til de relevante steder /usr и $HOME. Denne tjeneste udfører også oprydning, hvis AppImage slettes eller flyttes. På grund af det faktum, at hver desktop-manager opfører sig lidt forskelligt, for eksempel i hvilke formater den accepterer ikoner, i hvilke størrelser eller steder, er alt dette virkelig smertefuldt.
Applikationen går simpelthen ned ved udførelse, hvis der opstår fejl (der er f.eks. et bibliotek, der ikke er en del af basissystemet og ikke leveres i AppImage), og der er ingen, der fortæller brugeren i GUI, hvad der præcist sker. Vi begyndte at komme udenom dette ved at bruge meddelelser på skrivebordet, hvilket betyder, at vi skal fange fejl fra kommandolinjen, konvertere dem til beskeder, der er forståelige for brugeren, og som derefter skal vises på skrivebordet. Og selvfølgelig håndterer hvert skrivebordsmiljø dem lidt forskelligt.
I øjeblikket (september 2019 - oversætterens bemærkning) har jeg ikke fundet en enkel måde at fortælle systemet, at filen 1.png skal åbnes ved hjælp af Krita, og 2.png - ved at bruge GIMP.

Lagerplacering for specifikationer på tværs af skriveborde, der bruges i GNOME, KDE и Xfce er freedesktop.org

At opnå det sofistikerede niveau, der er dybt vævet ind i Haiku-arbejdsmiljøet, er vanskeligt, hvis ikke umuligt, på grund af specifikationerne XDG fra freedesktop.org til cross-desktop, samt implementeringer af desktop-managere baseret på disse specifikationer. Som et eksempel kan vi nævne et Firefox-ikon for hele systemet: tilsyneladende troede forfatterne af XDG ikke engang, at en bruger kunne have flere versioner af den samme applikation installeret.

Ikoner til forskellige versioner af Firefox

Jeg undrede mig over, hvad verden var Linux Jeg kunne lære af Mac OS X for at undgå at ødelægge systemintegrationen. Hvis du har tid og er involveret i dette, så sørg for at læse, hvad Arnaud Gourdold, en af de første Mac OS X-ingeniører, havde at sige:

Vi ønskede at gøre installationen af applikationen lige så let som at trække applikationsikonet fra et sted (server, eksternt drev) til dit computerdrev. For at gøre dette gemmer applikationspakken al information, inklusive ikoner, version, filtype, der behandles, type URL-skemaer, som systemet skal kende for at behandle applikationen. Dette inkluderer også oplysninger om 'central lagring' i Icon Services og Launch Services-databasen. For at understøtte ydeevnen 'opdages' applikationer flere 'velkendte' steder: Systemet og brugerens applikationsmapper og nogle andre automatisk, hvis brugeren navigerer til Finder i biblioteket, der indeholder applikationen. I praksis fungerede dette meget godt.

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

Der findes intet lignende fra denne infrastruktur i produktionsmiljøer. Linux, så vi leder efter løsninger på de strukturelle begrænsninger i AppImage-projektet.

Kommer Haiku til undsætning?

Og også: platforme Linux som grundlag for arbejdsmiljøer, er typisk så underspecificerede, at mange ting, der ville være ret simple i et sammenhængende full-stack system, bliver frustrerende fragmenterede og komplekse i LinuxJeg har dedikeret en hel rapport til problemstillinger relateret til platformen. Linux til arbejdsmiljøer (kyndige udviklere har bekræftet, at alt vil forblive sådan i meget lang tid).

Min rapport om problemerne i arbejdsmiljøet Linux i 2018

Selv Linus Torvalds indrømmede, at fragmentering var grunden til, at idéen om arbejdspladsen mislykkedes.

Dejligt at se Haiku!

Haiku gør alt forbløffende enkelt

Selvom en naiv tilgang til at "portere" AppImage til Haiku ville være blot at forsøge at kompilere dens komponenter (primært runtime.c og tjenesten) (hvilket måske endda er muligt!), ville dette ikke give Haiku megen fordel. Fordi faktisk er de fleste af disse problemer løst i Haiku og konceptuelt set er solide. Haiku leverer præcis de byggesten til den systeminfrastruktur, jeg har ledt efter i desktop-miljøer i så lang tid. Linux og kunne ikke tro, at de ikke var der. Nemlig:

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

ELF-filer, der ikke har en eksekverbarhedsbit, får en automatisk, når der dobbeltklikkes i filhåndteringen.
Programmer kan have indbyggede ressourcer, såsom ikoner, der vises i filhåndteringen. Der er ingen grund til at kopiere en masse billeder til specielle mapper med ikoner, og derfor er det ikke nødvendigt at rydde op i dem efter sletning eller flytning af applikationen.
Der er en database til at forbinde applikationer med dokumenter, det er ikke nødvendigt at kopiere nogen filer til dette.
I biblioteket lib/ ved siden af den eksekverbare fil søges der som standard i biblioteker.
Der er ikke mange distributioner og skrivebordsmiljøer; uanset hvad der virker, virker det overalt.
Der er ikke noget separat modul at køre, der er forskelligt fra Applications-mappen.
Applikationer har ikke indbyggede absolutte stier til deres ressourcer; de har specielle funktioner til at bestemme placeringen under kørsel.
Ideen med komprimerede filsystembilleder er blevet introduceret: dette er enhver hpkg-pakke. Alle er monteret af kernen.
Hver fil åbnes af det program, der oprettede den, medmindre du udtrykkeligt angiver andet. Hvor er det her fedt!

To png-filer. Bemærk de forskellige ikoner, der indikerer, at de vil blive åbnet af forskellige programmer, når der dobbeltklikkes. Bemærk også rullemenuen "Åbn med:", hvor brugeren kan vælge en individuel applikation. Hvor simpelt!

Det ser ud til, at mange af de hacks og løsninger, som AppImage har brug for på Linux, blive unødvendige på Haiku, som i sin kerne har en enkelhed og raffinement, der gør den velegnet til de fleste af vores behov.

Har Haiku alligevel brug for app-pakker?

Dette bringer mig til det store spørgsmål: Hvis det var en størrelsesorden nemmere at oprette et system som AppImage på Haiku end på Linux, ville det være værd at forfølge? Eller har Haiku, med sit hpkg-pakkesystem, effektivt elimineret behovet for en sådan idé? For at besvare det, er vi nødt til at se på motivationen bag AppImages.

Brugerens perspektiv

Lad os se på vores slutbruger:

Jeg vil installere et program uden at bede om en administratoradgangskode (root). Der er intet begreb om en administrator på Haiku, brugeren har fuld kontrol, da det er et personligt system! (I princippet kan du forestille dig dette i multiplayer-tilstand, jeg håber, at udviklerne holder det enkelt)
Jeg vil gerne have de nyeste og bedste versioner af applikationer uden at vente på, at de vises i min distribution (oftest betyder det "aldrig", i det mindste medmindre jeg opdaterer hele operativsystemet). På Haiku er dette "løst" med flydende udgivelser. Det betyder, at du kan få de nyeste og bedste versioner af applikationer, men for at gøre dette skal du konstant opdatere resten af systemet, hvilket effektivt gør det til et "bevægende mål".
Jeg vil have flere versioner af den samme applikation side om side, da der ikke er nogen måde at vide, hvad der var brudt i den seneste version, eller for eksempel, jeg som webudvikler skal teste mit arbejde under forskellige versioner af browseren. Haiku løser det første problem, men ikke det andet. Opdateringer rulles tilbage, men kun for hele systemet, det er umuligt (så vidt jeg ved) at køre for eksempel flere versioner af WebPositive eller LibreOffice på samme tid.

En af udviklerne skriver:

Grundlæggende er begrundelsen dette: use casen er så sjælden, at det ikke giver mening at optimere til det; at behandle det som et særligt tilfælde i HaikuPorts virker mere end acceptabelt.

Jeg skal beholde apps, hvor jeg kan lide dem, ikke på mit startdrev. Jeg løber ofte tør for diskplads, så jeg skal tilslutte et eksternt drev eller netværksmappe for at gemme programmer (alle versioner, som jeg har downloadet). Hvis jeg tilslutter et sådant drev, har jeg brug for, at programmer startes ved at dobbeltklikke. Haiku gemmer gamle versioner af pakker, men jeg ved ikke, hvordan jeg flytter dem til et eksternt drev, eller hvordan jeg starter programmer derfra senere.

Udviklerkommentar:

Teknisk set er dette allerede muligt med mount-kommandoen. Vi vil selvfølgelig lave en GUI til dette, så snart vi har nok interesserede brugere.

Jeg har ikke brug for millioner af filer spredt ud over filsystemet, som jeg ikke selv kan håndtere manuelt. Jeg vil have én fil pr. applikation, som jeg nemt kan downloade, flytte, slette. På Haiku er dette problem løst ved hjælp af pakker .hpkg, som overfører for eksempel python fra tusindvis af filer til én. Men hvis der for eksempel er Scribus, der bruger python, så skal jeg håndtere mindst to filer. Og jeg skal passe på at beholde versioner af dem, der fungerer sammen.

Flere versioner af AppImages kører side om side på én Linux

En applikationsudviklers perspektiv

Lad os se fra en applikationsudviklers synspunkt:

Jeg vil gerne styre hele brugeroplevelsen. Jeg vil ikke være afhængig af et operativsystem til at fortælle mig, hvornår og hvordan jeg skal frigive programmer. Haiku giver udviklere mulighed for at arbejde med deres egne hpkg repositories, men det betyder, at brugerne bliver nødt til at konfigurere dem manuelt, hvilket gør ideen "mindre attraktiv."
Jeg har en downloadside på min hjemmeside, hvor jeg distribuerer .exe for Windows, .dmg til Mac og .AppImage for LinuxEller måske vil jeg gerne tjene penge på adgangen til denne side? Alt er muligt? Hvad skal jeg sætte der som Haiku? Filen er nok .hpkg med afhængigheder kun fra HaikuPorts
Min software kræver specifikke versioner af anden software. For eksempel er det kendt, at Krita kræver en patchet version af Qt, eller Qt, der er finjusteret til en specifik version af Krita, i hvert fald indtil patcherne skubbes tilbage i Qt. Du kan pakke din egen Qt til din applikation i en pakke .hpkg, men højst sandsynligt er dette ikke velkomment.

Almindelig applikationsdownloadside. Hvad skal jeg skrive her for Haiku?

Vil bundter (eksisterer som applikationsmapper som AppDir eller .app i Apple-stil) og/eller billeder (i form af stærkt modificerede AppImages eller .dmg fra Apple) applikationer en nyttig tilføjelse til Haiku-skrivebordsmiljøet? Eller vil det udvande hele billedet og føre til fragmentering og derfor tilføje kompleksitet? Jeg er splittet: På den ene side er skønheden og sofistikeringen ved Haiku baseret på, at der normalt er én måde at gøre noget på, snarere end mange. På den anden side er det meste af infrastrukturen til kataloger og/eller applikationspakker allerede på plads, så systemet råber på, at de resterende få procent falder på plads.

Ifølge bygherren Hr. waddleplash

On Linux De (kataloger og applikationssæt, - ca. oversætter) er højst sandsynligt en teknisk løsning på systemiske problemer. Hos Haiku foretrækker vi blot at løse systemproblemer.

Hvad synes du?

Før du svarer...

Vent, lad os lave et hurtigt realitetstjek: faktisk applikationsmapper - allerede en del af Haiku:

Applikationsmapper findes allerede på Haiku, men er endnu ikke understøttet i filhåndteringen

De er bare ikke så godt understøttet som for eksempel Macintosh Finder. Hvor sejt ville det være, hvis QtCreator-biblioteket havde et "QtCreator"-navn og -ikon i øverste venstre hjørne, der starter programmet, når der dobbeltklikkes?

Lidt tidligere har jeg allerede spurgt:

Er du sikker på, at du kan køre dine årti gamle apps i dag, når alle appbutikker og distributionslagre har glemt dem og deres afhængigheder? Er du sikker på, at du stadig vil kunne få adgang til dit nuværende job i fremtiden?

Er der allerede et svar fra Haiku, eller kan kataloger og applikationspakker hjælpe her? Det tror jeg, de kan.

Ifølge mr. waddlesplash:

Ja, vi har svaret på spørgsmålet: Vi vil simpelthen understøtte disse applikationer, så længe det er nødvendigt, indtil nogen kan læse deres filformater på den rigtige måde eller tilbyde en-til-en-funktionalitet. Vores forpligtelse til at understøtte BeOS R5-apps på Haiku er et bevis på dette...

Det er rigtigt!

Hvilken fremgangsmåde skal Haiku tage?

Jeg kan forestille mig den fredelige sameksistens af hpkg, mapper og applikationsbilleder:

Systemsoftware bruger .hpkg
For den mest brugte software (især dem, der skal planlægge rullende udgivelser), brug .hpkg (ca. 80 % af alle tilfælde)
Nogle installeret via .hpkg, vil applikationer drage fordel af at flytte til en applikationskataloginfrastruktur (f.eks. QtCreator): de vil blive distribueret som .hpkg, som før.

Hr. waddlesplash skriver:

Hvis alt du behøver er at se applikationer i /system/apps, i stedet bør vi gøre mapperne i Deskbar mere overskuelige for brugerne, da /system/apps er ikke beregnet til at blive åbnet og vist regelmæssigt af brugere (i modsætning til MacOS). For sådanne situationer har Haiku et andet paradigme, men denne mulighed er i teorien acceptabel.

Haiku modtager infrastrukturen til at køre applikationsbilleder, natlige, kontinuerlige og test builds af software, samt til tilfælde, hvor brugeren ønsker at "fryse det i tide", for privat og intern software, og andre specielle use cases (ca. 20% Af alle). Disse billeder indeholder de filer, der er nødvendige for at køre programmet .hpkg, monteret af systemet, og efter applikationen er afsluttet - afmonteret. (Måske kan en filhåndtering lægge filer .hpkg ind i applikationsbilleder, automatisk eller efter brugerens anmodning - vel som når du trækker en applikation til en netværksmappe eller eksternt drev. Det er bare en sang! Eller rettere, poesi - haiku.) På den anden side vil brugeren måske installere indholdet af billedet i form af filer.hpkg, hvorefter de vil blive opdateret og behandlet på samme måde, som hvis de blev installeret gennem HaikuDepot... Vi skal brainstorme).

Citat fra hr. waddlesplash:

Det kan potentielt være nyttigt at køre programmer fra eksterne drev eller netværksmapper. Og at tilføje muligheden for at konfigurere flere "zoner" til pkgman ville helt sikkert være en god funktion.

Et sådant system ville drage fordel af hpkg, mapper og applikationsbilleder. De er gode hver for sig, men sammen bliver de uovervindelige.

Konklusion

Haiku har en infrastruktur, der leverer en simpel og sofistikeret brugergrænseflade til pc'er, og som går langt ud over, hvad der typisk tilbydes til pc'er på LinuxPakkesystem .hpkg — er et sådant eksempel, men andre dele af systemet er også gennemsyret af sofistikering. Haiku ville dog have gavn af ordentlig understøttelse af applikationskataloger og billeder. Hvordan dette bedst gøres, er værd at diskutere med folk, der kender Haiku, dets filosofi og arkitektur meget bedre end jeg gør. Jeg har trods alt kun brugt Haiku i lidt over en uge. Ikke desto mindre tror jeg, at dette friske perspektiv vil være nyttigt for Haikus designere, udviklere og arkitekter. Som minimum ville jeg være glad for at være en "sparringspartner" for dem. Jeg har over 10 års praktisk erfaring med at arbejde med applikationskataloger og billedpakker til Linux, og jeg vil gerne finde en anvendelse til dem i Haiku, hvilket jeg mener, de passer perfekt til. De potentielle løsninger, jeg har foreslået, er ikke de eneste på de problemer, jeg har beskrevet, og hvis Haiku-teamet beslutter sig for at finde andre, mere elegante, er jeg helt med på det. I princippet tænker jeg allerede på en idé til, hvordan man kan lave systemet. hpkg endnu mere fantastisk uden at ændre den måde, det fungerer på. Det viser sig, at Haiku-teamet havde tænkt på applikationsbundter i lang tid, da de implementerede et pakkehåndteringssystem, men desværre (tror jeg) idéen blev "forældet". Måske er det på tide at genoplive det?

Prøv det selv! Når alt kommer til alt, giver Haiku-projektet billeder til opstart fra DVD eller USB, genereret daglig.
Har du nogen spørgsmål? Vi inviterer dig til den russisktalende telegramkanal.

Fejloversigt: Sådan skyder du dig selv i foden i C og C++. Haiku OS opskrift samling

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

Liste over artikler: første Den anden tredje Fjerde femte sjette Syvende

Kun registrerede brugere kan deltage i undersøgelsen. Log ind, Vær venlig.