Något annat: Haiku-app-buntar?

TL; DR: Kan Haiku få ordentligt stöd för applikationspaket, som applikationskataloger (som .app på Mac) och/eller programbilder (Linux AppImage)? Jag tycker att detta skulle vara ett värdigt tillägg som är lättare att implementera korrekt än andra system eftersom det mesta av infrastrukturen redan är på plats.

En vecka sedan Jag upptäckte Haiku, ett oväntat bra system. Tja, eftersom jag länge har varit intresserad av kataloger och applikationsbilder (inspirerad av enkelheten hos Macintosh), är det inte förvånande att jag fick en idé...

För full förståelse är jag skaparen och författaren till AppImage, ett distributionsformat för Linux-applikationer som syftar till Mac-enkelhet och ger full kontroll till applikationsförfattare och slutanvändare (om du vill veta mer, se wiki и dokumentation).

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

Låt oss fundera lite, rent teoretiskt: vad måste göras 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 fantastiskt, men ett tänkt experiment skulle vara trevligt. Det visar också hur sofistikerad Haiku är, jämfört med Linux-skrivbordsmiljöer, där sådana saker är fruktansvärt svåra (jag har rätt att säga det: jag har kämpat med felsökning i 10 år).

På Macintosh System 1 var varje applikation en separat fil "hanterad" i Finder. Med AppImage försöker jag återskapa samma användarupplevelse på Linux.

För det första, vad är en AppImage? Detta är ett system för att släppa tredjepartsapplikationer (t.ex. Ultimaker Cure), så att applikationer kan släppas när och hur de vill: det finns inget behov av att känna till detaljerna för olika distributioner, bygga policyer eller bygga infrastruktur, inget underhållsstöd behövs och de berättar inte för användarna vad (inte) de kan installera på sina datorer. AppImage ska förstås som något som liknar ett Mac-paket i formatet .app inuti diskavbildningen .dmg. Den största skillnaden är att applikationer inte kopieras, utan förblir i AppImage för alltid, ungefär på samma sätt som Haiku-paket .hpkg monterad och aldrig installerad i vanlig mening.

Under loppet av mer än 10 år av existens har AppImage vunnit en viss tilltal och popularitet: Linus Torvalds själv godkände det offentligt, och vanliga projekt (till exempel LibreOffice, Krita, Inkscape, Scribus, ImageMagick) har antagit det som det huvudsakliga sättet att distribuera kontinuerliga eller nattliga builds, utan att störa installerade eller avinstallerade användarapplikationer. Emellertid håller Linux-skrivbordsmiljöer och distributioner oftast fortfarande fast vid den traditionella, centraliserade underhållsbaserade distributionsmodellen och/eller marknadsför sina egna företagsaffärer och/eller tekniska program baserade på Flatpak (RedHat, Fedora, GNOME) och Snappy (Canonical, Ubuntu). Det kommer löjligt.

Hur det hela fungerar

• Varje AppImage innehåller 2 delar: en liten dubbelklick-ELF (så kallad. runtime.c), följt av en filsystemsbild SquashFS.

• SquashFS-filsystemet innehåller applikationens nyttolast och allt som behövs för att köra det, vilket med rätta sinne inte kan anses vara en del av standardinstallationen för varje ganska nyligen målsystem (Linux-distribution). Den innehåller också metadata, såsom applikationens namn, ikoner, MIME-typer, etc., etc.

• När den körs av användaren använder runtime FUSE och squashfuse för att montera filsystemet, och hanterar sedan körning av någon ingångspunkt (aka AppRun) inuti den monterade AppImage.
  Filsystemet avmonteras efter att processen är klar.

Allt verkar enkelt.

Och dessa saker komplicerar allt:

