Autre chose: des packages d'application Haiku?

TL; DR : Haiku peut-il obtenir un support approprié pour les packages d'application, tels que les répertoires d'application (comme .app sur Mac) et / ou les images d'application (Linux AppImage )? Il me semble que ce sera un ajout digne, qui est plus facile à mettre en œuvre correctement que dans d'autres systèmes, car la plupart des infrastructures sont déjà là.

Il y a une semaine, j'ai découvert Haiku, un système étonnamment bon. Eh bien, depuis que je m'intéresse depuis longtemps aux catalogues et aux images d'application (inspirés de la simplicité du Macintosh), il n'est pas surprenant qu'une idée m'est venue à l'esprit ...

Pour une compréhension complète: Je suis le créateur et l'auteur d'AppImage, un format de distribution d'applications Linux visant à la simplicité Mac et offrant un contrôle complet aux auteurs d'applications et aux utilisateurs finaux (voulez en savoir plus - voir le wiki et la documentation ).

Et si nous faisons une AppImage pour Haiku?

Réfléchissons un peu, purement théoriquement: que faut-il faire pour obtenir une AppImage , ou quelque chose de similaire, sur Haiku? Il n'est pas nécessaire de créer quelque chose en ce moment, car le système qui est déjà dans Haiku fonctionne de manière incroyable, mais une expérience imaginaire se révélerait agréable. Il démontre également la sophistication de Haiku, par rapport aux environnements de bureau Linux où de telles choses sont terriblement difficiles (j'ai le droit de le dire: je débogue depuis 10 ans maintenant).

Sur Macintosh System 1, chaque application était un fichier distinct qui était «géré» dans le Finder. En utilisant AppImage, j'essaie de recréer la même expérience utilisateur sous Linux.

Tout d'abord, qu'est-ce que AppImage? Il s'agit d'un système de libération d'applications tierces (par exemple, Ultimaker Cura ) qui vous permet de libérer des applications quand et comment elles chassent: vous n'avez pas besoin de connaître les fonctionnalités de diverses distributions, de construire des politiques ou de construire une infrastructure, elles n'ont pas besoin de l'assistance de mainteneurs et elles ne disent pas aux utilisateurs quoi (non) peut être installé sur les ordinateurs. AppImage doit être compris comme quelque chose comme un package pour Mac au format .app intérieur d'une image disque .dmg . La principale différence est que les applications ne sont pas copiées, mais restent toujours dans AppImage, tout comme les packages Haiku .hpkg sont installés et ne sont jamais installés dans le sens habituel.

Pendant plus de 10 ans de son existence, AppImage a gagné en attrait et en popularité: Linus Torvalds lui-même l'a approuvé publiquement, et des projets répandus (par exemple, LibreOffice, Krita, Inkscape, Scribus, ImageMagick) l'ont accepté comme principal moyen de distribuer des assemblages continus ou nocturnes, non interférer avec les applications utilisateur installées ou non installées. Cependant, les bureaux et les distributions Linux s'accrochent le plus souvent au modèle de distribution centralisé traditionnel basé sur les mainteneurs et / ou promeuvent leurs propres programmes d'entreprise et / ou d'ingénierie basés sur Flatpak (RedHat, Fedora, GNOME) et Snappy (Canonical, Ubuntu) . Vient à drôle .

Comment ça marche

• Chaque AppImage contient 2 parties: un petit ELF exécutable à double-clic (le soi-disant. runtime.c ), suivi de l'image du système de fichiers SquashFS .

• Le système de fichiers SquashFS contient une charge utile sous la forme d'une application et tout ce dont vous avez besoin pour l'exécuter, ce qui, dans votre bon sens, ne peut pas être considéré comme faisant partie de l'installation par défaut pour chaque système cible assez récent (distribution Linux). Il contient également des métadonnées, par exemple, le nom de l'application, des icônes, des types MIME, etc., etc.

• Lorsqu'il est lancé par l'utilisateur, le runtime utilise FUSE et squashfuse pour monter le système de fichiers, après quoi il traite le lancement d'un point d'entrée (le soi-disant AppRun) à l'intérieur de l'AppImage monté.
  Le système de fichiers est démonté une fois le processus terminé.

Il semble que tout soit simple.

