Voilà à quoi va ressembler le main() de la plupart des applications pour Haiku.
Qui ressemble aussi à un code typique d'une application Qt ou GTK+. Ce n'est pas si original que cela.
Sinon bon, je trouve qu'il est assez délicat de comparer Haiku avec d'autres systèmes d'exploitations étant donné que c'est, dans l'ensemble, un système plus léger avec des applications qui sont elles aussi souvent plus légères. Il faudrait pouvoir comparer à fonctionnalité équivalente pour que cela fasse sens. Avec des applications vraiment lourdes (typiquement Firefox).
Car bon, moi aussi je peux faire mon noyau qui ne fait pas grand chose et que j'optimise à fond pour un processeur donné et je poutre Haiku et Linux pour lancer mon éditeur de texte maison. J'exagère le trait, Haiku n'est pas un petit OS non plus, il y a de quoi travailler et tant mieux.
Mais beaucoup de choses manquent et les applications (des tests que j'ai fait) sont souvent aussi plus simples que ceux sous Linux moderne (ce qui est fourni par GNOME, KDE ou Xfce en somme) du coup cela ne me semble pas délirant que Haiku soit plus rapide car la comparaison est biaisée. Ce n'est pas dit que ce soit dû à son architecture (et le peu qui est mis en avant ici est souvent reproduit par les autres systèmes depuis ou a un impact en réalité négligeable sur d'autres considérations).
Après je conviens que Haiku a un choix architectural qui simplifie l'écriture d'applications avec son API, c'est bien, mais globalement Qt et GTK+ font la même chose depuis quelque temps (le monde a évolué depuis BeOS et se sont inspirés de lui). La question de savoir si pour l'utilisateur c'est mieux d'afficher une fenêtre vide qui se rempli ou d'envoyer le tout quand c'est fini reste une question d'implémentation. Et à fonctionnalité constante système + applicatif, j'émets des doutes sur la réelle vitesse d'exécution de Haiku par rapport à d'autres systèmes.
[^] # Re: Réécrire l'histoire
Posté par Renault (site web personnel) . En réponse à la dépêche Haiku a 16 ans. Évalué à 3.
Qui ressemble aussi à un code typique d'une application Qt ou GTK+. Ce n'est pas si original que cela.
Sinon bon, je trouve qu'il est assez délicat de comparer Haiku avec d'autres systèmes d'exploitations étant donné que c'est, dans l'ensemble, un système plus léger avec des applications qui sont elles aussi souvent plus légères. Il faudrait pouvoir comparer à fonctionnalité équivalente pour que cela fasse sens. Avec des applications vraiment lourdes (typiquement Firefox).
Car bon, moi aussi je peux faire mon noyau qui ne fait pas grand chose et que j'optimise à fond pour un processeur donné et je poutre Haiku et Linux pour lancer mon éditeur de texte maison. J'exagère le trait, Haiku n'est pas un petit OS non plus, il y a de quoi travailler et tant mieux.
Mais beaucoup de choses manquent et les applications (des tests que j'ai fait) sont souvent aussi plus simples que ceux sous Linux moderne (ce qui est fourni par GNOME, KDE ou Xfce en somme) du coup cela ne me semble pas délirant que Haiku soit plus rapide car la comparaison est biaisée. Ce n'est pas dit que ce soit dû à son architecture (et le peu qui est mis en avant ici est souvent reproduit par les autres systèmes depuis ou a un impact en réalité négligeable sur d'autres considérations).
Après je conviens que Haiku a un choix architectural qui simplifie l'écriture d'applications avec son API, c'est bien, mais globalement Qt et GTK+ font la même chose depuis quelque temps (le monde a évolué depuis BeOS et se sont inspirés de lui). La question de savoir si pour l'utilisateur c'est mieux d'afficher une fenêtre vide qui se rempli ou d'envoyer le tout quand c'est fini reste une question d'implémentation. Et à fonctionnalité constante système + applicatif, j'émets des doutes sur la réelle vitesse d'exécution de Haiku par rapport à d'autres systèmes.