• Med en sådan mängd olika Linux-distributioner kan ingenting "med rätt sinne" kallas "en del av standardinstallationen för varje nytt målsystem." Vi arbetar kring detta problem genom att bygga exkluderingslista, så att du kan avgöra vad som kommer att paketeras i AppImage och vad som måste tas någon annanstans. Samtidigt saknar vi ibland, trots att allt i allmänhet fungerar utmärkt. Av denna anledning rekommenderar vi att paketskapare testar AppImages på alla målsystem (distributioner).
• Programnyttolaster måste kunna flyttas över filsystemet. Tyvärr har många applikationer hårdkodade absoluta vägar till till exempel resurser i /usr/share. Detta måste fixas på något sätt. Dessutom måste du antingen exportera LD_LIBRARY_PATH, eller fixa rpath så att laddaren kan hitta relaterade bibliotek. Den första metoden har sina nackdelar (som övervinns på komplexa sätt), och den andra är helt enkelt besvärlig.
• Den största UX-fällan för användare är det ställ in körbar bit AppImage-fil efter nedladdning. Tro det eller ej, men detta är en riktig barriär för vissa. Behovet av att ställa in körbarhetsbiten är besvärligt även för erfarna användare. Som en lösning föreslog vi att installera en liten tjänst som övervakar AppImage-filer och ställer in deras körbarhetsbit. I sin rena form är det inte den bästa lösningen, eftersom det inte fungerar direkt. Linux-distributioner tillhandahåller inte denna tjänst, därför har användarna en dålig upplevelse direkt.
• Linux-användare förväntar sig att ett nytt program har en ikon i startmenyn. Du kan inte säga till systemet: "Titta, det finns en ny applikation, låt oss jobba." Istället, enligt XDG-specifikationen, måste du kopiera filen .desktop till rätt plats i /usr för en systemomfattande installation, eller i $HOME för individ. Ikoner av vissa storlekar, enligt XDG-specifikationen, måste placeras på vissa platser i usr eller $HOME, och kör sedan kommandon i arbetsmiljön för att uppdatera ikoncachen, eller hoppas att arbetsmiljöhanteraren kommer att ta reda på det och automatiskt upptäcka allt. Samma med MIME-typer. Som en lösning föreslås att man använder samma tjänst, som förutom att sätta körbarhetsflaggan kommer, om det finns ikoner osv. i AppImage, kopiera dem från AppImage till rätt ställen enligt XDG. När den tas bort eller flyttas förväntas tjänsten rensa allt. Naturligtvis finns det skillnader i beteendet för varje arbetsmiljö, i grafiska filformat, deras storlekar, lagringsplatser och metoder för att uppdatera cacher, vilket skapar problem. Kort sagt, denna metod är en krycka.
• Om ovanstående inte räcker finns det fortfarande ingen AppImage-ikon i filhanteraren. Linux-världen har ännu inte bestämt sig för att implementera elficon (trots diskussion и genomförande), så det är omöjligt att bädda in ikonen direkt i applikationen. Så det visar sig att applikationer i filhanteraren inte har sina egna ikoner (ingen skillnad, AppImage eller något annat), de finns bara i startmenyn. Som en lösning använder vi miniatyrer, en mekanism som ursprungligen utformades för att göra det möjligt för skrivbordshanterare att visa miniatyrbilder av grafiska filer som sina ikoner. Följaktligen fungerar tjänsten för att ställa in körbarhetsbiten också som en "miniatyriserare", som skapar och skriver ikonminiatyrer till lämpliga platser /usr и $HOME. Den här tjänsten utför också rensning om AppImage tas bort eller flyttas. På grund av det faktum att varje skrivbordshanterare beter sig lite olika, till exempel i vilka format den accepterar ikoner, i vilka storlekar eller platser, är allt detta verkligen smärtsamt.
• Applikationen kraschar helt enkelt vid körning om fel uppstår (det finns till exempel ett bibliotek som inte är en del av bassystemet och som inte tillhandahålls i AppImage), och det finns ingen som talar om för användaren i det grafiska användargränssnittet exakt vad som händer. Vi började komma runt detta genom att använda aviseringar på skrivbordet, vilket innebär att vi måste fånga upp fel från kommandoraden, konvertera dem till användarförstådda meddelanden, som sedan måste visas på skrivbordet. Och naturligtvis hanterar varje skrivbordsmiljö dem lite olika.
• För tillfället (september 2019 - översättarens anmärkning) har jag inte hittat något enkelt sätt att berätta för systemet att filen 1.png måste öppnas med Krita, och 2.png - använder GIMP.

