🥇Altro: pacchetti di applicazioni Haiku?

TL; DR: Haiku può ottenere un supporto adeguato per i pacchetti applicativi, come le directory applicative (come .app in Mac) e/o immagini di applicazioni (Linux AppImage)? Penso che questa sarebbe un'aggiunta degna di nota e più facile da implementare correttamente rispetto ad altri sistemi, poiché la maggior parte dell'infrastruttura è già in atto.

Una settimana fa Ho scoperto Haiku, un sistema sorprendentemente valido. E poiché da tempo mi interesso di cataloghi e immagini di applicazioni (ispirato dalla semplicità del Macintosh), non sorprende che mi sia venuta un'idea...

Per essere chiari, sono il creatore e autore di AppImage, un formato di distribuzione di applicazioni Linux che mira a portare la semplicità del Mac sul tavolo e offre il controllo completo agli autori delle applicazioni e agli utenti finali (vedi il mio articolo per maggiori dettagli). wiki и documentazione).

E se creassimo un'AppImage per Haiku?

Pensiamo un po', puramente teoricamente: cosa bisogna fare per ottenere AppImage, o qualcosa di simile, su Haiku? Non c'è bisogno di creare qualcosa adesso, dato che il sistema di Haiku funziona già a meraviglia, ma un esperimento ipotetico sarebbe bello. Dimostra anche la sofisticatezza di Haiku rispetto ai desktop Linux, dove queste cose sono terribilmente difficili (ho il diritto di dirlo: ho lottato con il debugging per 10 anni ormai).

Su Macintosh System 1, ogni applicazione era un file separato, "gestito" nel Finder. Utilizzando AppImage, sto cercando di ricreare la stessa esperienza utente su Linux.

Innanzitutto, cos'è AppImage? È un sistema per rilasciare applicazioni di terze parti (ad esempio, Cura Ultimaker), che consente agli utenti di rilasciare applicazioni quando e come desiderano: non hanno bisogno di conoscere le specifiche delle varie distribuzioni, le policy di compilazione o l'infrastruttura di compilazione, non hanno bisogno del supporto dei manutentori e non devono dire agli utenti cosa non possono installare sui loro computer. Un'AppImage dovrebbe essere intesa come qualcosa di simile a un pacchetto Mac nel formato .app all'interno dell'immagine del disco .dmgLa differenza principale è che le applicazioni non vengono copiate, ma rimangono per sempre all'interno dell'AppImage, proprio come i pacchetti Haiku. .hpkg sono montati e mai installati nel senso usuale.

Nel corso della sua storia ultradecennale, AppImage ha acquisito una certa popolarità e trazione: lo stesso Linus Torvalds l'ha pubblicamente sostenuta e progetti popolari (ad esempio, LibreOffice, Krita, Inkscape, Scribus, ImageMagick) l'hanno adottata come metodo principale per distribuire build continue o notturne che non interferiscono con le applicazioni installate o disinstallate dagli utenti. Tuttavia, gli ambienti desktop e le distribuzioni Linux spesso si aggrappano ancora al tradizionale modello di distribuzione centralizzato basato sul manutentore e/o promuovono i propri programmi aziendali e/o di ingegneria basati su di esso. Flatpak (RedHat, Fedora, GNOME) e Elegante (Canonical, Ubuntu). Ci stiamo arrivando. ridicolmente.

Come funziona

Ogni AppImage contiene 2 parti: un piccolo ELF eseguibile (il cosiddetto runtime.c), seguito da un'immagine del file system SquashFS.

Il file system SquashFS contiene un payload sotto forma di applicazione e tutto il necessario per eseguirla, che in una mente sana di mente non dovrebbe essere considerato parte dell'installazione predefinita per ogni sistema di destinazione relativamente recente (distribuzione Linux). Contiene anche metadati, come il nome dell'applicazione, le icone, i tipi MIME e così via.

Una volta avviato dall'utente, il runtime utilizza FUSE e squashfuse per montare il file system, quindi elabora l'avvio di un punto di ingresso (il cosiddetto AppRun) all'interno dell'AppImage montata.
Il file system viene smontato al termine del processo.

Sembra tutto semplice.

E queste cose complicano le cose:

Con una tale varietà di distribuzioni Linux, nulla nella mente sana può essere definito "parte dell'installazione predefinita per ogni nuovo sistema di destinazione". Aggiriamo questo problema creando elenco di esclusione, che ci permette di determinare cosa verrà impacchettato in un'AppImage e cosa dovrà essere reperito altrove. Tuttavia, a volte non riusciamo a centrare l'obiettivo, anche se generalmente tutto funziona correttamente. Per questo motivo, consigliamo ai creatori di pacchetti di testare le AppImage su tutti i sistemi di destinazione (distribuzioni).
Le applicazioni come payload devono essere spostabili attraverso il file system. Sfortunatamente, molte applicazioni hanno percorsi assoluti codificati, ad esempio, per le risorse in /usr/shareQuesto problema deve essere risolto in qualche modo. Oltre a ciò, deve essere esportato LD_LIBRARY_PATH, o corretto rpath in modo che il loader possa trovare le librerie collegate. Il primo metodo ha i suoi svantaggi (che possono essere superati con metodi complessi), mentre il secondo è semplicemente macchinoso.
La più grande trappola UX per gli utenti è che devi imposta il bit eseguibile File AppImage dopo il download. Che ci crediate o no, questo rappresenta un vero ostacolo per alcuni. Impostare il bit eseguibile è macchinoso anche per gli utenti esperti. Come soluzione alternativa, abbiamo suggerito di installare un piccolo servizio che monitora i file AppImage e ne imposta il bit eseguibile. Nella sua forma pura, questa non è la soluzione migliore, poiché non funziona immediatamente. Le distribuzioni Linux non includono questo servizio, quindi gli utenti hanno un'esperienza di installazione scadente.
Gli utenti Linux si aspettano che una nuova applicazione abbia un'icona nel launcher. Non si può semplicemente dire: "Guarda, c'è una nuova app, iniziamo". Invece, secondo la specifica XDG, è necessario copiare il file. .desktop nel posto giusto in /usr per un'installazione a livello di sistema, o in $HOME per individuo. Le icone di determinate dimensioni, secondo la specifica XDG, devono essere posizionate in determinati punti in usr o $HOME, quindi eseguire comandi nell'area di lavoro per aggiornare la cache delle icone, oppure sperare che il gestore dell'area di lavoro lo capisca e rilevi automaticamente tutto. Lo stesso vale per i tipi MIME. Come soluzione alternativa, si consiglia di utilizzare lo stesso servizio che, oltre a impostare il flag eseguibile, se icone, ecc. sono presenti nell'AppImage, le copierà dall'AppImage nelle posizioni corrette in base a XDG. Quando si eliminano o si spostano icone, il servizio dovrebbe cancellare tutto. Naturalmente, ogni area di lavoro ha comportamenti diversi, inclusi formati di file grafici, dimensioni, posizioni di archiviazione e metodi di aggiornamento della cache, che sono ciò che crea il problema. In breve, questo metodo è una soluzione alternativa.
Come se tutto ciò non bastasse, non c'è ancora l'icona AppImage nel file manager. Il mondo Linux non ha ancora deciso di implementare elficon (nonostante discussione и implementazione), quindi è impossibile incorporare un'icona direttamente in un'applicazione. Ciò significa che le applicazioni nel file manager non hanno le proprie icone (AppImage o altro), ma solo nel menu di avvio. Come soluzione alternativa, utilizziamo le miniature, un meccanismo originariamente progettato per consentire ai gestori desktop di visualizzare le miniature dei file grafici come icone. Di conseguenza, il servizio per l'impostazione del bit eseguibile funge anche da "miniaturizzatore", creando e scrivendo le miniature delle icone nelle posizioni appropriate. /usr и $HOMEQuesto servizio pulisce anche le AppImage se vengono eliminate o spostate. Poiché ogni gestore desktop si comporta in modo leggermente diverso, ad esempio per quanto riguarda i formati, le dimensioni e le posizioni delle icone accettate, questo può essere piuttosto complicato.
L'applicazione si blocca semplicemente durante l'esecuzione se si verificano errori (ad esempio, c'è una libreria che non fa parte del sistema di base e non è inclusa nell'AppImage) e nessuno dice all'utente nella GUI cosa sta succedendo esattamente. Abbiamo iniziato a risolvere questo problema utilizzando preavviso sul desktop, il che significa che dobbiamo intercettare gli errori dalla riga di comando, convertirli in messaggi leggibili dall'utente e quindi visualizzarli sul desktop. E, naturalmente, ogni ambiente desktop li gestisce in modo leggermente diverso.
Al momento (settembre 2019, - nota del traduttore) non ho trovato un modo semplice per dire al sistema che il file 1.png devi aprirlo con Krita, e 2.png — utilizzando GIMP.

