Haïku fête ses 5 ans

Posté par  . Modéré par Florent Zara.
Étiquettes :
0
22
août
2006
Communauté
Le système d'exploitation libre Haïku, anciennement OpenBeOS, fête ses cinq ans. C'est le projet le plus complexe parmi ceux ayant pour objectif de fournir une version libre de BeOS, système d'exploitation très apprécié par certains et en avance sur son temps.

Aujourd'hui, Haïku peut démarrer et est relativement stable pour une version de développement. Les principaux travaux chantiers actuels sont la couche réseau et la pile USB.

Le projet Haïku utilise la licence MIT qui est semblable à la BSD.

BeOS était un système d'exploitation propriétaire développé par Be. Ce système était connu pour sa réactivité, sa légèreté et son API objet en C++ très simple à utiliser. Suite au rachat de Be par Palm, le développement de BeOS fut stoppé, mais rapidement, des groupes se sont formés visant à recréer BeOS. Certains avaient des approches jugées comme pragmatiques, en se basant sur un noyau solide, plutôt que de repartir de zéro. C'est ainsi que des projets ont vu le jour avec pour objectif de porter l'API et l'apparence de BeOS sur des noyau BSD ou Linux. Mais ces projets sont aujourd'hui à l'abandon, le seul qui reste est Haïku, qui est de loin le plus ambitieux.

Son objectif est de fournir une version R1 presque identique à la dernière version distribuée par Be, en redéveloppant tout de zéro. Le "presque à l'identique" signifie que bien que la compatibilité binaire soit assurée (un exécutable BeOS tourne sans problème sous Haïku), il y a tout de même quelques différences :
  • la couche réseau est celle que Be était en train de développer, fournissant des services identiques à ceux proposés par Linux ou les BSD
  • une pile USB prenant en charge les dernières version de la norme
  • une API claire pour ajouter de nouveaux CODEC

Pour tester sans devoir l'installer, vous pouvez utiliser QEMU avec les images fournies par l'équipe d'Haïku.

