Autre chose : les bundles d'applications Haiku ?

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 des images d'applications (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.

Il y a une semaine 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 bien comprendre, je suis le créateur et l'auteur d'AppImage, un format de distribution d'applications Linux qui vise la simplicité Mac et donne un contrôle total aux auteurs d'applications et aux utilisateurs finaux (si vous voulez en savoir plus, voir wiki и documentation).

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 AppImage, ou quelque chose de similaire, sur Haiku ? Il n'est pas nécessaire de créer quelque chose maintenant, car le système qui existe déjà dans Haiku fonctionne à merveille, mais une expérience imaginaire serait bien. Cela 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 me bats avec le débogage depuis 10 ans).

Sur le 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 sous Linux.

Tout d’abord, qu’est-ce qu’une AppImage ? Il s'agit d'un système de publication d'applications tierces (par exemple, Ultimaker Cura), 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.

Au cours de plus de 10 ans d'existence, AppImage a gagné en attrait et en popularité : Linus Torvalds lui-même l'a publiquement soutenu, et des projets courants (par exemple, LibreOffice, Krita, Inkscape, Scribus, ImageMagick) l'ont adopté comme moyen principal. pour distribuer des builds continus ou nocturnes, sans interférer avec les applications utilisateur installées ou désinstallées. Cependant, les environnements de bureau et les distributions Linux s'accrochent encore le plus souvent au modèle de distribution traditionnel et centralisé basé sur le mainteneur et/ou promeuvent leurs propres programmes d'entreprise et/ou d'ingénierie basés sur Flatpak (RedHat, Fedora, GNOME) et brusque (Canonique, Ubuntu). Ça arrive ridiculement.

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 CourgeFS.

• Le système de fichiers SquashFS contient la charge utile de l'application et tout ce qui est nécessaire pour l'exécuter, ce qui, dans un esprit sain, ne peut pas être considéré comme faisant partie de l'installation par défaut de tout système cible assez récent (distribution Linux). Il 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, rien de « sensé » ne peut être considéré comme « faisant partie de l’installation par défaut de chaque nouveau système cible ». Nous contournons ce problème en construisant liste d'exclusion, 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 exporter LD_LIBRARY_PATH, ou réparer rpath afin 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 définir le bit exécutable Fichier AppImage après le téléchargement. Croyez-le ou non, cela constitue un véritable obstacle pour certains. La nécessité de définir le bit d'exécutabilité est fastidieuse, même pour les utilisateurs expérimentés. Pour contourner le problème, nous avons suggéré d'installer un petit service qui surveille les fichiers AppImage et définit leur bit d'exécutabilité. Dans sa forme pure, ce n'est pas la meilleure solution, car elle ne fonctionnera pas immédiatement. Les distributions Linux ne fournissent pas ce service, les utilisateurs ont donc une mauvaise expérience dès le départ.
• Les utilisateurs de Linux s'attendent à ce qu'une nouvelle application ait une icône dans le menu de démarrage. 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 au bon endroit dans /usr pour une installation à l'échelle du système, ou dans $HOME pour particulier. Les icônes de certaines tailles, selon la spécification XDG, doivent être placées à certains endroits dans usr ou $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.
• Si ce qui précède ne suffit pas, il n'y a toujours pas d'icône AppImage dans le gestionnaire de fichiers. Le monde Linux n'a pas encore décidé d'implémenter elficon (malgré discussion и mise en oeuvre), 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 avis 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.png doit être ouvert en utilisant Krita, et 2.png - en utilisant GIMP.

Emplacement de stockage pour les spécifications multi-ordinateurs utilisées dans GNOME, KDE и Xfce 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. XDG de freedesktop.org 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 que le monde Linux pourrait apprendre de Mac OS X pour éviter de gâcher l'intégration du système. Si vous avez le temps et que vous êtes intéressé, assurez-vous de lire ce qu'Arnaud Gurdol, l'un des premiers ingénieurs de Mac OS X, a déclaré :

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é.

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