La posizione di archiviazione per le specifiche cross-desktop utilizzate in GNOME, KDE и Xfce è freedesktop.org

Raggiungere il livello di sofisticatezza profondamente intrecciato nell'ambiente desktop Haiku è difficile, se non impossibile, a causa delle specifiche XDG da freedesktop.org per implementazioni cross-desktop e desktop manager basate su queste specifiche. Un esempio è una singola icona di Firefox a livello di sistema: a quanto pare, gli autori di XDG non hanno mai considerato che un utente potesse avere installate più versioni della stessa applicazione.

Icone per diverse versioni di Firefox

Mi chiedevo cosa il mondo Linux potesse imparare da Mac OS X per evitare di compromettere l'integrazione dei sistemi. Se avete tempo e siete coinvolti in questo tipo di lavoro, assicuratevi di leggere cosa ha detto Arnaud Gourdol, uno dei primi ingegneri di Mac OS X:

Volevamo che installare un'app fosse semplice come trascinare l'icona di un'app da qualche parte (un server, un'unità esterna) sul disco rigido del computer. Per raggiungere questo obiettivo, tutte le informazioni che il sistema deve conoscere per elaborare l'app, tra cui icone, versioni, tipi di file e schemi URL, vengono memorizzate nel pacchetto dell'app. Questo include anche le informazioni per l'"archiviazione centralizzata" nei database di Icon Services e Launch Services. Per supportare le prestazioni, le app vengono "rilevate" in diverse posizioni "ben note": le cartelle di sistema e Applicazioni utente, oltre a diverse altre automaticamente se l'utente accede alla directory contenente l'app nel Finder. Nella pratica, questo ha funzionato molto bene.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 Sessione 144 - Mac OS X: Creazione di pacchetti di applicazioni e stampa di documenti.

Negli ambienti di produzione Linux non esiste nulla di simile a questa infrastruttura, quindi stiamo cercando soluzioni alternative per le limitazioni strutturali del progetto AppImage.

Haiku verrà in soccorso?

E un'altra cosa: le piattaforme Linux come base per gli ambienti desktop sono in genere così poco specificate che molte cose che sarebbero piuttosto semplici in un sistema coerente e full-stack diventano frustrantemente frammentate e complesse in Linux. Ho dedicato un intero intervento alle problematiche relative alla piattaforma Linux per gli ambienti desktop (sviluppatori esperti hanno confermato che questo rimarrà tale per molto tempo).

Il mio intervento sui problemi dei desktop Linux nel 2018

Anche Linus Torvalds ammise che la frammentazione fu la causa del fallimento dell'idea degli ambienti desktop.

È bello vedere Haiku!

Con Haiku tutto diventa incredibilmente semplice.

Sebbene un approccio ingenuo al "porting" di AppImage su Haiku sarebbe semplicemente provare a compilarne i componenti (principalmente runtime.c e il servizio) (il che potrebbe anche essere possibile!), ciò non apporterebbe molti vantaggi ad Haiku. Perché, in effetti, la maggior parte di questi problemi è già risolta in Haiku e concettualmente valida. Haiku fornisce esattamente gli elementi costitutivi dell'infrastruttura di sistema che cercavo da così tanto tempo negli ambienti desktop Linux e che non potevo credere non esistessero. Vale a dire:

Che ci crediate o no, molti utenti Linux non riescono a superare questo problema. Su Haiku, tutto funziona automaticamente!