Aller plus loin

  • # question

    Posté par  (site web personnel, Mastodon) . Évalué à 6.

    "BeOS, système d'exploitation très apprécié par certains et en avance sur son temps."

    En avance il y a 10 ans. Si Haïku réussit à sortir une version parfaitement identique au dernier BeOS, comment cela va-t-il supporter la comparaison avec les Linux/Windows/MacOSX de maintenant ?

    aussi, n'ayant jamais utilisé beos, j'ai souvent entendu qu'il était révolutionnaire mais je n'ai jamais trouvé "pourquoi". Quels sont les avantages de BeOS et qu'ai-je à gagner à utiliser Haïku plutôt que Linux ?

    Ce sont des questions sincères, je ne cherche pas à critiquer le travail de l'équipe. Ils font ce qu'ils veulent et une réponse de type : "Non, t'as rien à y gagner, ils font ça pour le plaisir et parce qu'ils aimaient bien BeOS" est entièrement satisfaisante.

    Mes livres CC By-SA : https://ploum.net/livres.html

    • [^] # Re: question

      Posté par  . Évalué à 4.

      Je crois que c'était lié au système de fichiers organisé en SGBD, un peu comme le fantômatique WinFS, et au fait que les fichiers étaient associés aux applications directement via un mimetype et plus par une extension à trois lettres.
      Ça, plus le fait que BeOS était orienté multimédia, devait donner de meilleures performances pour les carrioles utilisées à l'époque.
      Un Live CD serait chouette à obtenir, mais pas moyen de faire fonctionner leur moteur de recherche interne pour avoir ne serait-ce qu'une démo stable, et pas une nightly build...
      • [^] # Re: question

        Posté par  (site web personnel) . Évalué à 1.

        les fichiers étaient associés aux applications directement via un mimetype


        Ah, ça, je l'attend depuis pas mal de temps ... avec mon système GNU/Linux. Cela pourra-t-il venir un jour, quelqu'un sait ? Parce que parfois la libmagic se trompe ...
        Je crois que Mac OS le fait mais il me semble aussi que parfois, il y a des problèmes et on a toutes les peines du monde a mettre le bon mime type.

        Il m'est arrivé de modifier un fichier maple sur Mac OS X avec la ligne de commande mais Mac OS n'a plus jamais voulu le réouvrir. Le fichier était utilisé par maple sur l'environnement classic et le fichier était stoké sur un dossier samba, ca joue peut être.
        • [^] # Re: question

          Posté par  . Évalué à 5.

          De mémoire BeFS n'intégrait pas une BDD, au début oui, mais cela a été abandonné pour des raisons de performances. Mais le FS a toujours des trucs très intéressant :
          * support des types MIME (les types MIME sont définis par un démon qui tourne et analyse les fichiers)
          * support illimité des méta-donnée, on peut en ajouter autant qu'on le désir. Un exemple d'application, StyleEdit, le petit éditeur de texte de BeOS utilise les méta-donné pour stocker la mise en page d'un fichier texte (couleur, alignement, taille de la police) et si on lit le fichier texte sur un autre système, le fichier reste lisible, mais sans la mise en page
          * live query, des requêtes de recherches dynamiques, cela permet ainsi de lister tous les fichiers qui nous intéresse suivant un certains critères et ce résultat est mis à jour dynamiquement (couplé au méta-donnés cela peut donner des trucs très intéressant.
          Il est à noter que le OpenBFS de Haïku est un des composants qui a actuellement atteint le stade de la bêta.
    • [^] # Re: question

      Posté par  . Évalué à 1.

      J'ajouterais que Windows XP n'a pas évolué non plus depuis la mort de BeOS ;-) Mais bon, comparons ce qui est comparable : d'un côté, la boîte de développement la plus puissante^Wriche du monde, et d'un autre une bande de hippies (vu que Be a disparu), les forces en présence ne sont pas très équilibrées...
      Haiku risque de rester un OS intimiste, à la AmigaOS, et c'est dommage pour la diversité.
    • [^] # Re: question

      Posté par  (site web personnel) . Évalué à 10.

      je n'ai jamais trouvé "pourquoi"

      Son design a été prévu dès le début pour supporter le multithreading de façon très intensive, en prévoyant que (rapidement) on utiliserais des machines multiprocesseurs.
      Ce qui en fait (en faisait) un système très réactif - tu n'étais *jamais* bloqué dans l'interface à cause d'une opération en cours (un clic pour dérouler un menu lançait un nouveau thread chargé d'afficher et contrôler ce menu, chaque application avait un thread correspondant dans le système graphique...). Même sur des machines moyennes, tu pouvais sans problème jouer plusieurs films/musiques en même temps, tu sentais que les ressources de la machine étaient exploitées au maximum (j'ai souvent du mal à sentir ça sous Windows ou Linux).

      Côté file-system, le BeFS et l'utilisation importante des attributs associés aux fichiers - et ce dès le début, intégré à l'OS - était vraiment génial pour faire des recherches, ou pour simplement visualiser des fichiers et leurs caractéristiques associées sans avoir à ouvrir une appli tiers.

      Côté graphique, il y avait aussi le système des répliquants (des composants graphiques pouvant avoir une indépendance par rapport à leur fenêtre d'origine).

      Et bien sûr, l'API objet de BeOS, vraiment sympa.

      Vraiment dommage que ça n'ait pas pû être open-sourcé lorsque Be Inc. a fermé.

      qu'ai-je à gagner à utiliser Haïku plutôt que Linux ?

      Malheureusement, actuellement, aucun AMA (enfin, si, avec un QEmu, tu peux l'installer et voir par toi-même ce qu'il en est).
      On retombe dans le problème de l'avancée du projet, dans le problème de support de matériels très divers (déjà qu'avec Linux c'est pas toujours gagné), des applis disponibles (il y avait une bonne communauté autour de BeOS, et des applications commençaient à arriver).

      C'est dommage, j'ai récemment balancé tout le matériel de cette époque (CDs, livres) que j'avais sur BeOS...

      Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

      • [^] # Re: question

        Posté par  (site web personnel) . Évalué à 1.

        supporter le multithreading de façon très intensive

        Et comment cela se passait pour résoudre les problèmes qu'on peut voir lorsqu'on fait du multithread ? corruption de données en cas d'accès concurrent quoi.
        C'est juste que je trouve les mutex pas très pratiques a utiliser, mais peut être que cela devient très facile avec plus d'expériance. Alors je me demande si ils avaient une meilleure solution...
        • [^] # Re: question

          Posté par  (site web personnel) . Évalué à 9.

          comment cela se passait pour résoudre les problèmes qu'on peut voir lorsqu'on fait du multithread ?

          Il n'y avait rien de plus que des choses connues: mutex, sémaphores ; et en plus haut niveau: mémoire partagée, files de messages, ports de communication.

          Tout ça se retrouve maintenant dans les APIs de n'importe quel OS digne de ce nom. Mais... BeOS c'était à l'époque [*] où MacOS ne connaissait pas la mémoire protégée ni le multithreading préemptif, Windows était une surcouche de DOS, Linux était un Unix en développement avec une couche XFree pas toujours légère sur de petites config.

          BeOS c'était une façon intelligente et légère d'utiliser ces différents mécanismes (entre/dans les applications, avec les différents serveurs).

          Voir le BeBook... http://www.beunited.org/bebook/index.html

          Et plus spécifiquement:
          http://www.beunited.org/bebook/The%20Kernel%20Kit/index.html

          [*] Sauf erreur, la machine qui était vendue par Be Inc., c'était à l'origine un Bi-PPC603e à 166MHz... moi je tournais sur un PowerMac 7300 à 180MHz avec 80Mo de RAM, et c'était plus réactif qu'un PIV à moult gigagertz et plus de 1Go de RAM de maintenant.

          Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

          • [^] # Re: question

            Posté par  . Évalué à 0.

            Tu as juste oublié OS/2 qui n'avait rien à envier à BeOs coté technique.
            • [^] # Re: question

              Posté par  (site web personnel) . Évalué à 3.

              Disons rien à envier côté force de développement... et donc aboutissement du projet.

              Je n'ai dû voir OS/2 tourner qu'une seule fois, et s'il avait bonne réputation sur sa fin (entre autre une très bonne stabilité vs le Win95 de l'époque), ce n'était pas le cas des premières versions livrées.

              http://fr.wikipedia.org/wiki/OS/2

              Ils devaient quand même se taper toute une couche de compatibilité pour les applis DOS puis les applis Windows 3.x... pas sûr que ça ait été génial pour améliorer le côté technique.

              Où on voit encore que se battre dans la cour de Microsoft, c'est dur, très dur. Et plus encore pour du source fermé réalisé initialement en collaboration avec Microsoft (ce qui semble une des raisons du non-open-sourcing d'OS/2 d'après la page de Wikipedia).

              Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

          • [^] # Sur la BeBox

            Posté par  (site web personnel) . Évalué à 2.

            Il y a bien-sûr une page sur Wikipedia :-) http://fr.wikipedia.org/wiki/BeBox , qui indique http://www.bebox.nu/ .

            Et en plus, elle avait un vrai look: http://www.bebox.nu/images.php?s=images/ppcbebox

            Ah, c'était 133MHz, pas 166. Et c'était en 1995... il y a 11 ans.

            Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

            • [^] # Re: Sur la BeBox

              Posté par  . Évalué à 1.

              Les premiers modèles de BeBox PPC étaient 2x66 MHz, ce qui est probablement à l'origine de la confusion.

              Malheureusement, qu'elles soient à 2x66 ou 2x133, le gros défaut des BeBox PPC, c'est l'absence de cache L2, qui pénalise énormémement les applications quelles qu'elles soient. C'est ainsi qu'un modèle 2x66 est tout juste capable de lire un fichier mp3 à 44 KHz sans sauts, le bus mémoire étant sollicité en permanence...
              • [^] # Re: Sur la BeBox

                Posté par  (site web personnel) . Évalué à 2.

                Ah, mon Pm7300 devait avoir son cache L2, c'était vraiment fluide.

                Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

              • [^] # Re: Sur la BeBox

                Posté par  . Évalué à 1.

                C'était des PPC 601 si jeneme trompe pas, à peu près l'équivalent du 486.

                Dis moi, n'es-tu pas la personne qui m'a racheté ma BeBox pour porter NetBSD dessus ? La livraison de la machine avait été problématique, à ma grande honte.

                "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

        • [^] # Re: question

          Posté par  . Évalué à 0.

          D'après Andrew Tanenbauhm, sur sa page sur minix3 par exemple, pour éviter les problème de l'accès concurrent aux données (corruption, deadlocks), on mise plus sur la communication entre thread/processus que sur le partage des données.
      • [^] # Re: question

        Posté par  (site web personnel, Mastodon) . Évalué à 1.

        Il ne faut pas oublier non plus la bebox, la machine que vendait Be avec l'OS.

        Pour rappel, Be au départ voulait faire comme Apple, vendre du matos et l'os qui va avec; ce qui n'etait pas étonnant vu que le patron de Be était Jean Louis Gassée, un ancien d'Apple (pdg d'apple france, puis n° 2 d'apple monde).

        Bref, donc la Bebox. Je me rappelle qu'à l'époque, c'était la première machine bi-proc relativement accessible au publique. Et en plus elle n'était pas moche du tout, avec ses deux chenillards sur le devant qui indiquait l'occupation de chacun des deux procs (google est votre ami pour les photos). Avec des ports entrées-sorties sons d'origine, port PCI etc (tout ceci n'était pas forcément en standard dans les PC, pour le son sur les PC, fallait acheter des cartes additionnelles etc...)

        Pour les développeurs, les geeks, c'était donc une superbe machine à l'époque, avec un superbe OS temps réèl etc.. Voilà en partie pourquoi BeOS fut devenu un OS "culte".

        Malheureusement, les ventes n'ont pas été à la hauteur (surtout à cause de la compatibilité de l'os avec rien). Ils ont donc arrété la vente de la machine au bout de 2 ans (1997 je crois), et continué juste à développer l'OS.
    • [^] # Re: question

      Posté par  (site web personnel) . Évalué à 6.

      D'après ce qu'on expliquait à l'époque, BeOS a été conçu pour être un système temps réel dur et multithread "par défaut". Par exemple, lorsque tu utilise l'API standard de gestion de l'interface, BeOS te thread automatiquement la gestion de l'affichage et gère le reste dans un autre.

      Au milieu de cette page : http://www.espace-cubase.org/page.php?page=bepouraudio , tu trouveras pas mal d'infos.

      La gestion du shedduling, du switch entre taches et threads, l'accès à tout ce qui est flux de données (DD, vidéo, son) le rendait particulièrement adapté au multimédia (ce pour quoi il a été conçu). Il avait une conception assez orienté objet, on devrait plutôt dire composant. Un peu comme think

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: question

        Posté par  . Évalué à 2.

        Ce n'est pas du temps réel dur, mais c'est pas loin au niveau du résultat. Les temps de latence sont très bas sur toutes la partie multimédia.

        Sinon le fait que l'API est à 99% objet et qu'il a une architecture client/serveur doit y jouer au niveau de son aspect en forme de composant.
    • [^] # Re: question

      Posté par  . Évalué à 4.

      Il est clair que développer un projet aussi important est avant tout un affaire de passionnés. Et que presque 10 ans plus tard, BeOS n'est plus aussi en avance qu'avant. Mais il a tout de même de beau reste, comme sa réactivité, son API, sa légèreté et certaines technologies encore peut présente aujourd'hui, comme :
      * les translators : des modules fournissant des fonctions permettant de lire et écrire des fichiers, cela permet ainsi de les réutiliser dans n'importe quelle application
      * l'utilisation intensive des méta-donnés. Avec comme exemple concret StyleEdit (l'éditeur de texte de BeOS) qui utilise les méta-données pour stocker la mise en page des fichiers textes (couleur, alignement, police). Si un autre programme lit un fichier de StyleEdit, il le pourra, mais n'aura que le texte sans la mise en page
      * les live query, des requêtes de recherches de fichiers dynamiques, qui associées avec les méta-données permettent de faire des choses assez intéressante
      * les réplicants, qui sont des sortes de KParts. Ainsi, NetPositive (le navigateur Web de BeOS) peut être facilement embarqué dans n'importe quelle application
      • [^] # Re: question

        Posté par  . Évalué à 1.

        oups, je me répète sur les live query et les méta-données
      • [^] # Re: question

        Posté par  . Évalué à 3.

        A propos des translators, voici un exemple concret : en glissant le translator GIF dans le bon dossier système, TOUTES les applications BeOS savent instantanément lire et écrire le format GIF !

        BeOS le faisait il y a 20 ans !

        • [^] # Re: question

          Posté par  (site web personnel) . Évalué à 6.

          A noter que ce système emprunte l'idée aux Datatypes d'AmigaOS (ça s'appelait comme ça au départ en fait).
          C'est assez utile en effet pour ajouter le support de nouveaux formats...
          Et quelques trucs plus amusant, comme Gocr http://www.bebits.com/app/4098 qui converti une image en texte. Toute appli peut donc utiliser Gocr. De même j'ai converti une application de scannage (Sanity) en translator, qui permet à toute appli sachant ouvrir une image de scanner directement :)
    • [^] # Re: question

      Posté par  . Évalué à 1.

      >>En avance il y a 10 ans. Si Haïku réussit à sortir une version parfaitement identique au dernier BeOS, comment cela va-t-il supporter la comparaison avec les Linux/Windows/MacOSX de maintenant ?<<

      Très bien à mon avis: la réactivité des GUI sous BeOS était bien supérieur a un Linux/Windows/MacOSX de maintenant (et accessoirement sur la vitesse de boot aussi), ce qui est *très* agréable.

      Maintenant il restera toujours le probleme du manque d'appli..
  • # petite erreur

    Posté par  . Évalué à 0.

    Le drapeau à côté du lien Site officiel est le drapeau tricolore, mais le site, lui est bel et bien en anglais...
  • # NewOS, Syllable

    Posté par  . Évalué à 1.

    D'après la FAQ, Haiku utilise NewOS ( http://newos.org/ ) un noyau très différent de Linux. Du coup je trouve que cela rend ce projet beaucoup plus intéressant que les autres projets utilisant le noyau Linux, qui ne sont au final que des Desktops.

    A une époque un projet similaire avait fait un peu de bruit, Atheos ( http://www.atheos.cx/ ) . Quand est-il est Haiku+NewOS face à feu Atheos et son remplacant Syllable ( http://www.syllable.org/ ) ?

    Quoi qu'il en soit je suis convaincu que le libre a tout à gagner a posséder un OS conçu pour le Desktop. Bonne continuation.
    • [^] # Re: NewOS, Syllable

      Posté par  . Évalué à 2.

      AtheOS... c'est quand même un système, graphique qui plus est, fait par une seule personne ! Très fort quand même, et les caractéristiques semblaient ambitieuses :

      http://fr.wikipedia.org/wiki/MultideskOS http://en.wikipedia.org/wiki/AtheOS

      En plus le gars est également développeur de jeux, il a participé au jeu "Longest Journey" :

      http://www.mobygames.com/developer/sheet/view/developerId,14(...)

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: NewOS, Syllable

      Posté par  . Évalué à 1.

      >qui ne sont au final que des Desktops.

      Ben non c'étaient pas des destop, mais des écritures d'api, un peu comme gnustep quoi.
      Après que ça puisse devenir un desktop, je ne le nie pas...
      Enfin bon, de toutes façon, ils ne sont pas allés très loin.
    • [^] # Re: NewOS, Syllable

      Posté par  . Évalué à 2.

      Ce n'est pas le fait d'utiliser un noyau différent de Linux qui rend un projet intéressant. Il faut juger du résultat final (ou plutôt de l'état actuel).
      L'intérêt des projets qui étaient basés sur le noyau Linux c'était de profiter de sa grande compatibilité hardware. et de sa robustesse réputée.
      Mais, à mon avis, Linux a l'inconvénient d'évoluer trop vite. Sur un projet de la taille des BeOS-like, c'est trop consommateur de temps que d'essayer de suivre les multiples version du noyau... (déjà GCC lui-même...)

      Syllable suit son cours. J'ai un peu perdu pied depuis quelques mois mais il a l'avantage sur Haiku d'être utilisable : les drivers sont nombreux, le réseau fonctionne bien, le système est stable (l'API aussi, ce qui est bon pour les devs), le système de fichiers est très bon (il ne manque que les live queries, prévues mais pas encore développées)
      Le gros manque, comme partout, ce sont les applications "utilisateur" : pas de bureautique, pas de mozilla...
      Le petit manque de Syllable, c'est l'optimisation du système : le multitâche n'est pas optimal en termes de rapidité mais il est stable, ce qui est déjà bien.
      • [^] # Re: NewOS, Syllable

        Posté par  . Évalué à 2.

        Ce n'est pas le fait d'utiliser un noyau différent de Linux qui rend un projet intéressant. Il faut juger du résultat final (ou plutôt de l'état actuel).

        Je ne suis pas d'accord, car Linux n'est clairement pas orienté Desktop et c'est tant mieux. Par contre un noyau multithread qui intègrerait même une GUI serait un coup de boost énorme pour un OS Desktop, et cela se ressentirait sur le résultat final.
        C'était l'avantage de BeOS.


        Le gros manque, comme partout, ce sont les applications "utilisateur" : pas de bureautique, pas de mozilla...

        Un portage de GTK+ et Qt serait envisageable ?
        • [^] # Re: NewOS, Syllable

          Posté par  . Évalué à 3.

          Quand on développe sous BeOS/Haïku c'est pour utiliser l'API de BeOS/Haïku. Utiliser une surcouche fait perdre une grande partie de l'attrait du multi-thread et de toutes les technologies associées à BeOS/Haïku.

          Et puis c'est un boulot monstre, dont le temps serait très certainement mieux rempli et le boulot plus gratifiant pour les développeurs, à concevoir des applications spécialement dédiées à l'OS.
        • [^] # Re: NewOS, Syllable

          Posté par  . Évalué à 1.

          Pourrais tu étayer un peu.
          En quoi Linux n'est il pas orienté desktop ?
        • [^] # Re: NewOS, Syllable

          Posté par  . Évalué à 1.

          La GUI dans le noyeau ??!?

          Alors à quoi servent les tas de serveurs (ApplicationServer, WindowServer, etc.) ?

          BeOS le faisait il y a 20 ans !

        • [^] # Re: NewOS, Syllable

          Posté par  . Évalué à 1.

          > Un portage de GTK+ et Qt serait envisageable ?

          Si tu parles bien de Syllable, oui c'est envisageable mais rien n'est fait pour l'instant, à part des "portages" partiels pour quelques applications... C'est même fortement déconseillé par les développeurs principaux : il faut des applis natives pour aider au développement du système.

          Côté BeOS, GTK+ existe bien mais requiert l'installation d'un serveur X. Il n'y a pas de version native.

          Au final, on perd un grand intérêt du système hôte si on n'y fait tourner que des applis "portées". Et le mélange avec des applis natives pose forçément des problèmes d'ergonomie, de compatibilité, d'intégration...
          • [^] # Re: NewOS, Syllable

            Posté par  . Évalué à 3.

            il faut des applis natives pour aider au développement du système.

            Certe mais en attendant un portage GTK+ et Qt permettrait d'utiliser le système au quotidien, sinon ca se mord un peu la queue. Enfin on blablate, même un portage ne doit pas être simple à faire, il n'y a qu'à voir celui de GTK+ sur MacOS...
            • [^] # Re: NewOS, Syllable

              Posté par  . Évalué à 3.

              Qui voudrait utiliser au quotidien une application lente et bugguée. Selon moi, proposer de telles portages si complexes est plus dommageable qu'autre chose. Il vaut mieux dépenser son énergie à développer une application "from scratch", qui utilise les technologies du système et étant bien intégré que devoir se coltiner les adaptations d'une API qui n'est pas faîte pour ce système.

              Pour le portage de GTK, il me semble que c'est une vieille version, du style 1.2. Niveau portage, je ne sais pas si c'est vraiment utilisable. Même chose pour Qt, c'est une version 2.x.
    • [^] # Re: NewOS, Syllable

      Posté par  . Évalué à 2.

      Il te reste a prouver que c'est le noyau qui fait une différence entre un OS desktop tel BeOS et une distrib Linux: a mon avis, c'est plutot les surcouches.
  • # pas si intégristes que ça \o/

    Posté par  (site web personnel) . Évalué à 10.

    Une news BSD, une news Haiku... ça fait du bien de voir que tout le monde n'est pas aussi intégriste que sur IRC :))
  • # Le Commentaire Obligatoire

    Posté par  (site web personnel) . Évalué à 3.

    Pourquoi cette news n'est pas dans le théme Be ?
    => http://linuxfr.org/topics/Be.html
  • # Précisions

    Posté par  (site web personnel) . Évalué à 10.

    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 :)
    • [^] # Re: Précisions

      Posté par  . Évalué à 2.


      ça fait du bien de le voir booter


      Tout à fait. Je l'ai installé il y a quelques semaines, via Qemu puis très vite sur une partition dédiée. Malheureusement, il manque encore la stack réseau dans les builds... Et je n'ai pas trouvé le moyen de monter d'autres partitions, du coup c'est pas facile de partager des données...

      Bref, pas encore utilisable mais à suivre. De près.

      Pour ceux qui veulent tester, c'est plus simple qu'il n'y parait :
      http://www.haiku-os.org/wiki/index.php?title=Using_Haiku_Ima(...)

      Un ex-utilisateur régulier de BeOS 5 PE
  • # problèmes des drivers

    Posté par  (site web personnel) . Évalué à 3.

    Ce projet, comme d'autres OS m'intéresse beaucoup malhereusement, il y a toujours le problème des drivers. Si je garde linux alors que j'aimerais bien essayer serieusement le Hurd, les systèmes BSD ou encore Haïku c'est justement pour ses drivers.
    Je me demande si ce serait possible d'avoir avant l'OS une couche qui prenne en charge tout les problèmes materiels, gestion des drivers, ... et qui permettrait de lancer l'OS de mon choix qui n'aura plus a se soucier des drivers.

    Est-ce possible ?
    • [^] # Re: problèmes des drivers

      Posté par  . Évalué à 7.

      Je me demande si ce serait possible d'avoir avant l'OS une couche qui prenne en charge tout les problèmes materiels, gestion des drivers, ... et qui permettrait de lancer l'OS de mon choix qui n'aura plus a se soucier des drivers.

      C'était le boulot du BIOS, à la base. Il était prévu pour fournir des routines pour les tâches les plus courantes demandées au matériel (la fameuse interruption 13, si mes souvenirs sont bons). Le seul hic, c'est qu'avec le temps, les besoin ont évolué. Et, si on prend l'exemple des disques durs : le support de l'IDE fourni par le BIOS est rapidement devenu inutilisable : incapable de supporter les disques de grande capacité, etc. La conséquence est qu'aujourd'hui plus aucun OS "sérieux" (sauf erreur de ma part) ne passe par le BIOS pour ce genre d'opération.

      Un autre exemple de fonctionnalités qui "sortent" du BIOS et deviennent compétence de l'OS : la gestion d'énergie qui est passée d'APM (boulot fait par le BIOS sous le contrôle de l'OS) à ACPI (boulot fait par l'OS lorsque le BIOS en éprouve le besoin).

      Une alternative séduisante est EFI, qui permet apparement de pousser le principe des drivers du BIOS plus loin.
    • [^] # Re: problèmes des drivers

      Posté par  (site web personnel) . Évalué à 2.

      La virtualisation peut aider : tu prends un VMWare ou consort, tu le fais tourner sur la plateforme avec le plus de pilotes (Windows?), et ensuite tu peux installer l'OS client que tu désires.

      Pas forcément la meilleure solution, mais déjà une avancée.
  • # Le futur du desktop?

    Posté par  . Évalué à 4.

    Je lis ça et là que tout le monde parle de BeOS au passé, et donc Haïku, projet pour nostagiques?

    Le projet est très jeune, alors je pose la question:
    - qui aurait dit 5 ans après la naissance de Linux qu'il aurait le succès qu'il a aujourd'hui?
    j'aimerais bien retrouver les commentaires de l'époque "utilisable, réservé aux experts", ou "projet qui comporte plein de trucs intéressants si vous voulez étudier ça ou ça", etc.

    Alors, Haïku, futur Linux-killer sur desktop? (ouai, j'ai dit Linux-killer, parce que d'ici 10ans, windows aura disparu des desktops, hein! :D)
    • [^] # Re: Le futur du desktop?

      Posté par  . Évalué à 2.

      Linux a commence en 91, cinq ans apres on etait en 96, version du noyau 1.2 si je me rappelle bien.

      Slackware et RedHat etait bien installees, Debian existait deja. Sur le bureau Afterstep venait apporter un peu de eye candy par rapport a fvwm et le developpement de Gimp demarrait.

      5 ans apres sa naissance, je peux te garantir que Linux etait utilisable, avait une base d'utilisateurs solide, et 2-3 ans plus tard (KDE, Gnome) on commencait deja a pronostiquer la chute imminente de Windows ! (on a ete un peu trop optimistes la-dessus).
      • [^] # Re: Le futur du desktop?

        Posté par  (site web personnel) . Évalué à 7.

        La comparaison avec linux est carrement foireuse...
        dans Haiku ils reprogramment un peu tout,
        Linux y a que le noyau
        XFree existait déjà
        Tous les outils GNU aussi, (essayez Linux sans GNU pour rire...)
      • [^] # Re: Le futur du desktop?

        Posté par  . Évalué à 2.

        Afterstep venait apporter un peu de eye candy par rapport a fvwm

        Oh l'aut' eh ! ¹

        ¹ : ceci est une proposition de variante du « trop gros, passera pas »
        • [^] # Re: Le futur du desktop?

          Posté par  . Évalué à 2.

          Peut-etre que maintenant fvwm est joli avec la transparence, les themes et tout ca, mais a l'epoque c'etait pas trop le cas.

          D'ailleurs, si ca peut te rassurer dans "mon fvwm est mieux que ton wm", Afterstep etait au depart un hack de fvwm.
          • [^] # Re: Le futur du desktop?

            Posté par  . Évalué à 2.

            Franchement, ce ne sont pas la transparence ni les thèmes qui m'intéressent dans Fvwm, c'est plutôt le FvwmPager et la configurabilité.
            Mais en qui concerne 199x, AfterStep non plus n'avait pas de thèmes ni de transparence...

            Et puis, beaucoup de wm sont dérivés de Fvwm, lui-même issu de twm (cf. http://fr.wikipedia.org/wiki/Fvwm où l'on trouve un joli arbre généalogique).
  • # API BeOS sur système GNU/Linux

    Posté par  (site web personnel) . Évalué à 2.

    Est-il possible de porter l'API BeOS de Haïku sur mon système GNU/Linux ? Car apparament tout à l'air dêtre assez bien intégré, un peu comme GNUStep j'ai l'impression.

    En fait ce que je rêve, c'est une telle API bien intégrée pour mon OS favori, et de préférence utilisée. Actuellement, chaque environnement de bureau fournit ses propres mécanismes, j'aimerais bien que ce soit normalisé (freedesktop ?).
    • [^] # Re: API BeOS sur système GNU/Linux

      Posté par  . Évalué à 2.

      "Moui", ça s'appelle Blue Eyed OS qui est un BeOS-like sur un noyeau Linux avec XFree comme moteur d'affichage, mais tout le reste est BeOS-like.

      http://en.wikipedia.org/wiki/Blue_Eyed_OS
      http://www.blueeyedos.com/

      BeOS le faisait il y a 20 ans !

      • [^] # Re: API BeOS sur système GNU/Linux

        Posté par  . Évalué à 1.

        Pas grand chose sur le site que tu mentionnes, à part un laconique « We are back, stay tuned... Guillaume ».

        Et Google ne donne pas le moindre indice d'un quelconque paquet à télécharger.
        • [^] # Re: API BeOS sur système GNU/Linux

          Posté par  . Évalué à 2.

          Ça fait plus de deux ans que le projet est à l'arret, je pense que l'on peut dire qu'il est mort. De plus, le code n'a jamais été rendu public.
          • [^] # Re: API BeOS sur système GNU/Linux

            Posté par  (site web personnel) . Évalué à 3.

            En effet.
            Il était prévu qu'il soit passé sous GPL, mais on attend toujours.
            Par contre il existe différentes implémentation de l'API Be sous windows par ex. Gobe en a fait une pour porter Productive, et quelqu'un en a fait une pour tester les applis Haiku il y a qq années, mais je ne sais pas ou ça en est.
            Dans le svn de Haiku il y a une petite couche de d'émulation pour faire tourner certaines applis nécessaire à la cross compilation (rc pour compiler les resources, ...) peut-être qu'en partant de là c'est possible.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.