TL; DR: Haiku peut-il obtenir une prise en charge appropriée pour les packages d'applications, tels que les répertoires d'applications (comme .app sur Mac) et/ou images d'application (Linux AppImage) ? Je pense que ce serait un ajout intéressant, plus facile à mettre en œuvre correctement que d'autres systèmes puisque la plupart de l'infrastructure est déjà en place.
J'ai découvert Haiku, un système étonnamment bon. Eh bien, comme je m'intéresse depuis longtemps aux répertoires et aux images d'applications (inspirées de la simplicité du Macintosh), il n'est pas étonnant qu'une idée me soit venue à l'esprit...
Pour information, je suis le créateur et l'auteur d'AppImage, un format de distribution d'applications. Linux, qui vise à simplifier le Mac et à donner un contrôle total aux auteurs d'applications et aux utilisateurs finaux (voir plus bas). и ).
Et si nous créions une AppImage pour Haiku ?
Réfléchissons un peu, de manière purement théorique : que faut-il faire pour obtenir Ou quelque chose de similaire sur Haiku ? Inutile de créer quoi que ce soit pour l’instant, le système actuel de Haiku fonctionne à merveille, mais une petite expérience serait intéressante. Cela permettrait aussi de démontrer 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 lutte contre le débogage depuis déjà 10 ans).
Sur Macintosh System 1, chaque application était un fichier distinct, « géré » dans le Finder. En utilisant AppImage, j’essaie de recréer la même expérience utilisateur sur Linux.
Tout d’abord, qu’est-ce qu’une AppImage ? Il s'agit d'un système de publication d'applications tierces (par exemple, ), permettant aux applications d'être publiées quand et comment elles le souhaitent : il n'est pas nécessaire de connaître les spécificités des différentes distributions, de créer des politiques ou de construire une infrastructure, aucun support du responsable n'est nécessaire, et ils ne disent pas aux utilisateurs ce qu'ils peuvent (ne pas) installer sur leurs ordinateurs. AppImage doit être compris comme quelque chose de similaire à un package Mac au format .app à l'intérieur de l'image disque .dmg. La principale différence est que les applications ne sont pas copiées, mais restent pour toujours dans AppImage, de la même manière que les packages Haiku. .hpkg monté, et jamais installé au sens habituel du terme.
En plus de dix ans d'existence, AppImage a gagné en popularité : Linus Torvalds lui-même l'a publiquement soutenu, et des projets populaires (comme LibreOffice, Krita, Inkscape, Scribus et ImageMagick) l'ont adopté comme méthode principale de distribution de versions continues ou nocturnes qui n'interfèrent pas avec les applications installées ou non installées par les utilisateurs. Cependant, les environnements de bureau et les distributions Linux Le plus souvent, ils s'accrochent encore au modèle de distribution traditionnel et centralisé, basé sur des techniciens de maintenance, et/ou promeuvent leurs propres programmes commerciaux et/ou d'ingénierie d'entreprise basés sur (RedHat, Fedora, GNOME) et (Canonique, UbuntuÇa y arrive. .
Comment ça marche
- Chaque AppImage contient 2 parties : un petit ELF double-clic (appelé.
runtime.c), suivi d'une image du système de fichiers .
- Le système de fichiers SquashFS contient une charge utile sous la forme d'une application et de tout ce qui est nécessaire à son exécution, ce qui, de façon lucide, ne peut être considéré comme faisant partie de l'installation par défaut de tout système cible (distribution) suffisamment récent. LinuxIl contient également des métadonnées, telles que le nom de l'application, les icônes, les types MIME, etc.
- Lorsqu'il est exécuté par l'utilisateur, le runtime utilise FUSE et squashfuse pour monter le système de fichiers, puis gère l'exécution d'un point d'entrée (alias AppRun) à l'intérieur de l'AppImage montée.
Le système de fichiers est démonté une fois le processus terminé.
Tout semble simple.
Et ces choses compliquent tout :
- avec une telle variété de distributions Linux Plus rien de sensé ne peut être qualifié de « partie intégrante de l'installation par défaut pour chaque nouveau système cible ». Nous contournons ce problème en construisant , vous permettant de déterminer ce qui sera empaqueté dans AppImage et ce qui devra être emporté ailleurs. En même temps, nous manquons parfois, même si, en général, tout fonctionne très bien. Pour cette raison, nous recommandons aux créateurs de packages de tester AppImages sur tous les systèmes cibles (distributions).
- Les charges utiles des applications doivent être relocalisables dans le système de fichiers. Malheureusement, de nombreuses applications disposent de chemins absolus codés en dur vers, par exemple, des ressources dans
/usr/share. Cela doit être corrigé d’une manière ou d’une autre. De plus, vous devez soit exporterLD_LIBRARY_PATH, ou réparerrpathafin que le chargeur puisse trouver les bibliothèques associées. La première méthode a ses inconvénients (qui sont surmontés de manière complexe) et la seconde est tout simplement lourde. - Le plus gros piège UX pour les utilisateurs est que Le fichier AppImage après téléchargement représente un véritable obstacle pour certains utilisateurs. Activer le bit d'exécution est complexe, même pour les plus expérimentés. En guise de solution de contournement, nous suggérons l'installation d'un petit service qui surveille les fichiers AppImage et active leur bit d'exécution. Cette solution, telle quelle, n'est pas optimale car elle ne fonctionne pas immédiatement. Distributions Linux Ils ne proposent pas ce service, ce qui donne d'emblée une mauvaise expérience aux utilisateurs.
- Membres Linux Les utilisateurs s'attendent à ce qu'une nouvelle application possède une icône dans le lanceur. Il est impossible de simplement dire au système : « Tiens, une nouvelle application est disponible, lançons-la ! » Conformément à la spécification XDG, il est nécessaire de copier le fichier.
.desktopau bon endroit dans/usrpour une installation à l'échelle du système, ou dans$HOMEpour particulier. Les icônes de certaines tailles, selon la spécification XDG, doivent être placées à certains endroits dansusrou$HOME, puis exécutez des commandes dans l'environnement de travail pour mettre à jour le cache d'icônes, ou espérez que le gestionnaire de l'environnement de travail le comprendra et détectera automatiquement tout. Idem avec les types MIME. Comme solution de contournement, il est proposé d'utiliser le même service, qui, en plus de définir l'indicateur d'exécutabilité, le fera, s'il y a des icônes, etc. dans AppImage, copiez-les depuis AppImage aux bons endroits selon XDG. Une fois supprimé ou déplacé, le service est censé tout effacer. Bien entendu, il existe des différences dans le comportement de chaque environnement de travail, dans les formats de fichiers graphiques, leurs tailles, leurs emplacements de stockage et leurs méthodes de mise à jour des caches, ce qui crée un problème. Bref, cette méthode est une béquille. - Comme si cela ne suffisait pas, l'icône AppImage est toujours absente du gestionnaire de fichiers. Linux Nous n'avons toujours pas pris de décision concernant la mise en œuvre d'Elficon (malgré и ), il est donc impossible d’intégrer l’icône directement dans l’application. Il s'avère donc que les applications du gestionnaire de fichiers n'ont pas leurs propres icônes (aucune différence, AppImage ou autre), elles se trouvent uniquement dans le menu Démarrer. Pour contourner le problème, nous utilisons des vignettes, un mécanisme conçu à l'origine pour permettre aux gestionnaires de bureau d'afficher des images d'aperçu miniatures des fichiers graphiques sous forme d'icônes. Par conséquent, le service de configuration du bit d'exécutabilité fonctionne également comme un « miniaturiseur », créant et écrivant des vignettes d'icônes aux emplacements appropriés.
/usrи$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, dans quels formats il accepte les icônes, dans quelles tailles ou à quels endroits, tout cela est vraiment pénible. - L'application plante simplement lors 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 sur le bureau, ce qui signifie que nous devons détecter les erreurs de la ligne de commande, les convertir en messages compris par l'utilisateur, qui doivent ensuite être affichés sur le bureau. Et bien sûr, chaque environnement de bureau les gère un peu différemment.
- Pour le moment (septembre 2019 - ndlr) je n'ai pas trouvé de moyen simple d'indiquer au système que le fichier
1.pngdoit être ouvert en utilisant Krita, et2.png- en utilisant GIMP.
Emplacement de stockage pour les spécifications multi-ordinateurs utilisées dans , и est freedesktop.org
Atteindre le niveau de sophistication profondément ancré dans l’environnement de travail Haiku est difficile, voire impossible, en raison des spécifications. pour le cross-office, ainsi que les implémentations de gestionnaires de bureau basés sur ces spécifications. A titre d'exemple, on peut citer une icône Firefox à l'échelle du système : apparemment, les auteurs de XDG ne pensaient même pas qu'un utilisateur pouvait avoir plusieurs versions d'une même application installées.
Icônes pour différentes versions de Firefox
Je me demandais ce qu'était le monde. Linux Je pourrais tirer des leçons de Mac OS X pour éviter de rater l'intégration système. Si vous avez le temps et que vous travaillez sur ce projet, lisez attentivement ce qu'en disait Arnaud Gourdold, l'un des premiers ingénieurs de Mac OS X :
Nous voulions rendre l'installation de l'application aussi simple que de faire glisser l'icône de l'application depuis quelque part (serveur, lecteur externe) sur le lecteur de votre ordinateur. Pour ce faire, le package d'application stocke toutes les informations, 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 central » dans la base de données Icon Services et Launch Services. Pour prendre en charge les performances, les applications sont « découvertes » à plusieurs endroits « bien connus » : les répertoires d'applications système et utilisateur, et quelques autres automatiquement si l'utilisateur navigue vers le Finder dans le répertoire contenant l'application. En pratique, cela a très bien fonctionné.
Apple WWDC 2000 session 144 - Mac OS X : packaging d'applications et impression de documents.
Il n'existe rien de similaire dans cette infrastructure en environnement de production. LinuxNous recherchons donc des solutions de contournement aux limitations structurelles du projet AppImage.
Haïku vient-il à la rescousse ?
Et aussi : les plateformes Linux Les environnements de travail, qui constituent leur base, sont généralement si peu spécifiés que de nombreuses choses qui seraient assez simples dans un système complet et cohérent deviennent frustrantes, fragmentées et complexes. LinuxJ'ai consacré un rapport entier aux problèmes liés à la plateforme. Linux pour les environnements de travail (des développeurs compétents ont confirmé que tout restera ainsi pendant très longtemps).
Mon rapport sur les problèmes liés aux environnements de travail Linux dans 2018
Même Linus Torvalds a admis que la fragmentation était la raison de l'échec de l'idée de l'espace de travail.
Ravi de voir Haïku !
Le haïku rend tout incroyablement simple
Une approche simpliste pour « porter » AppImage sur Haiku consisterait à compiler ses composants (principalement runtime.c et le service) (ce qui est peut-être possible !), mais elle n'apporterait pas grand-chose à Haiku. En effet, la plupart de ces problèmes sont résolus dans Haiku et reposent sur des principes solides. Haiku fournit précisément les éléments constitutifs de l'infrastructure système que je recherche depuis si longtemps dans les environnements de bureau. Linux et n'arrivait pas à croire qu'ils n'étaient pas là. À savoir :
Croyez-le ou non, de nombreux utilisateurs ne parviennent pas à surmonter ce problème. LinuxSur Haiku, tout se fait automatiquement !
- Les fichiers ELF qui n'ont pas de bit d'exécutabilité en obtiennent un automatiquement lors d'un double-clic dans le gestionnaire de fichiers.
- Les applications peuvent avoir des ressources intégrées, telles que des icônes, affichées dans le gestionnaire de fichiers. Il n'est pas nécessaire de copier un tas d'images dans des répertoires spéciaux avec des icônes, et donc pas besoin de les nettoyer après avoir supprimé ou déplacé l'application.
- Il existe une base de données pour relier les candidatures aux documents, il n'est pas nécessaire de copier de fichiers pour cela.
- Dans le répertoire lib/ à côté du fichier 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'y a pas de module distinct à exécuter qui soit différent du répertoire Applications.
- Les applications n'ont pas de chemins absolus intégrés vers leurs ressources ; elles disposent de fonctions spéciales pour déterminer l'emplacement au moment de l'exécution.
- L'idée d'images de système de fichiers compressées 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 indication contraire explicite de votre part. Comme c'est cool !
Deux fichiers png. Notez les différentes icônes indiquant qu'elles seront ouvertes par différentes applications lors d'un double-clic. Notez également le menu déroulant « Ouvrir avec : » dans lequel l'utilisateur peut sélectionner une application individuelle. Comme c'est simple !
Il semble que beaucoup des astuces et des solutions de contournement nécessaires à AppImage sur Linux, deviennent inutiles sur le haïku, qui possède par essence une simplicité et une sophistication le rendant adapté à la plupart de nos besoins.
Haiku a-t-il besoin de packages d’applications après tout ?
Cela soulève une question importante : si la création d’un système comme AppImage sur Haiku était beaucoup plus simple que sur… LinuxVaudrait-il la peine de poursuivre dans cette voie ? Ou Haiku, avec son système d’empaquetage hpkg, a-t-il rendu une telle idée superflue ? Pour répondre à cette question, il nous faut examiner les motivations qui sous-tendent les AppImages.
Le point de vue de l'utilisateur
Regardons notre utilisateur final :
- Je souhaite installer une application sans demander de mot de passe administrateur (root). Il n'y a pas de concept d'administrateur sur Haiku, l'utilisateur a le contrôle total car il s'agit d'un système personnel ! (En principe, vous pouvez imaginer cela en mode multijoueur, j'espère que les développeurs resteront simples)
- Je souhaite obtenir les dernières et meilleures versions des applications, sans attendre qu'elles apparaissent dans ma distribution (le plus souvent, cela signifie « jamais », du moins à moins que je ne mette à 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 versions les plus récentes et les plus performantes des applications, mais pour ce faire, vous devez constamment mettre à jour le reste du système, le transformant ainsi en une « cible mouvante »..
- Je veux plusieurs versions de la même application côte à côte, car il n'y a aucun moyen de savoir ce qui a été cassé dans la dernière version, ou, disons, en tant que développeur Web, je dois tester mon travail sous différentes versions du navigateur. Le haïku résout le premier problème, mais pas le second. Les mises à jour sont annulées, mais uniquement pour l'ensemble du système ; il est impossible (à ma connaissance) d'exécuter, par exemple, plusieurs versions de WebPositive ou LibreOffice en même temps.
L'un des développeurs écrit :
Essentiellement, la raison est la suivante : le cas d'utilisation est si rare que son optimisation n'a pas de sens ; le traiter comme un cas particulier dans HaikuPorts semble plus qu'acceptable.
- Je dois conserver les applications là où je les aime, pas sur mon disque de démarrage. Je manque souvent d'espace disque, je dois donc 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 lecteur externe, ni comment lancer 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 nous aurons suffisamment d’utilisateurs intéressés.
- 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 est résolu à l'aide de packages
.hpkg, qui transfèrent, par exemple, python, des milliers de fichiers en un seul. Mais s'il y a, par exemple, Scribus utilisant python, alors je dois gérer au moins deux fichiers. Et je dois veiller à en conserver des versions qui fonctionnent les unes avec les autres.
Plusieurs versions d'AppImages fonctionnant côte à côte sur un seul appareil Linux
Le point de vue d'un développeur d'applications
Regardons du point de vue d'un développeur d'applications :
- Je veux contrôler toute l’expérience utilisateur. Je ne veux pas dépendre d'un système d'exploitation pour me dire quand et comment je dois publier des applications. Haiku permet aux développeurs de travailler avec leurs propres référentiels hpkg, mais cela signifie que les utilisateurs devront les configurer manuellement, ce qui rend l'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 LinuxOu peut-être devrais-je monétiser l'accès à cette page ? Tout est possible ? Que devrais-je y mettre pour les haïkus ? Le fichier suffit.hpkgavec des dépendances uniquement de HaikuPorts - Mon logiciel nécessite des versions spécifiques d'autres logiciels. Par exemple, on sait que Krita nécessite une version corrigée de Qt, ou Qt adapté à une version spécifique de Krita, au moins jusqu'à ce que les correctifs soient repoussés dans Qt. Vous pouvez empaqueter votre propre Qt pour votre application dans un package
.hpkg, mais ce n'est probablement pas le bienvenu.
Page de téléchargement d'applications régulières. Que dois-je publier ici pour Haiku ?
Les bundles (existant sous forme de répertoires d'applications comme AppDir ou .app dans le style Apple) et/ou des images (sous forme d'AppImages fortement modifiées ou .dmg d'Apple) sont-elles un complément utile à l'environnement de bureau Haiku ? Ou est-ce que cela va diluer l’ensemble du tableau et conduire à une fragmentation, et donc ajouter de la complexité ? Je suis déchiré : d'une part, la beauté et la sophistication du haïku reposent sur le fait qu'il existe généralement une façon de faire quelque chose, plutôt que plusieurs. D'un autre côté, la majeure partie de l'infrastructure pour les catalogues et/ou les suites d'applications est déjà en place, de sorte que le système demande impérativement que les quelques pour cent restants soient mis en place.
Selon le développeur
Sur Linux elles sont (catalogues et kits d'application, - env. traducteur) constituent très probablement une solution technique à des problèmes systémiques. Chez Haiku, nous préférons simplement résoudre les problèmes du système.
Qu'en pensez vous?
Avant de répondre...
Attendez, faisons un petit rappel à la réalité : en fait répertoires d'applications - fait déjà partie de Haiku :
Les répertoires d'applications existent déjà sur Haiku, mais ne sont pas encore supportés dans le gestionnaire de fichiers
Ils ne sont tout simplement pas aussi bien pris en charge que, par exemple, le Finder Macintosh. Ce serait cool si le répertoire QtCreator avait un nom et une icône « QtCreator » dans le coin supérieur gauche, lançant l'application en double-cliquant ?
Un peu plus tôt, j'ai déjà :
Êtes-vous sûr de pouvoir exécuter vos applications vieilles de dix ans aujourd'hui alors que tous les magasins d'applications et référentiels de distribution les ont oubliés ainsi que leurs dépendances ? Êtes-vous convaincu que vous pourrez toujours accéder à votre emploi actuel à l’avenir ?
Existe-t-il déjà une réponse de Haiku, ou les catalogues et les packages d'applications peuvent-ils être utiles ici ? Je pense qu'ils le peuvent.
Selon M. dandinement :
Oui, nous avons la réponse à la question : nous prendrons simplement en charge ces applications aussi longtemps que nécessaire jusqu'à ce que quelqu'un puisse lire correctement leurs formats de fichiers ou fournir des fonctionnalités individuelles. Notre engagement à prendre en charge les applications BeOS R5 sur Haiku en est la preuve...
C'est vrai!
Quelle ligne d’action Haiku devrait-il adopter ?
J'imagine la coexistence paisible de hpkg, des répertoires et des images d'application :
- Utilisations du logiciel système
.hpkg - Pour les logiciels les plus fréquemment utilisés (en particulier ceux qui nécessitent de planifier des versions glissantes), utilisez
.hpkg(environ 80 % de tous les cas) - Certains installés via
.hpkg, les applications bénéficieront du passage à une infrastructure d'annuaire d'applications (par exemple QtCreator) : elles seront distribuées sous forme de.hpkg, comme avant.
M. waddlesplash écrit :
Si tout ce dont vous avez besoin est de visualiser les applications dans
/system/apps, nous devrions plutôt rendre les répertoires de la Deskbar plus faciles à gérer pour les utilisateurs, car/system/appsn'est pas destiné à être ouvert et consulté régulièrement par les utilisateurs (contrairement à MacOS). Pour de telles situations, le haïku a un paradigme différent, mais cette option est, en théorie, acceptable.
- Haiku reçoit l'infrastructure pour exécuter des images d'applications, des builds nocturnes, continus et de test de logiciels, ainsi que pour les cas où l'utilisateur souhaite les « geler dans le temps », pour les logiciels privés et internes, et d'autres cas d'utilisation spéciaux (environ 20 % de tout). Ces images contiennent les fichiers nécessaires à l'exécution de l'application
.hpkg, monté par le système, et une fois l'application terminée - démonté. (Peut-être qu'un gestionnaire de fichiers pourrait mettre les fichiers.hpkgdans les images d'application, automatiquement ou à la demande de l'utilisateur - enfin, comme lorsque vous faites glisser une application vers un répertoire réseau ou un lecteur externe. C'est juste une chanson! Ou plutôt poésie - haïku.) En revanche, l'utilisateur peut vouloir installer le contenu de l'image sous forme de fichiers.hpkg, après quoi ils seront mis à jour et traités de la même manière que s'ils avaient été installés via HaikuDepot... Nous devons réfléchir).
Citation de M. dandinement :
L'exécution d'applications à partir de disques externes ou de répertoires réseau peut potentiellement être utile. Et ajouter la possibilité de configurer plus de « zones » pour pkgman serait certainement une fonctionnalité intéressante.
Un tel système tirerait parti de hpkg, des répertoires et des images d'application. Ils sont bons individuellement, mais ensemble, ils deviendront invincibles.
Conclusion
Haiku dispose d'une infrastructure offrant une interface utilisateur simple et sophistiquée pour PC, et va bien au-delà de ce qui est généralement proposé pour les PC sur LinuxSystème d'emballage .hpkg Haiku en est un exemple, mais d'autres parties du système sont également très sophistiquées. Cependant, Haiku gagnerait à bénéficier d'une prise en charge adéquate des catalogues d'applications et des images. La meilleure façon de procéder mérite d'être discutée 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. Néanmoins, je pense que ce regard neuf sera utile aux concepteurs, développeurs et architectes de Haiku. À tout le moins, je serais ravi de leur apporter mon expertise. J'ai plus de 10 ans d'expérience pratique dans la gestion des catalogues d'applications et des ensembles d'images. Linuxet j'aimerais leur trouver une utilité dans Haiku, pour lequel je pense qu'ils sont parfaitement adaptés. Les solutions potentielles que j'ai proposées ne sont pas les seules aux problèmes que j'ai décrits, et si l'équipe Haiku décide d'en trouver d'autres, plus élégantes, je suis tout à fait d'accord. En principe, je réfléchis déjà à une idée pour la mise en place du système. hpkg encore plus étonnant sans changer son fonctionnement. Il s'avère que l'équipe Haiku réfléchissait depuis longtemps aux bundles d'applications lors de la mise en œuvre d'un système de gestion de packages, mais malheureusement (je pense) l'idée est devenue "obsolète". Il est peut-être temps de le relancer ?
Essayez-le vous-même ! Après tout, le projet Haiku fournit des images pour démarrer à partir d'un DVD ou d'une clé USB, générées .
Avez-vous des questions? Nous vous invitons à la langue russe .
Aperçu des erreurs :
À partir de traduction : ceci est le huitième et dernier article de la série sur le haïku.
Liste des articles :
Seuls les utilisateurs enregistrés peuvent participer à l'enquête. s'il te plait.
Est-il judicieux de porter le système hpkg pour Linux?
Oui
Non
Déjà implémenté, j'écrirai dans les commentaires
20 utilisateurs ont voté. 5 utilisateurs se sont abstenus.
Source: habr.com
