Je vais répondre en reprenant la description présente sur le site de Haiku:
Haiku is an open-source operating system that specifically targets personal computing. Inspired by the BeOS, Haiku is fast, simple to use, easy to learn and yet very powerful.
L'objectif est donc de fournir un système open source, taillé spécialement pour l'informatique personelle (on entend par là: pas les smartphones, pas l'embarqué, et pas les serveurs). On le voudrait rapide, simple à utiliser et à apprendre, mais cependant puissant (que je traduirait plutôt par flexible).
Un certains nombres de contributeurs à Haiku ne croient pas à "Linux sur le Desktop". Les contraintes sont différentes entre un système embarqué, un serveur, et un PC de bureau, et il nous semble difficile d'arriver à répondre à tous ces besoins à la fois de façon optimale. L'adaptabilité d'un système GNU/Linux à tous ces marchés le force à faire des compromis pour aller plus dans un sens que dans un autre. Et actuellement, on a avec Android des gens qui poussent le support des smartphones, et avec RedHat des gens qui poussent plutôt le côté serveurs. Il y a Ubuntu qui essaie de s'attaquer au segment du desktop, mais je ne sais pas si ça durera encore longtemps. Visiblement leur succès n'a pas été aussi grand qu'attendu.
Il y a donc toujours une place pour un système libre sur ce marché.
Maintenant, la question qui fache, c'est comment on s'y prend pour arriver à prendre cette place avec Haiku. On va avoir besoin de faire évoluer encore plein de choses. Certaines ne posent pas vraiment question, par exemple, il va falloir mettre des efforts sur l'accélération 3D, un meilleur support des imprimantes, améliorer encore le port de LibreOffice. Mais à un peu plus long terme, on a un gros travail à faire pour prendre des décisions importantes pour la version "R2" de Haiku. Quelques exemples: doit-on remplacer les APIs de BeOS par celles de Qt (éventuellement avec quelques extensions)? Combien de temps va-t-on encore s'embêter à maintenir une version à base de gcc2 pour faire fonctionner les applications BeOS? Comment procèdera-t-on pour faire une transition en douceur? Jusqu'à quel point doit-on assurer la maintenance des vieilles applications BeOS? Doit-on conserver le système de fichiers BFS, essayer d'utiliser un système concurrent (par exemple ZFS, XFS ou btrfs), ou bien doit-on développer notre propre système de fichiers pour conserver les particularités de BFS (en particulier l'indexation des attributs étendus)? Jusqu'à quel point doit-on encourager le portage et l'intégration d'applications Qt et est-ce qu'il ne vaudrait pas mieux pousser les gens à écrire des applicatons natives?
Pour l'instant, ces sujets n'ont pas vraiment été abordés. La priorité est d'arriver à faire une version R1, et ensuite de voir si on arrive à construire un écosystème d'applications autour de notre OS. Si vous avez déjà vu ce qu'on démontre sur notre stand, il y a beaucoup d'idées intéressantes (gérer les mails ou une collection de medias avec des attributs étendus, par exemple), mais souvent on fait ça sous forme de démo bricolée avec le navigateur de fichier. La technologies est là mais ça manque souvent d'une interface utilisateur vraiment bien pensée, et au final personne n'utilise vraiment toutes ces belles fonctions. Je pense que le gros du travail va se trouver là dans les années à venir. Et une fois qu'on aura plein d'applications modernes, on aura un peu plus de recul sur les évolutions à apporter à l'API (même si on a déjà quelques idées).
Voilà, c'est ma vision des choses. Cependant j'en ai pas forcément beaucoup discuté avec tous les autres contributeurs du projet, et nous n'avons donc pas forcément fait converger nos idées sur ces différents points, pour l'instant.
[^] # Re: Avenir de Haiku
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 17 ans. Évalué à 10.
Je vais répondre en reprenant la description présente sur le site de Haiku:
L'objectif est donc de fournir un système open source, taillé spécialement pour l'informatique personelle (on entend par là: pas les smartphones, pas l'embarqué, et pas les serveurs). On le voudrait rapide, simple à utiliser et à apprendre, mais cependant puissant (que je traduirait plutôt par flexible).
Un certains nombres de contributeurs à Haiku ne croient pas à "Linux sur le Desktop". Les contraintes sont différentes entre un système embarqué, un serveur, et un PC de bureau, et il nous semble difficile d'arriver à répondre à tous ces besoins à la fois de façon optimale. L'adaptabilité d'un système GNU/Linux à tous ces marchés le force à faire des compromis pour aller plus dans un sens que dans un autre. Et actuellement, on a avec Android des gens qui poussent le support des smartphones, et avec RedHat des gens qui poussent plutôt le côté serveurs. Il y a Ubuntu qui essaie de s'attaquer au segment du desktop, mais je ne sais pas si ça durera encore longtemps. Visiblement leur succès n'a pas été aussi grand qu'attendu.
Il y a donc toujours une place pour un système libre sur ce marché.
Maintenant, la question qui fache, c'est comment on s'y prend pour arriver à prendre cette place avec Haiku. On va avoir besoin de faire évoluer encore plein de choses. Certaines ne posent pas vraiment question, par exemple, il va falloir mettre des efforts sur l'accélération 3D, un meilleur support des imprimantes, améliorer encore le port de LibreOffice. Mais à un peu plus long terme, on a un gros travail à faire pour prendre des décisions importantes pour la version "R2" de Haiku. Quelques exemples: doit-on remplacer les APIs de BeOS par celles de Qt (éventuellement avec quelques extensions)? Combien de temps va-t-on encore s'embêter à maintenir une version à base de gcc2 pour faire fonctionner les applications BeOS? Comment procèdera-t-on pour faire une transition en douceur? Jusqu'à quel point doit-on assurer la maintenance des vieilles applications BeOS? Doit-on conserver le système de fichiers BFS, essayer d'utiliser un système concurrent (par exemple ZFS, XFS ou btrfs), ou bien doit-on développer notre propre système de fichiers pour conserver les particularités de BFS (en particulier l'indexation des attributs étendus)? Jusqu'à quel point doit-on encourager le portage et l'intégration d'applications Qt et est-ce qu'il ne vaudrait pas mieux pousser les gens à écrire des applicatons natives?
Pour l'instant, ces sujets n'ont pas vraiment été abordés. La priorité est d'arriver à faire une version R1, et ensuite de voir si on arrive à construire un écosystème d'applications autour de notre OS. Si vous avez déjà vu ce qu'on démontre sur notre stand, il y a beaucoup d'idées intéressantes (gérer les mails ou une collection de medias avec des attributs étendus, par exemple), mais souvent on fait ça sous forme de démo bricolée avec le navigateur de fichier. La technologies est là mais ça manque souvent d'une interface utilisateur vraiment bien pensée, et au final personne n'utilise vraiment toutes ces belles fonctions. Je pense que le gros du travail va se trouver là dans les années à venir. Et une fois qu'on aura plein d'applications modernes, on aura un peu plus de recul sur les évolutions à apporter à l'API (même si on a déjà quelques idées).
Voilà, c'est ma vision des choses. Cependant j'en ai pas forcément beaucoup discuté avec tous les autres contributeurs du projet, et nous n'avons donc pas forcément fait converger nos idées sur ces différents points, pour l'instant.