Il n'y a rien de tel que cette infrastructure sur les postes de travail Linux, nous recherchons donc des solutions de contournement autour des limitations structurelles du projet AppImage.

Haïku vient-il à la rescousse ?

Et encore une chose : les plates-formes Linux en tant que base des environnements de bureau ont tendance à être tellement sous-spécifiées que de nombreuses choses qui sont assez simples dans un système full-stack cohérent sont frustrantes et complexes sous Linux. J'ai consacré un rapport entier aux problèmes liés à la plate-forme Linux pour les environnements de bureau (des développeurs avertis ont confirmé que tout restera ainsi pendant très longtemps).

Mon rapport sur les problèmes des environnements de bureau Linux en 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

Alors que l'approche naïve du "portage" d'AppImage sur Haiku consiste simplement à essayer de construire (principalement runtime.c et le 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 sont résolus dans le haïku et sont conceptuellement solides. Haiku fournit exactement les éléments constitutifs de l'infrastructure système que je recherchais depuis si longtemps dans les environnements de bureau Linux et que je ne pouvais pas croire qu'ils n'étaient pas là. À savoir:

Croyez-le ou non, c'est quelque chose que de nombreux utilisateurs de Linux ne peuvent pas surmonter. Sur 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 de nombreuses béquilles et solutions de contournement requises par AppImage sous Linux deviennent inutiles sur Haiku, qui possède à la base la simplicité et la sophistication qui lui permettent de répondre à la plupart de nos besoins.

Haiku a-t-il besoin de packages d’applications après tout ?

Cela nous amène à une grande question. S'il était beaucoup 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 packages hpkg, a-t-il effectivement éliminé le besoin de développer une telle idée ? Eh bien, pour répondre, nous devons examiner la motivation derrière l'existence d'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 le même 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 .exe Pour les fenêtres, .dmg pour Mac et .AppImage pour Linux. Ou peut-être que je souhaite monétiser l'accès à cette page, tout est possible ? Que dois-je y mettre pour le haïku ? Le fichier suffit .hpkg avec 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 M. dandinement

Sous Linux, ils (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à demandé:

Ê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/apps n'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 .hpkg dans 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'un cadre qui offre une expérience utilisateur simple et sophistiquée pour le PC, et va bien au-delà de ce qui est généralement fourni pour le PC Linux. Système de paquet .hpkg en est un exemple, mais le reste du système est également empreint de sophistication. Cependant, Haiku bénéficierait d’une prise en charge appropriée des répertoires et des images d’application. La meilleure façon de procéder mérite d'être discutée avec des personnes qui connaissent bien mieux que moi le haïku, sa philosophie et son architecture. Après tout, j'utilise Haiku depuis un peu plus d'une semaine. Néanmoins, je crois que les concepteurs, développeurs et architectes de Haiku bénéficieront de cette nouvelle perspective. À tout le moins, je serais heureux d’être leur « sparring-partenaire ». J'ai plus de 10 ans d'expérience pratique avec les catalogues et bundles d'applications Linux, et j'aimerais leur trouver une utilisation dans Haiku, pour lequel je pense qu'ils conviennent parfaitement. Les solutions potentielles que j'ai proposées ne sont en aucun cas les seules correctes 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 gros, je réfléchis déjà à l'idée de comment faire un 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 tous les jours.
Avez-vous des questions? Nous vous invitons à la langue russe canal de télégramme.

Aperçu des erreurs : Comment se tirer une balle dans le pied en C et C++. Collection de recettes Haiku OS

À partir de l'auteur traduction : ceci est le huitième et dernier article de la série sur le haïku.

Liste des articles : première La seconde Третья Quatrième cinquième Sixième Septième

Seuls les utilisateurs enregistrés peuvent participer à l'enquête. se connecters'il te plait.

Est-il judicieux de porter le système hpkg sous Linux ?

• Oui

• Aucun

• Déjà implémenté, j'écrirai dans les commentaires

20 utilisateurs ont voté. 5 utilisateurs se sont abstenus.

Source: habr.com