Quelques rectifications par rapport à l'article :
- "rachat de Be par Palm" : pas tout à fait, Palm a racheté la propriété intellectuelle de Be, pas la société elle-même.
- "la couche réseau est celle que Be était en train de développer" : pas exactement, BONE est toujours fermé. Mais en effet la couche réseau de Haiku lui est similaire (modulaire et dans le noyau) contrairement à BeOS R5 qui utilisait "net_server" dans l'espace utilisateur, connu pour être buggué et lent, pas tellement parce que tournant en mode utilisateur mais surtout parce qu'écrit en une semaine.
- "une API claire pour ajouter de nouveaux CODEC" : En effet, l'interface pour les codecs n'a jamais été documenté par Be, malgré les promesses, un peu dommage pour le "Media OS".
- le noyau est un fork de NewOS, mais il a bien changé depuis.
- BeOS était en effet en avance sur son temps, et a encore de l'avance sur certains domaines. C'est incroyable le nombre de choses qui ont été copié... même si ça n'est pas toujours BeOS qui les a inauguré il les a mise à la porté du grand public. Le support SMP, la préemption dans le noyau, les attributs étendus (en moins bien), un devfs hiérarchique, des modules noyau hiérarchisés et chargés automatiquement (enfin presque), le tick-less kernel (si, ça existait bien avant cette année !) sont autant de choses que Linux n'a que depuis peu. Les WinFS, Beagle, Spotlight n'existaient pas il y a peu. Les frameworks multimédias explosent en ce moment (GStreamer...) pourtant il n'y a pas tant de nouveautés que ça.
En parlant des LiveCD, tout le monde prétent avoir inventé le concept, pourtant les CDs d'installation de BeOS sont tous Live, il suffit de relancer le bureau (Ctrl-Alt-Del, Relaunch desktop). La gestion des types mime est un vrai bonheur. Il n'y a pas de raison de laisser l'utilisateur chercher l'appli si le système sait le faire. Des choses très simples comme le 'X-ray nav', la navigation depuis le menu contextuel semblent si évites qu'on peste dès qu'on se retrouve ailleurs sans elles. BeOS utilisait beaucoup des plugins, les rendant publics pour d'autres applications (reuse), et pouvait inclure une application dans une autre bien avant les ActiveX et autres, même si cela n'a jamais été suffisamment exploité.
Sur le multi-threading, avoir un thread par fenetre c'est tellement mieux. Un peu plus compliqué certes. Il faut utiliser des mutex et autres bénaphores. Mais c'est transparent dans une certaine mesure, en utilisant les BMessages, conteneur bien plus flexibles que ce qu'utilise GTK pour les évènements. Par exemple pour supporter les roulettes des souris ou la pression des tablettes graphiques aucun besoin de rajouter un membre à la structure et la rendre incompatible, l'addon (ici encore) de l'input_server ajoute un membre "wheel_x" et y... de type float. C'est bien pratique d'avoir le typage des données sans devoir connaitre sa signification. On peut les manipuler quand même un minimum. C'est pareil pour les attributs étendus du fs. Ils ont un type, ce qui permet (sauf une minorité de structures binaires) de les afficher et modifier (par script ou utilisateur) sans connaitre l'application qui l'utilise.
Les interfaces de scripting étaient également présentes depuis le début, mais également sous-utilisées.
Je pense parfois que si Be avait bréveté tout ça on serait bien dans la merde, y compris Microsoft :D
Sur OS/2, c'est vrai qu'OS/2 avait un certain nombre d'intéret, y compris les attributs étendus sur HPFS. Visiblement ça et le poids d'IBM n'a pas suffit à l'imposer non plus.
Oulala mais j'ai de quoi faire un livre, j'ai surement oublié des choses.
Pour revenir à Haiku, il reste beaucoup de bugs, y compris des sérieux dans la VM, mais ça fait du bien de le voir booter :)
# Précisions
Posté par Francois Revol (site web personnel) . En réponse à la dépêche Haïku fête ses 5 ans. Évalué à 10.
- "rachat de Be par Palm" : pas tout à fait, Palm a racheté la propriété intellectuelle de Be, pas la société elle-même.
- "la couche réseau est celle que Be était en train de développer" : pas exactement, BONE est toujours fermé. Mais en effet la couche réseau de Haiku lui est similaire (modulaire et dans le noyau) contrairement à BeOS R5 qui utilisait "net_server" dans l'espace utilisateur, connu pour être buggué et lent, pas tellement parce que tournant en mode utilisateur mais surtout parce qu'écrit en une semaine.
- "une API claire pour ajouter de nouveaux CODEC" : En effet, l'interface pour les codecs n'a jamais été documenté par Be, malgré les promesses, un peu dommage pour le "Media OS".
- le noyau est un fork de NewOS, mais il a bien changé depuis.
- BeOS était en effet en avance sur son temps, et a encore de l'avance sur certains domaines. C'est incroyable le nombre de choses qui ont été copié... même si ça n'est pas toujours BeOS qui les a inauguré il les a mise à la porté du grand public. Le support SMP, la préemption dans le noyau, les attributs étendus (en moins bien), un devfs hiérarchique, des modules noyau hiérarchisés et chargés automatiquement (enfin presque), le tick-less kernel (si, ça existait bien avant cette année !) sont autant de choses que Linux n'a que depuis peu. Les WinFS, Beagle, Spotlight n'existaient pas il y a peu. Les frameworks multimédias explosent en ce moment (GStreamer...) pourtant il n'y a pas tant de nouveautés que ça.
En parlant des LiveCD, tout le monde prétent avoir inventé le concept, pourtant les CDs d'installation de BeOS sont tous Live, il suffit de relancer le bureau (Ctrl-Alt-Del, Relaunch desktop). La gestion des types mime est un vrai bonheur. Il n'y a pas de raison de laisser l'utilisateur chercher l'appli si le système sait le faire. Des choses très simples comme le 'X-ray nav', la navigation depuis le menu contextuel semblent si évites qu'on peste dès qu'on se retrouve ailleurs sans elles. BeOS utilisait beaucoup des plugins, les rendant publics pour d'autres applications (reuse), et pouvait inclure une application dans une autre bien avant les ActiveX et autres, même si cela n'a jamais été suffisamment exploité.
Sur le multi-threading, avoir un thread par fenetre c'est tellement mieux. Un peu plus compliqué certes. Il faut utiliser des mutex et autres bénaphores. Mais c'est transparent dans une certaine mesure, en utilisant les BMessages, conteneur bien plus flexibles que ce qu'utilise GTK pour les évènements. Par exemple pour supporter les roulettes des souris ou la pression des tablettes graphiques aucun besoin de rajouter un membre à la structure et la rendre incompatible, l'addon (ici encore) de l'input_server ajoute un membre "wheel_x" et y... de type float. C'est bien pratique d'avoir le typage des données sans devoir connaitre sa signification. On peut les manipuler quand même un minimum. C'est pareil pour les attributs étendus du fs. Ils ont un type, ce qui permet (sauf une minorité de structures binaires) de les afficher et modifier (par script ou utilisateur) sans connaitre l'application qui l'utilise.
Les interfaces de scripting étaient également présentes depuis le début, mais également sous-utilisées.
Je pense parfois que si Be avait bréveté tout ça on serait bien dans la merde, y compris Microsoft :D
Sur OS/2, c'est vrai qu'OS/2 avait un certain nombre d'intéret, y compris les attributs étendus sur HPFS. Visiblement ça et le poids d'IBM n'a pas suffit à l'imposer non plus.
Oulala mais j'ai de quoi faire un livre, j'ai surement oublié des choses.
Pour revenir à Haiku, il reste beaucoup de bugs, y compris des sérieux dans la VM, mais ça fait du bien de le voir booter :)