TL; DR: Kan Haiku få ordentlig support til applikationspakker, såsom applikationsmapper (som .app på Mac) og/eller applikationsbilleder (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.
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é...
For fuld forståelse er jeg skaberen og forfatteren af AppImage, et Linux-applikationsdistributionsformat, der sigter mod Mac-enkelhed og giver fuld kontrol til applikationsforfattere og slutbrugere (hvis du vil vide mere, se и ).
Hvad hvis vi laver et AppImage til Haiku?
Lad os tænke lidt, rent teoretisk: hvad skal der gøres for at få , eller noget lignende, på Haiku? Det er ikke nødvendigt at skabe noget lige nu, for det system, der allerede findes i Haiku, fungerer fantastisk, men et imaginært eksperiment ville være rart. Det demonstrerer også det sofistikerede ved Haiku sammenlignet med Linux-desktopmiljøer, hvor sådanne ting er frygtelig vanskelige (det har jeg ret til at sige: Jeg har kæmpet med fejlretning i 10 år).
På Macintosh System 1 var hvert program en separat fil "administreret" i Finder. Ved at bruge 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. ), 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 mere end 10 års eksistens har AppImage vundet en vis appel og popularitet: Linus Torvalds selv godkendte det offentligt, og almindelige projekter (f.eks. LibreOffice, Krita, Inkscape, Scribus, ImageMagick) har taget det til sig som den vigtigste måde. at distribuere kontinuerlige eller natlige builds, uden at forstyrre installerede eller afinstallerede brugerapplikationer. Men Linux-desktopmiljøer og -distributioner klæber sig oftest stadig til den traditionelle, centraliserede vedligeholder-baserede distributionsmodel og/eller promoverer deres egen virksomhedsforretning og/eller ingeniørprogrammer baseret på (RedHat, Fedora, GNOME) og (Canonical, Ubuntu). Det kommer .
Hvordan det hele fungerer
- Hvert AppImage indeholder 2 dele: et lille dobbeltklik ELF (såkaldt.
runtime.c), efterfulgt af et filsystembillede .
- SquashFS-filsystemet indeholder applikationens nyttelast og alt det nødvendige for at køre det, som med rette sind ikke kan betragtes som en del af standardinstallationen for hvert ret nyere målsystem (Linux-distribution). Den indeholder også metadata, såsom applikationsnavn, ikoner, MIME-typer osv. 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 Linux-distributioner kan intet "med det rette sind" kaldes "en del af standardinstallationen for hvert nyt målsystem." Vi løser dette problem ved at bygge , 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 eksportereLD_LIBRARY_PATH, eller retterpathså 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 AppImage-fil efter download. Tro det eller ej, men dette er en reel barriere for nogle. Behovet for at indstille eksekverbarhedsbitten er besværligt selv for erfarne brugere. Som en løsning foreslog vi at installere en lille tjeneste, der overvåger AppImage-filer og indstiller deres eksekverbarhedsbit. I sin rene form er det ikke den bedste løsning, da det ikke fungerer ud af kassen. Linux-distributioner leverer ikke denne service, derfor har brugerne en dårlig oplevelse ud af boksen.
- Linux-brugere forventer, at et nyt program har et ikon i startmenuen. Du kan ikke fortælle systemet: "Se, der er en ny applikation, lad os arbejde." I stedet skal du ifølge XDG-specifikationen kopiere filen
.desktoptil det rigtige sted i/usrfor en systemdækkende installation eller i$HOMEfor individuelle. Ikoner af bestemte størrelser, i henhold til XDG-specifikationen, skal placeres bestemte steder iusreller$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 ovenstående ikke er nok, er der stadig ikke noget AppImage-ikon i filhåndteringen. Linux-verdenen har endnu ikke besluttet at implementere elficon (på trods af и ), 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 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.pngskal åbnes ved hjælp af Krita, og2.png- ved at bruge GIMP.
Lagerplacering for specifikationer på tværs af skriveborde, der bruges i , и 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 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 spekulerede på, hvad Linux-verdenen kunne lære af Mac OS X for at undgå at skrue op for systemintegration. Hvis du har tid og er til dette, så sørg for at læse, hvad Arnaud Gurdol, en af de første Mac OS X-ingeniører, sagde:
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.
Apple WWDC 2000 session 144 - Mac OS X: emballering af programmer og udskrivning af dokumenter.
Der er intet som denne infrastruktur på Linux-desktops, så vi leder efter løsninger omkring de strukturelle begrænsninger i AppImage-projektet.
Kommer Haiku til undsætning?
En ting mere: Linux-platforme som grundlag for skrivebordsmiljøer har en tendens til at være så underspecificerede, at mange ting, der er ganske enkle i et sammenhængende full-stack-system, er frustrerende fragmenterede og komplekse i Linux. Jeg viede en hel rapport til problemer relateret til Linux-platformen til desktop-miljøer (kyndige udviklere bekræftede, at alt vil forblive på denne måde i meget lang tid).
Min rapport om problemerne med Linux-desktopmiljøer 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
Mens den naive tilgang til at "portere" AppImage til Haiku er blot at forsøge at bygge (hovedsageligt runtime.c og servicere) dens komponenter (hvilket måske endda er muligt!), vil dette ikke give den store fordel for Haiku. For faktisk er de fleste af disse problemer løst i Haiku og er konceptuelt sunde. Haiku leverer præcis de systeminfrastrukturbyggeblokke, som jeg har ledt efter i Linux-desktopmiljøer i så lang tid og ikke kunne tro, at de ikke var der. Nemlig:
Tro det eller ej, dette er noget mange Linux-brugere ikke kan overkomme. På 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 krykker og løsninger, der kræves af AppImage på Linux, bliver unødvendige på Haiku, som har den enkelhed og sofistikerede kerne, der gør, at den kan klare de fleste af vores behov.
Har Haiku alligevel brug for app-pakker?
Dette fører til et stort spørgsmål. Hvis det var en størrelsesorden nemmere at skabe et system som AppImage på Haiku end på Linux, ville det så være værd at gøre? Eller har Haiku med sit hpkg-pakkesystem effektivt elimineret behovet for at udvikle en sådan idé? Nå, for at svare skal vi se på motivationen bag eksistensen af 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å samme 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
.exeTil Windows,.dmgtil Mac og.AppImagetil Linux. Eller måske vil jeg tjene penge på adgang til denne side. Alt er muligt? Hvad skal jeg lægge der til Haiku? Filen er nok.hpkgmed 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
På 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 :
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/appser 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.hpkgind 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 ramme, der giver en enkel og sofistikeret brugeroplevelse til pc'en og går langt ud over, hvad der typisk leveres til Linux pc'en. Pakkesystem .hpkg er et sådant eksempel, men resten af systemet er også gennemsyret af sofistikering. Haiku ville dog drage fordel af korrekt katalog- og applikationsbilledesupport. Hvordan man bedst gør dette, er værd at diskutere med folk, der kender Haiku, dens filosofi og arkitektur meget bedre end jeg gør. Jeg har trods alt brugt Haiku i lidt over en uge. Ikke desto mindre tror jeg, at Haikus designere, udviklere og arkitekter vil drage fordel af dette friske perspektiv. Jeg ville i det mindste være glad for at være deres "sparringspartner." Jeg har over 10 års praktisk erfaring med Linux-applikationskataloger og bundter, og jeg vil gerne finde en brug for dem i Haiku, som jeg synes, de passer perfekt til. De potentielle løsninger, jeg har foreslået, er på ingen måde de eneste rigtige til de problemer, jeg har beskrevet, og hvis Haiku-teamet beslutter sig for at finde andre, mere elegante, er jeg helt for det. Grundlæggende tænker jeg allerede på ideen om, hvordan man laver et system 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 .
Har du nogen spørgsmål? Vi inviterer dig til den russisktalende .
Fejloversigt:
Fra oversættelse: dette er den ottende og sidste artikel i serien om Haiku.
Liste over artikler:
Kun registrerede brugere kan deltage i undersøgelsen. , Vær venlig.
Giver det mening at portere hpkg-systemet til Linux?
-
Ja
-
Nej
-
Allerede implementeret, vil jeg skrive i kommentarerne
20 brugere stemte. 5 brugere undlod at stemme.
Kilde: www.habr.com