Lagringsplats för cross-desktop-specifikationer som används i GNOME, KDE и Xfce är freedesktop.org

Att uppnå den sofistikerade nivån som är djupt invävd i Haiku-arbetsmiljön är svårt, för att inte säga omöjligt, på grund av specifikationerna XDG från freedesktop.org för cross-desktop, samt implementeringar av skrivbordshanterare baserat på dessa specifikationer. Som ett exempel kan vi nämna en systemomfattande Firefox-ikon: uppenbarligen trodde författarna till XDG inte ens att en användare kunde ha flera versioner av samma applikation installerad.

Ikoner för olika versioner av Firefox

Jag undrade vad Linux-världen kunde lära sig av Mac OS X för att undvika att skruva upp systemintegrationen. Om du har tid och är intresserad av det här, se till att läsa vad Arnaud Gurdol, en av de första Mac OS X-ingenjörerna, sa:

Vi ville göra det lika enkelt att installera programmet som att dra programikonen från någonstans (server, extern enhet) till din datorenhet. För att göra detta lagrar applikationspaketet all information, inklusive ikoner, version, filtyp som bearbetas, typ av URL-scheman som systemet behöver känna till för att bearbeta applikationen. Detta inkluderar även information för "central lagring" i databasen Icon Services och Launch Services. För att stödja prestanda "upptäcks" applikationer på flera "välkända" platser: system- och användarprogramkatalogerna, och några andra automatiskt om användaren navigerar till Finder i katalogen som innehåller applikationen. I praktiken fungerade detta mycket bra.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 session 144 - Mac OS X: paketera applikationer och skriva ut dokument.

Det finns inget liknande den här infrastrukturen på Linux-datorer, så vi letar efter lösningar kring de strukturella begränsningarna i AppImage-projektet.

Kommer Haiku till undsättning?

Och en sak till: Linux-plattformar som bas för skrivbordsmiljöer tenderar att vara så underspecificerade att många saker som är ganska enkla i ett konsekvent fullstacksystem är frustrerande fragmenterade och komplexa i Linux. Jag ägnade en hel rapport åt frågor relaterade till Linux-plattformen för skrivbordsmiljöer (kunniga utvecklare bekräftade att allt kommer att förbli så här under mycket lång tid).

Min rapport om problemen med Linux-skrivbordsmiljöer 2018

Till och med Linus Torvalds medgav att fragmentering var anledningen till att arbetsplatsidén misslyckades.

Kul att se Haiku!

Haiku gör allt otroligt enkelt

Även om det naiva tillvägagångssättet för att "portera" AppImage till Haiku är att helt enkelt försöka bygga (främst runtime.c och serva) dess komponenter (vilket till och med kan vara möjligt!), kommer detta inte att ge mycket fördel för Haiku. För i själva verket är de flesta av dessa problem lösta i Haiku och är begreppsmässigt sunda. Haiku tillhandahåller exakt de byggstenar för systeminfrastruktur som jag har letat efter i Linux-skrivbordsmiljöer så länge och inte kunde tro att de inte fanns där. Nämligen:

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

• ELF-filer som inte har en körbarhetsbit får en automatiskt när du dubbelklickar i filhanteraren.
• Applikationer kan ha inbyggda resurser, till exempel ikoner, som visas i filhanteraren. Det finns inget behov av att kopiera en massa bilder till speciella kataloger med ikoner, och därför behöver du inte rensa upp dem efter att ha tagit bort eller flyttat programmet.
• Det finns en databas för att länka applikationer med dokument, det finns ingen anledning att kopiera några filer för detta.
• I lib/-katalogen bredvid den körbara filen, söks bibliotek som standard.
• Det finns inga många distributioner och skrivbordsmiljöer; vad som än fungerar, fungerar överallt.
• Det finns ingen separat modul att köra som skiljer sig från Applications-katalogen.
• Applikationer har inte inbyggda absoluta sökvägar till sina resurser, de har speciella funktioner för att bestämma platsen vid körning.
• Idén med komprimerade filsystembilder har introducerats: detta är vilket hpkg-paket som helst. Alla är monterade av kärnan.
• Varje fil öppnas av programmet som skapade den, om du inte uttryckligen anger något annat. Vad coolt är det här!