Et ces choses compliquent les choses:

• avec une telle variété de distributions Linux, il n'y a rien «dans leur bon sens» que vous pouvez appeler «une partie de l'installation par défaut pour chaque nouveau système cible». Nous contournons ce problème en assemblant une liste d' exclusion , ce qui nous permet de déterminer ce qui sera empaqueté dans AppImage et ce qui doit être pris ailleurs. Dans le même temps, nous manquons parfois, malgré le fait qu'en général, tout fonctionne bien. Pour cette raison, nous recommandons aux créateurs de packages de vérifier AppImages sur tous les systèmes cibles (distributions).
• Les applications sous forme de charge utile doivent être itinérantes dans le système de fichiers. Malheureusement, dans de nombreuses applications, les chemins absolus vers, par exemple, les ressources dans /usr/share codés en dur. Cela doit être corrigé d'une manière ou d'une autre. De plus, vous devez soit exporter LD_LIBRARY_PATH , soit corriger rpath pour que le chargeur puisse trouver les bibliothèques associées. La première méthode a ses inconvénients (qui sont gérés de manière complexe), et la seconde est tout simplement lourde.
• Le plus grand piège UX pour les utilisateurs consiste à définir le bit exécutable dans le fichier AppImage après le téléchargement. Croyez-le ou non, pour certains, c'est une véritable barrière. La nécessité de définir un bit exécutable est lourde même pour les utilisateurs avancés. Comme solution de contournement, nous avons proposé d'installer un petit service qui surveille les fichiers AppImage et définit le bit exécutable pour eux. Dans sa forme pure, pas la meilleure solution, car cela ne fonctionnera pas hors de la boîte. Les distributions Linux ne fournissent pas ce service, par conséquent, les utilisateurs prêts à l'emploi ne se portent pas bien.
• Les utilisateurs de Linux s'attendent à ce que la nouvelle application ait une icône dans le menu de lancement. Vous ne pouvez pas dire au système: "Regardez, il y a une nouvelle application, travaillons." Au lieu de cela, selon la spécification XDG, vous devez copier le fichier .desktop à l'emplacement souhaité dans /usr pour une installation à l'échelle du système ou dans $HOME pour une installation individuelle. Icônes de certaines tailles, selon la spécification XDG, vous devez le placer à certains endroits dans usr ou $HOME , puis exécuter des commandes dans l'environnement de travail pour mettre à jour le cache des icônes, ou espérer que le gestionnaire de l'environnement de travail le découvrira et détectera automatiquement tout. De même avec les types MIME. Comme solution de contournement, il propose Pour utiliser le même service, qui, en plus de définir l'indicateur d'exécution, copiera, s'il y a des icônes, etc. dans AppImage, d'AppImage vers les emplacements corrects selon le XDG, il est supposé que le service effacera tout lors de la suppression ou du déplacement. Bien sûr, il existe des différences de comportement pour chacun environnement de travail, dans les formats de fichiers graphiques, leurs tailles, les emplacements de stockage et les moyens de mettre à jour les caches, ce qui crée un problème. En bref, cette méthode est une béquille.
• Si ce qui précède ne suffit pas, il n'y a pas d'icône AppImage dans le gestionnaire de fichiers. Dans le monde Linux, ils n'ont toujours pas décidé d'implémenter elficon (malgré la discussion et l' implémentation ), il est donc impossible d'incorporer l'icône directement dans l'application. Il s'avère donc que les applications dans le gestionnaire de fichiers n'ont pas leurs propres icônes (pas de différence, AppImage ou autre), elles ne sont que dans le menu Démarrer. Comme solution de contournement, nous utilisons des miniatures - un mécanisme qui a été développé à l'origine pour que les gestionnaires de bureau puissent afficher des miniatures pour prévisualiser les fichiers graphiques sous forme d'icônes. Par conséquent, le service de définition du bit exécutable fonctionne également comme un «miniaturiseur», créant et enregistrant des miniatures d'icônes aux endroits correspondants /usr et $HOME . Ce service effectue également la suppression si AppImage est supprimé ou déplacé. Étant donné que chaque gestionnaire de bureau se comporte un peu différemment, par exemple, dans quels formats il accepte les icônes, dans quelles tailles ou à quels endroits, tout cela est vraiment douloureux.
• L'application se bloque simplement au moment de l'exécution si des erreurs se produisent (par exemple, il existe une bibliothèque qui ne fait pas partie du système de base et n'est pas fournie dans AppImage), et personne ne dit à l'utilisateur dans l'interface graphique ce qui se passe exactement. Nous avons commencé à contourner ce problème en utilisant des notifications sur le bureau, ce qui signifie que nous devons détecter les erreurs dans la ligne de commande, les convertir en messages compréhensibles par l'utilisateur, qui doivent ensuite être affichés sur le bureau. Et bien sûr, chaque environnement de travail les traite un peu différemment.
• Pour le moment (septembre 2019, traducteur environ), je n'ai pas trouvé de moyen simple de dire au système que le fichier 1.png être ouvert en utilisant Krita et 2.png - en utilisant GIMP.

L'emplacement de stockage pour les spécifications multi-bureaux utilisées par GNOME , KDE et Xfce est freedesktop.org

Il est difficile, voire impossible, d'atteindre un niveau de sophistication profondément ancré dans l'environnement de travail de Haiku, en raison des spécifications XDG de freedesktop.org pour le cross-desktop, ainsi que des implémentations de gestionnaires de bureau basées sur ces spécifications. À titre d'exemple, nous pouvons citer une icône Firefox à l'échelle du système: apparemment, les auteurs de XDG ne pensaient même pas que l'utilisateur pouvait avoir plusieurs versions de la même application.

Icônes de différentes versions de Firefox

Je me demandais ce que le monde Linux pouvait apprendre de Mac OS X, afin de ne pas gâcher l'intégration du système. Si vous avez le temps et que vous le faites, assurez-vous de lire ce qu'Arno Gourdol, l'un des premiers ingénieurs de Mac OS X, a déclaré:

Nous voulions installer l'application aussi facilement que faire glisser l'icône de l'application depuis un endroit (serveur, lecteur externe) sur le disque de votre ordinateur. Pour ce faire, toutes les informations sont stockées dans le package d'application, y compris les icônes, la version, le type de fichier en cours de traitement, le type de schémas d'URL que le système doit connaître pour traiter l'application. Cela inclut également des informations sur le «stockage centralisé» dans la base de données Icon Services et Launch Services. Pour maintenir les performances, les applications sont `` découvertes '' à plusieurs endroits `` bien connus '': dans le répertoire système et utilisateur Applications, ainsi que dans certains autres, automatiquement si l'utilisateur est passé au Finder dans le répertoire contenant l'application. En pratique, cela a très bien fonctionné.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 Session 144 - Mac OS X: empaquetage d'applications et impression de documents.

Il n'y a rien de similaire à cette infrastructure sur les bureaux Linux, nous recherchons donc des solutions de contournement autour des contraintes structurelles dans le projet AppImage.

Haiku est-il pressé d'aider?

Et encore une chose: les plates-formes Linux comme base des environnements de travail, en règle générale, sont si peu spécifiées que de nombreuses choses très simples dans un système cohérent avec une pile complète déçoivent la fragmentation et la complexité de Linux. J'ai consacré tout un rapport aux problèmes liés à la plate-forme Linux pour les environnements de travail (des développeurs avertis l'ont confirmé: tout restera ainsi très longtemps).

Mon rapport sur les environnements de bureau Linux en 2018

Même Linus Torvalds a admis que c'était à cause de la fragmentation que l'idée d'environnements de travail avait échoué.

Ravi de voir Haiku!

Avec Haiku, tout est incroyablement simple.

Bien que l'approche naïve du portage d'AppImage vers Haiku consiste simplement à essayer de construire (principalement runtime.c et service) ses composants (ce qui peut même être possible!), Cela n'apportera pas beaucoup d'avantages à Haiku. Parce qu'en fait, la plupart de ces problèmes ont été résolus par Haiku et conceptuellement justifiés. Haiku fournit exactement ces briques pour l'infrastructure système que je cherchais depuis si longtemps dans les environnements de bureau Linux et je ne pouvais pas croire qu'elles n'étaient pas là. À savoir:

Croyez-le ou non, de nombreux utilisateurs de Linux ne peuvent pas surmonter cela. Chez Haiku, tout se fait automatiquement!

• Les fichiers ELF qui n'ont pas de bit exécutable le reçoivent automatiquement lorsque vous double-cliquez dans le gestionnaire de fichiers.
• Les applications peuvent avoir des ressources intégrées, par exemple, des icônes qui apparaissent dans le gestionnaire de fichiers. Vous n'avez pas besoin de copier un groupe d'images dans des répertoires d'icônes spéciaux et, par conséquent, vous n'avez pas besoin de les nettoyer après avoir supprimé ou déplacé l'application.
• Il existe une base de données pour lier les applications aux documents, il n'est pas nécessaire de copier de fichiers pour cela.
• Dans le répertoire lib / à côté de l'exécutable, les bibliothèques sont recherchées par défaut.
• Il n'y a pas de nombreuses distributions et environnements de bureau, tout cela fonctionne - fonctionne partout.
• Il n'y a pas de module de lancement distinct qui diffère du répertoire Applications.
• Les applications n'ont pas de chemin absolu intégré vers leurs ressources; il existe des fonctions spéciales pour déterminer l'emplacement au moment de l'exécution.
• L'idée d'images compressées du système de fichiers a été introduite: il s'agit de n'importe quel package hpkg. Tous sont montés par le noyau.
• Chaque fichier est ouvert par l'application qui l'a créé, sauf si vous spécifiez explicitement autre chose. Comme c'est génial!

Deux fichiers png. Faites attention aux différentes icônes montrant qu'elles seront ouvertes par différentes applications en double-cliquant. Faites également attention au menu déroulant "Ouvrir avec:", où l'utilisateur peut sélectionner une application distincte. Comme c'est facile!

Il semble que de nombreuses béquilles et solutions de contournement nécessaires à AppImage sur Linux deviennent inutiles sur Haiku, qui est basé sur la simplicité et la sophistication, grâce auxquelles il répond à la plupart de nos besoins.

Haiku a-t-il finalement besoin de packages d'application?

Cela mène à une grande question. Si ce serait un ordre de grandeur plus facile de créer un système comme AppImage sur Haiku que sur Linux, cela en vaudrait-il la peine? Ou Haiku avec son système de paquets hpkg a-t-il pratiquement éliminé la nécessité de développer une telle idée? Eh bien, pour la réponse, vous devez examiner la motivation de l'existence d'AppImages.

Vue de l'utilisateur

Jetez un œil à notre utilisateur final:

• Je souhaite installer l'application sans demander le mot de passe administrateur (root). Sur Haiku, il n'y a pas de concept d'administrateur, l'utilisateur a le contrôle total, car il s'agit d'un système personnel! (En principe, vous pouvez imaginer cela en mode multi-utilisateurs, j'espère que les développeurs garderont la simplicité)
• Je veux obtenir les dernières et meilleures versions des applications, ne pas attendre qu'elles apparaissent dans ma distribution (le plus souvent cela signifie "jamais", du moins si vous ne mettez pas à jour l'intégralité du système d'exploitation). Sur Haiku, cela est "résolu" avec des versions flottantes. Cela signifie qu'il est possible d'obtenir les dernières et meilleures versions d'applications, mais pour cela, vous devez constamment mettre à jour le reste du système, en le transformant en une "cible mobile" .
• Je veux plusieurs versions de la même application à proximité, car vous ne pouvez pas savoir ce qui a été cassé dans la dernière version, ou, en tant que développeur Web, je dois vérifier mon travail sous différentes versions du navigateur. Haiku a résolu le premier, mais pas le deuxième problème. Les mises à jour sont annulées, mais uniquement pour l'ensemble du système, il est impossible (comme je le sais) de lancer, par exemple, plusieurs versions de WebPositive ou LibreOffice en même temps.

L'un des développeurs écrit:

En substance, la justification est la suivante: le cas d'utilisation est si rare que l'optimisation n'a pas de sens pour lui; le traiter comme un cas particulier chez HaikuPorts semble plus qu'acceptable.

• Je dois enregistrer les applications où je veux, et non sur le disque de démarrage. Je manque souvent d'espace sur les disques, j'ai donc besoin de connecter un lecteur externe ou un répertoire réseau pour stocker les applications (toutes les versions que j'ai téléchargées). Si je connecte un tel lecteur, j'ai besoin que les applications soient lancées en double-cliquant. Haiku enregistre les anciennes versions des packages, mais je ne sais pas comment les déplacer vers un disque externe, ni comment appeler des applications à partir de là plus tard.

Commentaire du développeur:

Techniquement, cela est déjà possible avec la commande mount. Bien sûr, nous créerons une interface graphique pour cela dès que suffisamment d'utilisateurs intéressés seront réunis.

• Je n'ai pas besoin de millions de fichiers dispersés dans le système de fichiers que je ne peux pas gérer moi-même manuellement. Je veux un fichier par application, que je peux facilement télécharger, déplacer, supprimer. Sur Haiku, ce problème a été résolu à l'aide de packages .hpkg , qui transfèrent, par exemple python, de milliers de fichiers à un. Mais s'il y a, par exemple, Scribus utilisant python, alors je dois gérer au moins deux fichiers. Et je dois faire attention à ce que leurs versions fonctionnent ensemble.

De nombreuses versions d'AppImages fonctionnant côte à côte sur un seul Linux

Vue du côté du développeur d'application

Regardons du point de vue du développeur de l'application:

• Je souhaite gérer l'ensemble de l'expérience utilisateur. Je ne veux pas dépendre du système d'exploitation, qui me dira quand et comment je devrais publier les applications. Chez Haiku, les développeurs peuvent travailler avec leurs propres référentiels hpkg, mais cela signifie que les utilisateurs devront les configurer manuellement, ce qui rend cette idée moins attrayante.
• J'ai une page de téléchargement sur mon site Web où je distribue .exe pour Windows, .dmg pour Mac et .AppImage pour Linux. Ou peut-être que je veux monétiser l'accès à cette page, est-ce possible? De quoi ai-je besoin pour publier sur Haiku? Assez de fichier .hpkg avec les dépendances de .hpkg uniquement
• Mon logiciel a besoin de certaines versions d'autres logiciels. Par exemple, il est connu que Krita a besoin d'une version fixe de Qt, ou Qt, qui est affinée à une version spécifique de Krita, au moins jusqu'à ce que les corrections reviennent à Qt. Vous pouvez emballer votre propre Qt pour l'application dans le package .hpkg , mais ce n'est probablement pas le bienvenu.

Page de téléchargement normal des applications. Que placer ici pour Haiku?

Les bundles (existants en tant que répertoires d'application comme AppDir ou .app dans le style Apple) et / ou les images (en tant qu'AppImages ou .dmg Apple fortement modifiés) seront-ils des ajouts utiles à l'environnement de travail Haiku? Ou va-t-il diluer le tableau dans son ensemble et entraîner une fragmentation, et donc ajouter de la complexité? Je suis déchiré: d'une part, la beauté et la sophistication du Haiku sont basées sur le fait qu'il y a généralement une façon de faire quelque chose, pas beaucoup. , / , , .

mr. waddlesplash

Linux ( , — . ) . Haiku .

?

...

, : — Haiku:

Haiku,

, , , Macintosh Finder. , QtCreator "QtCreator", ?

:

, , ? , - ?

Haiku, ? , .

mr. waddlesplash:

, : , , - . BeOS R5 Haiku — ...

!

Haiku?

hpkg, :

• .hpkg
• ( , ) .hpkg ( 80% )
• , .hpkg , ( , QtCreator): .hpkg , .

mr. waddlesplash :

, , — /system/apps , Deskbar , /system/apps , ( MacOS). Haiku , , , .

• Haiku , , , , " ", , ( 20% ). .hpkg , , — . (, .hpkg , — , . ! — .) , .hpkg , , HaikuDepot… ).

mr. waddlesplash:

. "" pkgman .

hpkg, . , .

Conclusion

Haiku , , , Linux. .hpkg — , . , Haiku . — , Haiku, , . Haiku . , , , Haiku. , «-». 10 Linux, Haiku, , , . , , Haiku , , — . , , hpkg , . , Haiku , , ( ) "". , ?

! Haiku DVD USB, .
? telegram- .

: C C++. Haiku OS

: Haiku.

: