TL;DR: Haiku — un sistema operativo progettato specificamente per PC, quindi ha alcuni trucchi che migliorano notevolmente il suo ambiente di lavoro rispetto agli altri. Ma come funziona?
Ho scoperto Haiku, un sistema sorprendentemente buono. Sono ancora colpito da quanto funzioni fluido, specialmente in confronto agli ambienti di lavoro su Linux. Oggi darò un'occhiata sotto il cofano. Dove sarà necessario per una comprensione approfondita, farò un confronto con il Macintosh originale, Mac OS X e gli ambienti di lavoro Linux (standard XDG di freedesktop.org).
Risorse nei file ELF
Ieri ho scoperto che IconOMatic può salvare icone nelle risorse rdef all'interno dei file eseguibili ELF. Oggi voglio vedere come funziona realmente.
Risorse? di , l'autore originale del programma Macintosh Finder e "padre" di Macintosh Resource Manager:
Mi preoccupa la natura rigida della scrittura tradizionale del codice. Per me, l'idea stessa di un'applicazione bloccata nel codice, senza la possibilità di modificare nulla dinamicamente, è una vera follia. Dobbiamo avere la possibilità di cambiare il maggior numero possibile di cose durante l'esecuzione. Ovviamente, il codice stesso dell'applicazione non può essere cambiato, ma ci sono cose che possono essere modificate senza ricompilare il codice?
Sul Macintosh originale hanno fatto in modo che questi file avessero una "sezione dati" e una "sezione risorse", il che ha reso straordinariamente semplice il salvataggio di diverse cose, ad esempio icone, traduzioni, ecc., nei file eseguibili.
Su Mac questo viene fatto utilizzando , un programma grafico per — sorpresa — l'editing delle risorse.
ResEdit sul Macintosh originale
Di conseguenza, è stato possibile modificare icone, voci di menu, traduzioni ecc. in modo abbastanza semplice, ma si portano comunque "dietro" le applicazioni.
In ogni caso, questo approccio aveva un grande svantaggio: funzionava solo su file system Apple, e ciò è stato uno dei motivi per cui Apple ha abbandonato la "sezione risorse" nel passaggio a Mac OS X.
Su Mac OS X Apple voleva una soluzione indipendente dal file system, quindi hanno adottato il concetto di pacchetti (da NeXT), cartelle che vengono gestite dal gestore di file come "oggetti opachi", simili ai file anziché alle cartelle. Qualsiasi pacchetto contenente un'applicazione nel formato .app contiene, tra le altre cose, un file Info.plist (in una sorta di analogia JSON o YAML di Apple), che contiene i metadati dell'applicazione.
Le chiavi del file Info.plist nel pacchetto dell'applicazione Mac OS X.
Le risorse, come icone, file UI e altro, sono memorizzate nel pacchetto come file. Il concetto è tornato essenzialmente alle origini in NeXT.
Mathematica.app su NeXTSTEP 1.0 nel 1989: appare come una cartella con file nel terminale, ma come un unico oggetto nel gestore di file grafico.
Torniamo a BeOS, su cui si basa Haiku. I suoi sviluppatori, passando da PEF (PowerPC) a ELF (x86) (lo stesso usato su Linux), decisero di aggiungere una sezione risorse alla fine dei file ELF. Non utilizzarono una sezione ELF propria, semplicemente la apposero alla fine del file ELF. Come risultato, i programmi strip e altri di binutils, che non ne erano a conoscenza, semplicemente la tranciavano. Pertanto, aggiungendo risorse in un file ELF su BeOS, è meglio non lavorarci con strumenti Linux.
E cosa sta succedendo ora con Haiku? In sostanza, più o meno la stessa cosa.
In teoria, sarebbe possibile collocare le risorse nella sezione ELF appropriata. Secondo gli sviluppatori nel canale #haiku su irc.freenode.net:
Con ELF la sezione avrebbe più senso... l'unica ragione per cui non lo facciamo è perché così si faceva in BeOS.
E non vale la pena cambiarlo ora.
Gestione delle risorse
Le risorse vengono scritte in un formato 'risorse' strutturato: in sostanza, è un elenco di risorse con dimensioni e poi il loro contenuto. Si è ricordato .
Come si possono verificare le risorse in Haiku? C'è qualcosa come ResEdit?
Secondo :
Per visualizzare le risorse fornite nel pacchetto dell'applicazione, si può trascinare il file eseguibile su un programma come È anche possibile accedere al terminale e lanciare il comando
listres nome_file..
Resourcer è disponibile in HaikuDepot, ma a me semplicemente si chiude.
Come gestire le risorse nei file ELF? Utilizzando rsrc. e rdef.. rdef. i file vengono raccolti in rsrc.. Il file rdef. è memorizzato in un formato di testo normale, quindi lavorarci è molto più semplice. Il file in formato rsrc. viene aggiunto alla fine del file ELF. Proviamo a giocare:
~> rc -h
Haiku Resource Compiler 1.1Per compilare uno script rdef in un file di risorse:
rc [opzioni] [-o ] ...Per convertire un file di risorse di nuovo in uno script rdef:
rc [opzioni] [-o ] -d ...Opzioni:
-d --decompile crea uno script rdef da un file di risorse
--auto-names costruisce nomi di risorsa dai simboli ID
-h --help mostra questo messaggio
-I --include aggiunge all'elenco dei percorsi di inclusione
-m --merge non cancella i contenuti esistenti del file di output
-o --output specifica il nome del file di output, il valore predefinito è out.xxx
-q --quiet non visualizza alcun messaggio di errore
-V --version mostra la versione del software e la licenza.È possibile utilizzare il programma xres per controllare e gestire:
/> xres
Usage: xres ( -h | --help )
xres -l <file> ...
xres <command> ...The first form prints this help text and exits.The second form lists the resources of all given files.The third form manipulates the resources of one or more files according to
the given commands.
(...)Va bene, proviamo?
/> xres -l /Haiku/system/apps/WebPositive/Haiku/system/apps/WebPositive resources:type ID size name
------ ----------- ----------- --------------------
'MIMS' 1 36 BEOS:APP_SIG
'APPF' 1 4 BEOS:APP_FLAGS
'MSGG' 1 421 BEOS:FILE_TYPES
'VICN' 101 7025 BEOS:ICON
'VICN' 201 91 kActionBack
'VICN' 202 91 kActionForward
'VICN' 203 300 kActionForward2
'VICN' 204 101 kActionStop
'VICN' 206 243 kActionGoStart
'MSGG' 205 1342 kActionGo
'APPV' 1 680 BEOS:APP_VERSIONMaggiori informazioni sulle risorse e sul formato rdef. si possono leggere .
Tipi di risorse standard
Sebbene sia possibile inserire qualsiasi cosa nelle risorse, ci sono alcuni tipi standard definiti:
app_signature: tipo MIME dell'applicazione, per associare file aperti, avvii, IPC, ecc.app_name_catalog_entry: Poiché il nome dell'applicazione è solitamente in inglese, qui si possono specificare i luoghi dove si trovano i nomi tradotti, in modo che gli utenti di diverse lingue possano vedere il nome tradotto dell'applicazione se lo desiderano.app_version: proprio quello che pensaviapp_flags: indicaregistrarcome gestire l'applicazione. Penso ci sia qualcosa di più di quanto appaia a prima vista. Per esempio, c'èB_SINGLE_LAUNCH, che costringe il sistema a lanciare un nuovo processo dell'applicazione ogni volta, su richiesta dell'utente (lo stesso principio è utilizzato per la maggior parte delle applicazioni su Linux). C'èB_MULTIPLE_LAUNCH, che costringe a lanciare un processo per ogni file. Infine, c'èB_EXCLUSIVE_LAUNCH, che costringe il sistema a lanciare solo un processo alla volta, indipendentemente da quanto spesso gli utenti lo avviano (per esempio, Firefox su Linux funziona in questo modo; lo stesso risultato può essere ottenuto nelle applicazioni Qt utilizzando la funzione ). Le applicazioni conB_EXCLUSIVE_LAUNCHvengono informate quando l'utente prova a lanciarle nuovamente: per esempio, ricevono il percorso del file che l'utente desidera aprire tramite di loro.vector_icon: Icona vettoriale dell'applicazione (In BeOS non c'erano icone vettoriali, la maggior parte delle applicazioni ne aveva invece due raster nelle eseguibili).
Certo, è possibile aggiungere risorse con qualsiasi ID e tipo desiderato, per poi leggerle all'interno dell'applicazione o in altre applicazioni utilizzando la classe BResources. Ma per ora, fermiamoci su un argomento affascinante: le icone.
Icone vettoriali in stile Haiku
Naturalmente, non solo Haiku ha scelto il miglior formato per le icone, in questa parte la situazione con gli ambienti desktop Linux è lontana dall'essere ideale:
me@host:~$ ls /usr/share/icons/hicolor/
128x128 256x256 512x512 index.theme
160x160 28x28 64x64 scalable
16x16 32x32 72x72 symbolic
192x192 36x36 8x8
22x22 42x42 96x96
24x24 48x48 icon-theme.cacheGuardando qualcosa del genere, si può già percepire cosa rappresenti questo pezzo.
Certo, ci sono icone vettoriali scalabili, che si possono comprendere. Perché allora esiste qualcos'altro? Perché il risultato del rendering della grafica vettoriale a piccole dimensioni può essere peggiore dell'ideale. Si desidera avere diverse varianti, ottimizzate per diverse dimensioni. Negli ambienti di lavoro Linux questo si ottiene distribuendo le icone con diverse dimensioni nel file system.
me@host:~$ find /usr/share/icons/ -name 'firefox.*'
/usr/share/icons/HighContrast/16x16/apps/firefox.png
/usr/share/icons/HighContrast/22x22/apps/firefox.png
/usr/share/icons/HighContrast/24x24/apps/firefox.png
/usr/share/icons/HighContrast/256x256/apps/firefox.png
/usr/share/icons/HighContrast/32x32/apps/firefox.png
/usr/share/icons/HighContrast/48x48/apps/firefox.png
/usr/share/icons/elementary-xfce/apps/128/firefox.png
/usr/share/icons/elementary-xfce/apps/16/firefox.png
/usr/share/icons/elementary-xfce/apps/22/firefox.png
/usr/share/icons/elementary-xfce/apps/24/firefox.png
/usr/share/icons/elementary-xfce/apps/32/firefox.png
/usr/share/icons/elementary-xfce/apps/48/firefox.png
/usr/share/icons/elementary-xfce/apps/64/firefox.png
/usr/share/icons/elementary-xfce/apps/96/firefox.png
/usr/share/icons/hicolor/128x128/apps/firefox.pngAttenzione: non esiste il concetto di diverse versioni di Firefox. Pertanto, non è possibile gestire in modo raffinato la situazione di avere più versioni dell'applicazione nel sistema.
Diverse icone di Firefox in diverse versioni. Al momento, non è possibile gestire questo in Linux senza vari ripieghi.
Mac OS X gestisce in modo leggermente più raffinato:
Mac:~ me$ find /Applications/Firefox.app | grep icns
/Applications/Firefox.app/Contents/MacOS/crashreporter.app
/Contents/Resources/crashreporter.icns
/Applications/Firefox.app/Contents/MacOS/updater.app/Contents/Resources/updater.icns
/Applications/Firefox.app/Contents/Resources/document.icns
/Applications/Firefox.app/Contents/Resources/firefox.icnsSi vede che c'è un file firefox.icns nel pacchetto Firefox.app, contenente tutte le dimensioni, quindi diverse versioni di una stessa applicazione hanno icone diverse.
Molto meglio! Le icone viaggiano insieme all'applicazione, tutte le risorse in un unico file.
Torniamo a Haiku. Una soluzione straordinaria, senza eccezioni. Secondo :
È stato sviluppato un formato speciale, ottimizzato per piccole dimensioni e renderizzazione rapida, HVIF. Pertanto, le nostre icone sono per lo più molto più piccole rispetto ai formati raster o più comunemente utilizzati come SVG.
E sono effettivamente ottimizzate:
Le dimensioni dell'icona in HVIF rispetto ad altri formati.
La differenza è notevole!
Ma la magia non finisce qui. Lo stesso HVIF può mostrare diversi livelli di dettaglio a seconda della dimensione di visualizzazione, anche se si tratta di un formato vettoriale.
Diversi livelli di dettaglio (LOD) a seconda della dimensione di rendering
Ora sugli svantaggi: non si può prendere un SVG, lanciarlo in ImageMagick e finire lì, è necessario passare attraverso diversi cicli per creare un'icona in formato HVIF. spiegazioni. Tuttavia, IconOMatic può importare SVG in modo piuttosto imperfetto; circa il 90% dei dettagli SVG viene importato con una certa probabilità, i restanti 10% dovranno essere regolati e modificati manualmente. Leggi di più su come HVIF fa la sua magia nel blog
Aggiunta dell'icona all'applicazione
Ora posso aggiungere un'icona al pacchetto creato , tenendo conto di tutte le informazioni ricevute.
Poiché non ho voglia di disegnare una mia icona per la mia applicazione QtQuickApp 'Ciao, Mondo' - la prendo da Qt Creator.
/Haiku/home> xres /Haiku/system/apps/QtCreator/bin/Qt Creator -o /Haiku/home/QtQuickApp/QtQuickApp -a VICN:101:BEOS:ICON /Haiku/system/apps/QtCreator/bin/Qt CreatorVerifichiamo che l'icona sia stata copiata:
/Haiku/home> xres -l /Haiku/home/QtQuickApp/QtQuickApp/Haiku/home/QtQuickApp/QtQuickApp
resources:type ID size name
------ ----------- ----------- --------------------
'VICN' 101 152238 BEOS:ICONSembra buona, ma perché, quando l'icona nuova è stata copiata, non viene visualizzata?
L'icona VICN:101:BEOS:ICONs copiata non viene ancora utilizzata come icona per l'applicazione nel file manager
Cosa mi è sfuggito?
Commento dello sviluppatore:
Devo creare un file
rdef.con tutte le risorse, poi eseguire il comandorc nome.rdef, questo creerà un file.rsrc. Poi devo eseguire il comandoresattr -o nome_binarico nome.rsrc. Almeno, utilizzo comandi simili per aggiungere icone ai miei script.
Bene, volevo creare una risorsa, non un attributo. Sono completamente confuso.
Caching intelligente usando il filesystem
L'apertura e la lettura degli attributi ELF sono lenti. Come ho già scritto sopra, l'icona viene scritta come risorsa nel file stesso. Questo metodo è più affidabile e consente il trasferimento su un altro filesystem. Tuttavia, poi viene anche copiata negli attributi del filesystem, ad esempio BEOS:ICON. Funziona solo su determinati filesystem, ad esempio BFS. Le icone mostrate dal sistema (in Tracker e Deskbar) vengono lette da questo attributo esteso, perché questa soluzione è veloce. In alcune situazioni (dove la velocità non è importante, ad esempio nella finestra di dialogo 'Informazioni su'), il sistema ottiene l'icona direttamente dalla risorsa nel file. Ma non è ancora finita. Ricorda, su Mac, gli utenti potevano sostituire le icone delle applicazioni, delle cartelle e dei documenti con le proprie, poiché su Mac è possibile fare queste 'cose importanti', ad esempio . Su Haiku, si dovrebbe considerare la risorsa (nel file) come l'icona originale fornita con l'applicazione, e l'attributo (nel filesystem BFS) come qualcosa che consente all'utente di apportare modifiche a piacere (anche se, suggerimento, un'interfaccia grafica per insertire un'icona personalizzata sopra l'icona predefinita non è ancora stata implementata).
Verifica degli attributi del filesystem
Utilizzando resaddr è possibile controllare e impostare gli attributi del filesystem.
/> resattr
Usage: resattr [ <options> ] -o <outFile> [ <inFile> ... ]
Reads resources from zero or more input files and adds them as attributes
to the specified output file, or (in reverse mode) reads attributes from
zero or more input files and adds them as resources to the specified output
file. If not existent the output file is created as an empty file.
(...)In sostanza, questo è un "collante" che svolge una trasformazione continua tra risorse (affidabili) e attributi (veloci) del file system. E poiché il sistema prevede l'acquisizione delle risorse e copia automaticamente, non mi preoccuperò ulteriormente di questo.
La magia dei pacchetti hpkg
Attualmente, per ottenere applicazioni su Haiku si utilizzano principalmente i pacchetti. .hpkgNon lasciatevi ingannare dal nome semplice: il formato .hpkg funziona in modo completamente diverso rispetto ad altri formati con nomi simili che avete incontrato, e ha vere e proprie superabilità.
Con i formati di pacchetto tradizionali, mi sono a lungo frustrato per questo fatto: scarichi un pacchetto, ma nel sistema si installa qualcos'altro (file all'interno del pacchetto). È abbastanza difficile gestire i file (ad esempio, eliminarli) quando un pacchetto viene installato nel modo tradizionale. E tutto ciò accade perché il contenuto del pacchetto si disperde per tutto il file system, compresi i luoghi in cui gli utenti comuni potrebbero non avere accesso in scrittura. Ciò genera un'intera classe di programmi - gestori di pacchetti. Trasferire software già installato, ad esempio, su un'altra macchina, un'unità rimovibile o un server di file diventa addirittura più difficile, se non impossibile. In un sistema Linux tradizionale possono facilmente esistere da diverse centinaia di migliaia a milioni di file isolati. È ovvio che ciò è sia fragile che lento, ad esempio durante l'installazione iniziale del sistema, durante l'installazione, l'aggiornamento e la rimozione di pacchetti normali, così come durante la copia del volume di avvio (partizione radice) su un altro supporto.
Sto lavorando a un progetto chiamato AppImage, un parziale rimedio per applicazioni per utenti finali. Questo è un formato di distribuzione software che raccoglie l'applicazione e tutte le sue dipendenze in un'unica immagine del file system, montata all'avvio dell'applicazione. Semplifica notevolmente le cose, poiché lo stesso ImageMagick si trasforma improvvisamente in un unico file, gestito nel file manager da normali mortali. Il metodo proposto funziona solo per il software, come riflesso nel nome del progetto, e ha anche il suo insieme di problematiche, poiché le persone che si occupano della fornitura di software per Linux tendono sempre a dare la colpa a me.
Torniamo a Haiku. Sei riuscito a trovare un equilibrio ottimale tra i tradizionali sistemi di pacchetti e la fornitura di software basata su immagini? I suoi pacchetti .hpkg sono praticamente immagini compresse del filesystem. Durante il boot del sistema, il kernel monta tutti i pacchetti installati e attivi con messaggi simili a questi nel kernel:
KERN: package_daemon [16042853: 924] pacchetto attivo: "gawk-4.2.1-1-x86_64.hpkg"
KERN: package_daemon [16043023: 924] pacchetto attivo: "ca_root_certificates_java-2019_01_23-1-any.hpkg"
KERN: package_daemon [16043232: 924] pacchetto attivo: "python-2.7.16-3-x86_64.hpkg"
KERN: package_daemon [16043405: 924] pacchetto attivo: "openjdk12_default-12.0.1.12-1-x86_64.hpkg"
KERN: package_daemon [16043611: 924] pacchetto attivo: "llvm_libs-5.0.0-3-x86_64.hpkg"Fantastico, vero? Tenete duro, la parte successiva sarà ancora più entusiasmante!
C'è un pacchetto molto speciale:
KERN: package_daemon [16040020: 924] pacchetto attivo: "haiku-r1~beta1_hrev53242-1-x86_64.hpkg"Contiene un sistema operativo davvero minimalista, incluso il kernel. Credici o meno, ma anche il kernel non viene estratto dal volume di avvio (partizione root), ma viene caricato con cura al suo posto dal pacchetto .hpkg. Wow! Ho già menzionato che, a mio avviso, parte della raffinatezza e della coerenza di Haiku è dovuta al fatto che l'intero sistema, dal kernel e dallo spazio utente di base fino alla gestione dei pacchetti e dell'infrastruttura dell'ambiente di lavoro, è sviluppato da un unico team. Immagina quanti gruppi e team sarebbero necessari per avviare qualcosa di simile basato su Linux [immagino il progetto PuppyLinux, — nota del traduttore]. Poi immagina quanto tempo ci vorrebbe affinché questo approccio venga implementato nelle distribuzioni. Si dice che: prendi un compito semplice, dividilo tra diversi esecutori e diventerà così complicato che non sarà più possibile risolverlo. In questo caso, Haiku mi ha aperto gli occhi. Penso che proprio questo stia accadendo su Linux ora (Linux, in questo caso, è un termine collettivo che indica il stack Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu).
Ripristino di sistema utilizzando hpkg
Quante volte si verifica la seguente situazione: l'aggiornamento è andato a buon fine, ma poi si scopre che qualcosa non funziona come dovrebbe? Se si usano i normali gestori di pacchetti, è difficile ripristinare lo stato del sistema al momento precedente all’installazione dei nuovi pacchetti (ad esempio, se qualcosa va storto). Alcuni sistemi offrono soluzioni alternative sotto forma di istantanee del file system, ma sono piuttosto ingombranti e non vengono applicate in tutti i sistemi. In Haiku questo problema è risolto tramite pacchetti .hpkg. Ogni volta che i pacchetti nel sistema vengono cambiati, i pacchetti più vecchi non vengono eliminati, ma conservati nel sistema in sottocartelle di tipo /Haiku/system/packages/administrative/state-<...>/ costantemente. Le operazioni incomplete memorizzano i loro dati in sottocartelle /Haiku/system/packages/administrative/transaction-<...>/.
Contenuto /Haiku/system/packages/administrative. Le cartelle
state… .hpkg contengono file di testo con i nomi dei pacchetti attivi, /Haiku/system/packages/administrative/state-<...>/activated-packages. Allo stesso modo, il nuovo /Haiku/system/packages/administrative/activated-packages.
Directory /Haiku/system/packages/administrative/state-<...>/ stato attivo
è registrato in un file di testo, che contiene solo un file di testo con l'elenco dei pacchetti attivi in quello stato (nel caso di installazione di pacchetti senza eliminazione), e se i pacchetti sono stati eliminati o aggiornati, la cartella state contiene le versioni precedenti dei pacchetti.
Al caricamento del sistema, sulla base dell'elenco dei pacchetti, si decide sull'attivazione (montaggio) dei pacchetti. È così semplice! Se qualcosa va storto al momento del caricamento, è possibile indicare al gestore di avvio di utilizzare un altro elenco, più vecchio. Il problema è risolto!
Il bootloader di Haiku. Ogni punto di ingresso riflette il corrispondente .hpkgstato attivo stato attivo
Contrariamente al
che si trova nel file system da parte di OSTree o Flatpak (a livello, offre lo stesso livello del Microsoft GUID).
L'elenco dei pacchetti attivi per ogni momento di tempo /Haiku/system/packages/administrative/writable-files Dati di configurazione .hpkg A quanto pare, nella cartella
ci sono file di impostazioni per i pacchetti, ma disponibili in scrittura. Infatti, come ricordate,
Ora vediamo come questi brillanti pacchetti .hpkg si integrano nell'ambiente di lavoro dell'utente (UX). Dopotutto, Haiku è destinato a un uso personale. Personalmente, ho elevato il livello confrontando l'esperienza utente con i pacchetti .app su Macintosh con una simile esperienza su .hpkg. Non voglio nemmeno paragonare la situazione con gli ambienti di lavoro su Linux, perché è assolutamente terribile rispetto a qualsiasi altro.
Mi vengono in mente i seguenti scenari:
- Voglio visualizzare il contenuto del pacchetto
.hpkg - Voglio installare un pacchetto
- Voglio rimuovere un pacchetto
- Voglio eliminare qualcosa che è arrivato nel sistema come parte di un pacchetto
- Voglio copiare qualcosa che è arrivato nel sistema come parte di un pacchetto
- Voglio scaricare tutte le dipendenze del pacchetto che non possono far parte di ogni installazione di Haiku (ad esempio, ho una macchina fisicamente isolata senza accesso a Internet).
- Voglio spostare i miei pacchetti (o parte di essi) separatamente in un'altra posizione, distinta dal volume di avvio (partizione radice) (poiché, ad esempio, ho poco spazio su di esso).
Questo dovrebbe coprire la maggior parte dei casi principali del mio lavoro quotidiano. Bene, iniziamo.
Controllo del contenuto del pacchetto
Su Mac faccio semplicemente clic destro sul pacchetto per aprirlo e visualizzare il contenuto nel Finder. In effetti, è solo una cartella mascherata! (So che ci sono pacchetti .pkg per la parte del sistema che non è applicazioni, ma gli utenti normali raramente interagiscono con essi).
Su Haiku faccio clic destro sul pacchetto, poi clicco su «Contents» per vedere cosa c'è dentro. Ma qui c'è solo un elenco di file senza possibilità di aprirli con un doppio clic.
Sarebbe molto meglio se ci fosse un modo (temporaneo) per montare il pacchetto .hpkg per visualizzarlo tramite il file manager, senza che l'utente debba preoccuparsi dei dettagli di implementazione. (Tra l'altro, è possibile aprire .hpkg il pacchetto in Expander, che può estrarlo proprio come qualsiasi altro archivio).
Nell'interfaccia di HaikuDepot, è possibile visualizzare l'elenco dei file del pacchetto, ma non c'è modo di visualizzare il contenuto, ad esempio facendo doppio clic su README.md
In questa categoria, Mac vince, ma l'aggiunta della funzionalità necessaria a HaikuDepot non dovrebbe presentare grandi difficoltà.
Installazione del pacchetto tramite GUI
Su Mac, la maggior parte delle immagini disco .dmg contiene pacchetti .app. Apriamo l'immagine disco con un doppio clic, dopodiché copiamo il pacchetto, ad esempio, trascinandolo in /Applications Finder. Per me è ovvio, ma ho sentito che alcuni principianti potrebbero non farcela. Per impostazione predefinita, Apple "offre" la cartella di sistema /Applications (su NeXT era di rete, oltre che individuale), ma è facile posizionare le proprie applicazioni su un server di file o in una sottocartella $HOME/Applications, se ti piace.
Su Haiku, doppio clic sul pacchetto, poi clicca su "Installa", è davvero semplice. Sono curioso di sapere cosa succede se il pacchetto ha dipendenze disponibili in HaikuPorts, ma ancora non installate. Su Linux non sanno davvero cosa fare in questa situazione, ma la soluzione è ovvia: chiedere all'utente se deve scaricare e installare le dipendenze. Esattamente ciò che fa Haiku.
Ho scaricato il pacchetto 'sanity' manualmente e vi ho cliccato sopra, il gestore pacchetti sa da dove prendere le sue dipendenze (a condizione che i repository siano già configurati nel sistema). Non ogni distribuzione Linux è in grado di farlo.
Un altro modo è utilizzare il gestore di file, basta trascinare .hpkg il pacchetto o in /Haiku/system/packages (per installazione di sistema, per impostazione predefinita), o in /Haiku/home/config/packages (per installazione individuale; non disponibile con il doppio clic — mi infastidisce ancora la parola "config" in questo contesto, che per me è sinonimo di "impostazioni"). Eppure, il concetto di più utenti non è ancora disponibile per Haiku (probabilmente è per questo che è tutto così semplice — non so, forse le funzionalità multiutente renderebbero le cose troppo complicate per l'ambiente di lavoro di un computer personale).
In questa categoria vince Haiku, perché sa lavorare non solo con le applicazioni, ma anche con i programmi di sistema.
Rimuovere un pacchetto dall'interfaccia grafica
Su Mac, basta trascinare l'icona dell'applicazione nel cestino, ed è tutto. Facile!
Su Haiku, prima di tutto, bisogna trovare dove si trova il pacchetto nel sistema, perché raramente lo installerai dove deve essere (il sistema fa tutto). Di solito bisogna cercare in /Haiku/system/packages (con installazione di sistema per impostazione predefinita), o in /Haiku/home/config/packages (ho già detto che "config" è un nome sbagliato?). Poi l'applicazione viene semplicemente trascinata nel cestino, ed è tutto.
Facile! Comunque, non direi così. Ecco cosa succede in realtà:
Ecco cosa succede se trascini l'applicazione nel cestino da /Haiku/system/packages
Ho provato a spostare nel cestino la mia applicazione di ieri «Ciao, mondo» su QtQuickApp. Non ho cercato di spostare la directory di sistema, e poiché tutti i pacchetti sono installati nella directory di sistema, non è possibile rimuovere un pacchetto .hpkg senza modificare «il suo contenuto». Un utente normale si spaventerebbe, premerebbe il pulsante «Annulla» che è impostato per impostazione predefinita.
Spiega :
Questo messaggio ha già più di 10 anni. Probabilmente dobbiamo impostarlo in modo che l'avviso appaia solo quando si sposta il pacchetto stesso. Gli utenti normali non devono fare così, comunque.
Bene, forse dobbiamo fare questo utilizzando HaikuDepot? Faccio doppio clic sul pacchetto in /Haiku/system/packages, aspettandomi che appaia il pulsante «Disinstalla». Niente, c'è solo «Installa». «Disinstalla», dove sei?
Per divertimento ho provato a vedere cosa succede se clicco su «Installa» per un pacchetto già installato. Risultato:
Ecco cosa succede se provi a installare un pacchetto già installato.
Poi appare:
Se premo «Applica modifiche» nella finestra precedente, sarà così
Suppongo che si tratti di un bug software, c'è già un link alla richiesta. [l'autore non ha fornito il link, — nota del traduttore]
Soluzione rapida: aggiungere il pulsante «Disinstalla» se il pacchetto è già presente in
/Haiku/system/packages, o in/Haiku/home/config/packages.
Quando guardo l'elenco dei pacchetti installati in HaikuDepot, vedo il mio pacchetto nell'elenco e posso rimuoverlo.
In questa categoria vince il Mac. Ma posso immaginare che, con la giusta configurazione, l'esperienza utente su Haiku sia migliore che su Mac. (Uno degli sviluppatori ha valutato così: «Meno di un'ora per aggiungere la funzionalità indicata in HaikuDepot, se sai un po' di C++», ci sono volontari?)
Rimozione di qualcosa dal pacchetto
Proviamo a rimuovere l'applicazione stessa, non il pacchetto .hpkg, da cui è nata (dubito che per i «comuni mortali» ci sia una differenza).
Su Mac, un utente di solito lavora con il file .dmg, da cui proviene il pacchetto dell'applicazione .app. Di solito, le immagini .dmg si accumulano nella cartella dei download, mentre i pacchetti vengono copiati dagli utenti in /Applications. C'è un'opinione che molti utenti non sappiano davvero cosa stiano facendo; questa ipotesi è confermata da un ex dipendente Apple. (Una delle cose che non mi piace di Mac. Ad esempio, con AppImage non c'è differenza tra l'applicazione e il pacchetto in cui si trova. Porti l'icona nel cestino = ed è tutto. Facile!)
Su Haiku, c'è anche una divisione tra apps/ e packages/, quindi dubito che agli utenti sia più chiaro. Ma cosa succede se trascini l'applicazione da apps/ nel cestino:
Ecco cosa succede quando cerchi di rimuovere un'applicazione ottenuta da un file .hpkg
Tecnicamente, è corretto (dal momento che l'app è collocata su un file system di sola lettura, prima di tutto), ma non è molto utile per l'utente.
Soluzione rapida: invece, suggeriscilo tramite GUI per rimuovere
.hpkg
Per divertimento ho provato a duplicare l'app, premendo Alt+D. Ho ricevuto il messaggio "Impossibile spostare o copiare oggetti su un volume di sola lettura". E tutto ciò perché /system oltre a /system/packages e /system/settings) è il punto di montaggio packagefs (ricordi come appare nell'output df?). К сожалению, вывод команды mount non chiarisce la situazione (come già detto in uno dei precedenti articoli), mountvolume non mostra ciò che cerchi (a quanto pare i pacchetti montati tramite loop .hpkg non sono considerati "volumi"), e ho anche dimenticato i comandi alternativi.
In questa categoria nessuno ha vinto, tranne AppImage (ma, a dire il vero, è un'opinione di parte). Tuttavia, si può immaginare che dopo un po' di adattamento, l'esperienza utente su Haiku sarà migliore che su Mac.
Nota: è necessario chiarire cosa si intende per "volume" in relazione a "partizione". Probabilmente è simile alla relazione tra "cartella" e "directory": la maggior parte delle directory viene visualizzata nell'esploratore file come cartelle, ma non tutte (ad esempio, i pacchetti, trattati come file). Tale rappresentazione mi rende ufficialmente un nerd?
Copiare il contenuto del pacchetto su un altro sistema
Su Mac, semplicemente trascino il pacchetto .app, e poiché le dipendenze all'interno del pacchetto vengono spostate insieme.
Su Haiku, trascino l'app, ma le dipendenze non vengono elaborate affatto.
Soluzione rapida: dovrebbe invece essere proposta la possibilità di trascinare il pacchetto "`.hpkg` interamente, insieme alle dipendenze, se presenti.
In questa categoria Mac vince decisamente. Almeno per me, amante della loro filosofia. Su Haiku sarebbe opportuno copiare .hpkg invece dell'allegato, ma il sistema non mi propone nulla di simile...
Scaricamento del pacchetto con tutte le sue dipendenze
Non ogni macchina è connessa alla rete tutto il tempo. Al contrario, alcune macchine (sì, sto guardando voi, moderni Windows, Mac e Linux) se ne dimenticano. Per me è importante che posso andare, per esempio, in un Internet café, scaricare software su un'unità portatile, inserire questa unità nel computer di casa e essere sicuro che tutto funzionerà [rischioso, fare una cosa del genere su Windows... — nota del traduttore].
Di conseguenza, un po' più spesso del solito, di solito ricevo dipendenze non soddisfatte su Windows e Linux.
Su Mac di solito è un singolo file, tutto ciò che serve è scaricare .dmg. Nella maggior parte dei casi non ha dipendenze, a parte quelle fornite di default da MacOS. Come eccezione, possiamo menzionare applicazioni complesse che richiedono un ambiente di esecuzione specifico, come Java.
Su Haiku scaricare il pacchetto .hpkg per, diciamo, la stessa applicazione in Java, può rivelarsi insufficiente, poiché Java può essere presente o assente sulla macchina di destinazione. C'è un modo per scaricare tutte le dipendenze per questo pacchetto .hpkg, a parte quelle che vengono installate in Haiku di default e, quindi, dovrebbero essere in ogni sistema Haiku?
In questa categoria Mac vince con un piccolo margine.
Commenta mr. waddlesplash:
Per scrivere un programma per raccogliere tutte le dipendenze di un'applicazione sotto forma di un insieme di pacchetti
.hpkgper qualcuno che conosce la struttura interna di Haiku, bastano circa 15 minuti. Aggiungere supporto per questo non è così difficile, se c'è un reale bisogno. Ma per me è una situazione rara.
Teniamo il respiro fino al prossimo articolo di questo ciclo.
Spostamento dei pacchetti in un'area separata
Come ho già scritto in precedenza, voglio collocare i miei pacchetti .hpkg (beh, o parte di essi) in un luogo speciale, separato dalla posizione abituale sul volume di avvio (partizione radice). Di solito (non così teorico) il motivo è che finisce costantemente lo spazio libero sui miei (integrati) dischi, indipendentemente da quanto siano grandi. E di solito collego dischi esterni o risorse di rete dove si trovano le mie applicazioni.
Su Mac trasferisco semplicemente i pacchetti .app su un disco rimovibile o una cartella di rete in Finder, e questo è tutto. Posso ancora aprire l'applicazione con un doppio clic come facevo di solito con il volume di avvio. Facile!
Su Haiku, come mi è stato detto, questo può essere fatto spostando i miei .hpkg pacchetti su un disco rimovibile o una cartella di rete, ma poi è necessario utilizzare alcuni comandi non documentati nel terminale per montarlo nel sistema. Non so come farlo usando solo l'interfaccia grafica.
In questa categoria vince il Mac.
Secondo mr. waddlesplash:
Qui si ottimizza in funzione dell'uso comune. Se ci sarà più richiesta da parte di un singolo utente, lo implementeremo. In ogni caso, esiste la possibilità di implementazioni di terze parti.
Ne parleremo nel prossimo articolo.
Parlando di cartelle di rete: sarebbe fantastico (presumo feste LAN) avere applicazioni semplici, rintracciabili e di rete (ad esempio, tramite Zeroconf), che possano essere copiate sul computer locale o avviate direttamente dalla rete locale. Certamente, gli sviluppatori hanno la possibilità di rifiutare tramite app_flags.
Relazione finale sull'integrazione del sistema hpkg con l'interfaccia grafica
Penso che prima di tutto a causa della relativa novità, l'integrazione .hpkg con l'interfaccia grafica lascia ancora desiderare. Ad ogni modo, ci sono diverse cose che possono essere migliorate in termini di UX...
Un'altra cosa: Kernel Debug Land
Sarebbe fantastico avere la possibilità di inserire comandi in caso di kernel panic, ad esempio syslog | grep usb. Bene, su Haiku questo è possibile grazie a Kernel Debug Land. Come si può vedere questa magia in azione, se tutto funziona come dovrebbe senza entrare in kernel panic? Facile, premi Alt+PrintScn+D (mnemonica Debug). Mi viene subito in mente , che permetteva agli sviluppatori originali del Macintosh di entrare nel debugger (se era installato, ovviamente).
Conclusione
Comincio a capire che la raffinatezza del sistema Haiku deriva dal fatto che il lavoro viene portato avanti da un piccolo team con una chiara orientazione verso l'ambiente di lavoro rendendo disponibili tutti i livelli del sistema.
Un netto contrasto con il mondo Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu, dove tutto è spezzettato in piccoli pezzi al punto che l'astrazione è sovrapposta a ulteriori astrazioni e viene spinta con delle soluzioni di emergenza.
Ho anche compreso come il sistema .hpkg combini le migliori pratiche dei tradizionali gestori di pacchetti, Snappy, Flatpak, AppImage, persino btrfs, e le mescoli con il principio del "funziona e basta" di Mac.
Sembra che qualcosa si sia "attivato" nella mia mente, e ho capito come il sistema .hpkg sia capace di tornare indietro, semplicemente guardandolo. Ma non sono io, è la bellezza e la semplicità del sistema. Molto di questo è permeato dallo spirito dell'originale Mac.
Sì, la navigazione delle pagine nel browser può essere a scatti e funzionare lentamente, ci potrebbero essere applicazioni mancanti (non ci sono Gtk, Electron — gli sviluppatori hanno concluso che non si abbinano bene con la raffinatezza), l'accelerazione video e 3D potrebbe addirittura mancare del tutto, ma mi piace comunque questo sistema. Infatti, queste cose possono essere corrette e prima o poi arriveranno. È solo una questione di tempo e, forse, di alcuni occhi rossi.
Non posso offrire aiuto, ma penso che da questo momento inizi l'anno di Haiku sul desktop.
Problemi casuali
Ci sono già richieste, o devo aprirne io?
- BeScreenCapture dovrebbe avere la possibilità di esportare in GIF, come in Peek. Questo può essere fatto usando ffmpeg, già disponibile per Haiku. .
- Il programma per catturare schermate non può catturare una finestra modale, ma cattura invece l'intero schermo
- Non è possibile ritagliare le schermate usando lo strumento di ritaglio in WonderBrush e poi salvare il risultato in un file
- Non mi piace molto il cursore a forma di mano in Haiku, ma penso che sia legato a sentimenti nostalgici. Questo è particolarmente fastidioso quando si usa lo strumento di ritaglio in Krita, perché risulta in un ritaglio impreciso (vedi le schermate con i dialoghi modali in questo articolo). Un cursore a forma di croce sarebbe fantastico. .
Provate voi stessi! Infatti, il progetto Haiku offre immagini da scaricare su DVD o USB, generate . Per installare, basta scaricare l'immagine e scriverla su una chiavetta usando
Hai domande? Ti invitiamo nel canale telegram in lingua russa .
Panoramica degli errori:
Da traduzione: questo è il sesto articolo di un ciclo su Haiku.
Elenco degli articoli:
Fonte: habr.com
