TL;DR: Haiku — un sistema operativo progettato specificamente per PC, con diverse funzionalità che migliorano notevolmente il suo ambiente di lavoro rispetto ad altri. Ma come funziona?
Ho scoperto Haiku, un sistema sorprendentemente buono. Sono ancora colpito da quanto funzioni senza intoppi, soprattutto rispetto agli ambienti di lavoro su Linux. Oggi darò un'occhiata sotto il cofano. Dove necessario per una comprensione più approfondita, farò un confronto con il Macintosh originale, Mac OS X e gli ambienti di lavoro Linux (lo standard XDG di freedesktop.org).
Risorse nei file ELF
Ieri ho scoperto che IconOMatic può salvare icone nelle risorse rdef nei file eseguibili ELF. Oggi voglio vedere come funziona realmente.
Risorse? da , autore originale del programma Macintosh Finder e 'padre' del Macintosh Resource Manager:
Mi preoccupa la rigida natura della programmazione tradizionale. Per me, l'idea stessa di un'applicazione cristallizzata nel codice, senza possibilità di modificarne dinamicamente alcunché, è una barbarie estrema. Deve esserci la possibilità di cambiare il maggior numero possibile di elementi durante il tempo di esecuzione. Certo, il codice stesso dell'applicazione non può essere cambiato, ma ci deve pur essere qualcosa che si può modificare senza ricompilare il codice?
Sul Macintosh originale, è stato implementato un sistema con una ‘sezione dati’ e una ‘sezione risorse’, il che ha notevolmente facilitato il salvataggio di diversi elementi, come icone, traduzioni, ecc., all'interno dei file eseguibili.
Su Mac, ciò è gestito da , un'applicazione grafica destinata, sorprendentemente, a modificare risorse.
ResEdit sul Macintosh originale
Ha quindi reso possibile modificare icone, voci di menu, traduzioni e altri elementi in modo abbastanza semplice, anche se continuano a ‘viaggiare’ con le applicazioni.
In ogni caso, questo approccio aveva un grande svantaggio: funzionava solo su file system Apple, e questo è stato uno dei motivi per cui Apple ha abbandonato la ‘sezione risorse’ con il passaggio a Mac OS X.
Su Mac OS X, Apple cercava una soluzione indipendente dal file system, quindi ha applicato il concetto di pacchetti (da NeXT), cartelle che vengono gestite dal gestore di file come "oggetti opachi", simili ai file, piuttosto che alle cartelle. Qualsiasi pacchetto con un'applicazione in formato .app ha, tra l'altro, un file Info.plist (in una sorta di analogia JSON o YAML di Apple), contenente i metadati dell'applicazione.
Le chiavi del file Info.plist dal pacchetto dell'applicazione Mac OS X.
Le risorse, come icone, file UI e altro, sono memorizzate nel pacchetto in forma di file. Il concetto è tornato sostanzialmente alle origini in NeXT.
Mathematica.app su NeXTSTEP 1.0 nel 1989: appare come una cartella con file nel terminale, ma come un oggetto unico 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 utilizzato su Linux), hanno deciso di aggiungere una sezione risorse alla fine dei file ELF. Per questo non è stata utilizzata una sezione ELF appropriata, ma è stata semplicemente aggiunta alla fine del file ELF. Di conseguenza, i programmi strip e altri da binutils, che non sapevano di ciò, lo hanno semplicemente tagliato. Quindi, quando si aggiungono risorse a un file ELF su BeOS, è meglio non lavorare con strumenti Linux.
E cosa sta succedendo ora con Haiku? Fondamentalmente, più o meno la stessa cosa.
In teoria, sarebbe possibile collocare le risorse nella sezione ELF desiderata. Secondo gli sviluppatori sul canale #haiku nella rete irc.freenode.net:
Con ELF la sezione avrebbe più senso… l'unico motivo per cui non lo facciamo è perché lo si faceva in BeOS.
E cambiarlo ora non ha senso.
Gestione delle risorse
Le risorse sono scritte in un formato 'risorsa' strutturato: in sostanza, è un elenco di risorse con dimensioni e poi il loro contenuto. Mi è tornato in mente .
Come si possono controllare le risorse in Haiku? Esiste qualcosa come ResEdit?
Secondo :
Per visualizzare le risorse fornite nel pacchetto applicativo, è possibile trascinare il file eseguibile su un programma tipo È anche possibile aprire il terminale e lanciare il comando
listres nome_file..
Resourcer è disponibile in HaikuDepot, ma per me semplicemente si blocca.
Come gestire le risorse nei file ELF? Usando rsrc. e rdef. rdef i file vengono assemblati in rsrc.. Il file rdef è memorizzato in un normale formato di testo, quindi è molto più facile lavorare con esso. Il file è in formato rsrc. aggiunto alla fine del file ELF. Proviamo a giocare:
~> rc -h
Haiku Resource Compiler 1.1
Per 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 costruisci i nomi delle risorse dai simboli ID
-h --help mostra questo messaggio
-I --include aggiungi all'elenco dei percorsi di inclusione
-m --merge non cancellare i contenuti esistenti del file di output
-o --output specifica il nome del file di output, il valore predefinito è out.xxx
-q --quiet non visualizzare alcun messaggio di errore
-V --version mostra la versione 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_VERSIONMaggiore informazione sulle risorse e sul formato rdef puoi leggere .
Tipi di risorse standard
Sebbene sia possibile mettere nelle risorse qualsiasi cosa, ci sono alcuni tipi standard definiti:
app_signature: Tipo MIME dell'applicazione, per il mapping di file aperti, avvio, IPC, ecc.app_name_catalog_entry: Poiché il nome dell'app è di solito in inglese, qui puoi specificare i luoghi in cui si trovano i nomi tradotti, in modo che utenti di lingue diverse possano vedere il nome tradotto dell'app quando lo desiderano.app_version: esattamente quello che pensaviapp_flags: indicaregistrarcome gestire un'applicazione. Penso che ci sia qualcosa di più di quanto sembri a prima vista. Ad esempio, c'èB_SINGLE_LAUNCH, che costringe il sistema ad avviare un nuovo processo dell'applicazione ogni volta che un utente lo richiede (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 (ad esempio, allo stesso modo si avvia Firefox su Linux; si può ottenere lo stesso risultato nelle applicazioni Qt utilizzando la funzione ). Le applicazioni conB_EXCLUSIVE_LAUNCHvengono avvisate quando un utente prova a lanciarle nuovamente: ad esempio, ricevono il percorso del file che l'utente desidera aprire tramite esse.vector_icon: Icona vettoriale dell'applicazione (In BeOS non c'erano icone vettoriali; la maggior parte delle applicazioni aveva invece due icone raster nelle proprie eseguibili).
Certo, è possibile aggiungere risorse con qualsiasi ID e tipo desiderato, dopo di che possono essere lette nell'applicazione o in altre applicazioni utilizzando la classe BResources. Ma prima di tutto, soffermiamoci su un argomento interessante: le icone.
Icone vettoriali in stile Haiku
Naturalmente, non è solo Haiku a scegliere il miglior formato per le icone; in questa parte, la situazione degli ambienti di lavoro Linux è tutt'altro che 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 i scalable, che contengono, come si può intuire, le icone vettoriali. Perché allora ci sono altre opzioni? Perché il risultato del rendering della grafica vettoriale a dimensioni ridotte può essere inferiore all'ideale. Si desidera avere varie opzioni ottimizzate per diverse dimensioni. Negli ambienti di lavoro Linux, questo si ottiene distribuendo le icone di 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.pngSi prega di notare che non esistono versioni diverse di Firefox. Pertanto, non è possibile gestire in modo raffinato la situazione con più versioni dell'applicazione nel sistema.
Diverse icone di Firefox in diverse versioni. Al momento, non è possibile gestire questo su Linux senza vari palliativi.
Mac OS X gestisce in modo un po' più sofisticato:
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, che contiene tutte le dimensioni, quindi diverse versioni della stessa applicazione hanno diverse icone.
Molto meglio! Le icone viaggiano insieme all'applicazione, tutte le risorse in un unico file.
Torniamo a Haiku. Una soluzione sbalorditiva, senza eccezioni. Secondo :
è stato sviluppato un formato speciale HVIF, altamente ottimizzato per piccole dimensioni e veloce rendering. Pertanto, le nostre icone sono per lo più molto più piccole rispetto ai formati raster o al comune formato SVG.
E sono effettivamente ottimizzate:
Dimensioni delle icone in HVIF rispetto ad altri formati.
La differenza è di un ordine di grandezza!
Ma la magia non finisce qui. Lo stesso HVIF può mostrare diversi livelli di dettaglio a seconda della dimensione di visualizzazione, nonostante sia un formato vettoriale.
Diversi livelli di dettaglio (LOD) a seconda della dimensione del rendering
Ora parliamo dei difetti: non puoi prendere un SVG, metterlo in ImageMagick e finire lì, devi passare attraverso diversi cicli per creare un'icona nel formato HVIF. spiegazioni. Tuttavia, IconOMatic può importare gli SVG in modo piuttosto imperfetto; circa il 90% dei dettagli dell'SVG viene importato con una certa probabilità, i restanti 10% dovranno essere configurati e modificati manualmente. Puoi leggere di più su come HVIF fa la sua magia nel blog
Aggiungere un'icona all'applicazione
Ora posso aggiungere un'icona al pacchetto creato , tenendo conto di tutte le informazioni ottenute.
Poiché al momento non ho particolare voglia di disegnare la mia icona per il mio 'Ciao, Mondo' QtQuickApp — 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 CreatorControlliamo se l'icona è 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 la nuova icona è stata copiata, non viene visualizzata?
Il VICN:101:BEOS:ICONs copiato non viene utilizzato come icona per l'applicazione nel gestore di file
Cosa mi sono perso?
Commento dello sviluppatore:
Devo creare un file
rdefcon tutte le risorse, poi eseguire il comandorc nome.rdef, questo creerà un file.rsrc. Poi devo eseguire il comandoresattr -o nome_binario nome.rsrc. Almeno, uso comandi simili per aggiungere icone ai miei script.
Beh, volevo creare una risorsa, non un attributo. Sono proprio confuso.
Cache intelligente utilizzando il filesystem
Aprire e leggere gli attributi ELF è lento. Come ho già scritto sopra, l'icona viene scritta come risorsa nel file stesso. Questo metodo è più affidabile, consente di sopravvivere alla copia su un altro filesystem. Tuttavia, poi viene anche copiato nell'attributo del filesystem, ad esempio BEOS:ICON. Funziona solo su alcune file system, ad esempio BFS. Le icone visualizzate dal sistema (in Tracker e Deskbar) vengono lette da questo attributo esteso, poiché questa soluzione è rapida. In alcune situazioni (dove la velocità non è importante, ad esempio nella finestra standard 'Informazioni su') il sistema ottiene l'icona direttamente dalla risorsa nel file. Ma non è ancora finita. Ricordate, su Mac, gli utenti possono sostituire le icone delle applicazioni, delle cartelle e dei documenti con le proprie, dato che su Mac è possibile fare queste 'cose importanti', ad esempio . Su Haiku, è importante considerare la risorsa (nel file) come l'icona di origine fornita con l'applicazione e l'attributo (nel file system BFS) come qualcosa che consente all'utente di apportare modifiche a piacere (sebbene, piccolo suggerimento, l'interfaccia grafica per inserire un'icona personalizzata sopra l'icona predefinita non sia ancora implementata).
Verifica degli attributi del file system
Con resaddr c'è la possibilità di controllare e impostare gli attributi del file system.
/> 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, è una 'colla' che esegue una conversione avanti e indietro tra risorse (affidabili) e attributi (veloci) del file system. Poiché il sistema prevede il recupero delle risorse e copia automaticamente, non mi preoccuperò ulteriormente di questo.
La magia dei pacchetti hpkg
Attualmente (più spesso) per ottenere programmi su Haiku si utilizzano pacchetti .hpkg. Non lasciatevi ingannare dal semplice nome: il formato .hpkg funziona in modo completamente diverso rispetto ad altri formati con nomi simili che avete incontrato, ha vere superpoteri.
Con i formati tradizionali dei pacchetti, mi sono a lungo frustrato per questo fatto: scarichi uno (pacchetto) e nel sistema ne installi un altro (file all'interno del pacchetto). È piuttosto difficile gestire i file (ad esempio, rimuoverli) quando un pacchetto viene installato nel modo tradizionale. Questo perché il contenuto del pacchetto si disperde in tutto il file system, inclusi i luoghi a cui un utente normale potrebbe non avere accesso in scrittura. Questo genera una vera e propria classe di programmi — gestori di pacchetti.. E nel caso di un software già installato, il trasferimento su un'altra macchina, un disco rimovibile o un server di file diventa persino più difficile, se non del tutto impossibile. In un sistema Linux standard possono facilmente esistere da diverse centinaia di migliaia a milioni di file isolati. È ovvio che questo sia sia fragile che lento, ad esempio durante l'installazione iniziale del sistema, l'installazione, l'aggiornamento e la rimozione di pacchetti comuni, così come durante la copia della partizione di avvio (partizione root) su un altro supporto.
Sto lavorando al progetto AppImage, una soluzione temporanea per applicazioni destinate agli utenti finali. Questo è un formato di distribuzione software che racchiude l'applicazione e tutte le sue dipendenze in un'unica immagine del file system, montata al momento dell'avvio dell'applicazione. Questo semplifica notevolmente le cose, poiché lo stesso ImageMagick si trasforma all'improvviso in un singolo file, gestito dagli utenti nel file manager. Il metodo proposto funziona solo per software, come riflesso nel nome del progetto, e presenta anche il proprio insieme di problemi, poiché le persone che si occupano di distribuzioni 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 distribuzione di software basata su immagini? I suoi pacchetti .hpkg sono di fatto immagini di file system compresse. Durante il caricamento del sistema, il kernel monta tutti i pacchetti installati e attivi, con messaggi del kernel simili ai seguenti:
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? Tenetevi forte, continuerà a essere ancora più interessante!
C'è un pacchetto molto speciale:
KERN: package_daemon [16040020: 924] pacchetto attivo: "haiku-r1~beta1_hrev53242-1-x86_64.hpkg"Contiene un sistema operativo piuttosto minimalista, incluso il kernel. Credeteci o no, ma persino il kernel non viene estratto dal volume di avvio (partizione radice), ma viene caricato con cura al suo posto da un pacchetto. .hpkg. Wow! Ho già accennato al fatto che, secondo me, 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 all'infrastruttura dell'ambiente di lavoro, è sviluppato da un'unica squadra. Immagina quanti gruppi e team sarebbero necessari per lanciarne uno simile basato su Linux. [immagino il progetto PuppyLinux, — nota del traduttore]. Poi immagina quanto tempo ci vorrebbe perché questo approccio venga implementato nelle distribuzioni. Dicono: prendi un compito semplice, dividilo tra diversi esecutori, e diventa così complesso da non poter più essere risolto. Haiku, in questo caso, mi ha aperto gli occhi. Penso che sia proprio quello che sta succedendo a Linux attualmente (Linux, in questo caso, è un termine collettivo che indica lo stack Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu).
Ripristino del sistema utilizzando hpkg
Quante volte ci si trova nella seguente situazione: l'aggiornamento è andato a buon fine, ma poi si scopre che qualcosa non funziona come dovrebbe? Quando si utilizzano gestori di pacchetti comuni, è difficile riportare lo stato del sistema a un momento precedente all'installazione dei nuovi pacchetti (ad esempio, quando qualcosa va storto). Alcuni sistemi offrono soluzioni come gli snapshot del file system, ma sono piuttosto ingombranti ed è raro che vengano applicati in tutti i sistemi. In Haiku, questo problema è risolto tramite pacchetti. .hpkgOgni volta che i pacchetti nel sistema cambiano, i pacchetti vecchi non vengono rimossi, ma conservati nel sistema in sottodirectory del tipo /Haiku/system/packages/administrative/state-<...>/ continuamente. Le operazioni incomplete memorizzano i propri dati in sottodirectory /Haiku/system/packages/administrative/transaction-<...>/.
Contenuto /Haiku/system/packages/administrative. Le directory "state..." contengono file di testo con i nomi dei pacchetti attivi, mentre "transaction..." contengono i pacchetti stessi.
"Stato attivo precedente", ovvero l'elenco .hpkg dei pacchetti attivi prima delle modifiche, viene registrato dopo ogni operazione nel gestore di file in un file di testo /Haiku/system/packages/administrative/state-<...>/activated-packages. In modo simile, viene registrato il nuovo "stato attivo" in un file di testo. /Haiku/system/packages/administrative/activated-packages.
Directory /Haiku/system/packages/administrative/state-<...>/ contiene solo un file di testo con l'elenco dei pacchetti attivi in questo stato (nel caso in cui siano stati installati pacchetti senza rimuoverli), e se i pacchetti sono stati rimossi o aggiornati, la cartella di stato contiene le versioni precedenti dei pacchetti.
Al caricamento del sistema si decide se attivare (montare) i pacchetti in base all'elenco dei pacchetti. È così semplice! Se qualcosa va storto durante il caricamento, è possibile indicare al manager di avvio di utilizzare un elenco diverso, più vecchio. Problema risolto!
Bootloader di Haiku. Ogni punto di ingresso riflette il corrispondente 'stato attivo'.
Apprezzo l'approccio con file di testo semplici come lista dello 'stato attivo', nei quali sono registrati nomi di facile comprensione. .hpkg. Questo contrasta fortemente con quanto creato per le macchine e non per le persone. da OSTree o Flatpak nel file system (allo stesso livello di Microsoft GUID).
L'elenco dei pacchetti attivi per ogni momento nel tempo.
Dati di configurazione
A quanto pare, nella cartella /Haiku/system/packages/administrative/writable-files ci sono file di configurazione per i pacchetti, ma non sono accessibili in scrittura. Come ricorderete, .hpkg sono montati in sola lettura. Pertanto, questi file devono essere copiati dai pacchetti prima della registrazione. Ha senso.
Integrazione GUI per il sistema .hpkg
Vediamo ora come questi straordinari pacchetti .hpkg gestiscono l'integrazione nell'ambiente di lavoro dell'utente (UX). Dopotutto, Haiku è progettato per l'uso personale. Personalmente, ho alzato l'asticella confrontando l'esperienza utente con i pacchetti .app su Macintosh con la stessa esperienza su .hpkg. Non voglio nemmeno confrontare 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 rimuovere 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 trasferire i miei pacchetti (o una parte di essi) in un altro posto, separato dal volume di avvio (partizione principale) (perché, ad esempio, ho pochissimo spazio su di esso).
Questo dovrebbe coprire la maggior parte dei casi principali della mia routine quotidiana. Bene, cominciamo.
Controllo del contenuto del pacchetto
Su Mac basta cliccare destro sul pacchetto per aprirlo e visualizzarne il contenuto nel Finder. In effetti, è semplicemente una cartella mascherata! (So che ci sono pacchetti .pkg per alcune parti del sistema che non sono applicazioni, ma gli utenti normali di solito non interagiscono con essi).
Su Haiku clicco con il tasto 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) di montare il pacchetto .hpkg per visualizzarlo tramite il gestore di file, senza che l'utente debba preoccuparsi dei dettagli dell'implementazione. (Tra l'altro, è possibile aprire .hpkg il pacchetto in Expander, che può estrarlo come qualsiasi altro archivio).
Nell'interfaccia di HaikuDepot puoi 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 aggiungere la funzionalità necessaria in HaikuDepot non dovrebbe essere troppo difficile.
Installazione del pacchetto tramite l'interfaccia grafica.
Su Mac, la maggior parte delle immagini disco .dmg contiene pacchetti. .appApriamo l'immagine disco con un doppio clic, dopodiché copiamo il pacchetto, ad esempio, trascinandolo in /Applications Finder. Per me è scontato, ma ho sentito che alcuni principianti potrebbero trovarlo difficile. Per impostazione predefinita, Apple "offre" una cartella di sistema comune /Applications (su NeXT era sia di rete che individuale), ma è possibile facilmente 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 clic su "Installa", più semplice di così non si può. Sono curioso di sapere cosa succede se il pacchetto ha dipendenze disponibili in HaikuPorts, ma ancora non installate. Su Linux in effetti non sanno cosa fare in questa situazione, ma la soluzione è ovvia: chiedere all'utente se è necessario scaricare e installare le dipendenze. Esattamente ciò che fa Haiku.
Ho scaricato manualmente il pacchetto 'sanity' e ci ho cliccato sopra; il gestore dei pacchetti sa da dove prendere le sue dipendenze (a patto che i repository siano già configurati nel sistema). Non tutte le distribuzioni Linux sono in grado di farlo.
Un altro modo è utilizzare un file manager, è sufficiente trascinare .hpkg il pacchetto o in /Haiku/system/packages (per l'installazione di sistema, per impostazione predefinita), o in /Haiku/home/config/packages (per l'installazione individuale; non disponibile con un doppio clic — mi infastidisce ancora la parola «config» in questo contesto, che per me è sinonimo di «settings»). Eppure il concetto di più utenti non è nemmeno disponibile per Haiku (forse per questo tutto è così semplice — non so, forse le capacità multutente complicano eccessivamente le cose per l'ambiente di lavoro di un computer personale).
In questa categoria vince Haiku, perché può lavorare non solo con le applicazioni, ma anche con i programmi di sistema.
Rimuovere un pacchetto attraverso l'interfaccia grafica
Su Mac, bisogna 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 nel posto giusto (è il sistema a gestirlo). Di solito, bisogna cercare in /Haiku/system/packages (con installazione predefinita del sistema), o in /Haiku/home/config/packages (ho già detto che «config» è un nome sbagliato?). Poi l'applicazione viene semplicemente trascinata nel cestino, e questo è tutto.
Facile! Tuttavia, non direi così. Ecco cosa succede realmente:
Ecco cosa si ottiene se si trascina l'applicazione nel cestino da /Haiku/system/packages
Ho provato semplicemente a spostare nel cestino la mia applicazione di ieri «Ciao, mondo» su QtQuickApp. Non ho cercato di spostare la cartella di sistema, e poiché tutti i pacchetti vengono installati nella cartella di sistema — è impossibile rimuovere un pacchetto .hpkg senza modificare «il suo contenuto». Un utente normale si spaventerebbe, premerebbe il pulsante «Annulla», impostato come predefinito.
Spiega :
Questo messaggio ha più di 10 anni. Probabilmente dobbiamo configurarlo in modo che l'avviso appaia solo durante il trasferimento del pacchetto stesso. In ogni caso, gli utenti normali non hanno bisogno di farlo.
Bene, forse dovrei farlo usando HaikuDepot? Faccio doppio clic sul pacchetto in /Haiku/system/packages, aspettandomi che appaia il pulsante «Disinstalla». Nope, c'è (solo) «Installa». «Disinstalla», dove sei?
Per curiosità, ho provato a vedere cosa succede se clicco su «Installa» per un pacchetto già installato. Risultato:
Questo è ciò che accade se provi a installare un pacchetto già installato.
Poi appare:
Se clicchi su «Applica modifiche» nella finestra precedente — appare così:
Presumo che sia un bug, il link alla segnalazione è già disponibile. [l'autore non ha fornito un link, — nota del traduttore]
Soluzione rapida: Aggiungere un pulsante «Disinstalla» se il pacchetto è già presente in
/Haiku/system/packages, o in/Haiku/home/config/packages.
Quando visualizzo l'elenco dei pacchetti installati in HaikuDepot, vedo il mio pacchetto nell'elenco e posso eliminarlo.
In questa categoria vince Mac. Ma posso immaginare che, con la giusta configurazione, l'esperienza utente su Haiku possa essere migliore rispetto a Mac. (Uno degli sviluppatori ha valutato così: «Meno di un'ora per aggiungere la funzionalità specificata in HaikuDepot, se sai un po' di C++», ci sono volontari?)
Eliminare qualcosa dal pacchetto
Proviamo a rimuovere l'applicazione stessa, e non il pacchetto .hpkg, da cui è provenuta (dubito che per i «normali mortali» ci sia una differenza).
Su Mac, l'utente di solito lavora effettivamente 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 dall'utente in /Applications. Si dice che molti utenti non sappiano cosa stiano facendo, e questa ipotesi è supportata da un ex dipendente di Apple. (Una delle cose che non mi piacciono dei Mac. Per esempio, con AppImage non c'è differenza tra l'applicazione e il pacchetto in cui si trova. Trascini l'icona nel cestino = ed è tutto. Facile!)
Su Haiku, c'è anche una suddivisione tra apps/ e packages/, quindi dubito che questo renda le cose più chiare per gli utenti. Ecco cosa succede se trascini un'applicazione da apps/ nel cestino:
Ecco cosa ottieni nel tentativo di eliminare un'applicazione presa da un file .hpkg
Tecnicamente è corretto (dato che l'app è posizionata su un filesystem di sola lettura, prima di tutto), ma non è particolarmente utile per l'utente.
Soluzione rapida: invece, offrire di eliminare tramite GUI
.hpkg
Per divertimento, ho provato a duplicare l'applicazione premendo Alt+D. Ho ricevuto un messaggio "Impossibile spostare o copiare oggetti su un volume di sola lettura". E tutto perché /system (oltre a /system/packages e /system/settings) è un punto di montaggio di packagefs (ricorda come appare nell'output df?). К сожалению, вывод команды mount non chiarisce la situazione (come era stato detto in uno dei precedenti articoli), mountvolume non mostra quello che si cerca (i pacchetti montati tramite loop, a quanto pare, .hpkg non sono considerati "volumi"), e ho anche dimenticato comandi alternativi.
In questa categoria nessuno ha vinto, tranne AppImage (ma, per essere onesti, è un'opinione parziale). Tuttavia, si può ipotizzare che, dopo la regolazione, l'esperienza utente su Haiku sarà migliore rispetto a quella su Mac.
Nota: è necessario chiarire cosa si intende per "volume" in relazione a "partizione". Probabilmente è simile al concetto di "cartella" rispetto a "catalogo": la maggior parte dei cataloghi viene visualizzata nel gestore di file come cartelle, ma non tutti (ad esempio, i pacchetti trattati come file). Tali considerazioni mi rendono un nerd ufficialmente?
Copiare il contenuto di un pacchetto su un altro sistema
Su Mac, semplicemente trascino il pacchetto .app, e poiché le dipendenze all'interno del pacchetto si spostano insieme.
Su Haiku, trascino l'applicazione, ma le dipendenze non vengono elaborate affatto.
Soluzione rapida: lasciare che venga proposto di trascinare il pacchetto "`.hpkg interamente, insieme alle dipendenze, se presenti.
In questa categoria, sicuramente vince il Mac. Almeno per me, amante della loro filosofia. Si dovrebbe copiare su Haiku. .hpkg invece di un'applicazione, ma il sistema non mi offre nulla del genere…
Scaricamento del pacchetto con tutte le sue dipendenze.
Non ogni macchina è sempre connessa alla rete. Anzi, alcune macchine (sì, sto guardando voi, moderni Windows, Mac e Linux) se ne dimenticano. Per me è importante poter andare, per esempio, in un internet café, caricare software su un supporto rimovibile, inserire quel supporto nel computer di casa e avere la certezza che tutto funzionerà [rischioso, fare una cosa del genere su Windows… — nota del traduttore].
Di conseguenza, più spesso del solito, di solito ottengo dipendenze non soddisfatte su Windows e Linux.
Su Mac di solito è un solo file, tutto ciò che serve è scaricare. .dmgLa maggior parte delle volte non ha dipendenze, tranne quelle fornite dalla stessa macOS per impostazione predefinita. Come eccezione si possono citare applicazioni complesse che richiedono un ambiente di esecuzione specifico, ad esempio Java.
Su Haiku scaricare il pacchetto. .hpkg per esempio, per la stessa applicazione in java, potrebbe non essere sufficiente, poiché java può sia essere presente che assente sulla macchina di destinazione. C'è un modo per scaricare tutte le dipendenze per questo pacchetto .hpkg, escludendo quelle installate in Haiku di default e che quindi dovrebbero essere in ogni sistema Haiku?
In questa categoria, Mac vince con un piccolo margine.
Commenta mr. waddlesplash:
Per scrivere un programma che raccoglie tutte le dipendenze di un'applicazione sotto forma di un insieme di pacchetti
.hpkgper qualcuno che conosce bene l'architettura di Haiku, ci vogliono circa 15 minuti. Aggiungere supporto per questo non è così difficile, se c'è una vera necessità. Ma per me è una situazione rara.
Tratteniamo il respiro fino al prossimo articolo in questo ciclo.
Spostamento dei pacchetti in una posizione separata
Come ho scritto in precedenza, voglio mettere i miei pacchetti .hpkg (o una parte di essi) in un'area speciale, separata dalla normale posizione sul volume di avvio (partizione principale). Normalmente (non così teoricamente) la ragione è che lo spazio libero sui miei (interni) dischi si sta esaurendo, indipendentemente da quanto siano grandi. Di solito collego dischi esterni o risorse di rete dove si trovano le mie applicazioni.
Su Mac Semplicemente sposto i pacchetti .app su un disco rimovibile o una cartella di rete in Finder, e questo è tutto. Posso ancora aprire il programma con un doppio clic come facevo di solito dal volume di avvio. Facile!
Su Haiku, come mi è stato detto, questo può essere raggiunto 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 montarli nel sistema. Non so come farlo usando solo l'interfaccia grafica.
In questa categoria vince il Mac.
Secondo mr. waddlesplash:
Qui l'ottimizzazione è calcolata per un uso normale. Se ci sarà una domanda superiore a quella di un singolo utente, lo realizzeremo. In ogni caso, esiste la possibilità di un'implementazione di terze parti.
Ne parleremo nel prossimo articolo.
Parlando di directory di rete: sarebbe fantastico (presumendo feste LAN) avere applicazioni di rete semplici e scopribili (ad esempio, tramite Zeroconf) che possano essere copiate sul computer locale o eseguite immediatamente dalla rete locale. Certamente, agli sviluppatori è data la possibilità di rinunciare tramite app_flags.
Rapporto finale sull'integrazione del sistema hpkg con GUI
Penso che soprattutto a causa della relativa novità, l'integrazione .hpkg con la GUI richieda ancora miglioramenti. In ogni caso, ci sono alcune cose che si possono migliorare riguardo all'UX…
Un'altra cosa: Kernel Debug Land
Sarebbe fantastico, in caso di kernel panic, avere la possibilità di inserire comandi, per esempio syslog | grep usb. Su Haiku questo è possibile grazie a Kernel Debug Land. Come vedere questa magia in azione, se tutto funziona bene senza incappare in un kernel panic? Facile, premendo Alt+PrintScn+D (mnemonico Debug). Mi vengono subito in mente , che permetteva ai primi sviluppatori di Macintosh di accedere al debugger (se era installato, naturalmente).
Conclusione
Inizio a capire che l'eleganza del sistema Haiku deriva dal fatto che il lavoro è svolto da un piccolo team con una chiara attenzione all'ambiente di lavoro, mantenendo tutti i livelli del sistema accessibili.
Un netto contrasto con il mondo Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu, dove tutto è frammentato in pezzi così piccoli che l'astrazione si sovrappone all'astrazione, supportata da rimedi vari.
Ho anche compreso come il sistema .hpkg combina le migliori pratiche dei tradizionali gestori di pacchetti, Snappy, Flatpak, AppImage, persino btrfs, mescolandole con il principio del "funziona semplicemente" di Mac.
Come se qualcosa si fosse "attivato" nella mia mente, e ho capito come il sistema .hpkg sia in grado di effettuare un rollback, semplicemente guardandolo. Ma non sono io, è la bellezza e la semplicità del sistema. Molto qui è permeato dallo spirito del Mac originale.
Sì, la navigazione delle pagine nel browser può essere scattosa e funzionare lentamente, potrebbero mancare applicazioni (niente Gtk, Electron — gli sviluppatori hanno concluso che non si adattano bene alla raffinatezza), l'accelerazione video e 3D può essere completamente assente, ma mi piace comunque questo sistema. Queste cose possono essere corrette e arriveranno prima o poi. È solo una questione di tempo e, forse, di un po' di occhi rossi.
Non posso offrire aiuto, ma penso che da questo momento in poi comincerà anno di Haiku sul desktop.
Problemi casuali
Potrebbe esserci già una richiesta, o devo aprirne una?
- 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ò acquisire una finestra modale, catturando invece l'intero schermo
- Non è possibile ritagliare le schermate utilizzando 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 calde sensazioni nostalgiche. Questo è particolarmente fastidioso quando si utilizza lo strumento di ritaglio in Krita, poiché si ottiene un ritaglio impreciso (vedi gli screenshot con i dialoghi modali in questo articolo). Un cursore a forma di croce sarebbe fantastico. .
Provatelo voi stessi! Infatti, il progetto Haiku fornisce immagini da scaricare su DVD o USB, generate . Per installarlo, basta scaricare l'immagine e scriverla su una chiavetta USB usando
Avete domande? Vi invitiamo a unirvi al nostro .
Panoramica sugli errori:
Da traduzione: questo è il sesto articolo di un ciclo su Haiku.
Elenco degli articoli:
Fonte: habr.com
