TL;DR: Haiku — un sistem de operare special conceput pentru PC-uri, având astfel câteva trucuri care îmbunătățesc semnificativ mediul său de lucru comparativ cu altele. Dar cum funcționează?
Am descoperit Haiku, un sistem surprinzător de bun. Sunt încă impresionat de cât de fluent funcționează, mai ales în comparație cu mediile de lucru de pe Linux. Astăzi voi arunca o privire sub capotă. Acolo unde este necesar pentru o înțelegere profundă, voi face comparații cu Macintosh-ul original, Mac OS X și mediile de lucru Linux (standardul XDG de la freedesktop.org).
Resurse în fișiere ELF
Ieri am aflat că IconOMatic poate salva icoane în resurse rdef din fișierele executabile ELF. Astăzi vreau să văd cum funcționează de fapt.
Resurse? de la , creatorul original al programului Macintosh Finder și „tatăl” Macintosh Resource Manager:
Mă îngrijorează natura rigidă a scrierii tradiționale de cod. Pentru mine, ideea unei aplicații încapsulate în cod, fără posibilitatea de a schimba ceva dinamic — este o barbarie extremă. Ar trebui să existe posibilitatea de a modifica cât mai mult pe timpul execuției. Desigur, codul aplicației nu poate fi modificat, dar există totuși ceva care poate fi schimbat și fără recompilarea codului?
Pe Macintosh-ul original, s-a realizat astfel încât aceste fișiere să aibă o „secțiune de date” și o „secțiune de resurse”, ceea ce a facilitat enorm salvarea diferitelor elemente, precum icoane, traduceri etc. în fișierele executabile.
Pe Mac, pentru aceasta se folosește , un program grafic pentru — surpriză — editarea resurselor.
ResEdit pe Macintosh-ul original
Astfel, a fost posibil să editezi icoane, elemente de meniu, traduceri etc. destul de ușor, totuși ele „călătoresc” împreună cu aplicațiile.
În orice caz, această abordare avea un dezavantaj mare: a funcționat doar pe sistemele de fișiere Apple, ceea ce a fost unul dintre motivele pentru care Apple a abandonat „secțiunea de resurse” în timpul tranziției la Mac OS X.
Pe Mac OS X, Apple a dorit o soluție independentă de sistemul de fișiere, așa că a adoptat conceptul de pachete (din NeXT), directoare care sunt tratate de managerul de fișiere ca „obiecte opace”, similar cu fișierele, nu cu directoare. Orice pachet cu o aplicație în format .app are, printre altele, un fișier Info.plist (într-un anumit echivalent JSON sau YAML de la Apple), care conține metadatele aplicației.
Cheile fișierului Info.plist din pachetul aplicației Mac OS X.
Resursele, cum ar fi icoanele, fișierele UI și altele, sunt stocate în pachet sub formă de fișiere. Conceptul a revenit practic la originile sale în NeXT.
Mathematica.app pe NeXTSTEP 1.0 în 1989: apare ca un director cu fișiere în terminal, dar ca un obiect unic în managerul grafic de fișiere.
Să ne întoarcem la BeOS, pe concepțiile căruia se bazează Haiku. Dezvoltatorii săi, la trecerea de la PEF (PowerPC) la ELF (x86) (același folosit pe Linux), au decis să adauge o secțiune de resurse la sfârșitul fișierelor ELF. Pentru aceasta nu s-a folosit o secțiune ELF proprie corespunzătoare, ci pur și simplu a fost adăugată la sfârșitul fișierului ELF. Ca rezultat, programele strip și altele din binutils, care nu știu de așa ceva, pur și simplu le-au tăiat. Prin urmare, adăugând resurse în fișierul ELF pe BeOS, este mai bine să nu lucrezi cu el cu instrumente Linux.
Ce se întâmplă acum cu Haiku? În principiu, mai mult sau mai puțin același lucru.
Teoretic, ar fi posibil să se plaseze resurse în secțiunea corespunzătoare a ELF. Conform dezvoltatorilor de pe canalul #haiku din rețeaua irc.freenode.net:
Cu ELF secțiunea ar avea mai mult sens… singurul motiv pentru care nu facem așa este că așa se făcea în BeOS.
Și nu merită să schimbăm asta acum.
Gestionarea resurselor
Resursele sunt scrise într-un format „structurat” de tip resursă: practic este o listă de resurse cu dimensiunile și apoi conținutul acestora. Mi-a venit în minte .
Cum putem verifica resursele în Haiku? Există ceva de genul ResEdit?
Conform :
Pentru a vizualiza resursele livrate în pachetul aplicației, poți trasa fișierul executabil pe un program de tip De asemenea, poți deschide terminalul și rula comanda
listres nume_fișier..
Resourcer este disponibil în HaikuDepot, dar la mine pur și simplu se blochează.
Cum putem gestiona resursele în fișiere ELF? Folosind rsrc. și rdef.. rdef. Fișierele sunt compilate în rsrc.. Fișierul rdef. este păstrat în format text obișnuit, astfel că lucrul cu el este mult mai ușor. Fișierul în format rsrc. este adăugat la sfârșitul fișierului ELF. Să încercăm să ne jucăm:
~> rc -h
Haiku Resource Compiler 1.1
Pentru a compila un script rdef într-un fișier de resurse:
rc [opțiuni] [-o ] ...
Pentru a converti un fișier de resurse înapoi într-un script rdef:
rc [opțiuni] [-o ] -d ...
Opțiuni:
-d --decompile creează un script rdef dintr-un fișier de resurse
--auto-names construiește numele resurselor din simbolurile ID
-h --help afișează acest mesaj
-I --include adaugă la lista căilor de includere
-m --merge nu șterge conținutul existent al fișierului de ieșire
-o --output specifică numele fișierului de ieșire, implicit este out.xxx
-q --quiet nu afișa mesaje de eroare
-V --version afișează versiunea software-ului și licențaPoți folosi programul xres pentru a verifica și gestiona:
/> 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.
(...)Bine, să încercăm?
/> 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_VERSIONMai multe despre resurse și format rdef. puteți citi .
Tipuri standard de resurse
Deși se pot include în resurse orice, există câteva tipuri standard definite:
app_signature: tipul MIME al aplicației, pentru a asocia fișierele deschise, execuția, IPC etc.app_name_catalog_entry: Deoarece numele aplicației este de obicei în engleză, aici se pot specifica locurile unde sunt depozitate numele traduse, astfel încât utilizatorii din diferite limbi să poată vedea, dacă doresc, numele tradus al aplicației.app_version: exact ceea ce te-ai gânditapp_flags: indicăregistrarcum să gestioneze aplicația. Cred că există mai mult decât pare la prima vedere. De exemplu, existăB_SINGLE_LAUNCH, care determină sistemul să lanseze un nou proces de aplicație de fiecare dată, la cererea utilizatorului (același principiu se folosește pentru majoritatea aplicațiilor pe Linux). ExistăB_MULTIPLE_LAUNCH, care forțează inițializarea unui proces pentru fiecare fișier. În cele din urmă, existăB_EXCLUSIVE_LAUNCH, care face ca sistemul să ruleze doar un singur proces simultan, indiferent de câte ori îl lansează utilizatorii (de exemplu, Firefox pe Linux se comportă astfel; același rezultat poate fi obținut în aplicațiile Qt folosind funcția ). Aplicațiile cuB_EXCLUSIVE_LAUNCHsunt notificate când utilizatorul încearcă să le lanseze din nou: de exemplu, primesc calea fișierului pe care utilizatorul dorește să îl deschidă folosind aplicația lor.vector_icon: Iconiță vectorială a aplicației (În BeOS nu existau iconițe vectoriale, majoritatea aplicațiilor având în schimb câte două iconițe raster în fișierele executabile).
Desigur, se pot adăuga resurse cu orice ID și tip dorit, după care se pot citi în aplicație sau în alte aplicații folosind clasa BResources. Dar mai întâi, să ne oprim la tema interesantă a iconițelor.
Iconițe vectoriale în stil Haiku
Desigur, nu doar Haiku a ales cel mai bun format pentru iconițe, în această privință situația cu medii de lucru pe Linux este departe de a fi ideală:
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.cachePrivind așa ceva, deja poți simți ce reprezintă acest fragment.
Desigur, există iconițe scalabile, care conțin, așa cum se poate înțelege, iconițe vectoriale. De ce mai există ceva altceva? Pentru că rezultatul redării graficii vectoriale la dimensiuni mici poate fi mai rău decât idealul. Este de dorit să avem diverse variante, optimizate pentru diferite dimensiuni. În medii de lucru Linux, acest lucru se realizează prin dispersarea iconițelor cu dimensiuni diferite pe sistemul de fișiere.
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.pngRețineți: nu există noțiunea de versiuni diferite de Firefox. Astfel, nu se poate trata cu finețe situația prezenței mai multor versiuni ale aplicației în sistem.
Iconițe diferite pentru Firefox în versiuni diferite. Până acum este imposibil să se gestioneze acest lucru în Linux fără diverse soluții de compromis.
Mac OS X gestionează un pic mai rafinat:
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.icnsSe poate observa că există un singur fișier firefox.icns în pachetul Firefox.app, care conține toate dimensiunile, așa că diferite versiuni ale aceleași aplicații au iconițe diferite.
Mult mai bine! Iconițele călătoresc împreună cu aplicația, toate resursele fiind într-un singur fișier.
Să ne întoarcem la Haiku. O soluție uimitoare, fără excepții. Conform :
A fost dezvoltat un format special, foarte optimizat pentru dimensiuni mici și redare rapidă, HVIF. De aceea, iconițele noastre sunt, în mare parte, mult mai mici decât în formatul raster sau în formatul SVG utilizat pe scară largă.
Și sunt într-adevăr optimizate:
Dimensiunile iconițelor în HVIF comparativ cu alte formate.
Diferența este de ordinul magnitudinii!
Dar magia nu se oprește aici. Același HVIF poate arăta diferite niveluri de detaliu în funcție de dimensiunea afisată, în ciuda faptului că este un format vectorial.
Diferite niveluri de detaliu (LOD) în funcție de dimensiunea redării
Acum despre dezavantaje: nu poți lua un SVG, să-l arunci în ImageMagick și să termini cu asta, trebuie să treci prin câteva cicluri pentru a crea o iconiță în format HVIF. sunt explicații. Cu toate acestea, IconOMatic poate importa SVG într-un mod destul de imperfect; aproximativ 90% din detalii SVG sunt importate cu o anumită probabilitate, iar celelalte 10% trebuie ajustate și modificate manual. Poți citi mai mult despre cum HVIF își face magia în blogul
Adăugând o iconiță în aplicație
Acum pot adăuga o iconiță pachetului creat , având în vedere toate informațiile obținute.
Dar, de vreme ce nu am mare chef să desenez propria mea pictogramă pentru aplicația mea «Salut, Lume» QtQuickApp — o iau din 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 CreatorSă verificăm că pictograma a fost copiată:
/Haiku/home> xres -l /Haiku/home/QtQuickApp/QtQuickApp/Haiku/home/QtQuickApp/QtQuickApp
resources:type ID size name
------ ----------- ----------- --------------------
'VICN' 101 152238 BEOS:ICONArată bine, dar de ce, când noua pictogramă este copiată, nu se afișează?
Pictograma copiată VICN:101:BEOS:ICONs nu este folosită momentan ca pictogramă pentru aplicația din managerul de fișiere
Ce am omis?
Comentariul dezvoltatorului:
Trebuie să creez un fișier
rdef.cu toate resursele, apoi să execut comandarc nume.rdef, aceasta va crea fișierul.rsrc. Apoi trebuie să execut comandaresattr -o nume_binar nume.rsrc. Cel puțin, folosesc astfel de comenzi pentru a adăuga pictograme la scripturile mele.
Ei bine, voiam să creez o resursă, nu un atribut. Sunt complet confuz.
Cache inteligent folosind sistemul de fișiere
Deschiderea și citirea atributelor ELF funcționează lent. Așa cum am menționat mai sus, pictograma este scrisă ca resursă în fișierul propriu-zis. Această metodă este mai fiabilă, permite supraviețuirea copiei pe un alt sistem de fișiere. Totuși, apoi este copiată și în atributul sistemului de fișiere, de exemplu BEOS:ICON. Acest lucru funcționează doar pe anumite sisteme de fișiere, de exemplu BFS. Pictogramele afișate de sistem (în Tracker și Deskbar) sunt citite din acest atribut extins, deoarece o astfel de soluție funcționează rapid. În unele locuri (unde viteza nu este importantă, de exemplu, fereastra standard „Despre”) sistemul obține pictograma direct din resursa din fișier. Dar asta nu e tot. Amintiți-vă, pe Mac, utilizatorii puteau înlocui pictogramele aplicațiilor, directoarelor, documentelor cu ale lor, deoarece pe Mac există posibilitatea de a face aceste „lucruri importante”, de exemplu . Pe Haiku, resursa (din fișier) ar trebui considerată pictograma inițială, livrată împreună cu aplicația, iar atributul (din sistemul de fișiere BFS) ca ceva care permite utilizatorului să facă modificări la dorința sa (deși, o sugestie, interfața grafică pentru inserarea unei pictograme personalizate deasupra pictogramei implicite nu a fost implementată încă).
Verificarea atributelor sistemului de fișiere
Folosind resaddr există posibilitatea de a verifica și stabili atributele sistemului de fișiere.
/> 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.
(...)Practic vorbim despre un „lipici” care face o transformare între resursele (de încredere) și atributele (viteze) ale sistemului de fișiere. Și deoarece sistemul presupune obținerea resurselor și face copiile automat, nu voi mai avea griji în legătură cu asta.
Magia pachetelor hpkg
În prezent (cel mai des) pentru a obține programe pe Haiku se utilizează pachete. .hpkg. Nu vă lăsați păcăliți de numele simplu: formatul .hpkg funcționează complet diferit față de alte formate cu nume similare cu care ați avut de-a face, având adevărate superputeri.
Cu formatele de pachet tradiționale, m-am simțit frustrat de un astfel de fapt: descarci un (pachet), dar în sistem se instalează altceva (fișierele din interiorul pachetului). E destul de greu să gestionezi fișierele (de exemplu, să le ștergi) atunci când pachetul este instalat în mod tradițional. Toate aceste lucruri se datorează faptului că conținutul pachetului se împrăștie în întreaga sistem de fișiere, inclusiv în locuri unde utilizatorul obișnuit poate să nu aibă acces pentru scriere. Aceasta generează o întreagă clasă de programe — manageri de pachete. Totuși, transferul unui software deja instalat, de exemplu, pe un alt computer, un disc portabil sau un server de fișiere devine chiar mai dificil sau chiar imposibil. Într-un sistem obișnuit bazat pe Linux, pot exista cu ușurință de la câteva sute de mii la milioane de fișiere izolate. Evident, aceasta este atât fragil, cât și lent, de exemplu, în timpul instalării inițiale a sistemului, în timpul instalării, actualizării și dezinstalării pachetelor obișnuite, precum și în timpul copiei volumului de boot (partea rădăcină) pe un alt suport.
Lucrez la proiectul AppImage, un fel de soluție parțială pentru aplicațiile utilizatorilor finali. Acesta este un format de distribuție software care adună aplicația și toate dependențele sale într-o singură imagine de sistem de fișiere, montată la pornirea aplicației. Acesta simplifică semnificativ lucrurile, deoarece același ImageMagick devine dintr-o dată un singur fișier, gestionat în managerul de fișiere de către muritorii obișnuiți. Metoda propusă funcționează doar pentru software, așa cum este reflectat în numele proiectului, și are propriul său set de probleme, deoarece persoanele care se ocupă cu livrarea software-ului pentru Linux întotdeauna aruncă responsabilitatea asupra mea.
Să ne întoarcem la Haiku. A reușit să găsească un echilibru optim între sistemele tradiționale bazate pe pachete și livrarea de software în baza imaginilor? Pachetele sale .hpkg sunt, de fapt, imagini comprimate ale sistemului de fișiere. La bootarea sistemului, kernelul montează toate pachetele instalate și active, aproximativ cu următoarele mesaje de kernel:
KERN: package_daemon [16042853: 924] pachet activ: "gawk-4.2.1-1-x86_64.hpkg"\nKERN: package_daemon [16043023: 924] pachet activ: "ca_root_certificates_java-2019_01_23-1-any.hpkg"\nKERN: package_daemon [16043232: 924] pachet activ: "python-2.7.16-3-x86_64.hpkg"\nKERN: package_daemon [16043405: 924] pachet activ: "openjdk12_default-12.0.1.12-1-x86_64.hpkg"\nKERN: package_daemon [16043611: 924] pachet activ: "llvm_libs-5.0.0-3-x86_64.hpkg"Impresionant, nu-i așa? Rămâneți, urmează și mai multe lucruri interesante!
Există un pachet foarte special:
KERN: package_daemon [16040020: 924] pachet activ: "haiku-r1~beta1_hrev53242-1-x86_64.hpkg"Acesta conține un sistem de operare foarte minimalist, inclusiv kernelul. Credeți sau nu, dar chiar și kernelul nu este extras din volumul de boot (partiția de bază), ci este încărcat cu grijă la locul său din pachet .hpkg. Wow! Am menționat deja că, din punctul meu de vedere, o parte din rafinamentul și coerența generală a Haiku se datorează faptului că întregul sistem, de la kernel până la spațiul de utilizator de bază, precum și gestionarea pachetelor și infrastructura mediului de lucru, sunt dezvoltate împreună de o echipă. Imaginați-vă câte grupuri și echipe ar fi necesare pentru a lansa ceva similar bazat pe Linux [îmi imaginez proiectul PuppyLinux, — nota traducătorului]. Apoi, imaginați-vă cât timp ar fi necesar pentru ca această abordare să fie implementată în distribuții. Se spune că: ia o sarcină simplă, împărț-o între diferite persoane, și devine atât de complicată încât deja nu mai poate fi rezolvată. Haiku, în acest caz, mi-a deschis ochii. Cred că exact asta se întâmplă pe Linux acum (Linux, în acest context, este un termen general care se referă la stiva Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu).
Rollback-ul sistemului folosind hpkg
Cât de frecvent se întâmplă următoarea situație: o actualizare a avut succes, dar apoi se descoperă că ceva nu funcționează așa cum ar trebui? Atunci când folosești manageri de pachete obișnuiți, e greu să readuci sistemul la starea de dinainte de instalarea noilor pachete (de exemplu, în cazul în care ceva a mers prost). Unele sisteme oferă soluții de tip snapshot al sistemului de fișiere, dar acestea sunt destul de voluminoase și nu se aplică în toate sistemele. În Haiku, acest lucru este rezolvat prin intermediul pachetelor. .hpkgDe fiecare dată când pachetele din sistem sunt modificate, pachetele vechi nu sunt șterse, ci sunt păstrate în sistem în subfoldere de tipul /Haiku/system/packages/administrative/state-<...>/ în mod constant. Operațiile nefinalizate își păstrează datele în subfoldere. /Haiku/system/packages/administrative/transaction-<...>/.
Conținut /Haiku/system/packages/administrativeFolderele „state...” conțin fișiere text cu numele pachetelor active, iar „transaction...” - pachetele în sine.
„Starea activă veche”, adică lista .hpkg a pachetelor active înainte de modificări este înregistrată după fiecare operație în managerul de fișiere într-un fișier text. /Haiku/system/packages/administrative/state-<...>/activated-packagesÎn mod similar, noua „stare activă” este înregistrată într-un fișier text. /Haiku/system/packages/administrative/activated-packages.
Folderul /Haiku/system/packages/administrative/state-<...>/ conține doar un fișier text cu lista pachetelor active în această stare (în cazul instalării pachetelor fără ștergere), iar dacă pachetele au fost șterse sau actualizate - folderul state conține versiunile vechi ale pachetelor.
La pornirea sistemului, pe baza listei de pachete se ia decizia de activare (montare) a pachetelor. Așa de simplu! Dacă în timpul încărcării ceva nu merge bine, se poate indica managerului de încărcare să folosească o altă listă, mai veche. Problema este rezolvată!
Încărcătorul Haiku. Fiecare punct de intrare reflectă corespunzătoarea „stare activă”
Îmi place abordarea cu fișierele text simple ca listă a „stării active”, în care sunt înregistrate nume ușor de înțeles. .hpkgAcest lucru contrastează puternic cu aglomerările create-pentru-mașini-și-nu-pentru-oameni Lista pachetelor active pentru fiecare moment în timp.
Datele de configurare
Se pare că în folderul
se află fișierele de configurare pentru pachete, dar disponibile pentru scriere. Căci, așa cum ați observat, /Haiku/system/packages/administrative/writable-files sunt montate doar pentru citire. Astfel, aceste fișiere trebuie copiate din pachete înainte de a scrie. Are sens. .hpkg Integrarea GUI pentru sistemul .hpkg
Integrarea GUI pentru sistemul .hpkg
Să ne uităm acum cum aceste pachete strălucitoare .hpkg fac față integrării în mediul de lucru al utilizatorului (UX). De fapt, Haiku este destinat utilizării personale. Personal, am stabilit un standard înalt, comparând experiența utilizatorului cu pachetele .app de pe Macintosh cu aceeași experiență pe .hpkg. Nici nu voi compara situația cu mediile de lucru pe Linux, pentru că este absolut groaznică în comparație cu orice altceva.
Îmi vin în minte următoarele scenarii:
- Vreau să vizualizez conținutul pachetului
.hpkg - Vreau să instalez pachetul
- Vreau să elimin pachetul
- Vreau să șterg ceva care a venit în sistem ca parte a pachetului
- Vreau să copiez ceva care a venit în sistem ca parte a pachetului
- Vreau să descarc toate dependențele pachetului care nu pot face parte din fiecare instalare Haiku (de exemplu, am o mașină fizic izolată fără acces la internet).
- Vreau să mut pachetele mele (sau o parte din ele) separat într-un alt loc, distinct de volumul de boot (partiția rădăcină) (pentru că, de exemplu, am lipsă de spațiu pe acesta).
Acestea ar trebui să acopere majoritatea cazurilor de utilizare din activitatea mea de zi cu zi. Ei bine, să începem.
Verificarea conținutului pachetului
Pe Mac pur și simplu fac clic dreapta pe pachet pentru a-l deschide și a vizualiza conținutul în Finder. De fapt, este doar un director mascat! (Știu că există pachete .pkg pentru partea sistemului care nu este aplicații, dar utilizatorii obișnuiți nu interacționează mai ales cu ele).
Pe Haiku fac clic dreapta pe pachet, apoi clic pe „Contents” pentru a vedea ce este în interior. Dar aici este doar o listă de fișiere fără opțiunea de a le deschide cu două clicuri.
Ar fi mult mai bine dacă ar exista o modalitate (temporară) de a monta pachetul .hpkg pentru a fi vizualizat prin managerul de fișiere, iar utilizatorului nu ar trebui să-i pese de detaliile implementării. (Apropo, se poate deschide .hpkg pachetul în Expander, care poate să-l dezarhiveze ca pe orice alt arhivă).
În interfața HaikuDepot, poți vizualiza lista fișierelor din pachet, dar nu există o modalitate de a vizualiza conținutul, de exemplu, făcând dublu clic pe README.md.
În această categorie, Mac câștigă, dar adăugarea funcționalităților necesare în HaikuDepot nu ar trebui să fie dificilă.
Instalarea pachetului prin GUI
Pe Mac, majoritatea imaginilor de disc .dmg conțin pachete .app. Deschidem imaginea de disc cu un dublu clic, apoi copiăm pachetul, de exemplu, trăgându-l în /Applications Finder. Pentru mine, acesta este un lucru evident, dar am auzit că unii începători s-ar putea să nu reușească să facă acest lucru. Implicit, Apple "oferă" un catalog comun /Applications (pe NeXT era în rețea, precum și individual), dar se poate ușor să îți plasezi aplicațiile pe un server de fișiere sau într-un subdirector $HOME/Applications, dacă îți place așa.
Pe Haiku, dublu clic pe pachet, apoi clic pe "Install", mai simplu de atât nu se poate. Mă întreb ce se întâmplă dacă pachetul are dependențe disponibile în HaikuPorts, dar care nu sunt încă instalate. Pe Linux, cu adevărat nu știu ce să facă în această situație, dar soluția este evidentă — să întrebi utilizatorul dacă vrea să descarce și să instaleze dependențele. Exact ce face Haiku.
Am descărcat manual pachetul 'sanity' și am dat clic pe el, managerul de pachete știe de unde să ia dependențele (cu condiția ca repozitoarele să fie deja configurate în sistem). Nu fiecare distribuție Linux știe să facă asta.
O altă metodă este utilizarea managerului de fișiere, este suficient să tragi .hpkg pachetul fie în /Haiku/system/packages (pentru instalare comună, implicit), fie în /Haiku/home/config/packages (pentru instalare individuală; indisponibilă la dublu clic — încă mă deranjează cuvântul „config” în acest loc, care pentru mine este sinonim cu „settings”). Și, de fapt, conceptul de utilizatori multipli nici măcar nu este disponibil pentru Haiku (probabil din acest motiv totul este atât de simplu — nu știu, poate că funcțiile multiutilizator vor complica lucrurile pentru un mediu de lucru al unui computer personal).
În această categorie, Haiku câștigă, deoarece poate lucra nu doar cu aplicații, ci și cu programe de sistem.
Ștergerea unui pachet din GUI
Pe Mac, trebuie să tragi pictograma aplicației în coșul de gunoi, și asta e tot. Ușor!
Pe Haiku, în primul rând, trebuie să găsești unde se află pachetul în sistem, deoarece rar îl vei instala acolo unde trebuie (totul face sistemul). De obicei, trebuie să cauți în /Haiku/system/packages (pentru instalare comună, implicit), sau în /Haiku/home/config/packages (am mai spus că „config” este un nume greșit?). Apoi aplicația este pur și simplu trasă în coșul de gunoi, și asta e tot.
Ușor! Totuși, nu aș spune asta. Iată ce se întâmplă de fapt:
Iată ce se întâmplă dacă tragi aplicația în coșul de gunoi din /Haiku/system/packages
Am încercat să mut aplicația mea de ieri „Salut, lume” pe QtQuickApp în coșul de gunoi. Nu am încercat să mut directorul sistemului, iar deoarece toate pachetele sunt instalate în directorul sistemului – nu este posibil să ștergi un pachet .hpkg fără a modifica „conținutul său”. Un utilizator obișnuit s-ar speria, ar apăsa butonul „Anulează”, setat implicit.
Explică :
Acest mesaj are deja mai mult de 10 ani. Cel mai probabil, trebuie să-l configurăm astfel încât avertizarea să apară doar atunci când se mișcă pachetul în sine. Utilizatorii obișnuiți oricum nu au nevoie să facă asta.
Bine, poate că ar trebui să fac asta folosind HaikuDepot? Dau double click pe pachet în /Haiku/system/packages, așteptând să apară butonul „Dezinstalare”. Nu, este (doar) „Instalare”. „Dezinstalare”, unde ești?
Pentru distracție, am încercat să văd ce se întâmplă dacă apăs „Instalare” pentru un pachet deja instalat. Se întâmplă asta:
Asta se întâmplă dacă încerci să instalezi un pachet deja instalat.
Apoi apare:
Dacă apăs „Aplică modificările” în fereastra anterioară – se va întâmpla asta
Presupun că este o eroare de programare, deja există un link pe cerere. [autorul nu a furnizat linkul, – n.r. translator]
Soluție rapidă: Adăugați un buton „Dezinstalează”, dacă pachetul este deja în
/Haiku/system/packages, sau în/Haiku/home/config/packages.
Când vizualizez lista de pachete instalate în HaikuDepot, văd pachetul meu în listă și pot să-l șterg.
În această categorie, Mac câștigă. Dar îmi pot imagina că, cu o configurare adecvată, experiența utilizatorului pe Haiku ar fi mai bună decât pe Mac. (Unul dintre dezvoltatori a evaluat asta astfel: „Mai puțin de o oră pentru a adăuga funcționalitatea indicată în HaikuDepot, dacă știi puțin C++”, sunt voluntari?)
Ștergerea cuiva dintr-un pachet
Să încercăm să ștergem aplicația în sine, nu pachetul .hpkg, din care a apărut aceasta (mă îndoiesc că pentru „simplii muritori” există vreo diferență).
Pe Mac, utilizatorul, de fapt, lucrează de obicei cu fișierul .dmg, de unde provine pachetul aplicației .app. De obicei, imaginile .dmg se acumulează în directorul de descărcări, iar pachetele sunt copiate de utilizator în /Applications. Există părerea că mulți utilizatori nu știu ce fac, această ipoteză fiind confirmată de un fost angajat Apple. (Una dintre lucrurile care nu-mi plac la Mac. De exemplu, cu AppImage nu este nicio diferență între aplicație și pachetul în care a fost aceasta. Tragi pictograma în coș = asta e tot. Ușor!)
Pe Haiku, există de asemenea o divizare între apps/ și packages/, așa că mă îndoiesc că utilizatorilor le este mai clar. Dar iată ce se întâmplă dacă tragi aplicația din apps/ în coș:
Iată ce se întâmplă când încerci să ștergi o aplicație luată dintr-un fișier .hpkg
Tehnic, este corect (deoarece aplicația este plasată pe un sistem de fișiere doar pentru citire, în primul rând), dar nu este foarte utilă pentru utilizator.
Soluție rapidă: să se ofere în schimb opțiunea de a șterge prin GUI.
.hpkg
De dragul experimentului, am încercat să dublez aplicația apăsând Alt+D. Am primit mesajul „Imposibil de mutat sau copiat obiecte pe un volum doar pentru citire”. Și asta pentru că /system (în afară de /system/packages și /system/settings) este punctul de montare packagefs (amintiți-vă cum apare în rezultatul df?). К сожалению, вывод команды mount nu clarifică situația (așa cum s-a spus într-unul dintre articolele anterioare), mountvolume nu arată ceea ce căutăm (se pare că pachetele montate prin loop .hpkg nu sunt considerate „volume”), iar eu am uitat comenzile alternative.
În această categorie, nimeni nu a câștigat, în afară de AppImage (dar, să fim sinceri, aceasta este o opinie părtinitoare). Cu toate acestea, putem imagina că, după ajustare, experiența utilizatorului pe Haiku va fi mai bună decât pe Mac.
Notă: trebuie să clarificăm ce înseamnă „volum” în raport cu „sectiunea”. Probabil că este similar cu relația „folder” cu „catalog”: majoritatea catalogurilor sunt afișate în managerul de fișiere ca foldere, dar nu toate (de exemplu, pachetele, care sunt gestionate ca fișiere). Tot astfel de excepții mă fac nerdo oficial?
Copierea conținutului unui pachet pe un alt sistem
Pe Mac, trag pur și simplu pachetul .app, iar deoarece dependențele din interiorul pachetului — acestea se mută împreună.
Pe Haiku, trag aplicația, dar dependențele nu sunt gestionate deloc.
Soluție rapidă: să se propună în schimb să se tragă pachetul „`.hpkg” complet, împreună cu dependențele, dacă există.
În această categorie, Mac câștigă fără îndoială. Cel puțin pentru mine, un fan al paradigmei lor. Pe Haiku ar trebui să fie copiat. .hpkg în loc de aplicație, dar sistemul nu îmi oferă așa ceva…
Descărcarea pachetului cu toate dependențele sale
Nu fiecare mașină este conectată la rețea tot timpul. Din contră, unele mașini (da, mă uit la voi, moderne Windows, Mac și Linux) uită de asta. Pentru mine este important să pot merge, de exemplu, la un internet cafe, să descarc software pe un mediu de stocare portabil, să introduc acel mediu în computerul de acasă și să fiu sigur că totul va funcționa [tipul riscant care face asta pe Windows… — nota traducătorului].
Ca urmare, de cele mai multe ori, obțin dependențe nesatisfăcute pe Windows și Linux.
Pe Mac de obicei este un singur fișier, tot ce trebuie să facem este să-l descărcăm .dmg. Cel mai adesea, nu are dependențe, în afară de cele furnizate de MacOS în mod implicit. Un exemplu de excepție poate fi aplicatii complicate care necesită un mediu de execuție adecvat, cum ar fi java.
Pe Haiku descarcă pachetul .hpkg pentru, să spunem, aceeași aplicație java, poate fi insuficient, deoarece java poate fi prezentă sau nu pe mașina țintă. Există o modalitate de a descărca toate dependențele pentru acest pachet .hpkg, în afară de cele care sunt instalate în Haiku în mod implicit și, prin urmare, ar trebui să fie în fiecare sistem Haiku?
În această categorie, Mac câștigă cu un mic avans.
Comentariul lui mr. waddlesplash:
Pentru a scrie un program care să adune toate dependențele unei aplicații sub formă de set de pachete
.hpkgpentru cineva familiarizat cu structura internă a Haiku, sunt suficiente aproximativ 15 minute. Adăugarea suportului pentru asta nu este atât de complicată, dacă există o nevoie reală. Dar pentru mine, aceasta este o situație rară.
Să respirăm adânc până la următorul articol din acest ciclu.
Mutarea pachetelor într-un loc separat
Așa cum am menționat anterior, vreau să pun pachetele mele .hpkg (sau o parte din ele) într-un loc special, separat de amplasarea obișnuită pe volumul de boot (partiția rădăcină). În mod normal (nu atât de teoretic), motivul este că tot timpul se termină spațiul liber pe discurile mele (încorporate), indiferent cât de mari sunt. Și de obicei conectez discuri externe sau resurse de rețea unde se află aplicațiile mele.
Pe Mac pur și simplu mut pachetele .app pe un hard disk extern sau un director de rețea în Finder, și asta e tot. Pot în continuare să deschid aplicația cu un dublu clic, exact cum făceam cu volumul de pornire. Simplu!
Pe Haiku, așa cum mi s-a spus, acest lucru poate fi realizat prin mutarea pachetelor mele .hpkg pe un hard disk extern sau un director de rețea, dar apoi trebuie să folosesc câteva comenzi nedocumentate în consolă pentru a le monta în sistem. Nu știu cum să fac asta, folosind doar GUI.
În această categorie, câștigă Mac.
Conform lui mr. waddlesplash:
Aici optimizarea se bazează pe utilizarea obișnuită. Dacă va exista o cerere mai mare decât pentru un singur utilizator, vom implementa asta. În orice caz, există posibilități de implementare terță.
Despre asta vom vorbi în articolul următor.
Dacă vorbim despre directoare de rețea: ar fi minunat (presupun că pentru LAN party) să existe aplicații de rețea simple, descoperibile (de exemplu, prin Zeroconf), care pot fi copiate pe computerul local sau rulate direct din rețeaua locală. Desigur, dezvoltatorii au opțiunea de a refuza prin app_flags.
Raportul final privind integrarea sistemului hpkg cu GUI
Cred că, în primul rând, din cauza noului relativ, integrarea .hpkg cu GUI încă lasă de dorit. Oricum, sunt câteva lucruri care pot fi îmbunătățite din perspectiva UX…
Î încă o chestiune: Kernel Debug Land
Ar fi grozav să avem posibilitatea de a introduce comenzi, de exemplu, în cazul unui kernel panic syslog | grep usb. Ei bine, la Haiku acest lucru este posibil datorită Kernel Debug Land. Cum poți vedea această magie în acțiune, dacă totul funcționează bine fără a ajunge în kernel panic? Ușor, apăsând Alt+PrintScn+D (mnemonica Debug). Îmi vin imediat în minte , care le permitea dezvoltatorilor originali de Macintosh să acceseze debuggerul (dacă era instalat, desigur).
Concluzie
Încep să înțeleg că sofisticarea sistemului Haiku provine din faptul că munca se desfășoară de o echipă mică, cu un accent clar pe mediul de lucru, având acces la toate straturile sistemului.
Un contrast puternic cu lumea Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu, unde totul este împărțit în bucăți mici până la un punct în care abstracția stă pe abstracție și este împinsă cu cârje.
De asemenea, a venit înțelegerea modului în care sistemul .hpkg combină cele mai bune practici ale gestionării tradiționale a pachetelor, Snappy, Flatpak, AppImage, chiar și btrfs, și le amestecă cu principiul 'funcționează pur și simplu' de la Mac.
A fost ca și cum ceva s-a «comutat» în mintea mea și am înțeles cum sistemul .hpkg poate reveni, doar privindu-l. Dar nu eu sunt frumos și simplu sistemul. Multe aici sunt impregnate cu spiritul originalului Mac.
Da, navigarea pe pagini în browser poate fi sacadată și poate funcționa ca o melc, aplicațiile pot lipsi (fără Gtk, Electron — dezvoltatorii au concluzionat că acestea se potrivesc prost cu rafinamentul), accelerarea video și 3D poate fi complet absentă, dar totuși îmi place acest sistem. Aceste lucruri pot fi corectate și vor apărea mai devreme sau mai târziu. Este doar o chestiune de timp și, poate, un pic de ochi roșu.
Nu pot oferi ajutor, dar cred că din acest moment va începe anul Haiku pe desktop.
Probleme aleatorii
Poate sunt deja cereri, sau trebuie să le deschid eu?
- BeScreenCapture ar trebui să aibă capacitatea de a exporta în GIF, cum face și Peek. Acest lucru se poate face cu ajutorul ffmpeg, deja disponibil pentru Haiku. .
- Programul de captură de ecran nu poate captura un dialog modal, în schimb, surprinde întreaga ecran
- Nu poți decupa capturile de ecran folosind un instrument de decupare în WonderBrush, apoi salvând rezultatul într-un fișier
- Nu-mi place prea mult cursorul în formă de mână în Haiku, dar cred că asta este legat de sentimentele nostalgice calde. Este deosebit de deranjant atunci când folosești instrumentul de decupare în Krita, deoarece rezultatul este o decupare inexactă (vezi capturile de ecran cu dialoguri modale în acest articol). Un cursor în formă de cruce ar fi minunat. .
Încercați singuri! Proiectul Haiku oferă imagini pentru descărcare de pe DVD sau USB, care sunt generate . Pentru instalare, este suficient să descărcați imaginea și să o scrieți pe un stick USB folosind
Aveți întrebări? Vă invităm în .
Revizuirea erorilor:
De la traducere: acesta este al șaselea articol din ciclul despre Haiku.
Lista articolelor:
Sursa: habr.com
