Le projet Haiku Project annonce la disponibilité d'Haiku R1/Alpha 1

Posté par  . Modéré par tuiu pol.
Étiquettes :
24
14
sept.
2009
Haiku
Le projet Haiku vient d'annoncer la disponibilité d'Haiku en version R1/alpha 1. Il s'agit de la première version officielle de ce système d'exploitation open source.
Haiku vise a être un système d'exploitation rapide, simple, efficace à utiliser, facile à apprendre tout en restant très puissant pour les utilisateurs de tous les niveaux.

Le projet Haiku a débuté il y a 8 ans sous le nom d'OpenBeOS. Son but était de recréer BeOS en version open source en licence MIT.
Avec la version R1/alpha 1, le projet ambitionne d'attirer les développeurs afin de proposer une version destinée au plus grand public.

Ses principaux attraits sont :
  • De se concentrer sur les besoins de l'informatique personnelle ;
  • D'avoir un noyau conçu pour la réactivité ;
  • De proposer un système entièrement "threaded" pour optimiser les multi-processeurs ;
  • D'avoir une API orientée objet pour un développement plus rapide ;
  • De disposer un système de fichiers du type base de donnés avec support des métadonnées (OpenBFS) ;
  • D'avoir une interface unifiée et cohérente.

Aller plus loin

  • # Réactivité

    Posté par  . Évalué à 1.

    La réactivité du site web du projet Haiku me rappelle plus un Windows NT rendu poussif par la lecture d'une disquette que la rapidité interstellaire de BeOS.

    Le mirroir le plus proche de chez nous a l'air d'être allemand : http://download.berlios.de/haiku/haiku-r1alpha1-iso.zip
    Sinon il y a toujours les torrents : http://baron.haiku-os.org/releases/r1alpha1/haiku-r1alpha1-i(...)


    Vivement ce soir que je teste ça :)

    BeOS le faisait il y a 20 ans !

  • # Scheduler

    Posté par  . Évalué à 6.

    D'avoir un noyau conçu pour la réactivité ;

    sur des monoproc ou des quadricoeurs ?

    • [^] # Re: Scheduler

      Posté par  . Évalué à 4.

      Ça dépend... Il utilise BFS pour les monoproc et CFS pour les multi...


      ~~~~> [ ]

    • [^] # Re: Scheduler

      Posté par  . Évalué à 3.

      De proposer un système entièrement "threaded" pour optimiser les multi-processeurs ;
      ...

      • [^] # Re: Scheduler

        Posté par  . Évalué à 3.

        C'est marrant moi j'aurais plutôt dit :

        De proposer un système entièrement 'threaded' optimisé pour les multi-processeurs

        Parce que là on pourrait croire que le Scheduler est tellement fort qu'il améliore les performances des CPU multicores

        • [^] # Re: Scheduler

          Posté par  . Évalué à 1.

          <humour>
          C'est exactement ça, le scheduler modifie le microcode du processeur pour l'optimiser.
          </humour>

        • [^] # Re: Scheduler

          Posté par  . Évalué à 5.

          Ce que je reproche a cette phrase c'est qu'on pourrait croire que le systeme "entierement 'threadé'" est un avantage uniquement pour les multi-processeurs, pourtant quand j'ai testé BeOS j'avais été bluffé par la réactivité des applications sur un *mono*-CPU!

          Windows et Linux n'ayant pas reussi a reproduire cette reactivite (sur des CPU beaucoup plus puissant), j'aurais tendance a penser que le noyau seul n'explique pas cette reactivite, mais qu'il faut que tout (noyau, couches basses et applications) soient ecrit dans ce but pour atteindre ce resultat..

          • [^] # Re: Scheduler

            Posté par  . Évalué à 2.

            Effectivement c'est le cas sous BeOS : des threads partout, partout, partout. J'ai lu un article où un créateur du système originel expliquait qu'en gros BeOS n'est pas tellement plus rapide, mais fait en sorte que parmi tous les threads il y en ai toujours un pour répondre à l'utilisateur, et c'est ce qui donne l'impression de réactivité.

            Linux ne posant pas de problème à ce niveau je pense, il "suffirait" d'utiliser les threads plus intensivement dans les applications utilisateur pour obtenir cette réactivité.

            • [^] # Re: Scheduler

              Posté par  . Évalué à 2.

              >il "suffirait" d'utiliser les threads plus intensivement dans les applications utilisateur pour obtenir cette réactivité.

              Certes, mais c'est loin d'être gagné:
              -regarde Firefox, il a fallu que Chrome botte le c* des developpeurs de FF pour qu'ils se mettent enfin a utiliser des thread differents (processsus) pour chaque onglets (normalement ce sera dans FF4) qui est pourtant une architecture 'logique' (je n'ai pas attendu Chrome pour pester contre FF quand un onglet figeait tout les autres).

              -C. Kolivas annonce un nouveau scheduler pour ammeliorer l'utilisation en desktop sur Linux, Ingo Molnar essaye de mesurer l'ammelioration sur un benchmark qui contient OLTP..


              Heureusement que les SSDs vont bientôt être a un tarif "abordable", car la ré-écriture des applications pour amméliorer la réactivité, je n'y crois pas: BeOS est tres, tres vieux et pourtant il etait bien meilleur que ce qu'on a maintenant sur ce point la.

              • [^] # Re: Scheduler

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

                ne pas confondre thread et processus. Bien sûr que Firefox utilise des threads depuis des années : pour les requêtes réseaux, pour les traitements n'ayant pas une interaction directe avec l'affichage etc.

                Utiliser des threads pour chaque onglet, ça n'apporterais rien : les threads sont dans le même processus d'exécution, donc si ça plante dans l'un, tout plante.

                Par contre oui, un *processus* par onglet, ça apporte une sécurité dans l'execution. Et c'est effectivement ce qui est fait dans Chrome et bientôt dans Firefox (c'est en cours de dev). Mais bon, ça occupe aussi beaucoup plus de mémoire (Chrome occupe plus de mémoire que le FF actuel dans pas mal de cas), et ça complexifie les communications entre onglet, avec le reste du navigateur (stockage de l'historique, du bookmark, synchro des prefs etc etc...).

                • [^] # Re: Scheduler

                  Posté par  . Évalué à 3.

                  >ne pas confondre thread et processus.

                  Je ne confonds pas: chaque processus contient au moins une thread donc comme FF4 va passer en mode un onglet = un process, il va utilise plus de thread d'execution qu'avant pour l'affichage, ce qui est bon pour la reactivite de l'interface (les espaces memoires different des processus sont bon pour la robustesse mais n'ont pas a priori d'impact sur la reactivite de l'interface).


                  >[coupe] pour les traitements n'ayant pas une interaction directe avec l'affichage


                  C'est bien ce que je lui reproche! C'est une restriction tres importante. Le but d'un navigateur web, c'est bien d'*afficher* des pages, non?


                  >Utiliser des threads pour chaque onglet, ça n'apporterais rien : les threads sont dans le même processus d'exécution, donc si ça plante dans l'un, tout plante


                  Je parlais de la reactivite, utiliser des thread ou des processus c'est la meme chose de ce point de vue la.
                  Tu change de sujet en parlant de la robustesse..

                • [^] # Re: Scheduler

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

                  > Et ça complexifie les communications entre onglet, avec le reste du navigateur

                  Il y a aussi moyen de simplifier le code. Le mode multi-profile ne sers a rien. Cela date de l'époque Windows98 mais avec des PC qui gère le multi-utilisateurs, cette gestion interne dans firefox augmente le code et n'apporte rien sauf de temps en temps des emmerdes... On pourrait remplacer tout cela par un lancement de firefox avec une option en ligne de commande qui donnerait le chemin du profile, c'est tout.

                  Je suis connecté sur ma machine, disons A. Je me connecte via ssh -CX sur une machine B et je lance firefox en ligne de commande avec une page web, c'est le firefox de la machine A qui charge la page et non un nouveau firefox qui est lancé sur la machine B. Ce comportement est unique au produit de la fondation mozilla et ne se retrouve nul par ailleurs et heureusement, car c'est hyper chiant. Tout ce code pourrait être virer lui aussi car à mon sens il est totalement illogique et compliqué.

                  Bref, tout cela pour dire qu'il y a des points qui pourraient être simplifier sans que l'utilisateur en souffre, au contraire.

                  • [^] # Re: Scheduler

                    Posté par  . Évalué à 3.

                    Le mode multi-profile ne sers a rien.

                    Les développeurs de plugins s'en servent beaucoup pour passer d'un profile de développement à un profile d'utilisation normale entre autres.

                    • [^] # Re: Scheduler

                      Posté par  . Évalué à 2.

                      Les développeurs de plugins peuvent généralement gérer ça en ligne de commande et/ou via des raccourcis spécifiques. Pas besoin de la petite interface de création/sélection de profils (le -ProfileManager). L'option "-profile" suffit amplement.

                  • [^] # Re: Scheduler

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

                    > On pourrait remplacer tout cela par un lancement de firefox avec une option en ligne de commande qui donnerait le chemin du profile, c'est tout


                    là je ne comprend pas ta phrase qui est en contradiction avec ce que tu dis plus haut : "le mode multi-profile ne sers à rien".

                    le fais de démarrer avec le profil de son choix en ligne de commande, existe depuis le debut, c'est le paramètre -Profile suivit du nom du profile.

                    Sinon, oui, le mode multi-profile sert à quelque chose, surtout aux dévelopeurs d'extensions, aux developpeurs de firefox, à ceux qui veulent tester les nightlies ou beta sans craindre de flinguer leur profil utilisé au quotidien avec leur firefox stable etc...

                    Et le retirer ne retirerait pas grand chose en terme de ligne de code....

                    Et d'ailleurs, je ne vois pas pourquoi tu parles de multi profile : ça n'a strictement rien à voir avec ce dont je parlais, avec la communications entre onglet....

                    Conçernant ton problème de connection via ssh, y a un paramètre : -no-remote, pour éviter que firefox utilise la dernière session lancée.

                    > Tout ce code pourrait être virer lui aussi car à mon sens il est totalement illogique et compliqué.

                    compliqué ? tu es aller voir le code en question ? à mon avis non, parce qu'il ne s'agit que de quelques ligne de bash dans le script de lancement !

                    • [^] # Re: Scheduler

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

                      Je n'ai jamais dis qu'il y a avait un rapport entre ce que je disais et les onglets... C'était juste deux exemples de bouts de code qui a mon sens ne servent à rien.

                      Le mode multi-profile est pénible sauf pour les développeurs. Donc je dis juste de changer cela avec un

                      firefox --config chemin_du_profile

                      Ce que tu dis, on peut choisir son profile avec -Profile, n'a rien a rien. Il reste une gestion des profiles. Si tu donnes le chemin du profile, il n'y a plus réellement de gestion multi-profile.

                      Quand au mode -no-remote, j'aimerais savoir qui l'utilise, pour moi ce mode remote par défaut n'a que des inconvénients et est à l'opposé du mode de tous les autres logiciels. Pourquoi firefox s'occupe de savoir si on est en mode remote et s'il y a un autre firefox à l'autre bout !

                      Bref, je ne sais pas combien il y a de lignes pour ces deux exemples que je donne. Je dis juste qu'on peut améliorer d'un coté et en profiter pour simplifier de l'autre. C'est tout.

            • [^] # Re: Scheduler

              Posté par  . Évalué à 1.

              au niveau espace utilisateur, un truc genre libdispatch devrait faire l'affaire.

    • [^] # Re: Scheduler

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

      Les ordonnanceurs,
      Tels les les papillons dorés,
      Tournent et volent.

    • [^] # Re: Scheduler

      Posté par  . Évalué à 5.

      Le BeOS originel etait concu pour un ordinateur bi-CPU, mais en final il etait tres reactif meme sur les ordinateurs mono-CPU: bien plus que les systemes actuels sur du materiel pourtant beaucoup plus puissant..

      J'espere qu'Haiku a reussi a reproduire cette caracteristique de BeOS.

      • [^] # Re: Scheduler

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

        J'espere qu'Haiku a reussi a reproduire cette caracteristique de BeOS.
        La première fois que je l'ai essayé depuis quelques mois, je l'ai fait (par accident) avec un qemu non virtualisé, donc émulé. Et j'avais rien remarqué de particulier à part le temps de boot relativement long. Je pense que ça suffit à répondre sur ce point :)

        • [^] # Re: Scheduler

          Posté par  . Évalué à 3.

          J'ai eu exactement la même expérience il y a un an ou deux. Et je viens de tester assez brièvement (entre midi et deux) sur du matériel tout à fait récent - un portable, avec assez peu de périphériques reconnus - et c'est honorable. Je suppose qu'avec des drivers corrects (notamment pour la carte vidéo) ça poutrerait des mamans ourses.

        • [^] # Re: Scheduler

          Posté par  . Évalué à 1.

          c'est bizarre je viens de le booter sur un vieux truc, environ 4s après le bios j'ai le desktop haiku.
          le multitache à l'air bluffant aussi. Genre sans accel 3D tu fait tourner teapot, bon ca tourne a peu pres vite. ten rajoute, ben teapote tourne plus lentement, sans saccades. tu peut lancer autant que tu veut jamais il saccade, il ralenti c'est tout.
          a peu près comme ca que je me rappelle de beos ;p

  • # Détails..

    Posté par  . Évalué à 10.

    La dépeche laisse un peu sur sa faim, on aurait aimé plus de détails sur Haiku, comme quoi il était capable de faire tourner VLC et Firefox, qu'il disposait d'un ensemble déja fourni d'applications utilisateurs, d'un look sympa (hérité de BeOS), qu'il compilait avec GCC4 depuis peu, qu'il avait une pile réseau portée de FreeBSD.. bref, à vous de fouiller le joli site du projet.

    J'avais testé un snapshot du svn il y'a quelques mois sur un vieux PC, ca tourne fort bien, et ca fourmille d'idées sympa pour ceux qui connaissent pas cet univers.

    • [^] # Re: Détails..

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

      Hum, petit rappel : linuxfr est un site collaboratif. Comme tu sembles bien renseigné, n'hésite pas à proposer une dépêche pour les prochaines versions.

      Il y a eu deux versions de cette dépêche. J'ai refusé la première parce qu'elle était trop maigre. Je trouve que le deuxième version était encore trop maigre, mais elle a quand même été approuvée :-) C'est génial quand on a plusieurs dépêches / journaux qu'on peut recouper pour en faire une dépêche plus complète. Mais quand on reçoit juste une dépêche maigre, on hésite entre ne rien publier (dommage) ou publier quand même.

      Pour proposer une dépêche :
      http://linuxfr.org/submit.html

      PS : En plus, on peut gagner des livres, abonnements à des magazines, etc. J'ai reçu mon livre Ruby, yahoo !

  • # PXE

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

    J'ai entendu parler de possibilité de démarrer Haiku par réseau. Ça se trouve, des images démarrables par PXE ? Juste au cas où : j'aimerais autant essayer sans cramer un CD.

    • [^] # Re: PXE

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

      Pour l'instant il faut compiler le bootloader soi-même...
      TARGET_BOOT_PLATFORM=pxe_ia32 jam pxehaiku-loader

      Quand aux CD, les réinscriptibles ça existe ;-)

      • [^] # Re: PXE

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

        Oh, pour les réinscriptible, je sais, c'est juste qu'aujourd'hui, pour tous les machins démarrables que j'utilise parfois (Debian Live, installateur Debian, installateur Ubuntu, Memtest86+, FreeDOS, GRUB Invaders), je me suis débarrassé de mes piles de CD que je passais mon temps à re-graver à chaque mise à jour.

        • [^] # Re: PXE

          Posté par  . Évalué à 3.

          en même temps, il y a toujours l'option "qemu plus montage de l'iso"

          c'est souvent pratique pour tester un OS sans crader la station de travail :)

          • [^] # Re: PXE

            Posté par  . Évalué à 3.

            oui, avec juste :

            qemu -cdrom tonimagedisque.iso

            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

  • # Système de fichier avec support des métadonnées

    Posté par  . Évalué à 6.

    Le système de fichier BFS permet d'associer des métadonnées aux fichiers. Cela peut concerner de nombreux types d'informations, comme par exemple, le type du fichier (image, mail, vidéo) mais aussi des informations plus abstraites comme le sujet d'un mail ou encore le nom de l'artiste pour un morceau de musique. Si j'ai bien compris le système incorpore un système d'indexage automatique des metadata qui permet de rechercher des fichiers en formulant des requêtes comme on le ferait avec un base de données relationnelle.

    Je dois dire qu'à elle seule cette fonctionnalité me donne sérieusement envie d'utiliser Haiku. Mais avant que je m'y mette un jour, je me demande si on pouvait imaginer transposer ces fonctionnalités sur linux.

    Voici quelques pistes :

    * Il existe un port d' OpenBFS pour linux appelé BeFS (pour ne pas confondre avec le célèbre Brain Fuck Scheduler). Le lien :
    http://sourceforge.net/projects/befs-driver/
    Je ne sais pas si il est envisageable de le voir fonctionner sur un noyau récent de linux puisque selon la page sourceforge la dernière version remonte à 2002. En tout cas sur ma debian squeeze l'outillage nécessaire *ne semble* pas disponible. J'ai juste remarqué deux choses: mkfs.bfs n'a malheureusement rien à voir avec BeFS et testdisk permet de vérifier des partitions BeFS (ah!).

    * Un outil comme tracker (http://projects.gnome.org/tracker/) permet de reproduire quelques aspects du fonctionnement de BFS notamment la partie recherche de fichier en fonction des métadonnées. Mais en l'état, la syntaxe des requêtes est trop simpliste.
    D'autre part tracker n'est qu'une surcouche à un système de fichier traditionnel, et je pense (a priori) que les possibilités sont pas conséquents plus limitées.

    * Enfin il y a libferris qui est système de fichier virtuel avec des possibilités d'extractions de métadata très étendues. Voici le lien : http://www.libferris.com/about (je me suis en tête de le packager pour debian, apparemment il existe des paquets pour suse et fedora)

    Pour conclure, en l'état de mes recherches, je dirais qu'il existe des solutions qui permettent de profiter de certains aspects de la richesse d'un système de fichiers avec metatags, mais qu'il manque des briques pour que l'édifice soit complet, autrement dit c'est tout un écosystème logiciel qu'il faudrait repenser.

    • [^] # Re: Système de fichier avec support des métadonnées

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

      un exemple flagrant que j'avais observé sous BeOS des capacités du BFS était sont éditeur de texte. On pouvait y faire une mise en forme rustique (couleur, taille, police, alignement ...) sur son texte, mais un simple cat du fichier ne revelait qu'un bete texte ascii sans la moindre trace de mise en forme ! et pourtant dans l'éditeur, la mise en forme était toujours présente !
      merci les méta data du BFS, vous me manquiez :,(
      faut pas que j'essayer haiku, si je remet un pieds dans le monde BeOS je vais plus jamais en sortir.

      • [^] # Re: Système de fichier avec support des métadonnées

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

        Ouais enfin perso je trouve cette exemple pas super, planquer des informations concernant le contenu dans les métadonnées, ça me paraît pas pertinent. Limite si c'était l'équivalent d'un css dans les métadonnées et que le contenu garde juste la structure, pourquoi pas.

        Et puis avec un fichier structuré un simple *2txt et tu as l'équivalent de ton cat de BeOS.

        • [^] # Re: Système de fichier avec support des métadonnées

          Posté par  . Évalué à 1.

          "Et puis avec un fichier structuré un simple *2txt et tu as l'équivalent de ton cat de BeOS."
          Oui, mais les autres applications qui pourraient vouloir accéder au texte sans devoir interagir avec la mise en forme ?

          • [^] # Re: Système de fichier avec support des métadonnées

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

            Avec un fichier "fichier.foo" dans le format foo que tu veux faire traiter sans mise en forme par l'application bar tu fais :
            foo2txt fichier.foo | bar

            Bien sûr tu ne travail plus sur le même fichier, mais je vois mal comment bar pourrait ne pas foutre le bordel sur fichier.foo : s'il ne sais rien des métadonnées comment en garantir l'intégrité après modification ?

        • [^] # Re: Système de fichier avec support des métadonnées

          Posté par  . Évalué à 8.

          J'avais moi aussi été très impressionné par les possibilités de ce système de fichier et de de sa bonne exploitation à tout les niveau du système. Ca avait changé ma façon de travailler avec les fichiers.

          Par exemple le daemon qui recevait les mails les stockait en vrac dans un répertoire sous forme de fichiers au format texte avec un type Mime:Mail et des metadonnées comme From, To, subject, Spam, Status....
          Ensuite il suffisait de créér sur son bureau des répertoire virtuel (livequery) qui contenaient une genre de requête SQL (par exemple: Affiche les fichiers avec typeMime=mail, satus=unread, Spam=false) puis de faire afficher par le navigateur de fichier les metadonnées attendus pour un mail (titre du mail, auteur, status, date...) Et hop on avais un petit gestionnaire de mail.

          De même que les ID3 pour les MP3 ou les EXIFS pour les images servaient à renseigner les metadonnées, on pouvait utiliser le navigateur de fichier comme un gestionnaire multimedia assez puissant.

          Ce système étant très bien intégré à tout les niveaux du système. On en venait à l'utiliser assez naturellement, on finissait même par ne plus avoir besoin de penser en terme de hiérarchie de répertoires/fichiers.

          Ce système était très réactif, chaque changement sur un fichier était immédiatement répercuté au niveau des livequery, on ne ressentait aucune latence même sur une machine dont le processeur n'était pourtant pas une bête de guerre (166Mhz).

    • [^] # Re: Système de fichier avec support des métadonnées

      Posté par  . Évalué à 2.

      Le probleme n'est pas tellement au niveau du systeme de fichier, mais au niveau des logiciels: meme si tu avais un BeFS parfaitement fonctionnel, quels logiciels utiliseraient ces attributs?

      A moins que KDE|Gnome|XFence|etc decide d'utiliser cette methode, cela resterait inexploité..

      • [^] # Re: Système de fichier avec support des métadonnées

        Posté par  . Évalué à 3.

        Pour le moment, les applis Gnome/KDE semblent se tourner vers un usage de métadonnées stockées ailleurs que dans le fs, et mettent des bases de données un peu partout pour divers usages (desktop-couch en ce moment chez gnome, akonadi qui vient avec mysql chez kde...).

        Un système de fichier plus élaboré permettrait peut-être de s'en passer, tout en allant vers quelque-chose de plus interopérable, élégant et ne cassant pas la philosophie Unix du "tout est fichier". Non ?

    • [^] # Re: Système de fichier avec support des métadonnées

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

      seul problème de ce type de FS : quand tu veux copier ton fichier vers une autre machine (linux, windows etc), tu perds toutes les métas datas.. Donc dans certains cas, des informations..

  • # Test réussi sur VirtualBox

    Posté par  . Évalué à 3.

    Je viens de télécharger ce soir l'image ISO de Haiku R1 Alpha 1, que j'ai installé dans une machine virtuelle sous VirtualBox.

    Pour ceux qui rencontreraient des problèmes de réseau, prenez le Intel Pro 1000 MT Desktop au lieu du PCNET Fast-III.

    Je poste ce commentaire depuis Haiku, en passant.

    Comme beaucoup de gens l'ont dit, je suis bluffé par sa rapidité de démarrage/extinction. 8 secondes grand max entre le démarrage de la machine virtuelle et le bureau Haiku. Pas plus de 5 secondes pour avoir le système "prêt à éteindre".

    Evidemment, niveau ergonomie, on a connu mieux, mais il faut reconnaître qu'il y a déjà pas mal d'applis pour découvrir cet OS, même par un système virtuel. Et je ne regrette pas de l'avoir tenté.

    Si vous avez assez de curiosité et quelques Go de libre en virtuel, n'hésitez pas à tester.

    Evidemment, de là à dire que je l'utiliserais tous les jours, y a un fossé. Mais cela permet de découvrir autre chose que Windows, Linux et OS X.

    • [^] # Re: Test réussi sur VirtualBox

      Posté par  . Évalué à 1.

      Idem et en effet problèmes réseau , merci pour le truc, sinon clavier en qwerty ...
      Mais la bête est bien réactive, intéressante, cela me rappelle les démos vues dans les bureaux de BeOS à la défense. -nostalgie-

      En tout j'y crois pas mal pour un système de base (mail texte dev web).

  • # C'est leeeeent et ça plante

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

    J'ai testé l'installation sur une partition de mon portable Dell Core Duo 1.2 GHz, 512 Mo de RAM, hé bin j'ai jamais vu un truc aussi lent.

    L'install à partir d'un dvd+rw est d'une vitesse gastéropodesque, au bout de 2 heures et demie elle n'en était qu'à 50%, et a fini par crasher le système avec une erreur de driver SCSI (c'est un graveur USB externe ?!?) avec l'apparition d'une invite de commandes en mode panique par dessus l'affichage graphique, top classe.

    Bref, pas encore au point.

    • [^] # Re: C'est leeeeent et ça plante

      Posté par  . Évalué à 2.

      chez moi cela a mis 15-20 minutes pour tout installer, et encore parce que j'avais un cdrw qui ramait un peu. Je pense que le problème vient du lecteur en usb, j'avais lu à une époque que haiku ne faisait pas bon ménage avec le usb 2, mais peut-etre que cela a changé...

      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: C'est leeeeent et ça plante

        Posté par  . Évalué à 2.

        Sur mon Dell XPS M1330, l'installation à partir d'un CD-RW a pris longtemps mais s'est bien terminée. Et avec une partition de 40 go, je suis tranquille pour la prochaine décennie !

        Une fois installé, c'est très rapide. Seul problème : la carte wifi n'est pas reconnue (cette couche est encore en dév). Donc je n'ai pas d'accès au réseau. Du coup, c'est un peu gênant pour l'utiliser comme OS principal... snif...

        Et puis, il va falloir travailler sur la traduction car pour l'instant tout est en anglais (c'est pas gênant mais ça fait une régression par rapport au BeOS original et aux distributions Linux actuelles)

        Je vais continuer à suivre ça de près... Haiku-os.org est dans mes flux RSS favoris !

        • [^] # Re: C'est leeeeent et ça plante

          Posté par  . Évalué à 2.

          Heu ... de mémoire BeOS n'a jamais été en français (en tout cas pas la R4.5 ni la R5).

          BeOS le faisait il y a 20 ans !

          • [^] # Re: C'est leeeeent et ça plante

            Posté par  . Évalué à 10.

            pourtant je croyais que BeOS le faisait il y a 10 ans ? ;)

            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: C'est leeeeent et ça plante

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

          Testé en VirtualBox hier soir, comme Jean-Baptiste, ça démarre en à peine 10 sec et sans changement intempestif de driver graphique (très appréciable, ça fait tout de suite très propre - cette même impression que laisse Mac OS X).

          Concernant l'installation, dans la VBox, ça a du prendre grand maximum, 5 min. Il n'y a pas grand chose à ajouter.

          Je cherchais un projet dans le genre ces derniers temps, je pense que je vais contribuer. :D

          There is no spoon...

      • [^] # Re: C'est leeeeent et ça plante

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

        Même quand le lecteur n'était pas sollicité, ça ramait à mort quand même. L'affichage complet d'une boite de dialogue se fait par exemple en plusieurs secondes, bouton après bouton ...

        Même problème pour l'installation avec et sans le système live. Peut-être est-ce dû à mes "malheureux" 512 MB de RAM qui sont bouffés par un ram disque ou autre ?

        Bon j'ai aussi testé le live CD sur un KVM, ça a l'air de bien tourner. J'arrête mes médisances :)

        • [^] # Re: C'est leeeeent et ça plante

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

          Non, Haiku boote très bien avec 128Mo, donc...

          Il s'agit sûrement d'un problème avec l'USB, la majorité des périphériques "mass storage" sont buggués et n'implémentent pas correctement les specs... Il se peut aussi que le pilote ATA ait désactivé le DMA parce qu'il n'arrivait pas à le faire fonctionner...

          Il est possible d'obtenir des informations en appuyant sur la barre d'espace au boot, "select safe-mode options" -> "enable on screen debug output".

          • [^] # Re: C'est leeeeent et ça plante

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

            Merci pour ta réponse. Je précise qu'en effet Haiku tourne correctement dans une session KVM sur le même PC sous GNU/Linux, avec 256 Mo de réservés. Il y a donc semble-t-il un problème de driver.

            Je testerai la fonction debug demain.

    • [^] # Re: C'est leeeeent et ça plante

      Posté par  . Évalué à 1.

      Tu devrais aller voir sur slashdot il y a un lien sur l'upgrade pour windows seven, ca va etre rigolo sur du "midle hardware" l'uprgrade prendrais plus de 20h (chiffre publie par Microsoft itself).

  • # Test réussi sur un système réel

    Posté par  . Évalué à 5.

    J'ai testé tout à l'heure le livecd sur mon ordinateur: tout est reconnu et fonctionne correctement.

    Je viens donc de retailler une partition logique, sur laquelle j'ai réservée 2.5 Go, et j'ai installé, très facilement, Haiku dessus (je poste avec en ce moment).

    Je m'engage donc à utiliser Haiku à temps complet pendant au moins une semaine, et plus si affinités ! Je reviendrai vous faire mes retours d'expérience à l'issue de cette période...

    (on dirait qu'il n'est pas possible d'écrire sur mes partitions ext3/ext2, seulement de les lire, du coup je vais travailler sur une clé usb que je synchronise habituellement avec les fichiers perso de mon /home)

    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

  • # Haiku pour le son (temps réel, toussa)

    Posté par  . Évalué à 3.

    Salut,

    En lisant les commentaires il semblerait qu'un des gros points forts de Haiku soit ça réactivité.

    Je me demandais donc si cela pouvait avoir un rapport (un impact ?) sur une utilisation temps réel de sa machine, par exemple pour le son (MAO ?) où ça semble être important.

    En fait j'y connais rien en informatique temps réel, en son et le lien qui va avec, mais si j'ai bien compris, sous Linux c'est un problème et on doit utiliser des noyaux patchés pour pouvoir faire des trucs cool avec du son.
    J'ai même cru comprendre que pour les puristes, écouter du son en très bonne qualité (je ne parle donc pas de mp3, de carte audio intégrée ni de bafles de PC :) nécessiterait un noyau patché pour le temps réel !

    Haiku pourrait-il répondre à ce genre de problématiques ?
    Des connaisseurs dans la salle ?

    Merci :)

    • [^] # Re: Haiku pour le son (temps réel, toussa)

      Posté par  . Évalué à 7.

      Je sais que le sujet avait été abordé sur la mailing-list LAD (Linux Audio Developer), et la conclusion était que le temps réel "soft" de BeOS était mieux qu'un vanilla kernel, mais moins bien qu'un noyau patché. Comme les différents éléments du patch RT sont petit à petit intégrés dans la branche principale, je pense qu'à long terme Linux pourrait offrir une meilleure latence out of the box.

      Je dit "pourrait" parce que le noyau ne fait pas tout. Il faut aussi une couche audio efficace (on l'a, elle s'appelle Jack), et facile à mettre en oeuvre (sans commentaires). BeOS avait ça. D'ailleurs la plupart des fonctionnalités plébiscitées de Jack (et même de GStreamer) étaient déjà présente dans le MediaKit.

      Enfin et surtout, il faut des applications, et là BeOS avait un excellent départ, dû en partie au fait que nombre de développeurs venaient du monde Mac, traditionnellement lié à la MAO.

      Si l'imbroglio Alsa/Jack/PulseAudio (et Ladpa/Dssi/Lv2, et Laddca/Lash/Ladish, etc.) débouche sur une solution stable et efficace, je pense que Linux a beaucoup à offrir à la MAO.

      Dans tout les cas, Haiku semble très prometteur...

      PS: pour ce qui est de l'utilité d'un noyau patché RT pour écouter de la musique, je pense que le seul intérêt est d'éviter les coupures liées à la charge.

      • [^] # Re: Haiku pour le son (temps réel, toussa)

        Posté par  . Évalué à 3.

        là je suis en train d'essayer d'écouter de la musique sur Haiku, et c'est plutôt... catastrophique ! Je ne sais pas si c'est à cause de ma carte son (une banale AC97) ou à cause d'autre chose, mais le son grésille, crachotte, est haché voire coupé, bref, c'est pas fameux du tout. J'avais des morceaux (en ogg) sur un disque usb externe, cela faisait cela, j'ai essayé de le copier sur le même disque sur lequel est installé le système, en beosfs, c'est pareil, j'ai essayé avec un mp3, et également en désactivant la fonctionnalité "real-time" pour le son, j'ai mis le processeur en "performance" maxi, idem.

        Est-ce que cela le fait également pour ceux qui ont installé le système chez eux ?

        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: Haiku pour le son (temps réel, toussa)

      Posté par  . Évalué à 2.

      Le grand succès dans son temps de beos a été dans les studios de son, avec des solutions pro ayant connu un beau succès car très performantes.
      je n'en sais guère plus, mais jke pense qu'en effet le son était très bien géré , haiku par contre je ne sais pas .

      • [^] # Re: Haiku pour le son (temps réel, toussa)

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

        Et puis, si je me souviens correctement. Steinberg avait commencé à porter Cubase dessus, ce qui aurait pu tout changer pour ce système car cela aurait certainement apporté les constructeurs de matériel dessus et le support du matos.

        Pour des raisons que j'ai oublié ou que j'ignore cela a été annulé et l'opportunité pour BeOS de prendre son envol dans le monde de la MAO a filé.

        Dommage.

  • # Tests rapides

    Posté par  . Évalué à 3.

    J'ai suivi le développement d'Haiku depuis le début, l'essayant sur des VMs dès que ça a été possible. Et c'était sympa.

    Mais hier soir, j'ai eu envie de tester cette fameuse Alpha1 sur du "vrai" matos. J'ai donc collé l'image "raw" sur une SHDC, et balancé le tout sur mon fidèle EeePC 701. Près de 40 secondes de boot. Mais ça fonctionne, l'écran est directement à la bonne taille, le touchpad fonctionne "normalement" (ascenseurs et tout). Une carte réseau semble détectée, mais malheureusement c'est juste la filaire, et je n'ai pas de câble sous la main. Snif.

    Deuxième tentative, un peu plus chiatique : je colle la même image "raw" sur le SSD interne de l'EeePC. Et là ... je suis resté scotché. J'avais lu ici et là des témoignages sur la vitesse de boot d'Haiku, mais je ne m'attendais pas à ça. Dix secondes, montre en main, avant un bureau pleinement fonctionnel. Et pour un truc, au final, bien plus réactif que la Xandros de base. À mon sens, il y a clairement de gros débouchés pour ce type d'OS sur des "petits" (ou vieux, c'est selon) systèmes comme ça.

    En tous cas, j'ai retrouvé pour quelques minutes le plaisir de ce vieux BeOS. Mais libre. Et franchement, dès qu'il y a un pilote WiFi correct pour cette machine, je la laisse indéfiniment sous Haiku (quitte à garder une Debian sur carte SD pour quand j'ai besoin d'un truc plus complet).

    • [^] # Re: Tests rapides

      Posté par  . Évalué à 2.

      sur mon PC de bureau, depuis le disque dur, cela démarre en 13-14 secondes (avec le bureau fonctionnel), c'est effectivement appréciable.
      Je pensais que sur le ssd cela serait plus rapide encore...

      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: Tests rapides

      Posté par  . Évalué à 4.

      En ce qui concerne le Wifi et puisque je vois que tu testes sur EeePC , un appel aux testeurs ( Atheros seulement pour le moment ) a été lancé le 14.

      http://dev.osdrawer.net/projects/show/haiku-wifi

      ;)

      • [^] # Re: Tests rapides

        Posté par  . Évalué à 2.

        Ah, mais c'est que tu as fait mon jour, là, comme dirait Harry. Franchement, merci, je me demande comment j'ai pu rater ça. Il faut clairement que j'essaye ;)

  • # Sites en français

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

    Pour ceux qui se sentent mal à l'aise avec l'anglais, il existe des sites francophones autour de BeOS/Haiku :
    http://beosfrance.com/
    http://ubix.org/

Suivre le flux des commentaires

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