TL; DR: Pot Haiku obtenir el suport adequat per a paquets d'aplicacions, com ara directoris d'aplicacions (com ara .app a Mac) i/o imatges d'aplicacions (Linux AppImage)? Crec que aquesta seria una addició digna que és més fàcil d'implementar correctament que altres sistemes, ja que la major part de la infraestructura ja està al seu lloc.
Vaig descobrir Haiku, un sistema inesperadament bo. Bé, com que fa temps que m'interessen els directoris i les imatges d'aplicacions (inspirades en la senzillesa del Macintosh), no és d'estranyar que em vingui al cap una idea...
Per a una comprensió completa, sóc el creador i autor d'AppImage, un format de distribució d'aplicacions de Linux que té com a objectiu la simplicitat de Mac i dóna control total als autors i usuaris finals d'aplicacions (si voleu saber-ne més, vegeu и ).
Què passa si fem una AppImage per a Haiku?
Pensem una mica, purament teòricament: què cal fer per aconseguir-ho , o alguna cosa semblant, a Haiku? No cal crear res ara mateix, perquè el sistema que ja existeix a Haiku funciona de manera sorprenent, però un experiment imaginari estaria bé. També demostra la sofisticació de Haiku, en comparació amb els entorns d'escriptori Linux, on aquestes coses són terriblement difícils (tinc el dret de dir-ho: he estat lluitant amb la depuració durant 10 anys).
Al Macintosh System 1, cada aplicació era un fitxer separat "gestionat" al Finder. Amb AppImage estic intentant recrear la mateixa experiència d'usuari a Linux.
En primer lloc, què és una AppImage? Aquest és un sistema per alliberar aplicacions de tercers (per exemple, ), permetent que les aplicacions s'alliberin quan i com vulguin: no cal conèixer les especificitats de les diverses distribucions, crear polítiques o crear infraestructura, no es necessita suport de manteniment i no diuen als usuaris què (no) poden instal·lar. als seus ordinadors. AppImage s'ha d'entendre com una cosa semblant a un paquet de Mac en el format .app dins de la imatge del disc .dmg. La diferència principal és que les aplicacions no es copien, sinó que romanen dins de l'AppImage per sempre, igual que els paquets Haiku. .hpkg muntat i mai instal·lat en el sentit habitual.
Al llarg de més de 10 anys d'existència, AppImage ha guanyat certa atractiu i popularitat: el mateix Linus Torvalds la va avalar públicament i projectes comuns (per exemple, LibreOffice, Krita, Inkscape, Scribus, ImageMagick) l'han adoptat com a via principal. per distribuir compilacions contínues o nocturnes, sense interferir amb les aplicacions d'usuari instal·lades o desinstal·lades. No obstant això, els entorns d'escriptori i les distribucions de Linux, sovint, encara s'aferren al model de distribució tradicional i centralitzat basat en el manteniment i/o promouen els seus propis programes empresarials i/o d'enginyeria basats en (RedHat, Fedora, GNOME) i (Canònic, Ubuntu). Arriba .
Com funciona tot
- Cada AppImage conté 2 parts: un petit ELF de doble clic (anomenat.
runtime.c), seguit d'una imatge del sistema de fitxers .
- El sistema de fitxers SquashFS conté la càrrega útil de l'aplicació i tot el necessari per executar-la, la qual cosa no es pot considerar com a part de la instal·lació predeterminada per a tots els sistemes de destinació bastant recents (distribució Linux). També conté metadades, com ara el nom de l'aplicació, icones, tipus MIME, etc., etc.
- Quan l'executa l'usuari, el temps d'execució utilitza FUSE i squashfuse per muntar el sistema de fitxers i, a continuació, gestiona l'execució d'algun punt d'entrada (també conegut com AppRun) dins de l'AppImage muntada.
El sistema de fitxers es desmunta un cop finalitzat el procés.
Tot sembla senzill.
I aquestes coses ho compliquen tot:
- Amb tanta varietat de distribucions de Linux, res "en la ment correcta" no es pot anomenar "part de la instal·lació predeterminada per a cada nou sistema de destinació". Treballem aquest tema construint , que us permet determinar què s'empaquetarà a l'AppImage i què caldrà portar a un altre lloc. Al mateix temps, de vegades trobem a faltar, malgrat que, en general, tot funciona molt bé. Per aquest motiu, recomanem que els creadors de paquets provein AppImages en tots els sistemes (distribucions) de destinació.
- Les càrregues útils de l'aplicació han de ser reubicables al sistema de fitxers. Malauradament, moltes aplicacions tenen camins absoluts codificats, per exemple, als recursos
/usr/share. Això s'ha de solucionar d'alguna manera. A més, heu d'exportarLD_LIBRARY_PATH, o arreglarrpathperquè el carregador pugui trobar biblioteques relacionades. El primer mètode té els seus inconvenients (que es superen de maneres complexes), i el segon és senzillament feixuc. - El major inconvenient d'UX per als usuaris és aquest Fitxer AppImage després de la descàrrega. Ho creieu o no, això és una veritable barrera per a alguns. La necessitat d'establir el bit d'execubilitat és complicada fins i tot per als usuaris experimentats. Com a solució alternativa, vam suggerir instal·lar un petit servei que supervisa els fitxers AppImage i estableix el seu bit d'execució. En la seva forma pura, no és la millor solució, ja que no funcionarà fora de la caixa. Les distribucions de Linux no ofereixen aquest servei, per tant, els usuaris tenen una mala experiència fora de la caixa.
- Els usuaris de Linux esperen que una nova aplicació tingui una icona al menú d'inici. No pots dir-li al sistema: "Mira, hi ha una nova aplicació, anem a treballar". En canvi, segons l'especificació XDG, cal copiar el fitxer
.desktopal lloc correcte a/usrper a una instal·lació a tot el sistema, o en$HOMEper a individus. Les icones de determinades mides, segons l'especificació XDG, s'han de col·locar en determinats llocsusro$HOME, i després executeu ordres a l'entorn de treball per actualitzar la memòria cau d'icones, o espereu que el gestor de l'entorn de treball ho esbringui i ho detecti automàticament. El mateix amb els tipus MIME. Com a solució alternativa, es proposa utilitzar el mateix servei que, a més d'establir la bandera d'executabilitat, ho farà, si hi ha icones, etc. a AppImage, copieu-los des de l'AppImage als llocs adequats segons XDG. Quan es suprimeix o es mou, s'espera que el servei ho esborri tot. Per descomptat, hi ha diferències en el comportament de cada entorn de treball, en els formats de fitxers gràfics, les seves mides, les ubicacions d'emmagatzematge i els mètodes d'actualització de la memòria cau, la qual cosa crea un problema. En resum, aquest mètode és una crossa. - Si l'anterior no és suficient, encara no hi ha icona d'AppImage al gestor de fitxers. El món Linux encara no ha decidit implementar elficon (malgrat и ), per la qual cosa és impossible incrustar la icona directament a l'aplicació. Així doncs, resulta que les aplicacions del gestor de fitxers no tenen les seves pròpies icones (sense diferència, AppImage o una altra cosa), només es troben al menú d'inici. Com a solució alternativa, estem utilitzant miniatures, un mecanisme que es va dissenyar originalment per permetre als gestors d'escriptori mostrar imatges de vista prèvia en miniatura dels fitxers gràfics com a icones. En conseqüència, el servei per configurar el bit d'execució també funciona com a "miniaturitzador", creant i escrivint miniatures d'icones a les ubicacions adequades.
/usrи$HOME. Aquest servei també realitza la neteja si l'AppImage s'elimina o es mou. A causa del fet que cada gestor d'escriptori es comporta de manera lleugerament diferent, per exemple, en quins formats accepta icones, en quines mides o llocs, tot això és realment dolorós. - L'aplicació simplement es bloqueja en l'execució si es produeixen errors (per exemple, hi ha una biblioteca que no forma part del sistema base i no es subministra a AppImage) i ningú no diu a l'usuari a la GUI què està passant exactament. Vam començar a evitar-ho fent servir a l'escriptori, la qual cosa significa que hem de detectar errors des de la línia d'ordres, convertir-los en missatges comprensibles per l'usuari, que després s'han de mostrar a l'escriptori. I, per descomptat, cada entorn d'escriptori els gestiona una mica diferent.
- De moment (setembre de 2019 - nota del traductor) no he trobat una manera senzilla de dir al sistema que el fitxer
1.pngs'ha d'obrir amb Krita i2.png- utilitzant GIMP.
Ubicació d'emmagatzematge per a les especificacions entre escriptoris utilitzades , и és freedesktop.org
Aconseguir el nivell de sofisticació profundament teixit a l'entorn de treball Haiku és difícil, si no impossible, a causa de les especificacions per a diversos escriptoris, així com implementacions de gestors d'escriptori basats en aquestes especificacions. Com a exemple, podem citar una icona de Firefox a tot el sistema: pel que sembla, els autors de XDG ni tan sols pensaven que un usuari pogués tenir instal·lades diverses versions de la mateixa aplicació.
Icones per a diferents versions de Firefox
Em preguntava què podria aprendre el món Linux de Mac OS X per evitar malmetre la integració del sistema. Si teniu temps i us interessa, assegureu-vos de llegir el que va dir Arnaud Gurdol, un dels primers enginyers de Mac OS X:
Volíem que la instal·lació de l'aplicació sigui tan fàcil com arrossegar la icona de l'aplicació des d'algun lloc (servidor, unitat externa) a la unitat de l'ordinador. Per fer-ho, el paquet de l'aplicació emmagatzema tota la informació, incloent icones, versió, tipus de fitxer que s'està processant, tipus d'esquemes d'URL que el sistema necessita saber per processar l'aplicació. Això també inclou informació per a "emmagatzematge central" a la base de dades de serveis d'icones i serveis de llançament. Per donar suport al rendiment, les aplicacions es "descobreixen" en diversos llocs "coneguts": els directoris d'aplicacions del sistema i d'usuari, i alguns altres automàticament si l'usuari navega al Finder al directori que conté l'aplicació. A la pràctica això va funcionar molt bé.
Apple WWDC 2000 sessió 144 - Mac OS X: embalatge d'aplicacions i impressió de documents.
No hi ha res com aquesta infraestructura als ordinadors de sobretaula Linux, de manera que estem buscant solucions alternatives a les limitacions estructurals del projecte AppImage.
El Haiku vindrà al rescat?
I una cosa més: les plataformes Linux com a base dels entorns d'escriptori solen estar tan poc especificades que moltes coses que són bastant senzilles en un sistema de pila completa coherent es troben frustrantment fragmentades i complexes a Linux. Vaig dedicar un informe sencer a problemes relacionats amb la plataforma Linux per a entorns d'escriptori (els desenvolupadors experts van confirmar que tot seguirà així durant molt de temps).
El meu informe sobre els problemes dels entorns d'escriptori Linux el 2018
Fins i tot Linus Torvalds va admetre que la fragmentació era la raó per la qual la idea de l'espai de treball va fallar.
Un plaer veure Haiku!
El haiku fa que tot sigui increïblement senzill
Tot i que l'enfocament ingenu de "portar" AppImage a Haiku és simplement intentar construir (principalment runtime.c i servei) els seus components (que fins i tot pot ser possible!), això no aportarà gaire benefici a Haiku. Perquè, de fet, la majoria d'aquests problemes es resolen en haiku i són conceptualment sòlids. Haiku proporciona exactament els blocs de construcció d'infraestructura del sistema que he estat buscant en entorns d'escriptori Linux durant tant de temps i que no em podia creure que no hi eren. És a dir:
Ho creieu o no, això és una cosa que molts usuaris de Linux no poden superar. En Haiku tot es fa automàticament!
- Els fitxers ELF que no tenen un bit d'execució n'obtenen un automàticament quan es fa doble clic al gestor de fitxers.
- Les aplicacions poden tenir recursos integrats, com ara icones, que es mostren al gestor de fitxers. No cal copiar un munt d'imatges a directoris especials amb icones i, per tant, no cal netejar-les després d'esborrar o moure l'aplicació.
- Hi ha una base de dades per enllaçar aplicacions amb documents, no cal copiar cap fitxer per a això.
- Al directori lib/ al costat del fitxer executable, les biblioteques es cerquen per defecte.
- No hi ha nombroses distribucions i entorns d'escriptori; el que funcioni, funciona a tot arreu.
- No hi ha cap mòdul separat per executar que sigui diferent del directori d'aplicacions.
- Les aplicacions no tenen integrades camins absoluts als seus recursos; tenen funcions especials per determinar la ubicació en temps d'execució.
- S'ha introduït la idea de les imatges del sistema de fitxers comprimits: aquest és qualsevol paquet hpkg. Tots ells estan muntats pel nucli.
- Cada fitxer l'obre l'aplicació que l'ha creat, tret que especifiqueu el contrari explícitament. Què xulo això!
Dos fitxers png. Tingueu en compte les diferents icones que indiquen que les diferents aplicacions les obriran quan feu doble clic. Tingueu en compte també el menú desplegable "Obre amb:" on l'usuari pot seleccionar una aplicació individual. Que senzill!
Sembla que moltes de les crosses i solucions necessàries per AppImage a Linux esdevenen innecessàries a Haiku, que té la simplicitat i la sofisticació en el seu nucli que fa que s'ocupi de la majoria de les nostres necessitats.
Haiku necessita paquets d'aplicacions després de tot?
Això porta a una gran pregunta. Si fos un ordre de magnitud més fàcil de crear un sistema com AppImage a Haiku que a Linux, valdria la pena fer-ho? O Haiku, amb el seu sistema de paquets hpkg, ha eliminat efectivament la necessitat de desenvolupar aquesta idea? Bé, per respondre hem de mirar la motivació darrere de l'existència d'AppImages.
Perspectiva de l'usuari
Vegem el nostre usuari final:
- Vull instal·lar una aplicació sense demanar una contrasenya d'administrador (arrel). No hi ha cap concepte d'administrador en Haiku, l'usuari té el control total ja que és un sistema personal! (En principi, podeu imaginar-ho en mode multijugador, espero que els desenvolupadors ho facin senzill)
- Vull obtenir les últimes i millors versions d'aplicacions, sense esperar que apareguin a la meva distribució (la majoria de vegades això vol dir "mai", almenys si no actualitzo tot el sistema operatiu). A Haiku això es "resol" amb llançaments flotants. Això vol dir que és possible obtenir les versions més recents i millors d'aplicacions, però per fer-ho cal actualitzar constantment la resta del sistema, convertint-lo de manera efectiva en un "objectiu mòbil"..
- Vull diverses versions de la mateixa aplicació una al costat de l'altra, ja que no hi ha manera de saber què es va trencar a l'última versió o, per exemple, jo, com a desenvolupador web, necessito provar el meu treball amb diferents versions del navegador. El haiku resol el primer problema, però no el segon. Les actualitzacions es retreuen, però només per a tot el sistema; és impossible (que jo sàpiga) executar, per exemple, diverses versions de WebPositive o LibreOffice alhora.
Un dels desenvolupadors escriu:
Bàsicament, la raó és la següent: el cas d'ús és tan rar que optimitzar-lo no té sentit; tractar-lo com un cas especial a HaikuPorts sembla més que acceptable.
- He de mantenir les aplicacions on m'agradin, no a la meva unitat d'inici. Sovint em quedo sense espai al disc, així que necessito connectar una unitat externa o un directori de xarxa per emmagatzemar aplicacions (totes les versions que he baixat). Si connecto una unitat d'aquest tipus, necessito que s'iniciïn aplicacions fent doble clic. Haiku desa versions antigues de paquets, però no sé com moure'ls a una unitat externa o com llançar aplicacions des d'allà més tard.
Comentari del desenvolupador:
Tècnicament, això ja és possible amb l'ordre mount. Per descomptat, farem una GUI per a això tan bon punt tinguem prou usuaris interessats.
- No necessito milions de fitxers escampats pel sistema de fitxers que no puc gestionar manualment. Vull un fitxer per aplicació que puc descarregar, moure i suprimir fàcilment. En Haiku aquest problema es resol mitjançant paquets
.hpkg, que transfereixen, per exemple, Python, de milers de fitxers a un sol. Però si hi ha, per exemple, Scribus que utilitza Python, he de tractar com a mínim amb dos fitxers. I he de tenir cura de mantenir-ne versions que funcionin entre elles.
Diverses versions d'AppImages s'executen una al costat de l'altra al mateix Linux
La perspectiva d'un desenvolupador d'aplicacions
Mirem des del punt de vista d'un desenvolupador d'aplicacions:
- Vull controlar tota l'experiència de l'usuari. No vull dependre d'un sistema operatiu per dir-me quan i com he de llançar aplicacions. Haiku permet als desenvolupadors treballar amb els seus propis repositoris hpkg, però això vol dir que els usuaris els hauran de configurar manualment, cosa que fa que la idea sigui "menys atractiva".
- Tinc una pàgina de descàrrega al meu lloc web on distribueixo
.exeper a Windows,.dmgper a Mac i.AppImageper a Linux. O potser vull monetitzar l'accés a aquesta pàgina, hi ha res possible? Què hi he de posar per a Haiku? El fitxer és suficient.hpkgamb dependències només de HaikuPorts - El meu programari requereix versions específiques d'un altre programari. Per exemple, se sap que Krita requereix una versió pegada de Qt, o Qt que estigui ajustada a una versió específica de Krita, almenys fins que els pedaços es tornen a introduir a Qt. Podeu empaquetar el vostre propi Qt per a la vostra aplicació en un paquet
.hpkg, però el més probable és que això no sigui benvingut.
Pàgina habitual de descàrrega d'aplicacions. Què he de publicar aquí per a Haiku?
Paquets Will (que existeixen com a directoris d'aplicacions com AppDir o .app a l'estil d'Apple) i/o imatges (en forma d'AppImages molt modificades o .dmg d'Apple) una addició útil a l'entorn d'escriptori Haiku? O diluirà tota la imatge i conduirà a la fragmentació i, per tant, afegirà complexitat? Estic trencat: d'una banda, la bellesa i la sofisticació del Haiku es basa en el fet que normalment hi ha una manera de fer alguna cosa, en lloc de moltes. D'altra banda, la major part de la infraestructura per a catàlegs i/o suites d'aplicacions ja està al seu lloc, de manera que el sistema demana a crits que el percentatge restant quedi al seu lloc.
Segons el desenvolupador
A Linux ells (catàlegs i kits d'aplicació, - aprox. traductor) són probablement una solució tècnica a problemes sistèmics. A Haiku preferim resoldre simplement els problemes del sistema.
Què penses?
Abans de respondre...
Espera, fem una ràpida comprovació de la realitat: de fet directoris d'aplicacions - ja forma part del Haiku:
Els directoris d'aplicacions ja existeixen a Haiku, però encara no són compatibles amb el gestor de fitxers
No són tan compatibles com, per exemple, el Macintosh Finder. Què tan fantàstic seria si el directori QtCreator tingués un nom i una icona "QtCreator" a l'extrem superior esquerre, llançant l'aplicació quan feu doble clic?
Una mica abans jo ja :
Esteu segur que podeu executar les vostres aplicacions de fa una dècada avui quan totes les botigues d'aplicacions i els repositoris de distribució s'hagin oblidat d'ells i de les seves dependències? Estàs segur que encara podràs accedir a la teva feina actual en el futur?
Ja hi ha una resposta d'Haiku, o els catàlegs i els paquets d'aplicacions poden ajudar aquí? Crec que poden.
Segons el Sr. waddlesplash:
Sí, tenim la resposta a la pregunta: simplement donarem suport a aquestes aplicacions durant el temps que sigui necessari fins que algú pugui llegir els seus formats de fitxer de la manera correcta o proporcionar una funcionalitat individual. El nostre compromís de donar suport a les aplicacions BeOS R5 a Haiku és una prova d'això...
Això és segur!
Quin curs d'acció hauria de prendre Haiku?
Puc imaginar la coexistència pacífica d'hpkg, directoris i imatges d'aplicacions:
- Ús del programari del sistema
.hpkg - Per al programari utilitzat amb més freqüència (especialment aquells que necessiten programar versions continuades), utilitzeu
.hpkg(aproximadament el 80% dels casos) - Alguns instal·lats via
.hpkg, les aplicacions es beneficiaran de passar a una infraestructura de directoris d'aplicacions (per exemple, QtCreator): es distribuiran com.hpkg, com abans.
Sr. waddlesplash escriu:
Si tot el que necessiteu és veure les aplicacions a
/system/apps, en canvi hauríem de fer que els directoris de Deskbar siguin més manejables per als usuaris, ja que/system/appsno està pensat per ser obert i visualitzat regularment pels usuaris (a diferència de MacOS). Per a aquestes situacions, l'Haiku té un paradigma diferent, però aquesta opció és, en teoria, acceptable.
- Haiku rep la infraestructura per executar imatges d'aplicacions, compilacions nocturnes, contínues i de prova de programari, així com per als casos en què l'usuari vulgui "congelar-lo a temps", per a programari privat i intern, i altres casos d'ús especials (al voltant del 20% de tots). Aquestes imatges contenen els fitxers necessaris per executar l'aplicació
.hpkg, muntat pel sistema, i després de completar l'aplicació - desmuntat. (Potser un gestor de fitxers podria posar fitxers.hpkgen imatges d'aplicació, automàticament o a petició de l'usuari, bé, com quan arrossegueu una aplicació a un directori de xarxa o a una unitat externa. Només és una cançó! O millor dit, poesia - haiku.) D'altra banda, l'usuari pot voler instal·lar el contingut de la imatge en forma de fitxers.hpkg, després de la qual s'actualitzaran i es processaran de la mateixa manera que si s'instal·lessin a través de HaikuDepot... Hem de fer una pluja d'idees).
Cita del sr. waddlesplash:
L'execució d'aplicacions des de discs externs o directoris de xarxa pot ser útil. I afegir la possibilitat de configurar més "zones" per a pkgman seria sens dubte una bona característica.
Aquest sistema aprofitaria hpkg, directoris i imatges d'aplicacions. Són bons individualment, però junts es tornaran invencibles.
Conclusió
Haiku té un marc que proporciona una experiència d'usuari senzilla i sofisticada per a l'ordinador i va molt més enllà del que normalment es proporciona per a l'ordinador Linux. Sistema de paquets .hpkg n'és un exemple, però la resta del sistema també està impregnada de sofisticació. Tanmateix, Haiku es beneficiarà d'un suport adequat de directoris i imatges de l'aplicació. La millor manera de fer-ho val la pena discutir amb gent que conegui l'Haiku, la seva filosofia i arquitectura molt millor que jo. Després de tot, he estat utilitzant Haiku durant una mica més d'una setmana. No obstant això, crec que els dissenyadors, desenvolupadors i arquitectes de Haiku es beneficiaran d'aquesta nova perspectiva. Com a mínim, estaria encantat de ser el seu "company d'entrenador". Tinc més de 10 anys d'experiència pràctica amb catàlegs i paquets d'aplicacions de Linux, i m'agradaria trobar-los un ús a Haiku, per al qual crec que són perfectes. Les possibles solucions que he proposat no són de cap manera les úniques correctes per als problemes que he descrit, i si l'equip de Haiku decideix trobar-ne d'altres més elegants, estic a favor. Bàsicament, ja estic pensant en la idea de com fer un sistema hpkg encara més sorprenent sense canviar la manera de funcionar. Resulta que l'equip de Haiku feia temps que pensava en paquets d'aplicacions quan implementava un sistema de gestió de paquets, però malauradament (crec) la idea va quedar "obsoleta". Potser és hora de reviure-ho?
Prova-ho tu mateix! Després de tot, el projecte Haiku proporciona imatges per arrencar des de DVD o USB, generades .
Té vostè alguna pregunta? Et convidem a la parla russa .
Visió general de l'error:
D' traducció: aquest és el vuitè i últim article de la sèrie sobre Haiku.
Llista d'articles:
Només els usuaris registrats poden participar en l'enquesta. si us plau.
Té sentit portar el sistema hpkg a Linux?
-
Sí
-
No
-
Ja implementat, escriuré als comentaris
Han votat 20 usuaris. 5 usuaris es van abstenir.
Font: www.habr.com