Ai file ELF che non hanno il bit eseguibile viene assegnato automaticamente quando si fa doppio clic nel file manager.
Le app possono avere risorse integrate, come le icone che compaiono nel file manager. Questo elimina la necessità di copiare un sacco di immagini in directory speciali, il che significa che non è necessario ripulirle dopo aver eliminato o spostato l'app.
Esiste un database per collegare le applicazioni ai documenti, non è necessario copiare alcun file per farlo.
Per impostazione predefinita, le librerie vengono cercate nella directory lib/ accanto al file eseguibile.
Non ci sono più distribuzioni e ambienti desktop; ciò che funziona, funziona ovunque.
Non esiste un modulo di avvio separato che sia diverso dalla directory Applicazioni.
Le applicazioni non dispongono di percorsi assoluti integrati per raggiungere le proprie risorse; esistono funzioni speciali per determinare la posizione durante l'esecuzione.
È stata implementata l'idea delle immagini di file system compresse: qualsiasi pacchetto hpkg. Tutti vengono montati dal kernel.
Ogni file si apre con l'applicazione che lo ha creato, a meno che non venga specificato diversamente. Fantastico!

Due file PNG. Notate le diverse icone, che indicano che si apriranno in applicazioni diverse con un doppio clic. Notate anche il menu a discesa "Apri con:", dove l'utente può selezionare un'applicazione specifica. Semplicissimo!

Sembra che molti degli hack e delle soluzioni alternative richiesti da AppImage su Linux siano inutili su Haiku, che ha una semplicità e una sofisticatezza di base che lo rendono adatto alla maggior parte delle nostre esigenze.

Haiku ha comunque bisogno di pacchetti applicativi?

Questo solleva un interrogativo importante. Se creare un sistema come AppImage su Haiku fosse un ordine di grandezza più semplice che su Linux, ne varrebbe la pena? Oppure Haiku, con il suo sistema di pacchetti hpkg, ha di fatto eliminato la necessità di un'idea del genere? Beh, per rispondere a questa domanda, dobbiamo analizzare le motivazioni alla base di AppImage.

La prospettiva di un utente

Diamo un'occhiata al nostro utente finale:

