Par contre tu dis d'un coté que l'intérêt c'est qu'il n'y a qu'une seule équipe pour tout et de l'autre que tu aimerais voir des projets se lancer sur haiku, ça ne me semble pas aller ensemble.
Oui, c'est compliqué.
Cela dit, actuellement il y a de nombreux projets qui sont maintenus par les même développeurs que l'OS. En fait c'est plutôt l'inverse: des gens commencent par développer une application, trouvent des bugs dans l'OS qui les empêchent d'avancer, et finissent par se retrouver contributeurs sur le système.
Souvent, les applications adoptent les conventions de nommage et de formatage de code de Haiku, ainsi que les conventions d'interface graphique. Je pense qu'on retrouve un peu la même chose dans un projet comme GNOME ou KDE, sauf qu'il y a une frontière par exemple entre GNOME-GTK-applications et les couches plus basses (libc, noyau). Pas infranchissable, mais compliquée, en particulier parce qu'il y a plusieurs implémentations de la libc (glibc, musl, bsd, ...) et du noyau (Linux, BSD, ...). En conséquence, utiliser une fonctionnalité nécessite qu'elle soit disponible dans toutes les implémentations, et finalement on doit se contenter de ce qui est commun entre tous les systèmes.
Dans Haiku, il n'y a pas de frontière de ce type. Si on a besoin de rajouter quelque chose dans le noyau ou dans la libc, on peut le faire directement.
Il n'y a pas non plus la frontière entre la distribution Linux et les paquets qui sont intégrés dedans. Donc, gestion commune des sorties de nouvelles versions, par exemple. Ce qui facilite la maintenance.
D'un autre côté, on a maintenant plein d'applications basées sur Qt, et on retrouve là un certains nombre de problèmes qu'il y a sous Linux. Mais actuellement c'est compliqué d'utiliser Haiku sans ces applications, car il n'y a pas beaucoup d'applications natives. Ce qui demande donc de faire un compromis. Faut-il essayer d'améliorer ces applications Qt, ou bien plutôt écrire des applications natives? Le deuxième choix est probablement meilleur à long terme, mais pas à court terme. Et si le système n'est pas utilisable à court terme, les développeurs de Haiku ne vont pas pouvoir l'utiliser, et ils vont être moins motivés pour contribuer et développer de nouvelles applications.
[^] # Re: Question bête...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku embauche un développeur à (presque) plein temps. Évalué à 4.
Oui, c'est compliqué.
Cela dit, actuellement il y a de nombreux projets qui sont maintenus par les même développeurs que l'OS. En fait c'est plutôt l'inverse: des gens commencent par développer une application, trouvent des bugs dans l'OS qui les empêchent d'avancer, et finissent par se retrouver contributeurs sur le système.
Souvent, les applications adoptent les conventions de nommage et de formatage de code de Haiku, ainsi que les conventions d'interface graphique. Je pense qu'on retrouve un peu la même chose dans un projet comme GNOME ou KDE, sauf qu'il y a une frontière par exemple entre GNOME-GTK-applications et les couches plus basses (libc, noyau). Pas infranchissable, mais compliquée, en particulier parce qu'il y a plusieurs implémentations de la libc (glibc, musl, bsd, ...) et du noyau (Linux, BSD, ...). En conséquence, utiliser une fonctionnalité nécessite qu'elle soit disponible dans toutes les implémentations, et finalement on doit se contenter de ce qui est commun entre tous les systèmes.
Dans Haiku, il n'y a pas de frontière de ce type. Si on a besoin de rajouter quelque chose dans le noyau ou dans la libc, on peut le faire directement.
Il n'y a pas non plus la frontière entre la distribution Linux et les paquets qui sont intégrés dedans. Donc, gestion commune des sorties de nouvelles versions, par exemple. Ce qui facilite la maintenance.
D'un autre côté, on a maintenant plein d'applications basées sur Qt, et on retrouve là un certains nombre de problèmes qu'il y a sous Linux. Mais actuellement c'est compliqué d'utiliser Haiku sans ces applications, car il n'y a pas beaucoup d'applications natives. Ce qui demande donc de faire un compromis. Faut-il essayer d'améliorer ces applications Qt, ou bien plutôt écrire des applications natives? Le deuxième choix est probablement meilleur à long terme, mais pas à court terme. Et si le système n'est pas utilisable à court terme, les développeurs de Haiku ne vont pas pouvoir l'utiliser, et ils vont être moins motivés pour contribuer et développer de nouvelles applications.