TL;DR: Haiku peut-il recevoir un support approprié pour les paquets d'applications, par exemple les catalogues d'applications (comme .app sur Mac) et/ou les images d'applications (Linux AppImage) ? Je pense que cela serait un ajout digne de ce nom, plus facile à intégrer que dans d'autres systèmes, car une grande partie de l'infrastructure est déjà en place.
j'ai découvert Haiku, un système étonnamment bon. Comme je m'intéresse depuis longtemps aux catalogues et aux images d'applications (inspiré par la simplicité de Macintosh), il n'est pas surprenant que cette idée m'ait traversé l'esprit…
Pour être clair : je suis le créateur et l'auteur d'AppImage, un format de distribution d'applications Linux, conçu pour la simplicité de Mac et offrant un contrôle total aux auteurs d'applications et aux utilisateurs finaux (si vous voulez en savoir plus — voir et ).
Que diriez-vous de créer AppImage pour Haiku ?
Imaginons un peu, purement théoriquement, ce qu'il faudrait faire pour obtenir , ou quelque chose de similaire, sur Haiku ? Il n'est pas nécessaire de créer quelque chose tout de suite, car le système déjà présent dans Haiku fonctionne étonnamment bien, et cette expérience imaginaire serait plutôt intéressante. De plus, elle démontre la finesse de Haiku par rapport aux environnements de bureau Linux, où des choses similaires sont terriblement difficiles (j'ai le droit de le dire : ça fait 10 ans que je me bats avec le débogage).
Sur Macintosh System 1, chaque application était un fichier distinct, « géré » dans le Finder. En utilisant AppImage, j'essaie de recréer cette expérience utilisateur sur Linux.
Tout d'abord, qu'est-ce qu'AppImage ? C'est un système de publication d'applications tierces (par exemple, ), permettant de distribuer des applications quand et comme bon leur semble : pas besoin de connaître les spécificités de différents distributions, les politiques de compilation ou l'infrastructure de compilation, pas besoin de dépendances, et elles ne disent pas aux utilisateurs ce qu'ils peuvent ou ne peuvent pas installer sur leurs ordinateurs. AppImage doit être compris comme quelque chose de similaire à un paquet pour Mac au format .app à l'intérieur d'une image disque .dmg. La principale différence est que les applications ne sont pas copiées, mais restent toujours à l'intérieur de l'AppImage, un peu comme les paquets Haiku .hpkg sont montés, et ne sont jamais installés au sens habituel.
AppImage a acquis au cours de ses plus de 10 années d'existence une certaine attraction et popularité : Linus Torvalds lui-même l'a publiquement approuvé, et des projets bien connus (comme LibreOffice, Krita, Inkscape, Scribus, ImageMagick) l'ont adopté comme principal moyen de distribution des versions continues ou nightly, sans interférer avec les applications installées ou non installées des utilisateurs. Cependant, les environnements de travail et les distributions Linux s'accrochent encore souvent à un modèle de distribution traditionnel et centralisé basé sur des œillets d'accompagnement et/ou promeuvent leurs propres programmes d'affaires et/ou d'ingénierie corporatifs. (RedHat, Fedora, GNOME) et (Canonical, Ubuntu). Ça en devient .
Comment tout fonctionne
- Chaque AppImage contient deux parties : un petit exécutable ELF qui se lance par double-clic (appelé
runtime.c), suivi d'une image de système de fichiers .
- Le système de fichiers SquashFS contient la charge utile sous forme d'application et tout ce dont elle a besoin pour se lancer, ce qui ne peut pas être considéré, dans un esprit sain, comme faisant partie de l'installation par défaut pour chaque système cible suffisamment 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.
- Lorsqu'un utilisateur lance l'application, runtime utilise FUSE et squashfuse pour monter le système de fichiers, puis traite le lancement d'un certain point d'entrée (appelé AppRun) à l'intérieur de l'AppImage monté.
Le système de fichiers se démonte après la fin du processus.
C'est en fait très simple.
Mais ces éléments compliquent tout :
- avec une telle variété de distributions Linux, rien ne peut vraiment être considéré, dans un esprit sain, comme « partie de l'installation par défaut pour chaque système cible récent ». Nous contourtons ce problème en construisant , qui permet de définir ce qui sera emballé dans l'AppImage et ce qu'il faudra obtenir ailleurs. Cependant, nous nous trompons parfois, bien que dans l'ensemble, tout fonctionne très bien. Pour cette raison, nous conseillons aux créateurs de paquets de tester les AppImages sur tous les systèmes cibles (distributions).
- Les applications sous forme de charge utile doivent être mobiles dans le système de fichiers. Malheureusement, de nombreuses applications ont des chemins absolus fixes vers, par exemple, des ressources dans
/usr/share. Cela doit être corrigé d'une manière ou d'une autre. En outre, il faut soit exporterLD_LIBRARY_PATH, ou modifierrpathafin que le chargeur puisse trouver les bibliothèques associées. La première méthode a ses inconvénients (qui nécessitent des solutions complexes), tandis que la seconde est simplement encombrante. - Le plus grand piège UX pour les utilisateurs est qu'il faut pour le fichier AppImage après son téléchargement. Que vous y croyiez ou non, c'est un véritable obstacle pour certains. La nécessité de définir le bit d'exécution est encombrante même pour les utilisateurs expérimentés. Comme solution de contournement, nous avons proposé d'installer un petit service qui surveille les fichiers AppImage et définit leur bit d'exécution. En l'état, ce n'est pas la meilleure solution, car cela ne fonctionnera pas « out of the box ». Les distributions Linux ne fournissent pas ce service, donc pour les utilisateurs, tout va mal « out of the box ».
- Les utilisateurs de Linux s'attendent à ce qu'une nouvelle application ait une icône dans le menu de lancement. On ne peut pas dire au système : « Regardez, une nouvelle application, faites fonctionner ça ». Au lieu de cela, conformément à la spécification XDG, il faut copier le fichier
.desktopau bon endroit dans/usrpour une installation système généralisée, ou dans$HOMEpour une installation individuelle. Les icônes de certaines tailles, conformément à la spécification XDG, doivent être placées aux endroits spécifiques dansusrou$HOME, après quoi il faut exécuter des commandes dans l'environnement de travail pour mettre à jour le cache des icônes, ou espérer que le gestionnaire de bureau saisira et détectera automatiquement tout. Il en va de même pour les types MIME. Comme solution de contournement, il est proposé d'utiliser le même service, qui, en plus de définir le bit exécutable, copiera, en présence d'icônes, etc., à partir de l'AppImage aux bons endroits conformément à XDG. Lors de la suppression ou du déplacement, le service devrait théoriquement nettoyer tout. Bien sûr, il y a des différences de comportement dans chaque environnement de bureau, dans les formats de fichiers graphiques, leurs tailles, leurs emplacements de stockage et les méthodes de mise à jour des caches, ce qui crée le problème. En gros, cette méthode est un bricolage. - 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, la décision d'adopter elficon n'a toujours pas été prise (malgré le et ), donc il est impossible d'incorporer l'icône directement dans l'application. Ainsi, il s'avère que les applications dans le gestionnaire de fichiers n'ont pas leurs propres icônes (peu importe, AppImage ou autre), elles n'existent que dans le menu de lancement. Comme solution de contournement, nous utilisons des miniatures — un mécanisme qui a été conçu à l'origine pour permettre aux gestionnaires de bureau d'afficher des images réduites en aperçu des fichiers graphiques comme leurs icônes. Par conséquent, le service d'installation de bits d'exécution fonctionne également comme un « miniatureur », créant et enregistrant des miniatures d'icônes aux emplacements appropriés.
/usret$HOME. Ce service effectue également un nettoyage si l'AppImage est supprimée ou déplacée. Étant donné que chaque gestionnaire de bureau se comporte légèrement différemment, par exemple, en termes de formats acceptés pour les icônes, de tailles ou d'emplacements, cela peut être assez problématique. - L'application plante simplement à l'exécution en cas d'erreurs (par exemple, s'il y a une bibliothèque qui ne fait pas partie du système de base et qui n'est pas fournie dans l'AppImage), et personne n'informe l'utilisateur dans l'interface graphique de ce qui se passe vraiment. Nous avons commencé à contourner cela en utilisant sur le bureau, ce qui signifie que nous devons capturer les erreurs de la ligne de commande, les transformer en messages compréhensibles pour l'utilisateur, puis les afficher sur le bureau. Et bien sûr, chaque environnement de bureau les traite un peu différemment.
- À l'heure actuelle (septembre 2019, — note du traducteur), je n'ai pas trouvé de moyen simple de dire au système que le fichier
1.pngdoit être ouvert avec Krita, et2.png— avec GIMP.
Le lieu de stockage des spécifications cross-desktop utilisées dans , et est freedesktop.org
Atteindre un niveau de sophistication profondément intégré dans l'environnement de bureau Haiku est compliqué, pour ne pas dire « impossible », en raison des spécifications pour le cross-desktop, ainsi que des implémentations des gestionnaires de bureau basées sur ces spécifications. Par exemple, une icône système unique pour Firefox : manifestement, il n'a jamais traversé l'esprit des auteurs de XDG qu'un utilisateur pourrait avoir plusieurs versions de la même application installées.
Icônes des différentes versions de Firefox
Je me suis demandé ce que le monde Linux pourrait apprendre de Mac OS X pour ne pas échouer lors de l'intégration système. Si vous avez le temps et que vous vous intéressez à ce sujet, n'hésitez pas à lire ce qu'a dit Arnaud Gurdol, l'un des premiers ingénieurs de Mac OS X :
Nous voulions que l'installation d'une application soit aussi simple que de faire glisser l'icône de l'application depuis n'importe où (serveur, disque externe) vers le disque de votre ordinateur. Pour cela, le paquet d'application conserve toutes les informations, y compris les icônes, la version, le type de fichier traité, le type de schéma URL que le système doit connaître pour traiter l'application. Cela inclut également des informations pour le 'stockage centralisé' dans la base de données Icon Services et Launch Services. Pour prendre en charge la performance de l'application, celles-ci sont 'découvertes' à plusieurs emplacements 'bien connus' : dans le répertoire système et utilisateur des Applications, ainsi que dans d'autres emplacements automatiquement, si l'utilisateur navigue dans le Finder jusqu'au répertoire contenant l'application. En pratique, cela a très bien fonctionné.
Apple WWDC 2000 session 144 - Mac OS X : empaquetage d'applications et impression de documents.
Il n'existe rien de similaire dans cette infrastructure sur les environnements de travail Linux, donc nous cherchons des moyens de contourner les limitations structurelles du projet AppImage.
Est-ce que Haiku se précipite à l'aide ?
Et encore : les plateformes Linux en tant que base des environnements de travail sont généralement si peu spécifiées que beaucoup de choses qui sont très simples dans un système cohérent avec une pile complète s'avèrent frustrantes par leur fragmentation et leur complexité sur Linux. J'ai consacré une présentation entière aux questions liées à la plateforme Linux pour les environnements de travail (des développeurs expérimentés ont confirmé : cela ne changera pas de sitôt).
Ma présentation sur les problèmes des environnements de travail Linux en 2018
Même Linus Torvalds a reconnu qu'à cause de la fragmentation, l'idée des environnements de travail n'a pas réussi.
C'est agréable de voir Haiku !
Avec Haiku, tout devient incroyablement simple
Bien qu'une approche naïve du « portage » d'AppImage sur Haiku consiste simplement à essayer de construire (principalement runtime.c et le service) ses composants (ce qui pourrait même être possible !), cela n'apportera pas vraiment de bénéfice à Haiku. En effet, la plupart de ces problèmes sont déjà résolus sur Haiku et sont conceptuellement justifiés. Haiku fournit exactement les briques pour l'infrastructure système que j'ai tant cherchées dans les environnements de travail sous Linux et que je n'arrivais pas à croire qu'elles n'y étaient pas. À savoir :
Que vous le croyiez ou non, mais cela est un défi pour de nombreux utilisateurs de Linux. Sur Haiku, tout se fait de manière automatique !
- Les fichiers ELF, n'ayant pas de bit d'exécution, l'obtiennent automatiquement lorsqu'on double-clique dans le gestionnaire de fichiers.
- Les applications peuvent avoir des ressources intégrées, par exemple des icônes, qui s'affichent dans le gestionnaire de fichiers. Il n'est pas nécessaire de copier une multitude d'images dans des répertoires spéciaux d'icônes, ce qui signifie qu'il n'est pas nécessaire de les nettoyer après la suppression ou le déplacement de l'application.
- Il existe une base de données pour lier les applications aux documents, il n'est pas nécessaire de copier des 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'existe pas de nombreuses distributions et environnements de bureau, tout ce qui fonctionne — fonctionne partout.
- Il n'existe pas de module distinct pour l'exécution, différent du répertoire Applications.
- Les applications n'ont pas de chemins absolus intégrés vers leurs ressources, il existe des fonctions spéciales pour déterminer l'emplacement à l'exécution.
- L'idée des images compressées de systèmes de fichiers est intégrée : c'est n'importe quel paquet hpkg. Tous sont montés par le noyau.
- Chaque fichier est ouvert par l'application qui l'a créé, sauf indication contraire explicite. Comme c'est génial !
Deux fichiers png. Notez les différentes icônes, indiquant qu'ils seront ouverts par différentes applications par double-clique. Notez également le menu déroulant « Ouvrir avec : », où l'utilisateur peut choisir une application distincte. Comme c'est simple !
Il semble que de nombreux ajustements et solutions de contournement nécessaires pour AppImage sur Linux deviennent inutiles sur Haiku, qui se base sur la simplicité et l'élégance, ce qui lui permet de répondre à la plupart de nos besoins.
Les paquets d'applications sont-ils finalement nécessaires sur Haiku ?
Cela soulève une grande question. Si créer un système similaire à AppImage sur Haiku s'avérait beaucoup plus simple que sur Linux, faudrait-il s'y atteler ? Ou bien Haiku, avec son système de paquets hpkg, a-t-elle effectivement éliminé la nécessité de développer une telle idée ? Eh bien, pour y répondre, il faut examiner la motivation derrière l'existence des AppImages.
Un point de vue utilisateur
Regardons notre utilisateur final :
- Je veux installer une application sans demander le mot de passe administrateur (root). Il n'y a pas de concept d'administrateur sur Haiku, l'utilisateur a un contrôle total, car c'est un système personnel ! (En principe, cela pourrait également être envisagé en mode multi-utilisateur, j'espère que les développeurs conserveront la simplicité)
- Je veux obtenir les dernières et meilleures versions des applications, sans attendre qu'elles apparaissent dans ma distribution (ce qui signifie le plus souvent « jamais », à moins de mettre à jour tout le système d'exploitation). Sur Haiku, cela est 'résolu' grâce aux versions flottantes. Cela signifie qu'il est possible d'obtenir les dernières et meilleures versions des applications, mais il faut constamment mettre à jour le reste du système, transformant ainsi ce dernier en 'cible mouvante'..
- Je veux avoir plusieurs versions de la même application côte à côte, car je ne peux pas savoir ce qui a été cassé dans la dernière version, ou, par exemple, en tant que développeur web, je dois vérifier mon travail sur différentes versions de navigateur. Haiku a résolu le premier problème, mais pas le second. Les mises à jour peuvent être annulées, mais seulement pour l'ensemble du système, il n'est pas possible (autant que je sache) de lancer, par exemple, plusieurs versions de WebPositive ou de LibreOffice simultanément.
Un des développeurs écrit :
En substance, le raisonnement est le suivant : le scénario d'utilisation est tellement rare que l'optimisation pour celui-ci n'a pas de sens ; le traiter comme un cas particulier dans HaikuPorts semble plus que raisonnable.
- J'ai besoin de garder des applications là où je le souhaite, et non sur le disque de démarrage. Mon disque se remplit souvent, donc je dois brancher un disque externe ou un répertoire réseau pour stocker des applications (toutes les versions que j'ai téléchargées). Si je branche un tel disque, les applications doivent se lancer par double-clic. Haiku conserve les anciennes versions des paquets, mais je ne sais pas comment les déplacer sur un disque externe, ni comment ensuite appeler les applications depuis là-bas.
Commentaire du développeur :
Techniquement, c'est déjà possible avec l'équipe mount. Bien sûr, nous créerons une interface graphique pour cela dès qu'il y aura suffisamment d'utilisateurs intéressés.
- Je ne veux pas de millions de fichiers éparpillés dans le système de fichiers que je ne peux pas gérer manuellement. Je veux un fichier par application, facilement téléchargeable, déplaçable, supprimable. Sur Haiku, ce problème est résolu avec des paquets
.hpkg, qui regroupent, par exemple, python, de milliers de fichiers en un seul. Mais si, par exemple, Scribus utilise python, je dois gérer au moins deux fichiers. Et je dois m'assurer de conserver les versions qui fonctionnent ensemble.
De nombreuses versions d'AppImages, exécutées côte à côte sur un Linux
Perspective du développeur d'applications
Voyons cela du point de vue du développeur d'applications :
- Je veux contrôler l'expérience utilisateur dans son ensemble. Je ne veux pas dépendre du système d'exploitation qui me dicte quand et comment je dois publier des applications. Sur Haiku, les développeurs peuvent travailler avec leurs propres dépôts 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
.exepour Windows,.dmgpour Mac et.AppImagepour Linux. Et si je souhaitais monétiser l'accès à cette page, c'est tout à fait possible ? Que devrais-je y mettre pour Haiku ? Un seul fichier.hpkgavec des dépendances uniquement de HaikuPorts - Mon logiciel nécessite des versions spécifiques d'autres logiciels. Par exemple, il est connu que pour Krita, une version corrigée de Qt est nécessaire, ou un Qt précisément configuré pour une version spécifique de Krita, du moins jusqu'à ce que les corrections soient intégrées dans Qt. Il est possible d'emballer son propre Qt pour l'application dans le paquet
.hpkg, mais cela ne sera probablement pas bien perçu.
Page de téléchargement classique de l'application. Que devrais-je y mettre pour Haiku ?
Les bundles (existants sous forme de répertoires d'applications, comme AppDir ou .app au style Apple) et/ou des images (sous forme d'AppImages fortement modifiées ou .dmg Les applications d'Apple) sont-elles un complément utile à l'environnement de travail de Haiku ? Ou cela va-t-il diluer l'ensemble et conduire à une fragmentation, ajoutant ainsi de la complexité ? J'hésite : d'un côté, la beauté et le raffinement de Haiku reposent sur le fait qu'il y a généralement une seule manière de faire les choses, plutôt que plusieurs. D'un autre côté, une grande partie de l'infrastructure pour les répertoires et/ou les ensembles d'applications est déjà en place, donc le système appelle à l'intégration des derniers pourcentages restants.
Selon le développeur
Sur Linux, ils (répertoires et ensembles d'applications, - note du traducteur) sont probablement une solution technique aux problèmes systémiques. Sur Haiku, nous préférons simplement résoudre les problèmes systémiques.
Qu'en pensez-vous ?
Avant de répondre…
Attendez, faisons un rapide état des lieux : en réalité les répertoires d'applications sont déjà une partie de Haiku :
Les répertoires d'applications existent déjà sur Haiku, mais ne sont pas encore pris en charge dans le gestionnaire de fichiers.
Ils ne sont tout simplement pas aussi bien pris en charge que, disons, dans le Finder de Macintosh. Que ce serait génial si le répertoire de QtCreator affichait le nom et l'icône « QtCreator » en haut à gauche, lançant l'application par un double clic ?
Un peu plus tôt, j'ai déjà :
Êtes-vous sûr de pouvoir lancer vos applications d'il y a dix ans aujourd'hui, alors que tous les magasins d'applications et dépôts de distributions les oublieront ainsi que leurs dépendances ? Êtes-vous sûr de pouvoir toujours accéder à votre travail actuel à l'avenir ?
Y a-t-il déjà une réponse de la part de Haiku, ou les répertoires et ensembles d'applications pourront-ils aider ici ? Je pense qu'ils le pourront.
Selon Mr. waddlesplash :
Oui, nous avons une réponse à la question : nous allons simplement prendre en charge ces applications aussi longtemps que nécessaire, jusqu'à ce que quelqu'un puisse lire correctement leurs formats de fichiers ou assurer une fonctionnalité équivalente. Notre engagement à maintenir le fonctionnement des applications BeOS R5 sur Haiku en est une preuve directe…
C'est exact !
Quel plan d'action Haiku devrait-il adopter ?
Je peux imaginer une coexistence pacifique de hpkg, des répertoires et des images d'applications :
- Le logiciel système utilise
.hpkg - Pour les logiciels les plus utilisés (surtout ceux qui nécessitent des versions flottantes programmées), on utilise
.hpkg(environ 80 % de tous les cas) - Certains, installés via
.hpkg, les applications bénéficieront de la transition vers une infrastructure avec des catalogues d'applications (comme QtCreator) : elles seront diffusées sous forme de.hpkg, comme avant.
mr. waddlesplash dit :
Si tout ce dont vous avez besoin est de visualiser des applications dans
/system/apps, il faudrait plutôt rendre les catalogues dans Deskbar plus gérables pour les utilisateurs, car/system/appsil n'est pas prévu que les utilisateurs l'ouvrent et le regardent régulièrement (contrairement à MacOS). Pour de telles situations, Haiku a une autre paradigme, mais cette option est, en théorie, acceptable.
- Haiku obtient une infrastructure pour exécuter des images d'applications, des compilations nocturnes, continues et de test de logiciels, ainsi que pour les cas où l'utilisateur souhaite « congeler dans le temps », pour des logiciels privés et internes, et d'autres cas d'utilisation particuliers (environ 20 % de tous). Ces images contiennent les fichiers nécessaires au lancement de l'application
.hpkg, montés par le système, et après la fin de l'application, démontés. (Peut-être que le gestionnaire de fichiers pourrait placer des fichiers.hpkgdans des images d'applications, automatiquement ou à la demande de l'utilisateur — un peu comme lorsqu'on glisse une application vers un répertoire réseau ou un disque externe. C'est tout simplement une mélodie ! Ou plutôt une poésie — un haïku.) D'un autre côté, l'utilisateur pourrait vouloir installer le contenu de l'image sous forme de fichiers.hpkg, après quoi ils seraient mis à jour et traités exactement de la même manière que s'ils avaient été installés via HaikuDepot... Un brainstorming est nécessaire).
Citation de mr. waddlesplash :
Lancer des applications depuis des disques externes ou des catalogues réseau pourrait potentiellement être utile. De plus, ajouter la possibilité de personnaliser davantage de « zones » pour pkgman serait certainement une bonne fonctionnalité.
Un tel système tirerait parti de hpkg, des catalogues et des images d'applications. Ils sont bons séparément, mais ensemble, ils deveniront imbattables.
Conclusion
Haiku dispose d'une infrastructure fournissant une interface utilisateur simple et raffinée pour PC, allant bien au-delà de ce qui est généralement proposé pour les PC sous Linux. Le système de paquets .hpkg — un exemple parmi d'autres, mais les autres parties du système sont également imprégnées de sophistication. Néanmoins, un bon support des catalogues et des images d'application bénéficierait à Haiku. La meilleure façon de procéder serait d'en discuter avec des personnes qui connaissent Haiku, sa philosophie et son architecture bien mieux que moi. Après tout, je n'utilise Haiku que depuis un peu plus d'une semaine. Cela dit, je pense que ce nouveau regard sera utile aux concepteurs, développeurs et architectes de Haiku. Au minimum, je serais ravi d'être leur 'partenaire d'entraînement'. J'ai plus de 10 ans d'expérience pratique avec des catalogues et des ensembles d'applications pour Linux, et j'aimerais leur trouver une application pour Haiku, dont la conception, selon moi, leur convient parfaitement. Les solutions potentielles que je propose ne sont certainement pas les seules bonnes pour les problèmes que j'ai décrits, et si l'équipe de Haiku décide de trouver d'autres solutions plus élégantes, je ne peux qu'applaudir. En principe, je réfléchis déjà à des idées sur la façon de faire fonctionner le système. hpkg encore plus incroyable, sans changer la façon dont il fonctionne. Il s'avère que l'équipe de Haiku a longtemps réfléchi aux ensembles d'applications lors de l'implémentation du système de gestion des paquets, mais malheureusement, (je pense) que l'idée est tombée dans l'oubli. Peut-être est-il temps de la faire renaître ?
Essayez par vous-même ! En effet, le projet Haiku fournit des images à télécharger sur DVD ou USB, générées .
Vous avez des questions ? Nous vous invitons sur notre .
Revue des erreurs :
De de traduction : c'est le huitième et dernier article d'une série sur Haiku.
Liste des articles :
Seuls les utilisateurs enregistrés peuvent participer au sondage. , s'il vous plaît.
Y a-t-il un sens à porter le système hpkg pour Linux ?
Oui
Non
Déjà réalisé, j'écrirai dans les commentaires
20 utilisateurs ont voté. 5 utilisateurs se sont abstenus.
Source : habr.com