Voglio installare l'applicazione senza chiedere la password di amministratore (root). Su Haiku non esiste il concetto di amministratore, l'utente ha il pieno controllo perché è un sistema personale! (In linea di principio, potresti immaginarlo in modalità multigiocatore, spero che gli sviluppatori lo mantengano semplice)
Voglio ottenere le versioni più recenti e migliori delle app, non aspettare che appaiano nella mia distribuzione (il che di solito significa "mai", almeno a meno che non aggiorni l'intero sistema operativo). Haiku "risolve" questo problema con le versioni continue. Questo significa che è possibile ottenere le versioni più recenti e migliori delle applicazioni, ma per farlo è necessario aggiornare costantemente il resto del sistema, trasformandolo di fatto in un "bersaglio mobile"..
Voglio avere più versioni della stessa app affiancate perché non riesco a capire cosa non funziona nell'ultima versione oppure, ad esempio, come sviluppatore web ho bisogno di testare il mio lavoro su diverse versioni del browser. Haiku risolve il primo problema, ma non il secondo. Gli aggiornamenti possono essere annullati, ma solo per l'intero sistema; è impossibile (per quanto ne so) eseguire, ad esempio, più versioni di WebPositive o LibreOffice contemporaneamente.

Uno degli sviluppatori scrive:

In sostanza, la logica è che il caso d'uso è così raro che ottimizzarlo non ha senso; gestirlo come un caso speciale in HaikuPorts sembra più che accettabile.

Ho bisogno di salvare le app dove voglio, non sull'unità di avvio. Spesso esaurisco lo spazio su disco, quindi devo collegare un'unità esterna o una condivisione di rete per archiviare le app (tutte le versioni che ho scaricato). Se collego un'unità di questo tipo, ho bisogno che le app si avviino con un doppio clic. Haiku conserva vecchie versioni dei pacchetti, ma non so come spostarle su un'unità esterna e come richiamare le applicazioni da lì.

Commento dello sviluppatore:

Tecnicamente, questo è già possibile con il comando mount. Naturalmente, creeremo un'interfaccia grafica non appena ci saranno abbastanza utenti interessati.

Non ho bisogno di milioni di file sparsi nel file system che non posso gestire manualmente. Voglio un file per applicazione che posso scaricare, spostare ed eliminare facilmente. In Haiku, questo problema viene risolto utilizzando i pacchetti. .hpkg, che trasferiscono, ad esempio, Python da migliaia di file a uno solo. Ma se ho, ad esempio, Scribus, che usa Python, allora devo gestire almeno due file. E devo assicurarmi che siano mantenuti in versioni compatibili.

Più versioni di AppImages in esecuzione affiancate su un singolo box Linux

La prospettiva di uno sviluppatore di app

Diamo un'occhiata alla questione dal punto di vista di uno sviluppatore di app:

Voglio avere il controllo completo dell'esperienza utente. Non voglio dipendere dal sistema operativo che mi dice quando e come rilasciare le app. Haiku consente agli sviluppatori di lavorare con i propri repository hpkg, ma ciò significa che gli utenti devono configurarli manualmente, rendendo l'idea "meno attraente".
Ho una pagina di download sul mio sito web dove distribuisco .exe per Windows, .dmg per Mac e .AppImage Per Linux. O forse voglio monetizzare l'accesso a questa pagina? Tutto è possibile? Cosa dovrei mettere lì per Haiku? Basta un file .hpkg con dipendenze solo su HaikuPorts
Il mio software richiede versioni specifiche di altri software. Ad esempio, Krita richiede una versione patchata di Qt, o una versione di Qt ottimizzata per una versione specifica di Krita, almeno finché le patch non saranno ripristinate su Qt. È possibile impacchettare il proprio Qt per un'applicazione in un pacchetto .hpkg, ma molto probabilmente questo non è gradito.

Una tipica pagina di download di un'applicazione. Cosa dovrebbe contenere Haiku?

I kit (esistenti come directory di applicazioni come AppDir o .app nello stile Apple) e/o immagini (sotto forma di AppImage pesantemente modificate o .dmg Aggiungere app (di Apple) è un'aggiunta utile al desktop di Haiku? O diluirà il quadro generale e porterà a una frammentazione, aggiungendo quindi complessità? Sono combattuto: da un lato, la bellezza e la raffinatezza di Haiku derivano dal fatto che di solito c'è un solo modo per fare qualcosa, non molti. Dall'altro, la maggior parte dell'infrastruttura per cataloghi e/o pacchetti di applicazioni è già presente, quindi il sistema necessita a gran voce che la restante percentuale si adatti.

Secondo lo sviluppatore Sig. waddlesplash

Su Linux loro (cataloghi e pacchetti applicativi, — nota del traduttore) sono molto probabilmente soluzioni tecniche a problemi sistemici. Su Haiku, preferiamo semplicemente risolvere i problemi sistemici.

Cosa ne pensi?

Prima di rispondere…

Aspetta, facciamo un rapido controllo della realtà: directory delle applicazioni — fa già parte di Haiku:

Le directory delle applicazioni esistono già su Haiku, ma non sono ancora supportate nel file manager.

Semplicemente non sono supportati bene come, ad esempio, il Finder del Macintosh. Quanto sarebbe bello se la directory di QtCreator avesse un nome e un'icona "QtCreator" nell'angolo in alto a sinistra, che avviasse l'applicazione con un doppio clic?

Un po' prima io già ho chiesto:

Sei sicuro di poter eseguire le tue app di dieci anni fa oggi, quando tutti gli app store e i repository di distribuzione se ne sono dimenticati, così come le loro dipendenze? Sei sicuro di poter ancora accedere al tuo lavoro attuale in futuro?

Haiku ha già dato una risposta, oppure cataloghi e pacchetti di applicazioni potrebbero essere d'aiuto? Credo di sì.

Secondo il sig. waddlesplash:

Sì, abbiamo una risposta a questa domanda: supporteremo queste applicazioni per tutto il tempo necessario, finché qualcuno non riuscirà a leggere correttamente i loro formati di file o a fornire funzionalità 1:1. Il nostro impegno nel supportare le applicazioni BeOS R5 su Haiku ne è una chiara prova…

Giusto!

Quale linea d'azione dovrebbe seguire Haiku?

Posso immaginare una coesistenza pacifica di hpkg, directory e immagini delle applicazioni:

Il software di sistema utilizza .hpkg
Per i software più comunemente utilizzati (in particolare per quelli che necessitano di pianificare rilasci continui), utilizzare .hpkg (circa l'80% di tutti i casi)
Alcuni installati tramite .hpkg, le applicazioni trarranno vantaggio dallo spostamento verso un'infrastruttura con directory applicative (ad esempio, QtCreator): saranno distribuite come .hpkg, come prima.

Il signor Waddlesplash scrive:

Se tutto ciò che vuoi è visualizzare le app in /system/apps, invece dobbiamo rendere le directory in Deskbar più gestibili per gli utenti, perché /system/apps Non è progettato per essere aperto e visualizzato regolarmente dagli utenti (a differenza di macOS). Haiku ha un paradigma diverso per queste situazioni, ma è comunque un'opzione accettabile.

Haiku riceve l'infrastruttura per l'esecuzione di immagini applicative, build notturne, continue e di test del software, nonché per i casi in cui l'utente desidera "congelare" il software nel tempo, per software privato e interno e altri casi d'uso speciali (circa il 20% del totale). Queste immagini contengono i file necessari per eseguire l'applicazione. .hpkg, montato dal sistema e, dopo la chiusura dell'applicazione, smontato. (Forse il file manager potrebbe posizionare i file .hpkg in immagini di applicazioni, automaticamente o su richiesta dell'utente, ad esempio quando si trascina un'applicazione su una condivisione di rete o su un'unità esterna. È solo una canzone! O meglio, una poesia, un haiku.) D'altra parte, l'utente potrebbe voler installare il contenuto dell'immagine come file..hpkg, dopodiché verranno aggiornati ed elaborati esattamente come se fossero stati installati tramite HaikuDepot... Dobbiamo fare un po' di brainstorming).

Citazione del signor waddlesplash:

Avviare applicazioni da unità esterne o condivisioni di rete potrebbe essere utile. Aggiungere la possibilità di configurare più "zone" per pkgman sarebbe sicuramente una funzionalità gradita.

Un sistema del genere sfrutterebbe i punti di forza di hpkg, cataloghi e immagini applicative. Sebbene ciascuno di essi sia valido singolarmente, insieme sarebbero imbattibili.

conclusione

Haiku ha un'infrastruttura che fornisce un'interfaccia utente semplice e sofisticata per PC, e va ben oltre ciò che è tipicamente fornito per i PC Linux. Il sistema di pacchetti .hpkg — è un esempio, ma anche altre parti del sistema sono ricche di sofisticatezza. Tuttavia, Haiku trarrebbe beneficio da un supporto adeguato per cataloghi e immagini applicative. Il modo migliore per farlo è discuterne con persone che conoscono Haiku, la sua filosofia e la sua architettura molto meglio di me. Dopotutto, uso Haiku solo da poco più di una settimana. Ciononostante, credo che questa nuova prospettiva sarà utile ai designer, agli sviluppatori e agli architetti di Haiku. Come minimo, sarei felice di essere uno "sparring partner" per loro. Ho oltre 10 anni di esperienza pratica con cataloghi e bundle applicativi per Linux e mi piacerebbe trovarne un utilizzo in Haiku, per il quale credo siano perfetti. Le potenziali soluzioni che ho proposto non sono affatto le uniche corrette per i problemi che ho descritto, e se il team di Haiku decidesse di trovarne altre più eleganti, sarei assolutamente favorevole. In linea di principio, sto già pensando a un'idea su come rendere il sistema hpkg Ancora più sorprendente, senza modificarne il funzionamento. A quanto pare, il team di Haiku aveva pensato a lungo ai bundle applicativi durante l'implementazione del sistema di gestione dei pacchetti, ma purtroppo (credo) l'idea è stata relegata nella categoria "obsoleta". Forse è ora di rilanciarla?

Prova tu stesso! Dopotutto, il progetto Haiku fornisce immagini per l'avvio da DVD o USB, generate quotidiano.
Hai domande? Ti invitiamo alla lingua russa canale telegramma.

Panoramica degli errori: Come spararsi ai piedi in C e C++. Raccolta di ricette del sistema operativo Haiku

Da l'autore Traduzione: Questo è l'ottavo e ultimo articolo della serie Haiku.

Elenco degli articoli: prima La seconda terzo quarto quinto sesto settimo

Solo gli utenti registrati possono partecipare al sondaggio. AccediPer favore.