Två png-filer. Notera de olika ikonerna som indikerar att de kommer att öppnas av olika program när du dubbelklickar på dem. Notera också rullgardinsmenyn "Öppna med:" där användaren kan välja en enskild applikation. Hur enkelt!

Det ser ut som att många av de kryckor och lösningar som krävs av AppImage på Linux blir onödiga på Haiku, som har den enkelhet och sofistikerade kärnan som gör att den klarar de flesta av våra behov.

Behöver Haiku apppaket trots allt?

Detta leder till en stor fråga. Om det vore en storleksordning lättare att skapa ett system som AppImage på Haiku än på Linux, skulle det vara värt att göra det? Eller har Haiku, med sitt hpkg-paketsystem, effektivt eliminerat behovet av att utveckla en sådan idé? Tja, för att svara måste vi titta på motivationen bakom existensen av AppImages.

Användarens perspektiv

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

• Jag vill installera ett program utan att be om ett administratörslösenord (root). Det finns inget koncept med administratör på Haiku, användaren har full kontroll eftersom det är ett personligt system! (I princip kan du föreställa dig detta i multiplayer-läge, jag hoppas att utvecklarna håller det enkelt)
• Jag vill få de senaste och bästa versionerna av applikationer, utan att vänta på att de ska dyka upp i min distribution (oftast betyder detta "aldrig", åtminstone om jag inte uppdaterar hela operativsystemet). På Haiku är detta "löst" med flytande utsläpp. Detta innebär att du kan få de senaste och bästa versionerna av applikationer, men för att göra detta måste du ständigt uppdatera resten av systemet, vilket effektivt gör det till ett "rörligt mål".
• Jag vill ha flera versioner av samma applikation sida vid sida, eftersom det inte finns något sätt att veta vad som var trasigt i den senaste versionen, eller säg, jag som webbutvecklare behöver testa mitt arbete under olika versioner av webbläsaren. Haiku löser det första problemet, men inte det andra. Uppdateringar rullas tillbaka, men bara för hela systemet, det är omöjligt (så vitt jag vet) att köra till exempel flera versioner av WebPositive eller LibreOffice samtidigt.

En av utvecklarna skriver:

Grunden är i huvudsak detta: användningsfallet är så sällsynt att det inte är meningsfullt att optimera för det; att behandla det som ett specialfall i HaikuPorts verkar mer än acceptabelt.

• Jag måste ha appar där jag gillar dem, inte på min startenhet. Jag får ofta slut på diskutrymme, så jag måste ansluta en extern enhet eller nätverkskatalog för att lagra applikationer (alla versioner som jag har laddat ner). Om jag ansluter en sådan enhet behöver jag applikationer som startas genom att dubbelklicka. Haiku sparar gamla versioner av paket, men jag vet inte hur man flyttar dem till en extern enhet, eller hur man startar applikationer därifrån senare.

Utvecklarens kommentar:

Tekniskt sett är detta redan möjligt med mount-kommandot. Naturligtvis kommer vi att göra ett GUI för detta så fort vi har tillräckligt många intresserade användare.

• Jag behöver inte miljontals filer utspridda över filsystemet som jag inte kan hantera manuellt själv. Jag vill ha en fil per applikation som jag enkelt kan ladda ner, flytta, ta bort. På Haiku löses detta problem med hjälp av paket .hpkg, som överför till exempel python från tusentals filer till en. Men om det till exempel finns Scribus som använder python, då måste jag hantera minst två filer. Och jag måste passa på att behålla versioner av dem som fungerar med varandra.

Flera versioner av AppImages körs sida vid sida på samma Linux

Ett applikationsutvecklares perspektiv

Låt oss titta från en applikationsutvecklares synvinkel:

• Jag vill kontrollera hela användarupplevelsen. Jag vill inte vara beroende av ett operativsystem för att tala om för mig när och hur jag ska släppa applikationer. Haiku tillåter utvecklare att arbeta med sina egna hpkg-förråd, men det betyder att användarna måste ställa in dem manuellt, vilket gör idén "mindre attraktiv."
• Jag har en nedladdningssida på min hemsida där jag distribuerar .exe för Windows, .dmg för Mac och .AppImage för Linux. Eller jag kanske vill tjäna pengar på åtkomst till den här sidan, allt är möjligt? Vad ska jag lägga där för Haiku? Filen räcker .hpkg med beroenden endast från HaikuPorts
• Min programvara kräver specifika versioner av annan programvara. Till exempel är det känt att Krita kräver en patchad version av Qt, eller Qt som är finjusterad till en specifik version av Krita, åtminstone tills patcharna trycks tillbaka i Qt. Du kan paketera din egen Qt för din applikation i ett paket .hpkg, men troligtvis är detta inte välkommet.

Vanlig sida för nedladdning av applikationer. Vad ska jag skriva här för Haiku?

Kommer buntar (finns som programkataloger som AppDir eller .app i Apple-stil) och/eller bilder (i form av kraftigt modifierade AppImages eller .dmg från Apple) applikationer ett användbart tillägg till Haiku-skrivbordsmiljön? Eller kommer det att späda ut hela bilden och leda till fragmentering, och därför lägga till komplexitet? Jag är sliten: å ena sidan bygger skönheten och sofistikeringen av Haiku på det faktum att det vanligtvis finns ett sätt att göra något, snarare än många. Å andra sidan är det mesta av infrastrukturen för kataloger och/eller applikationssviter redan på plats, så systemet ropar på att de återstående få procenten ska falla på plats.

Enligt utvecklaren herr. waddlesplash

På Linux de (kataloger och applikationssatser, - ca. översättare) är troligen en teknisk lösning på systemproblem. På Haiku föredrar vi att helt enkelt lösa systemproblem.

Vad tror du?

Innan du svarar...

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

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

De stöds helt enkelt inte lika bra som, säg, Macintosh Finder. Hur coolt skulle det vara om QtCreator-katalogen hade ett "QtCreator"-namn och -ikon i det övre vänstra hörnet, och startar programmet när du dubbelklickar på det?

Lite tidigare har jag redan frågade:

Är du säker på att du kan köra dina decennium gamla appar idag när alla appbutiker och distributionsförråd har glömt dem och deras beroenden? Är du säker på att du fortfarande kommer att kunna få tillgång till ditt nuvarande jobb i framtiden?

Finns det redan ett svar från Haiku, eller kan kataloger och applikationspaket hjälpa till här? Jag tror att de kan.

Enligt mr. waddlesplash:

Ja, vi har svaret på frågan: vi kommer helt enkelt att stödja dessa applikationer så länge det behövs tills någon kan läsa deras filformat på rätt sätt eller tillhandahålla en-till-en-funktionalitet. Vårt åtagande att stödja BeOS R5-appar på Haiku är ett bevis på detta...

Det är säkert!

Vilken handling bör Haiku vidta?

Jag kan föreställa mig den fredliga samexistensen av hpkg, kataloger och applikationsbilder:

• Systemprogramvaran använder .hpkg
• För den mest använda programvaran (särskilt de som behöver schemalägga rullande releaser), använd .hpkg (ungefär 80 % av alla fall)
• Vissa installerade via .hpkg, kommer applikationer att dra nytta av att flytta till en applikationskataloginfrastruktur (t.ex. QtCreator): de kommer att distribueras som .hpkg, som förut.

herr. waddlesplash skriver:

Om allt du behöver är att se applikationer i /system/apps, istället borde vi göra katalogerna i Deskbar mer lätthanterliga för användarna, eftersom /system/apps är inte avsedd att regelbundet öppnas och visas av användare (till skillnad från MacOS). För sådana situationer har Haiku ett annat paradigm, men detta alternativ är i teorin acceptabelt.

• Haiku får infrastrukturen för att köra applikationsbilder, nattliga, kontinuerliga och testversioner av mjukvara, samt för fall då användaren vill "frysa den i tid", för privat och intern programvara och andra speciella användningsfall (cirka 20 % av allt). Dessa bilder innehåller de filer som behövs för att köra programmet .hpkg, monterad av systemet, och efter att applikationen är klar - avmonterad. (Kanske en filhanterare kan lägga filer .hpkg till applikationsbilder, automatiskt eller på användarens begäran - ja, som när du drar en applikation till en nätverkskatalog eller extern enhet. Det är bara en låt! Eller snarare poesi - haiku.) Å andra sidan kanske användaren vill installera innehållet i bilden i form av filer.hpkg, varefter de kommer att uppdateras och bearbetas på samma sätt som om de installerades via HaikuDepot... Vi måste brainstorma).

Citat från mr. waddlesplash:

Att köra applikationer från externa enheter eller nätverkskataloger kan potentiellt vara användbart. Och att lägga till möjligheten att konfigurera fler "zoner" för pkgman skulle definitivt vara en trevlig funktion.

Ett sådant system skulle dra fördel av hpkg, kataloger och applikationsbilder. De är bra var för sig, men tillsammans kommer de att bli oövervinnerliga.

Slutsats

Haiku har ett ramverk som ger en enkel och sofistikerad användarupplevelse för PC:n och går långt utöver vad som vanligtvis tillhandahålls för Linux PC. Paketsystem .hpkg är ett sådant exempel, men resten av systemet är också genomsyrat av sofistikering. Haiku skulle dock dra nytta av korrekt katalog- och programavbildningsstöd. Hur man bäst gör detta är värt att diskutera med folk som känner till Haiku, dess filosofi och arkitektur mycket bättre än jag. Jag har trots allt använt Haiku i lite över en vecka. Ändå tror jag att detta fräscha perspektiv kommer att vara användbart för Haikus designers, utvecklare och arkitekter. Åtminstone skulle jag gärna vara deras "sparringspartner". Jag har över 10 års praktisk erfarenhet av Linux-programkataloger och paket, och jag skulle vilja hitta en användning för dem i Haiku, som jag tror att de passar perfekt för. De potentiella lösningarna jag har föreslagit är inte på något sätt de enda korrekta för de problem jag har beskrivit, och om Haiku-teamet bestämmer sig för att hitta andra, mer eleganta, är jag helt för det. I grund och botten tänker jag redan på idén om hur man gör ett system hpkg ännu mer fantastiskt utan att ändra hur det fungerar. Det visar sig att Haiku-teamet hade tänkt på applikationspaket länge när de implementerade ett pakethanteringssystem, men tyvärr (tror jag) blev idén "föråldrad". Kanske dags att återuppliva det?

Prova själv! När allt kommer omkring ger Haiku-projektet bilder för uppstart från DVD eller USB, genererade dagligen.
Har du några frågor? Vi inbjuder dig till den rysktalande telegramkanal.

Felöversikt: Hur man skjuter sig själv i foten i C och C++. Haiku OS receptsamling

Från författare översättning: detta är den åttonde och sista artikeln i serien om Haiku.

Lista över artiklar: första andra tredje fjärde femte sjätte sjunde

Endast registrerade användare kan delta i undersökningen. Logga in, Snälla du.

Är det vettigt att porta hpkg-systemet till Linux?

• Ja

• Ingen

• Redan implementerad, jag kommer att skriva i kommentarerna

20 användare röstade. 5 användare avstod från att rösta.

Källa: will.com