TL; DRR: Haiku è un sistema operativo progettato specificamente per PC, quindi ha alcuni accorgimenti per renderlo un ambiente desktop molto migliore di altri. Ma come funziona?
Ho scoperto Haiku, un sistema inaspettatamente buono. Sono ancora stupito di quanto funzioni senza intoppi, soprattutto se confrontato con gli ambienti desktop Linux. Oggi darò un'occhiata sotto il cofano. Ove necessario per una comprensione approfondita, farò confronti con i desktop originali Macintosh, Mac OS X e Linux (standard XDG da freedesktop.org).
Risorse nei file ELF
Ieri ho appreso che IconOMatic può memorizzare le icone nelle risorse rdef nei file eseguibili ELF. Oggi voglio vedere come funziona davvero.
Risorse? от , l'autore originale del Macintosh Finder e il padre del Macintosh Resource Manager:
Sono preoccupato per la natura rigida della codifica tradizionale. Per me, l'idea stessa di un'applicazione congelata nel codice, senza la possibilità di modificare nulla in modo dinamico, è la più sfrenata. Dovrebbe essere possibile modificare il più possibile in fase di esecuzione. Naturalmente, il codice dell'applicazione stesso non può essere modificato, ma è possibile modificare qualcosa senza ricompilare il codice?
Il Macintosh originale prevedeva che questi file avessero una "sezione dati" e una "sezione risorse", che rendeva estremamente facile salvare cose come icone, traduzioni e così via. nei file eseguibili.
Su Mac, questo vale , un programma grafico per - improvvisamente - modificare le risorse.
ResEdit su Macintosh originale
Di conseguenza, è diventato possibile modificare icone, voci di menu, traduzioni e così via. abbastanza facile, ma continuano a "viaggiare" con le applicazioni.
In ogni caso, questo approccio aveva un grosso svantaggio: funzionava solo sui file system Apple, motivo per cui Apple ha abbandonato la "sezione risorse" quando è passata a Mac OS X.
Su Mac OS X, Apple voleva una soluzione indipendente dal file system, quindi ha adottato il concetto di pacchetti (da NeXT), directory trattate come "oggetti opachi" dal file manager, come file, non directory. Qualsiasi pacchetto con un'applicazione nel formato .app ha, tra l'altro, il file Info.plist (in qualche analogo di JSON o YAML di Apple) contenente i metadati dell'applicazione.
Chiavi del file Info.plist dal pacchetto dell'applicazione Mac OS X.
Le risorse, come icone, file dell'interfaccia utente e altro, vengono archiviate nel pacchetto come file. Il concetto in realtà è tornato alle sue radici in NeXT.
Mathematica.app su NeXTSTEP 1.0 nel 1989: appare come una directory di file nel terminale, ma come un singolo oggetto nel file manager 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 di risorse alla fine dei file ELF. Questo non utilizzava la propria sezione ELF corretta, veniva semplicemente aggiunta alla fine del file ELF. Come risultato del programma strip e altri in binutils che non lo sanno l'hanno semplicemente interrotto. Pertanto, dopo aver aggiunto risorse a un file ELF su BeOS, è meglio non lavorarci con gli strumenti Linux.
E cosa sta succedendo ora con Haiku? Fondamentalmente, più o meno lo stesso.
In teoria, sarebbe possibile collocare le risorse nella sezione desiderata dell'ELF. Secondo gli sviluppatori sul canale #haiku su irc.freenode.net:
Con ELF, la sezione avrebbe più senso... l'unico motivo per cui non lo facciamo è perché l'abbiamo fatto in BeOS."
E non ha bisogno di cambiare ora.
Правление ресурсами
Le risorse sono scritte in un formato "risorsa" strutturato: si tratta infatti di un elenco di risorse con le dimensioni e quindi il loro contenuto. ricordato .
Come controllare le risorse in Haiku? Esiste qualcosa come ResEdit?
Secondo :
Puoi trascinare e rilasciare l'eseguibile su un programma come . Puoi anche andare al terminale ed eseguire il comando
listres имя_файла.
Resourcer è in HaikuDepot, ma per me va in crash.
Quindi, come gestisci le risorse nei file ELF? Usando rsrc и rdef. rdef i file sono raccolti in rsrc. File rdef memorizzato in formato di testo normale, quindi è molto più facile da lavorare. Formato del file rsrc aggiunto alla fine del file ELF. Proviamo a giocare:
~> rc -h
Haiku Resource Compiler 1.1To compile an rdef script into a resource file:
rc [options] [-o <file>] <file>...To convert a resource file back into an rdef script:
rc [options] [-o <file>] -d <file>...Options:
-d --decompile create an rdef script from a resource file
--auto-names construct resource names from ID symbols
-h --help show this message
-I --include <dir> add <dir> to the list of include paths
-m --merge do not erase existing contents of output file
-o --output specify output file name, default is out.xxx
-q --quiet do not display any error messages
-V --version show software version and licensePuoi usare il programma xres 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.
(...)Ok, 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_VERSIONUlteriori informazioni su risorse e formato rdef puoi leggere .
Tipi di risorse standard
Mentre puoi inserire qualsiasi cosa nelle risorse, ci sono alcuni tipi standard definiti:
app_signature: tipo MIME dell'applicazione, per corrispondere a file aperti, avvio, IPC, ecc.app_name_catalog_entry: poiché il nome dell'applicazione è solitamente in inglese, è possibile specificare qui i luoghi in cui si trovano i nomi tradotti, in modo che gli utenti di lingue diverse vedano il nome dell'applicazione tradotto, se lo desiderano.app_version: Esattamente quello che pensaviapp_flags: indicaregistrarcome gestire l'applicazione. Penso che ci sia più di quanto sembri. Ad esempio, c'èB_SINGLE_LAUNCH, che fa sì che il sistema avvii un nuovo processo applicativo ogni volta che l'utente lo richiede (lo stesso principio viene utilizzato per la maggior parte delle applicazioni su Linux). MangiareB_MULTIPLE_LAUNCH, causando l'esecuzione del processo per ciascun file. Finalmente c'èB_EXCLUSIVE_LAUNCH, che costringe il sistema ad avviare un solo processo alla volta, indipendentemente dalla frequenza con cui gli utenti lo avviano (ad esempio, è così che si avvia Firefox su Linux; lo stesso risultato può essere ottenuto nelle applicazioni Qt utilizzando la funzione ). Applicazioni conB_EXCLUSIVE_LAUNCHvengono avvisati quando l'utente tenta di eseguirli nuovamente: ad esempio ottengono il percorso del file che l'utente desidera aprire con loro.vector_icon: icona del vettore dell'applicazione (BeOS non aveva icone vettoriali, la maggior parte delle applicazioni aveva invece due icone bitmap nei file eseguibili).
Naturalmente, puoi aggiungere risorse con qualsiasi ID e tipo desiderato, quindi leggerle nell'applicazione stessa o in altre applicazioni utilizzando la classe BResources. Ma prima, concentriamoci sull'affascinante tema delle icone.
Icone vettoriali in stile Haiku
Certo, non solo Haiku ha scelto il miglior formato di icona, in questa parte la situazione con i desktop 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 questo, puoi già sentire cos'è questo pezzo.
Ovviamente esiste uno scalabile contenente, come puoi vedere, icone vettoriali. Perché allora c'è qualcos'altro? Perché il risultato del disegno di grafica vettoriale in piccole dimensioni può essere tutt'altro che ideale. Vorrei avere diverse opzioni, ottimizzate per dimensioni diverse. Negli ambienti desktop Linux, ciò si ottiene spargendo icone di varie dimensioni in tutto il 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 noti che non esiste il concetto di versioni diverse di Firefox. Pertanto, non è possibile gestire con garbo la situazione con la presenza di più versioni dell'applicazione nel sistema.
Diverse icone di Firefox in diverse versioni. Finora, è impossibile gestirlo in Linux senza varie stampelle.
Mac OS X gestisce un po' 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 può vedere che c'è un file firefox.icns nel pacchetto Firefox.app, contenente tutte le dimensioni, in modo che versioni diverse della stessa applicazione abbiano icone diverse.
Molto meglio! Le icone viaggiano con l'applicazione, tutte le risorse sono in un unico file.
Torniamo all'Haiku. Una decisione strabiliante, senza eccezioni. Secondo :
È stato sviluppato uno speciale formato HVIF, altamente ottimizzato per dimensioni ridotte e rendering veloce. Pertanto, le nostre icone sono per la maggior parte molto più piccole delle bitmap o del formato SVG ampiamente utilizzato.
E sono ancora ottimizzati:
Dimensioni delle icone in HVIF rispetto ad altri formati.
Un ordine di grandezza di differenza!
Ma la magia non finisce qui. Lo stesso HVIF può mostrare diversi livelli di dettaglio a seconda della dimensione visualizzata, anche se è un formato vettoriale.
Diversi livelli di dettaglio (LOD) in base alla dimensione del rendering
Ora sugli svantaggi: non puoi prendere SVG, lanciarlo in ImageMagick e finirlo, devi passare attraverso diversi cicli per creare un'icona in formato HVIF. spiegazioni. Tuttavia, IconOMatic può essere piuttosto imperfetto nell'importazione di SVG; circa il 90% dei dettagli SVG viene importato con una certa probabilità, il restante 10% dovrà essere configurato e modificato manualmente. Leggi di più su come HVIF fa la sua magia sul blog
Aggiunta di un'icona a un'applicazione
Ora posso aggiungere un'icona al pacchetto creato , tenendo conto di tutte le informazioni ricevute.
Bene, dal momento che non sono particolarmente ansioso di disegnare la mia icona per la mia QtQuickApp "Hello World", la tiro fuori 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 copiata:
/Haiku/home> xres -l /Haiku/home/QtQuickApp/QtQuickApp/Haiku/home/QtQuickApp/QtQuickApp
resources:type ID size name
------ ----------- ----------- --------------------
'VICN' 101 152238 BEOS:ICONSembra buono, ma perché quando la nuova icona viene copiata, non viene visualizzata?
Il VICN:101:BEOS:ICONs copiato non è ancora utilizzato come icona dell'applicazione nel file manager
Cosa mi sono perso?
Commento dello sviluppatore:
È necessario creare un file
rdefcon tutte le risorse, quindi eseguire il comandorc имя.rdef, questo creerà un file.rsrc. Quindi è necessario eseguire il comandoresattr -o имя_бинарника имя.rsrc. Come minimo, utilizzo comandi simili per aggiungere icone ai miei script.
Bene, volevo creare una risorsa, non un attributo. Sono decisamente confuso.
Caching intelligente utilizzando il file system
L'apertura e la lettura degli attributi ELF è lenta. Come ho scritto sopra, l'icona è scritta come risorsa nel file stesso. Questo metodo è più affidabile, ti consente di sopravvivere alla copia su un altro file system. Tuttavia, viene copiato anche in un attributo del file system, ad esempio BEOS:ICON. Funziona solo su determinati filesystem, come BFS. Le icone mostrate dal sistema (nel Tracker e nella Deskbar) vengono lette da questo attributo esteso perché questa soluzione è veloce. In alcuni punti (dove la velocità non è importante, ad esempio una tipica finestra "Informazioni"), il sistema riceve un'icona direttamente da una risorsa in un file. Ma questa non è la fine. Ricorda, su Mac gli utenti potrebbero sostituire le icone di applicazioni, cartelle, documenti con le proprie, perché su Mac è possibile fare queste cose "importanti", ad esempio . Su Haiku, pensa a una risorsa (in un file) come l'icona originale fornita con un'applicazione e un attributo (in un filesystem BFS) come qualcosa che consente all'utente di apportare modifiche a piacimento (sebbene, accenno, una GUI per l'inserimento di un'icona personalizzata sopra l'icona è facoltativo (non ancora implementato per impostazione predefinita).
Controllo degli attributi del file system
Con resaddr è possibile 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.
(...)È essenzialmente la "colla" che esegue la conversione avanti e indietro tra risorse (affidabili) e attributi (veloci) del file system. E poiché il sistema presuppone l'acquisizione delle risorse ed esegue la copia automaticamente, non me ne preoccuperò ulteriormente.
La magia dei pacchetti hpkg
Attualmente (il più delle volte) i pacchetti vengono utilizzati per ottenere programmi su Haiku .hpkg. Non lasciarti ingannare dal semplice nome: il formato .hpkg funziona in modo molto diverso rispetto ad altri formati con nomi simili che hai incontrato, ha dei veri e propri superpoteri.
Con i formati di pacchetto tradizionali, sono rimasto a lungo sconvolto a causa di questo fatto: scarichi una cosa (pacchetto) e un'altra viene installata nel sistema (file all'interno del pacchetto). È piuttosto difficile gestire i file (ad esempio rimuoverli) quando si installa un pacchetto nel modo tradizionale. E tutto a causa del contenuto del pacchetto sparsi nel file system, inclusi i luoghi in cui un utente normale potrebbe non avere accesso in scrittura. Ciò dà origine a un'intera classe di programmi: gestori di pacchetti. Ma il trasferimento del software già installato, ad esempio, su un'altra macchina, disco rimovibile o file server diventa ancora più difficile, se non impossibile. Su un tipico sistema basato su Linux, possono facilmente esistere da centinaia di migliaia a milioni di file separati. Inutile dire che questo è sia fragile che lento, ad esempio durante l'installazione iniziale del sistema, durante l'installazione, l'aggiornamento e la rimozione di pacchetti ordinari e durante la copia del volume di avvio (partizione root) su un altro supporto.
Sto lavorando a un progetto AppImage, una stampella parziale per le applicazioni dell'utente finale. Si tratta di un formato di distribuzione del software che raccoglie un'applicazione e tutte le sue dipendenze in un'unica immagine del file system che viene montata all'avvio dell'applicazione. Semplifica enormemente le cose, visto che lo stesso ImageMagick si trasforma improvvisamente in un unico file gestito in un file manager da comuni mortali. Il metodo suggerito funziona solo per il software, come si evince dal nome del progetto, e ha anche una propria serie di bug, dal momento che i fornitori di software Linux mi indicano sempre.
Torniamo all'Haiku. Hai trovato il giusto equilibrio tra i sistemi di imballaggio tradizionali e la consegna del software basata su immagini? I suoi pacchi .hpkg immagini di file system realmente compresse. Quando il sistema si avvia, il kernel monta tutti i pacchetti installati e attivi con qualcosa come i seguenti messaggi del kernel:
KERN: package_daemon [16042853: 924] active package: "gawk-4.2.1-1-x86_64.hpkg"
KERN: package_daemon [16043023: 924] active package: "ca_root_certificates_java-2019_01_23-1-any.hpkg"
KERN: package_daemon [16043232: 924] active package: "python-2.7.16-3-x86_64.hpkg"
KERN: package_daemon [16043405: 924] active package: "openjdk12_default-12.0.1.12-1-x86_64.hpkg"
KERN: package_daemon [16043611: 924] active package: "llvm_libs-5.0.0-3-x86_64.hpkg"Fantastico, sì? Resisti, andrà ancora peggio!
C'è un pacchetto molto speciale:
KERN: package_daemon [16040020: 924] active package: "haiku-r1~beta1_hrev53242-1-x86_64.hpkg"Contiene un sistema operativo molto minimalista, compreso il kernel. Che tu ci creda o no, anche il kernel stesso non viene estratto dal volume di avvio (partizione root), ma viene caricato ordinatamente al suo posto dal pacchetto. .hpkg. Oh! Ho accennato in precedenza che, per me, parte della sofisticatezza e coerenza complessiva di Haiku deriva dal fatto che l'intero sistema, dal kernel e lo spazio utente di base, alla gestione dei pacchetti e all'infrastruttura desktop, è sviluppato in collaborazione da un team. Immagina quanti gruppi e team diversi ci vorrebbero per eseguire qualcosa di simile su Linux. [Immagino il progetto PuppyLinux, - ca. traduttore]. Quindi immagina quanto tempo ci vorrà per implementare questo approccio nelle distribuzioni. Dicono: prendi un compito semplice, dividilo tra diversi esecutori e diventerà così complicato che non sarà più risolto. Haiku mi ha aperto gli occhi in questo caso. Penso che questo sia esattamente ciò che sta accadendo su Linux ora (Linux in questo caso è un termine collettivo per lo stack Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu).
Ripristino del sistema tramite hpkg
Con quale frequenza si verifica la seguente situazione: l'aggiornamento è andato a buon fine e poi si scopre che qualcosa non funziona come dovrebbe? Se utilizzi normali gestori di pacchetti, è difficile riportare lo stato del sistema a un momento precedente all'installazione di nuovi pacchetti (ad esempio, quando qualcosa è andato storto). Alcuni sistemi offrono soluzioni alternative sotto forma di istantanee del filesystem, ma queste sono ingombranti e non applicabili su tutti i sistemi. In Haiku questo è risolto con i pacchetti .hpkg. Ogni volta che i pacchetti nel sistema cambiano, i vecchi pacchetti non vengono rimossi, ma vengono memorizzati nel sistema in sottodirectory come /Haiku/system/packages/administrative/state-<...>/ costantemente. Le operazioni in sospeso 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, "transaction ..." - i pacchetti stessi.
"Vecchio stato attivo", ad es. elenco .hpkg i pacchetti attivi prima che le modifiche vengano scritte dopo ogni operazione nel file manager in un file di testo /Haiku/system/packages/administrative/state-<...>/activated-packages. Allo stesso modo, un nuovo "stato attivo" viene scritto in un file di testo /Haiku/system/packages/administrative/activated-packages.
elenco /Haiku/system/packages/administrative/state-<...>/ contiene solo un file di testo con un elenco di pacchetti attivi di questo stato (in caso di installazione di pacchetti senza rimuoverli) e se i pacchetti sono stati rimossi o aggiornati, la directory di stato contiene le vecchie versioni dei pacchetti.
All'avvio del sistema, in base all'elenco dei pacchetti, viene presa la decisione di attivare (montare) i pacchetti. È così semplice! Se qualcosa va storto durante il download, puoi dire al download manager di utilizzare un elenco diverso e più vecchio. Problema risolto!
Caricatore di avvio Haiku. Ogni punto di ingresso visualizza uno "stato attivo" corrispondente
Mi piace l'approccio di utilizzare file di testo semplice come un elenco di "stato attivo" con nomi di facile comprensione .hpkg. Ciò è in netto contrasto con il costruito per la macchina e non per l'uomo da OSTree o Flatpak nel file system (allo stesso livello del GUID Microsoft).
Elenco dei pacchetti attivi per ogni momento
Dati di configurazione
A quanto pare il catalogo /Haiku/system/packages/administrative/writable-files contiene file di configurazione per i pacchetti, ma scrivibili. Dopotutto, come ricordi, .hpkg sono montati in sola lettura. Pertanto, questi file devono essere copiati dai pacchetti prima di essere scritti. Ha il significato.
Integrazione della GUI per il sistema .hpkg
Vediamo ora come funzionano questi pacchi luccicanti .hpkg far fronte all'integrazione nell'ambiente di lavoro dell'utente (UX). Dopotutto, Haiku è pensato per uso personale, dopotutto. Personalmente, ho alzato il livello confrontando l'esperienza dell'utente con i pacchetti. .app su Macintosh con la stessa esperienza su .hpkg. Non confronterò nemmeno la situazione con gli ambienti desktop Linux, perché è assolutamente terribile rispetto a qualsiasi altro.
Mi vengono in mente i seguenti scenari:
- Desidero visualizzare il contenuto del pacchetto
.hpkg - Voglio installare un pacchetto
- Voglio rimuovere un pacchetto
- Voglio eliminare qualcosa che è entrato nel sistema come parte di un pacchetto
- Voglio copiare qualcosa che è entrato nel sistema come parte di un pacchetto
- Voglio scaricare tutte le dipendenze dei pacchetti 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 (beh, parte di essi) separatamente in un altro posto, separato dal volume di avvio (partizione root) (perché, ad esempio, non ho abbastanza spazio su di esso).
Questo dovrebbe coprire la maggior parte dei casi principali del mio lavoro quotidiano. Bene, cominciamo.
Controllo del contenuto della confezione
per Mac Faccio semplicemente clic con il pulsante destro del mouse su un pacchetto per aprirlo e visualizzarne il contenuto nel Finder. È davvero solo una directory sotto mentite spoglie! (So che ci sono pacchetti .pkg per una parte del sistema che non è applicazioni, ma gli utenti ordinari il più delle volte non interagiscono con esse).
Sugli Haiku Faccio clic destro sul pacchetto, quindi clicco su "Contenuto" per vedere cosa c'è dentro. Ma è solo un elenco di file senza la possibilità di fare doppio clic per aprirli.
Sarebbe molto meglio se ci fosse un modo per montare (temporaneamente) un pacchetto .hpkg da visualizzare tramite un file manager e l'utente non dovrebbe preoccuparsi dei dettagli di implementazione. (A proposito, puoi aprire .hpkg pacchetto dentro Expander, che può decomprimerlo come qualsiasi altro archivio).
Nell'interfaccia di HaikuDepot è possibile visualizzare l'elenco dei file del pacchetto, ma non è possibile visualizzarne il contenuto, ad esempio facendo doppio clic su README.md
In questa categoria vince il Mac, ma aggiungere le giuste funzionalità a HaikuDepot non dovrebbe essere un grosso problema.
Installazione di un pacchetto tramite la GUI
per Mac, la maggior parte delle immagini disco .dmg contenere pacchetti .app. Apri l'immagine del disco facendo doppio clic, quindi copia il pacchetto, ad esempio trascinandolo su /Applications nel Cercatore. Per me è ovvio, ma ho sentito che alcuni principianti potrebbero non padroneggiarlo. Per impostazione predefinita, Apple "suggerisce" una directory a livello di sistema /Applications (su NeXT era in rete oltre che individuale), ma puoi facilmente posizionare le tue applicazioni su un file server o in una sottodirectory $HOME/Applicationsse ti piace così tanto.
Sugli Haiku, fai doppio clic sul pacchetto, quindi fai clic su "Installa", non potrebbe essere più semplice. Mi chiedo cosa succede se un pacchetto ha dipendenze disponibili in HaikuPorts, ma non ancora installate. Su Linux non sanno davvero cosa fare in questa situazione, ma la soluzione è ovvia: chiedi all'utente se le dipendenze devono essere scaricate e installate. Esattamente quello che fa Haiku.
Ho scaricato manualmente il pacchetto 'sanity' e ho fatto clic su di esso, il gestore pacchetti sa da dove ottenere le sue dipendenze (supponendo che i repository siano già sul sistema). Non tutte le distribuzioni Linux possono farlo.
Un altro modo è utilizzare il file manager, basta trascinare e rilasciare .hpkg pacchetto o in /Haiku/system/packages (per un'installazione a livello di sistema, per impostazione predefinita) o in /Haiku/home/config/packages (per impostazione individuale; non disponibile facendo doppio clic - sono ancora infastidito dalla parola "config" in questo posto, che per me in questo caso è sinonimo di "impostazioni"). E il concetto di più utenti non è ancora disponibile per Haiku (forse è per questo che è così semplice - non lo so, forse le funzionalità multiutente complicheranno le cose inutilmente per un ambiente desktop desktop).
In questa categoria vince Haiku, perché può funzionare non solo con le applicazioni, ma anche con i programmi di sistema.
Rimozione di un pacchetto dalla GUI
per Mac, devi trascinare l'icona dell'applicazione nel cestino e il gioco è fatto. Facilmente!
Sugli Haiku, in primo luogo, devi trovare dove si trova il pacchetto nel sistema, perché raramente lo installi nel posto giusto (il sistema fa tutto). Di solito devi cercare /Haiku/system/packages (in un'installazione predefinita a livello di sistema) o in /Haiku/home/config/packages (Ho già detto che "config" è il nome sbagliato?). Quindi l'applicazione viene semplicemente trascinata nel cestino e il gioco è fatto.
Facilmente! Tuttavia, non direi così. Ecco cosa sta realmente accadendo:
Questo è ciò che accade quando trascini un'app nel cestino da /Haiku/system/packages
Ho appena provato a spostare l'app "Hello world" di ieri su QtQuickApp nel cestino. Non ho provato a spostare la directory di sistema, e poiché tutti i pacchetti sono installati nella directory di sistema, è impossibile rimuovere il pacchetto .hpkg senza cambiamento "il suo contenuto". Un utente normale si spaventerebbe, premerebbe il pulsante "Annulla" assegnato per impostazione predefinita.
Spiega :
Questo post ha più di 10 anni. Molto probabilmente, dobbiamo configurarlo in modo che l'avviso venga visualizzato solo quando il pacchetto stesso viene spostato. Gli utenti ordinari non hanno bisogno di farlo comunque.
Ok, forse dovresti farlo usando HaikuDepot? Fare doppio clic sul pacchetto /Haiku/system/packages, in attesa che venga visualizzato il pulsante "Disinstalla". No, c'è (solo) "Installa". Disinstalla, dove sei?
Per divertimento, ho provato a vedere cosa succede se faccio clic su "Installa" su un pacchetto già installato. Risulta così:
Questo accade se si tenta di installare un pacchetto già installato.
Appare dopo:
Se fai clic su "Applica modifiche" nella finestra precedente, risulterà così
Presumo che si tratti di un errore del software, il collegamento all'applicazione è già presente. [l'autore non ha fornito un collegamento, - ca. traduttore]
Correzione rapida: aggiungere un pulsante "Disinstalla" se il pacchetto è già presente
/Haiku/system/packageso dentro/Haiku/home/config/packages.
Quando visualizzo l'elenco dei pacchetti installati in HaikuDepot, posso vedere il mio pacchetto nell'elenco e posso rimuoverlo.
Mac vince questa categoria. Ma posso immaginare che con una corretta configurazione, l'esperienza utente su Haiku sarà migliore che su Mac. (Uno degli sviluppatori lo ha valutato in questo modo: "Meno di un'ora per aggiungere la funzionalità specificata a HaikuDepot se conosci un po 'di C ++", qualche volontario?)
Rimozione di qualcosa da un pacchetto
Proviamo a disinstallare l'app stessa, non il pacchetto .hpkg, da cui è apparso (dubito che per i "semplici mortali" ci sia qualche differenza).
per Mac, l'utente lavora normalmente con il file .dmgda dove proviene il pacchetto dell'applicazione .app. Di solito immagini .dmg vengono accumulati nella directory dei download, i pacchetti vengono copiati dall'utente in /Applications. Si ritiene che molti utenti stessi non sappiano cosa stanno facendo, questa ipotesi è confermata da un ex dipendente Apple. (Una delle cose che non mi piacciono su un Mac. E con AppImage, ad esempio, non c'è differenza tra l'app e il pacchetto in cui si trovava. Trascina l'icona nel cestino = è così. Facile!)
Sugli Haiku, c'è anche una divisione tra apps/ и packages/, quindi dubito che questo lo abbia reso più chiaro agli utenti. Ma cosa succede se trascini l'applicazione da apps/ Aggiungi al carrello:
Questo è ciò che accade quando provi a rimuovere un'applicazione prelevata da un file .hpkg
È tecnicamente corretto (dopo tutto, l'applicazione è ospitata su un file system di sola lettura, in primo luogo), ma non è particolarmente utile per l'utente.
Correzione rapida: suggerisci tramite GUI di eliminare invece
.hpkg
Per divertimento, ho provato a duplicare l'applicazione premendo Alt + D. È stato visualizzato il messaggio "Impossibile spostare o copiare oggetti su un volume di sola lettura". E tutto perché /system (Oltretutto /system/packages и /system/settings) è il punto di montaggio di packagefs (ricorda come appare nell'output df?). Sfortunatamente, l'output del comando mount non chiarisce la situazione (come si diceva in uno degli articoli precedenti), mountvolume non mostra quello che stai cercando (apparentemente pacchetti montati tramite loop .hpkg non sono considerati "volumi"), e inoltre ho dimenticato i comandi alternativi.
In questa categoria nessuno ha vinto, tranne AppImage (ma questa, a dire il vero, è un'opinione di parte). Tuttavia, si può immaginare che dopo le modifiche, l'esperienza utente su Haiku sarà migliore che su Mac.
Nota: è necessario capire cosa sia "volume" in relazione a "partizione". Questo è probabilmente simile a una relazione tra "cartella" e "directory": la maggior parte delle directory appaiono come cartelle nel file manager, ma non tutte (ad esempio i pacchetti trattati come file). Questo genere di cose fa di me ufficialmente un nerd?
Copia del contenuto di un pacchetto su un altro sistema
per Mac, tirando stupidamente il pacco .appe poiché le dipendenze si trovano all'interno del pacchetto, si spostano insieme.
Sugli Haiku, trascino l'applicazione, ma le dipendenze non vengono affatto elaborate.
Correzione rapida: suggerisci invece di trascinare l'intero pacchetto "`.hpkg", insieme alle eventuali dipendenze.
In questa categoria, il Mac vince nettamente. Almeno per me, amante del loro paradigma. Gli haiku dovrebbero essere copiati .hpkg invece di un'applicazione, ma il sistema non mi offre questo ...
Download di un pacchetto con tutte le sue dipendenze
Non tutte le macchine sono sempre online. Al contrario, alcune macchine (sì, ti sto guardando, i moderni Windows, Mac e Linux) se ne dimenticano. Per me è importante poter andare in un Internet cafè, ad esempio, scaricare software su un supporto rimovibile, inserire questo supporto nel mio computer di casa ed essere sicuro che tutto funzioni [ragazzo del rischio, fallo su Windows ... - ca. . traduttore].
Di conseguenza, un po' più spesso del solito, di solito mi ritrovo con dipendenze non soddisfatte da Windows e Linux.
per Mac questo di solito è un file, tutto ciò che serve è scaricarlo .dmg. Molto spesso, non ha dipendenze diverse da quelle fornite da MacOS stesso per impostazione predefinita. Un'eccezione sono le applicazioni complesse che richiedono un ambiente di runtime appropriato, come java.
Sugli Haiku scarica il pacchetto .hpkg per, diciamo, la stessa applicazione java, potrebbe non essere sufficiente, poiché java può essere presente o meno sulla macchina di destinazione. C'è un modo per scaricare tutte le dipendenze per un determinato pacchetto .hpkgdiversi da quelli che sono installati di default in Haiku e quindi dovrebbero essere su ogni sistema Haiku?
In questa categoria, il Mac vince con un piccolo margine.
Commentato dal sig. waddlesplash:
Scrivere un programma per raccogliere tutte le dipendenze di un'applicazione come un insieme di pacchetti
.hpkgper qualcuno che abbia familiarità con l'interno di Haiku, sono sufficienti circa 15 minuti. Non è così difficile aggiungere supporto per questo se ce n'è una reale necessità. Ma per me questo è raro.
Tratteniamo il respiro fino al prossimo articolo di questa serie.
Spostare i pacchi in una posizione separata
Come ho scritto prima, voglio mettere i miei pacchetti .hpkg (beh, o parte di essi) in un posto speciale, separato dal solito posizionamento sul volume di avvio (partizione root). Nel solito caso (non così teorico), la ragione di ciò è che le mie unità (integrate) esauriscono costantemente lo spazio libero, non importa quanto siano grandi. E di solito mappo le unità esterne o le condivisioni di rete in cui risiedono le mie applicazioni.
per Mac sposto solo i pacchi .app su un'unità rimovibile o una directory di rete nel Finder, e il gioco è fatto. Posso ancora fare doppio clic per aprire l'app come faccio normalmente dal volume di avvio. Appena!
Sugli Haiku, come mi è stato detto, questo può essere ottenuto spostando my .hpkg pacchetti su un'unità rimovibile o una directory di rete, ma è necessario utilizzare alcuni comandi non documentati nella console per montarli sul sistema. Non so come farlo usando solo la GUI.
Mac vince questa categoria.
Secondo il sig. waddlesplash:
Questa è un'ottimizzazione basata sul normale utilizzo. Se c'è una richiesta per più di un utente, la implementeremo. In ogni caso, esiste la possibilità di un'implementazione di terze parti.
Di questo parleremo nel prossimo articolo.
Parlando di directory di rete: sarebbe fantastico (presupponendo che i LAN party) avessero applicazioni semplici, rilevabili, a livello di rete (ad esempio da Zeroconf) che possono essere copiate su un computer locale o eseguite direttamente dalla rete locale. Naturalmente, gli sviluppatori hanno la possibilità di rinunciare tramite app_flags.
Rapporto finale sull'integrazione del sistema hpkg con la GUI
Penso che principalmente a causa della relativa novità dell'integrazione .hpkg con la GUI lascia ancora molto a desiderare. Ad ogni modo, ci sono alcune cose che potrebbero essere migliorate in termini di UX...
Ancora una cosa: Kernel Debug Land
Sarebbe bello poter inserire comandi durante il kernel panic, per esempio syslog | grep usb. Bene, su Haiku è possibile grazie a Kernel Debug Land. Come puoi vedere questa magia in azione se tutto funziona come dovrebbe per te senza entrare nel panico del kernel? Facilmente premendo Alt + PrintScn + D (mnemonico di debug). Ricordo subito , che consentiva agli sviluppatori Macintosh originali di accedere al debugger (se ne era stato installato uno, ovviamente).
conclusione
Comincio a rendermi conto che la sofisticatezza del sistema Haiku deriva dal fatto che il lavoro viene svolto da un piccolo team con una chiara attenzione all'ambiente di lavoro, con accesso a tutti i livelli del sistema.
Un netto contrasto con il mondo di Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu, dove tutto è suddiviso in piccoli pezzi a tal punto che l'astrazione si siede sull'astrazione e guida le stampelle.
C'era anche una comprensione di come il sistema .hpkg combina le migliori pratiche dei gestori di pacchetti tradizionali, Snappy, Flatpak, AppImage, persino btrfs, e le mescola con l'approccio "funziona e basta" del Mac.
Era come se qualcosa "cambiasse" nella mia testa, e ho capito come funziona il sistema .hpkg sa rotolare via, solo guardandola. Ma questo non sono io, ma la bellezza e la semplicità del sistema. Molto qui è intriso dello spirito del Mac originale.
Sì, la navigazione nel browser può essere a scatti e funzionare come una lumaca, le applicazioni possono mancare (niente Gtk, Electron - gli sviluppatori hanno concluso che non vanno bene con la raffinatezza), l'accelerazione video e 3d potrebbe essere completamente assente, ma comunque io piace questo sistema. Dopotutto, queste cose possono essere corrette e prima o poi appariranno. È solo questione di tempo e forse un po' di occhi rossi.
Non posso offrire aiuto, ma penso che inizierà d'ora in poi. anno di haiku sul desktop.
Problemi casuali
Forse ci sono già delle applicazioni o devo aprirle?
- BeScreenCapture dovrebbe essere in grado di esportare in GIF come Peek. Questo può essere fatto con ffmpeg già disponibile per Haiku. .
- Lo strumento Screenshot non riesce a catturare uno screenshot di una finestra modale, catturando invece l'intero schermo
- Non puoi ritagliare schermate con lo strumento di ritaglio di WonderBrush e quindi salvare il risultato in un file
- Non mi piace particolarmente il cursore a forma di mano in Haiku, ma penso che abbia una calda atmosfera nostalgica. Ciò è particolarmente fastidioso quando si utilizza lo strumento di ritaglio in Krita, in quanto risulta in un ritaglio impreciso (vedere gli screenshot delle finestre di dialogo modali in questo articolo). Un cursore a mirino sarebbe fantastico. .
Prova tu stesso! Dopotutto, il progetto Haiku fornisce immagini per l'avvio da DVD o USB, generate . Per installare, basta scaricare l'immagine e masterizzarla su un'unità flash USB utilizzando
Hai domande? Ti invitiamo alla lingua russa .
Panoramica degli errori:
Da Traduzione: Questo è il sesto articolo della serie Haiku.
Elenco degli articoli:
Fonte: habr.com