Le projet Haiku est une réminiscence de feu BeOS. Pour les plus jeunes, BeOS était un système d'exploitation propriétaire développé en C++ par Be Inc. de 1990 à 2000. Son architecture était totalement indépendante, tout en ayant beaucoup de traits POSIX, ce qui permettait avec peu de travail d'y retrouver Qt, Mozilla, SDL, QEMU, Bash et bon nombre d'autres références classiques aux côtés de la logithèque propre de BeOS.
Haiku, anciennement OpenBeOS, reprend donc le flambeau de BeOS, avec cette ré-écriture libre, entreprise en 2001, avec l'appui de l'association à but non lucratif créée à cet effet. D'après Wikipédia, « …une version alpha de Haiku R1 est distribuée le 14 septembre 2009. La R1 Alpha 2 est sortie le 9 mai 2010, la R1 Alpha 3 le 20 juin 2011, et la R1 Alpha 4 le 12 novembre 2012. ». Nous couvrons ici les plans pour Haiku Bêta 1 et R1. Pour information ou rappel, toujours d'après Wikipedia : « Le développement d'Haiku est actuellement focalisé sur la R1, qui doit être quasiment identique à la dernière version distribuée par Be, la R5. ».
Sommaire
Haiku qu’est-ce donc ?
Il était une fois BeOS, un système d’exploitation propriétaire né sur les processeurs d'architecture Hobbit, puis porté sur PPC (en fait une machine hybride utilisant 2 Hobbits, 3 DSP et 2 PPC). C'était la période des BeBox.
BeOs a tenté l'aventure Intel sur un marché où seul Windows 9x dominait le Bureau, dans le but de sortir de la confidentialité. La philosophie de développement était de ne pas s'encombrer du passé, de toujours profiter au mieux du matériel récent.
- BeOS était avant tout un OS orienté multimédia et performances temps réel (N. D. L. A. : à l’époque, je redémarrais sour BeOs pour lire les vidéos qui étaient trop lourdes pour mplayer sur mon pauvre Cyrix à 133 MHz).
- BeOS avait un système de fichiers journalisé transactionnel 64 bits appelé BFS qui fait encore rêver bien des concepteurs de systèmes de fichiers modernes.
- BeOS démarrait en moins de temps qu’il ne faut à bien des OS récents pour sortir de veille, un certain Lennart en rêve encore.
- BeOS, même s’il avait un véritable terminal, démarrait directement en mode graphique, un certain Rasterman en rêve encore. ;-)
- BeOS imposait une structure multi‐threadée au code des applications natives, ce qui leur donnait une réactivité impressionnante, même sur des machines aujourd’hui (et à l’époque) considérées comme limitées.
Pour la petite histoire, Be Inc. était dirigée par un français, Jean-Louis Gassée, qui a failli ravir la place de Steve Jobs durant les années creuses d'Apple. Oui, Mac OS X aurait pu être sur une base BeOS plutôt que NextStep.
La chose ne s'est point faite et Be Inc. ne trouvant pas sa place sur le marché a fini par sombrer. Une nouvelle Release 6 (dite Zeta) devait sortir et corriger bien des erreurs de jeunesses du système (comme sa gestion calamiteuse du réseau), mais Be Inc. fut rachetée et enterrée par Palm.
Et pour l'histoire encore plus petite, le projet s’appelle Haiku car c’est sous cette forme poétique qu’étaient diffusés les messages d’erreurs du navigateur NetPositive.
Trop beau, trop tôt.
C'est en 2001 que Michael Phipps décide de lancer le projet Haiku (OpenBeOS au commencement). Son objectif pour la première release (dite R1) est d'être iso-fonctionnel avec BeOS R5. Cela implique de conserver la compatibilité binaire, le compilateur de reférence (gcc2), la configuration, toutes les API, les pilotes…
Où en sommes‐nous ?
Après quelques discussions enflammées sur la liste de diffusion Haiku, il y a quelques semaines, concernant la sortie d'une Nième alpha, il a été décidé lors du BeGeistert 2014 qu'il fallait accélérer les choses. Nombre de contributeurs se sentaient en effet coincés dans une logique d'archéologie concernant les contraintes techniques sus-citées du projet.
Nous sommes en 2014 et la bêta 1 pointe le bout de son nez, après 4 alphas. Haiku est presque BeOS, parfois moins bien, souvent bien mieux. La pile TCP/IP issue de FreeBSD en est un bon exemple.
L'accent va désormais se porter rapidement sur la R2 et la gigantesque aire de jeux qu'elle représente pour les hackers de tous poils.
L’annonce de la bonne nouvelle
C'est Adrien Destugues qui a posté la bonne nouvelle ce 2 novembre, ce qui suit est une traduction libre :
Salut les devs,
Pendant le BeGeistert coding sprint nous avons eu une longue discussion avec Ingo, Oliver et Ithamar à propos du futur d'Haiku et des difficultés que nous avons à produire une release. Nous avons cherché à nous mettre d'accord et nous aimerions proposer un plan pour atteindre la R1 et passer à l'étape suivante du développement.
Les objectifs sont multiples :
- Enfin fournir une version stable avec le nécessaire pour les développeurs
- Mettre au point un cycle de développement plus efficace qui permettra des releases plus fréquentes
- Permettre aux développeurs de travailler sur des choses plus passionnantes sans se sentir coupable de ne pas contribuer à l'objectif primaire de la R1
Notre raisonnement est qu'aujourd'hui la compatibilité binaire n’intéresse que peu de développeurs, probablement de même que les utilisateurs. Nous savons que la plupart des gens utilisent plus des applications Qt ou Java que natives de BeOs R5, d'autant qu'au cours des deux dernières années, l'équipe de HaikuArchives a été occupée à récupérer les sources de bon nombre d'applications BeOS, afin qu'elles puissent être mises à jour pour les prochaines releases. En outre, nous pensons qu'une R1 stable permettra d'inciter plus de développeurs à s'impliquer pour Haiku, apporter de nouvelles applications qui ne sont simplement pas concernées par la compatibilité binaire.
Nous avons fait un premier jet du plan qui assurera une transition douce vers le futur d'Haiku
Cela inclut la Bêta 1 puis les étapes vers la R1 incluant une branche de maintenance, ainsi que le développement pour la R2 et les choses amusantes qui vont descendre dans notre dépôt git comme d'habitude.
Pré-requis pour la Bêta1
À ce stade, nous avons atteint le checkpoint « fonctionnalités complètes » défini par le sondage « futures fonctionnalités de Haïku » de 2010. La dernière grande chose qui manquait était le gestionnaire des paquets, qui a été fusionné dans Haiku il y a un an et est maintenant stable et utilisable.
Il reste cependant quelques points de blocage qui empêchent la Beta 1 de passer la porte. La plupart ne sont pas les tâches de développement pour Haiku lui-même, et se rapportent à l'infrastructure PM. Nous avons besoin d'un processus automatisé pour construire les paquets à partir des applications produites par Haikuports afin de les intégrer aux releases. La pratique actuelle qui est de donner à un développeur un accès de commit pour télécharger des paquets n'est pas acceptable car il y a trop de travail et elle conduit à des problèmes de maintenance pour tous les paquets (un paquet est mis à jour, car il est une dépendance d'un autre, mais cela en casse un troisième qui ne peut fonctionner qu'avec une version plus ancienne, etc.).
Il y a aussi quelques questions ouvertes telles que l'absence de prise en charge IMAP dans les versions actuelles. Cela a disparu depuis l'Alpha3 et il existe des alternatives acceptables (en utilisant Beam ou un webmail), de sorte que la prise en charge d'IMAP pourrait être laissée de côté.
Plan pour la Bêta1
Sans les quelques points indiqués précédemment, il est inutile d'essayer de produire une release. Alors essayons d'abord de les résoudre. Oliver a travaillé pour y arriver, mais plus d'aide serait évidemment la bienvenue. Cela implique des travaux sur HaikuPorter (Python), ainsi que l'infrastructure serveur pour produire des builds. C'est peut-être le bon moment pour des non adeptes du C++ de rejoindre le projet.
Une fois ces points résolus, le temps de la release sera venu. Je prends la charge de coordinateur de release. Mon plan est d'utiliser plus ou moins le même schéma que pour les versions alpha et bêta.
Plans pour la R1
J'ai été mandaté pour mettre au point un plan pour la R1 et au-delà plutôt que des sorties au coup par coup chaque année des nouvelles Alpha. Voici ma proposition à cet effet.
À partir de la version bêta1, le tronc de Haiku sera consacré à la R2. Le contenu exact de cette nouvelle version doit être décidé entre les développeurs, mais il doit y avoir un consensus à passer à gcc4 ou clang comme compilateur principal, se débarrasser de notre ancienne libc customisée et la remplacer par une officielle et un peu de nettoyage des strates de l'API .
C++11 va également commencer à être plus utilisé.
La prise charge de l'API R1 et/ou la compatibilité BeOS R5/gcc2 dans R2 peuvent être maintenues si quelques-uns sont motivés pour le faire – aucun des participants du BeGeistert code sprinters n'est intéressé, mais d'autres développeurs peuvent vouloir le faire.
Cela n'a même pas besoin de rester dans le tronc d'Haiku, nous pourrions le fournir au besoin en third-party – similaire à la façon dont notre port Qt est actuellement distribué. Il reste quelques efforts pour y arriver et des gens devront en prendre soin.
Pendant ce temps, la branche de Bêta1 vit sa vie et deviendra un jour la R1. Ensuite, le plan est d'être à l'écoute des rapports de bugs des utilisateurs et développeurs et de rétroporter depuis la branche principale quand ce sera nécessaire. Quand la bêta1 sera complète, aucune nouvelle fonctionnalité ne sera plus jamais ajoutée. En tant que coordinateur de la Bêta1, je peux aussi prendre le rôle de responsable de la R1 et m'occuper du rétro-portage. Après un délai raisonnable (peut-être 3 à 6 mois - selon le nombre de bugs trouvés) après release de la Bêta1, une version R1 sera construite depuis cette même branche. Dès lors, la branche pourra vivre et produire de nouvelles version (R1.1, etc.) si de nouveaux problèmes sont détectés. Ou bien on peut basculer sur un mode « rolling release » où les mises à jour sont poussées en utilisant le gestionnaire de paquets. Aucune nouvelle fonctionnalité ne devra être ajoutée dans cette branche.
Nous pensons que ce plan permet une sortie de la R1 relativement indolore et à court terme. En tant que développeurs Haiku, nous devons admettre que ce ne sera pas une sortie parfaite. Il serait plus souple et lisse que les Bêtas s'appuient sur les branches des Alphas, mais il y aura forcement des bugs et limitations. Je ne pense pas qu'il y ait un moyen d'obtenir une release parfaite et sans bug dans un délai raisonnable avec notre main-d'œuvre actuelle.
Suite à la publication R1, la compatibilité BeOS R5 pourra continuer à exister dans la R2, soit dans une branche, soit comme un paquet externe.
La branche R1 continuera à recevoir des correctifs pour que ceux qui utilisent Haiku en production (nous pensons à TuneTracker) puissent compter sur une version solide et stable comme base pour leurs produits. De cette façon, les gens peuvent continuer à utiliser la R1 ou migrer vers la R2 et profiter de toutes les nouvelles fonctionnalités, mais au risque de découvrir de nouveaux bugs.
--
Adrien
Que faire maintenant ?
Haiku n'a d'avenir que s'il trouve ses utilisateurs. Il offre un environnement simple, rapide et efficace tout en donnant accès à des outils de qualité auprès desquels les habitués de GNU/Linux ne sont pas dépaysés.
Installez-le dans une VM ou sur une machine qui s'ennuie, vivez au quotidien avec et il deviendra vite votre indispensable compagnon.
Débusquez les bugs, remontez-les, proposez des corrections si vous le pouvez : le challenge est plus accessible qu'avec GNU/Linux, profitez en !
On n'attend plus que vous !
Aller plus loin
- Le site d'Haiku (1993 clics)
- L'annonce d'origine sur la liste de discussion Haiku (248 clics)
- L'écosystème Haiku moderne (476 clics)
- Haiku Slideshow (380 clics)
- Le tag "Haiku" sur superuser.com (181 clics)
# Eh ben...
Posté par XB . Évalué à -10.
Punaise y'a encore des gens pour s'intéresser à BeOS ?
Si je suis admiratif de la performance technique j'ai de sérieux doutes quant à l'intérêt du truc. Qui a envie d'utiliser un quelquechose qui a un look de fin du XXe siècle ? Mais bon si ça amuse certains tant mieux.
[^] # Re: Eh ben...
Posté par Narishma Jahar . Évalué à 10.
Moi.
Je préfère largement le look rétro des années 90 aux interfaces modernes où tout est surdimensionné et trop d'espace gaspillé.
[^] # Re: Eh ben...
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 6.
En effet, rien que le principe de n'utiliser que l'espace disponible pour s'afficher, et ne jamais être en maximiser était très agréable.
[^] # Re: Eh ben...
Posté par Le Gab . Évalué à 1.
À part les icônes et la police, je trouve qu'il est assez moderne et "frais". Après, l'esthétique, quelle est l'ergonomie. Je l'ai utilisé dans une VM il n'y a pas si longtemps mais voilà, faut être honnête, c'est un OS passe-temps.
ps:J'adore Gnome Shell.
[^] # Re: Eh ben...
Posté par dinomasque . Évalué à 4.
La Deskbar (l'espèce de barre des tâches) est très pratique dans son coin en haut à gauche.
Le Tracker (le gestionnaire de fichiers) est en mode spatial et permet de naviguer dans les sous-arborescences d'un dossier via un menu contextuel très pratique.
L'ergonomie est en quelque sorte l'aboutissement de l'ergonomie "Windows95" (tant regrettée par les fans de GNOME 2).
BeOS le faisait il y a 20 ans !
[^] # Re: Eh ben...
Posté par Neije . Évalué à 10.
Bon déjà si tu avais été curieux, tu aurais suivi le lien sur tunetracker (et oui Haiku est utilisé en production). Donc c'est loin d'être inutile …
Ensuite, le look, bah si on commence à discuter les goûts et les couleurs …
Enfin, chacun à quand même le droit de "perdre son temps" (comme tu le dis) comme on le souhaite. C'est quoi cet intégrisme pervers qui consiste à juger sans savoir ?
Pour tout ça, j'ai moinser !
Ce n'est pas parce que les choses sont difficiles que nous n'osons pas. C'est parce que nous n'osons pas qu'elles sont difficiles. - Sénéque
[^] # Re: Eh ben...
Posté par reno . Évalué à 9. Dernière modification le 24 novembre 2014 à 16:26.
Et bien pour avoir utiliser BeOS a l'époque les avantages listés dans le journal sont(étaient?) vraies, pas juste du marketing: les applications natives étaient très réactives (beaucoup plus que sur Windows ou Linux), démarrage en 14s sur mon PC de l'époque (Céléron 333!) comparés à 1min(Windows qui triche et est très lent au démarrage) et 1m20s(Linux), donc ça ne m'étonne pas que certains s'intéressent toujours à BeOS, maintenant sur un PC moderne avec SSD, est-ce que BeOS/Haiku reste intéressant?
Je ne sais pas..
A voire quand ils sortiront une version 'stable', enfin si ils y arrivent parce que prendre la décision de développer un nouveau noyau plutôt que de réutiliser Linux ou FreeBSD, on sent bien que (comme la majorité des projets opensource/libre) ils ont pris le parti de se faire plaisir en réinventant la roue et tant pis si ça prend beaucoup plus de temps au final.
[^] # Re: Eh ben...
Posté par dinomasque . Évalué à 1.
Je doute malheureusement du succès de Haiku. L'architecture compacte et très performante de BeOS n'est plus aussi utile aujourd'hui.
Et je me pose des questions en matières de performance (le noyau de BeOS était par exemple "lent" comparé aux Linux d'époque) et de support matériel (surtout vis à vis du serveur d'affichage maison de Haiku face à Wayland, voire MIR).
BeOS le faisait il y a 20 ans !
[^] # Re: Eh ben...
Posté par Le Gab . Évalué à 8.
T'es sûr? T'as essayé linux sur un RaspbPi ou autre truc ARM basse conso/perf?
C'est quoi un noyau lent?
[^] # Re: Eh ben...
Posté par zurvan . Évalué à 10.
c'est comme un cerveau lent, sauf que ça ne vole pas :)
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Eh ben...
Posté par dinomasque . Évalué à 3.
Le noyau de BeOS n'était pas lent dans l'absolu mais il l'était plus que Linux sur la quasi-totalité des benchmarks. C'était plutôt le reste de l'OS qui faisait la fulgurapidité de BeOS.
BeOS le faisait il y a 20 ans !
[^] # Re: Eh ben...
Posté par tao popus . Évalué à 7.
Mince, j'ai plussé par erreur… Oui, j'utilise du Linux sur de l'ARM basse conso (moins de 15W pour l'ensemble du système (limite de 5A de l'USB, je fais tourner sur du 2A, loin des 100~300W d'un PC classique ou il n'y a pas que le CPU), et ça dépote plus qu'on ne pourrait le croire, même si certains supports d’accélération 3D libre manque (Lima pas bougé depuis ~3 ans)), LLVM à fait de gros progrès.
Et encore, j'ai un vieux machin, le RK3288 de Rockchip (vendu sur différents appareils avec Linux, pas de redevance crosoft) a une bonne gestion de l’accélération graphique (pilote fermé). Différents pilotes libres sont en bonne voie (freedreeno, VideoCore), est au top des perfs ARM, permet de jouer plusieurs vidéos HD simultanées (ça me rappelle les démos de BeOS sur la BeBox, en LowD à l'époque, qui étaient exceptionnelles sur ce point). Bon, certes ce type de machine à 100€ qui consomme 15W sont plus proche du Corei3 que du Corei7, mais bon, pas même prix, pas même factures EDF, pas même encombrement…
Bien content de voir que BeOS continue son petit chemin via Haiku. Encore un truc à tester dans ma TODO (port des trucs que j'avais codé sue BeBox ?). Le côté monothread de certains trucs (Firefox par exemple quand un mot de passe (htpassword) est demandé, impossible d'aller copier depuis un autre onglet, me semble toujours un retour 15 ans en arrière, avant BeOS )
[^] # Re: Eh ben...
Posté par reno . Évalué à 2.
Pas si sur que toi là, OK le démarrage un SSD et ca roule, les videos/OpenGL là Linux devrait etre bien supérieur (à plus forte raison s'il faut faire tourner Haiku dans une VM!), mais une GUI très réactive grâce aux applications utilisant le multithreading?
Sur ce point, BeOS/Haiku a peut être un avantage sur les OS a base de Linux, ce n'est pas vraiment lié au noyau, plutôt aux frameworks..
[^] # Re: Eh ben...
Posté par xcomcmdr . Évalué à 5.
Euh, c'est pas nouveau, ça date au moins des années 90s. C'est possible de le faire en Win32, Windows Forms, WPF (pour Windows), etc… et sous Linux/whatever avec GTK/Qt/whatever…
Du moment que ton langage te permet de faire des threads, c'est possible. Rien à voir avec les frameworks…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Eh ben...
Posté par reno . Évalué à 7.
1) Entre ce qui est possible et ce qui est réalisé en pratique, il y a une GROSSE différence.
2) Le framework a de l'importance dans la mesure ou il pousse/encourage le multi-threading ou pas, de mémoire sur BeOS le multi-threading est encouragé avec par exemple une thread pour la fenêtre et une thread pour l'application.
C'est un peu la même chose que pour les langages: le C te "permet" de faire des threads, Erlang "impose" de faire des threads..
Ce ne sont pas que des considérations théoriques, le résultat est(était?) que sur BeOS les applis que j'avais utilisé à l'époque étaient super-réactives, ce n'était PAS le cas pour les applis sur Windows ou Linux.
Bon ça date et les applis ont eu le temps d'évoluer pas mal depuis, donc ça sera intéressant de comparer Haiku et un desktop Linux moderne(Wayland peut aider ici d'ailleurs), mais ça ne m'étonnerai pas que les applis Haiku restent bien plus réactives que les applis Linux: la latence/le temps de réaction, c'est difficile a mesurer et donc c'est rarement optimisé..
[^] # Re: Eh ben...
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Sauf que les processus Erlang ne sont pas des threads C, c'est bien plus léger.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Eh ben...
Posté par reno . Évalué à 2.
Il me semble que maintenant il y a les 2 en Erlang: les threads légères reparties sur des threads systèmes(1 par core(?)), après je n'y connais pas grand chose en Erlang..
[^] # Re: Eh ben...
Posté par barmic . Évalué à 4.
C'est pas le cas de tous les frameworks/lib de GUI (Qt, GTK, EFL, etc) ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Eh ben...
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
Malhereusement non!
La plupart des frameworks ont un seul thread qui fait tout.
Dans BeOS et dans Haiku, la moindre application a au moins 3 threads:
- Le thread de l'application, qui fait les traitements longs
- Le thread de la fenêtre, qui répond aux actions de l'utilisateur
- Et un thread dans le serveur graphique, qui dessine la fenêtre
Alors oui, c'est possible de faire la même chose avec d'autres frameworks, mais c'est tout un bazar (avec des problèmes de synchronisation) et personne (ou pas beaucoup de gens) ne le fait.
Les APIs de BeOS et de Haiku sont conçues pour limiter les problèmes. La communication entre ces threads se fait via des messages (similaires aux signaux/slots de Qt) qui permettent d'échanger des données sans avoir à traiteer soi même les problèmes de synchronisation. Donc, quand l'utilisateur clique sur un bouton, le thread de la fenÛêtre réagit au quart de tour (il a rien d'autre à faire, en même temps), et tout ce qu'il fait, c'est transmettre le message:
- Au thread de l'application: "clic sur le bouton x" (pour lancer un traitement quelconque)
- Au thread du serveur graphique (pour redessiner le bouton)
Avec ce système il est difficile d'avoir une fenêtre gelée (à moins de le faire exprès). L'utilisation de la plupart des autres systèmes m'est insupportable avec des curseurs en sablier ou en ballon de plage à chaque clic.
[^] # Re: Eh ben...
Posté par xcomcmdr . Évalué à -9.
Je faisais déjà ça en Windows Forms du temps de .NET 2.0 avec un Dispatcher pour accéder au thread de l'UI et un backgroundWorker pour les tâches en arrière-plan.
Encore une fois, rien de nouveau.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Eh ben...
Posté par Anthony Jaguenaud . Évalué à 7.
D’après Wikipédia .net, la version 2.0 date de 2005, beOS des années 90.
[^] # Re: Eh ben...
Posté par xcomcmdr . Évalué à -5.
Et comme Windows Forms n'est qu'un wrapper autour de GDI/COM, et que ce dernier ça date aussi des années 90s…
Et même : avoir un dispatcher et un thread, ça se fait en C en 30 secondes chrono…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Eh ben...
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 5.
Tu manques définitivement de perspective. On est en train de parler d'un OS qui était révolutionnaire à la fin des années 90, qui imposait une architecture aux applications (vue isolée dans son thread, bus système qui inspirera DBUS), et tu parles de ce qu'on peut faire en 2014 avec du C.
Quand au 30 s chrono, je demandes à voir.
[^] # Re: Eh ben...
Posté par xcomcmdr . Évalué à -5.
Ça se faisait déjà en C dans les années 90s, désolé mais je vois rien de nouveau à la notion d'avoir les tâches longues dans des background threads pour pas freezer l'UI.
Ça fait vingt ans au moins que c'est une bonne pratique, et elle n'a jamais été spécifique à BeOS.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Eh ben...
Posté par dinomasque . Évalué à 10.
Il y a 15 ans, les interfaces graphiques de BeOS étaient affichées de manière fluide et répondaient au doigt et à l'oeil là ou celles des autres systèmes "gelaient" souvent (c'est encore le cas aujourd'hui avec Firefox et bien d'autres applications).
Alors oui, c'était possible depuis très longtemps, mais ce n'était pas fait et c'est encore trop rarement le cas. Alors que sous BeOS c'était pour 100% des applications, sans aucun effort de la part du développeur.
BeOS le faisait il y a 20 ans !
[^] # Re: Eh ben...
Posté par lolop (site web personnel) . Évalué à 3.
Il y a vingt ans, si un autre thread que le thread principal voulait accéder à l'API de l'interface graphique… crash. Alors, oui, la séparation working thread/thread GUI on savait faire - mais c'était rarement fait (sous MacOS<X et Windows<95, pseudo-multithread de merde). Et si le thread GUI pour X raison prend du temps, alors toute l'interface graphique se fige.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Eh ben...
Posté par xcomcmdr . Évalué à -2. Dernière modification le 26 novembre 2014 à 07:30.
Euh, c'est pareil aujourd'hui. Les règles n'ont pas changé, mais ça n'empêche pas de faire des interfaces qui délèguent les tâches lourdes dans des threads séparés, et d'ensuite notifier l'UI à l'aide de RegisterWindowMessage et PostMessage (Win32).
Et Win32, c'est plutôt vieux comme API… (ça date de Windows 95 quoi)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Eh ben...
Posté par lolop (site web personnel) . Évalué à 2.
Oui, c'est vieux… mais on en est encore la: «Et si le thread GUI pour X raison prend du temps, alors toute l'interface graphique se fige.» dans la grande majorité des applications.
L'API ne fait pas une architecture.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Eh ben...
Posté par xcomcmdr . Évalué à 1.
Et c'est bien pour ça qu'on utilise plusieurs threads, même dans BeOS.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Eh ben...
Posté par whity . Évalué à 10.
Je crois que tu es passé à côté du propos.
Le propos, c’est que les outils de développement BeOS (api, etc) t’incitent très fortement (quasiment, forcent ?) à utiliser une architecture multithread, là où les outils de développement gtk / qt / win32 t’incitent plutôt à tout faire dans la mainloop du thread de la gui.
Et effectivement, régulièrement, des applis freezent, sous windows comme sous linux. Tu peux blâmer les développeurs, dire que ce sont des incompétents et qu’il y a tous les outils dont ils ont besoin. Ça te fera peut-être du bien, mais ça ne changera pas grand chose au final…
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Eh ben...
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
Forcent, oui. Tu crées un objet BApplication, 1 thread. Tu crées un objet BWindow, 1 thread (+ 1 du coté du serveur graphique pour le rendu). Après on peut faire exprès de ne pas se servir du thread de la BApplication et faire tous les traitements dans le thread de la fenetre pour avoir une UI lente. Mais il faut faire exprès (et encore, de toutes façon le système envoie des messages à ces deux threads selon les cas donc il faudrait les rediriger de l'un vers l'autre).
Dans la plupart des autres frameworks, c'est l'inverse. On peut faire une UI réactive avec un thread dédié aux traitements longs, mais il faut le faire exprès.
Un autre détail: par défaut le thread fenetre a une priorité supèrieure, et donc le système est plus réactif. Là encore, sur les autres systèmes, on peut le faire, mais ça n'est pas le cas par défaut.
Dans Haiku on essaie pas de révolutionner l'informatique, on essaie de faire un système qui "juste marche". Pour ça on a les memes solutions et bonnes pratiques que tout le monde, mais on essaie de faire en sorte que la bonne solution soit également la plus simple à mettre en œuvre.
[^] # Re: Eh ben...
Posté par barmic . Évalué à 4.
Je ne suis pas spécialiste, mais j'ai sincèrement du mal à le croire. J'entends parler de cette bonne pratique depuis trop longtemps pour imaginer que ce n'est pas utiliser par les API les plus connues.
Par contre si l'intérêt d'Haiku c'est sont framework graphique, ce n'est pas forcément la peine de s'embêter à écrire un OS complet pour ça, ça peut très bien s'écrire au dessus xorg/MIR/wayland et de la bibliothèque XCB (qui, si je me souviens bien, est conçue pour faire de la programmation réactive ce qui colle bien avec des threads).
De plus si ce n'est pas le cas de toutes les biblio/framework, c'est au moins le cas de Qt donc qu'elle est la différence entre Haiku et Linux/KDE par exemple ?
Sincèrement j'ai rien contre Haiku, je n'ai jamais essayé, je n'ai jamais essayé BeOS, mais je suis pour qu'il y ai des OS alternatifs à Linux en libre, c'est juste pour essayer de te faire dire qu'est-ce qui est cool dans Haiku. :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Eh ben...
Posté par Anthony Jaguenaud . Évalué à 10.
Je ne sais pas si Qt5 a changé ça, mais dans le 4 par défaut, tout est mono-thread. Il faut volontairement mettre des traitements dans les threads. Et de mémoire c’était très compliqué de mettre la boucle d’événement principale ailleurs que dans le thread principal (celui qui démarre
main)[^] # Re: Eh ben...
Posté par cedric . Évalué à 7.
Avec QtQuick, il y a un mecanisme de rendu asynchrone. Le probleme etant si je ne me trompe pas que le modele de rendu de Qt classique ne permet pas d'abstraire la gestion de thread et rend difficile sont evolution. En gros, l'absence d'un scene graph fait que tout doit tourner dans la main loop (L'utilisation d'un appel a une fonction paint et laisse la possibilite de faire du rendu immediat a l'application).
[^] # Re: Eh ben...
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
C'est un interêt de Haiku.
Le choix de refaire un OS complet a au moins deux raisons. D'abord, au lancement du projet, Linux n'était pas du tout ce qu'il est aujourd'hui. En 2001, la distribution à la mode pour avoir un PC facile à utiliser, c'était Mandrake 8 ou Corel Linux. C'était très loin de ce que pouvait faire BeOS, et il manquait au noyau plein de petites choses qui faisaient que ça ne semblait pas être une solution viable.
De plus, un des buts du projet était de préserver la compatibilité avec BeOS, y compris pour les pilotes de périphériques (à l'époque le support était à peu près aussi bon que sous Linux, et les gens intéressés par Haiku avaient plutôt des machines compatibles avec BeOS).
De toutes façons, je te retourne la question, pourquoi continuer Linux et GNU maintenant que le vrai UNIX est libre sous la forme des BSD? Pourquoi continuer GTK alors que Qt est libre aujourd'hui?
Pour faire la même chose que Haiku, il faudrait prendre plusieurs morceaux de la pile logicielle classique de Linux (un noyau, un serveur graphique, un toolkit, un framework media du genre de gstreamer, etc). Alors oui, tout ce qu'on peut faire avec Haiku, on peut aussi le faire avec un GNU/Linux récent, mais en utilisant une douzaine de bibliothèques, chacune avec son API différente, chacune avec ses développeurs, son bugtracker, sa mailing list de support. C'est ça qui rend compliqué le développement d'une application. Et ça c'est sans parler des problèmes d'intégration entre applications utilisant des bibliothèques différentes.
[^] # Re: Eh ben...
Posté par xcomcmdr . Évalué à -6.
pour pas revenir 10 ans en arrière (rien qu'au niveau du support matériel…) ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Eh ben...
Posté par reno . Évalué à 3.
"vrai Unix" ça ne veut pas dire grand chose (Plan9?) et puis la compatibilité matérielle de Linux est bien meilleure que celle des *BSD.
Ça c'est totalement FAUX, tu peux prendre juste le noyau Linux (même pas glibc si tu n'en as pas envie) et faire un clone de BeOS là dessus, ça représente déjà énormément de travail en moins que de partir de rien (enfin presque rien pour Haiku, je crois que le noyau existait déjà mais il avait très peu de driver), certes tu peux aussi partir d'une distrib Linux classique et ajouter 'à minima' un support des appli BeOS comme tu le suggère mais ça n'est pas le seul choix possible: tout le continuum est possible.
[^] # Re: Eh ben...
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
La compatibilité matérielle de Linux est meilleure… parce que y'a plus de gens qui contribuent. Si Haiku fait pareil dans 10 ans, ou est le problème? Pourquoi ça marcherait pas pour Haiku si ça a marché pour Linux?
Et donc, oui, on peut prendre un noyau Linux et l'userland de Haiku: ça existe, ça s'apelle Cosmoe, et le projet Haiku est beaucoup plus actif. Pour les diverses raisons que j'ai mentionnées par ailleurs:
- Faire un noyau et des drivers en C++, c'est pas courant et c'est un projet intéressant
- Le code du noyau et des drivers est propre et lisible (ce n'est pas toujours le cas de Linux)
- L'API entre les drivers et le noyau est compatible avec BeOS et surtout, est stable: un vieux driver continue de fonctionner meme s'il n'a pas été "mainliné". Dans Linux ces APIs changent quasi systématiquement d'une version à l'autre.
- Avoir la main sur le noyau permet d'implémenter les choses comme on veut, avec par exemple une IPC spécifique (les "ports") qui est à la base de plein de choses dans Haiku (les BMessages qui s'échangent entre threads, les flux média entre applications un peu comme ce que fait jack). Non, ce n'est pas indispensable, et il existe des équivalents sous Linux implémentés à l'aides d'autres solutions (sockets UNIX, mémoire partagée, …). Mais oui, ça fait partie de l'idée du projet Haiku d'avoir un système qui est un tout cohérent, et pas seulement un aggrégat de divers projets comme la plupart des distributions Linux.
Autre exemple: le gestionnaire de paquets de Haiku a une particularité, les paquets ne sont pas extraits, mais montés sous forme d'un système de fichiers virtuel. Pour installer un paquet, on le copie au bon endroit (dans /system/packages). Pour désinstaller, on supprime ou déplace le fichier. Facile. Point intéressant, le noyau est dans un paquet. Le bootloader est donc capable de le retrouver dans ce paquet et de le charger en RAM. Ensuite le noyau peut trouver les paquets, récupérer les pilotes de périphériques qui sont dedans, et lancer le système. Oui, on pourrait le faire avec un noyau Linux, sous forme d'un patch qui aurait peu de chance d'etre accepté upstream, et qu'il faudrait donc maintenir d'une version à l'autre du noyau Linux. Pas sur que ça soit moins de travail, finalement.
En plus, Haiku a choisi la license MIT pour se permettre une éventuelle fusion avec BeOS si celui ci continuait d'exister. ça ne s'est finalement pas fait, mais avec un noyau sous GPL ça aurait été juste impossible.
Toujours pas convaincu? Pas de problème: le projet Cosmoe fait exactement ça: prendre l'espace utilisateur de Haiku et le faire tourner sur un noyau Linux. C'est possible aujourd'hui sans trop de difficultés car Linux a rattrapé une grosse partie de son retard depuis 2001. Seulement, il y a beaucoup de gens pour dire aux développeurs de Haiku qu'ils se trompent, qu'ils devraient utiliser Linux comme tout le monde, que s'ils le faisaient tout le monde utiliserait cet OS génial, et tout ça. Mais pour contribuer à Cosmoe, d'un coup, y'a plus personne (ah si, des développeurs de Haiku, pour montrer que oui, c'est possible!)
Je redonne le lien vers Cosmoe (je me répète, mais bon): http://github.com/ithamar/cosmoe
[^] # Re: Eh ben...
Posté par reno . Évalué à 5.
1) Parce que Linux existe déjà? Le pool de développeurs libre est limité..
2) Linux sur le desktop ça n'a pas si bien marché que ça..
Sauf que toutes ces raisons ne concernent que les développeurs de la partie noyau, donc ce que tu écris c'est qu'implémenter un noyau est très intéressant pour des développeurs noyau, OK mais le reste du monde s'en fiche pas mal..
La OK, effectivement le Linux de base n'a pas l'équivalent de l'IPC 'haute performance' de BeOS (Android si, inspiré de BeOS d'ailleurs), après est-ce que ça a un réel impact sur le ressenti utilisateur sur un PC 'normal'?
Difficile à dire, d'autant plus que Linux est plus performant a d'autres endroits..
Je passe sur l'histoire du gestionnaire de paquet et du noyau, oui toute utilisation de code externe a des conséquences mais bon même Haiku réutilise WebKit pour le navigateur web..
1) Personne n'a dit que le développement de logiciel libre était rationnel.
2) Finaliser Haiku a l'air de prendre beaucoup de temps, un classique: la partie fun ça intéresse des gens mais peaufiner le bébé (ce qui est énormément de travail) là..
[^] # Re: Eh ben...
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
Si je n'étais pas contributeur Haiku, je ne pense pas que je serais contributeur Linux. Donc, avoir un projet comme Haiku pour les développeurs de noyau qui ont envie de faire du C++ augmente le pool de dévloppeurs de logiciels libres. C'est plutot cool, non?
Je prend des exemples dans le noyau, parce qu'on est en train de le comparer à Linux (qui est seulement un noyau). Mais le même raisonnement s'applique à d'autres parties du système: là ou on utilise des bibliothèques externes (il n'y a pas que WebKit, mais aussi par exemple freetype et ffmpeg), elles sont systématiquement enveloppées dans une API en C++ qui s'intègre avec le reste du système.
Comme je l'ai dit, le choix de ne pas utiliser Linux a été fait en 2001. Les choses ont changé aujourd'hui et si le projet commençait maintenant, on ferait peut etre un choix différent. Mais là, on essaie surtout de sortir une version 1 "finie" afin de pouvoir passer à la suite. Et donc, je ne vois pas l'interet de passer du temps à changer de noyau maintenant alors qu'on en a un qui marche quand meme pas si mal que ça. Une fois la version 1 sortie, oui, pourquoi pas. Mais je trouve ça dommage pour les développeurs qui sont intéressés pour travailler sur un noyau en C++ (et qui potentiellement ne sont pas intéressés pour contribuer à Linux en C, ni aux autres parties de Haiku qui ne sont pas le noyau). Cosmoe est là, il attend son heure, et si ça intéresse assez de gens qui s'y mette sérieusement, ça peut faire un système utilisable sans avoir trop d'efforts à faire. En attendant, on continue à utiliser notre propre noyau.
[^] # Re: Eh ben...
Posté par cedric . Évalué à 8.
XCB permet surtout d'avoir un contexte explicitement lie a chaque appel de l'API. Ce qui permet de gerer de multiple thread sans probleme avec plusieurs connections. Le probleme, c'est qu'il n'est toujours pas possible d'utiliser OpenGL avec et donc on doit faire un fallback via Xlib dans la main loop. Ce qui tue un peu tout l'interet.
De maniere general, tous les systemes linux sont concu autour d'un unique canal de communication avec le display server pour les inputs et les ordres au systeme d'affichage. Ceux qui veut forcement dire qu'on a pas mal de boulot dans la main loop. Apres on peut toujours utiliser un thread pour le rendu et pousser le resultat depuis la main loop. C'est ce que font Qt, je crois, et les EFL.
La difference majeur de ce que j'en ai compris, c'est que le thread de rendu est actuellement dans le serveur cote BeOS alors que sur Linux ont a eu une tres forte tendance a s'en eloigner (X vs Wayland). La principale raison cote Linux etant qu'on a plein de toolkit different donc l'interface expose par X est devenu bien trop complexe sans jamais pouvoir repondre au besoin des toolkits. Alors que dans BeOS, le toolkit de BeOS etait integre des le depart et donc le serveur avait un travail moins generique a founir. Probablement que cela aide pour scheduler le rendu en appelant les routines de rendu directement dans le serveur au moment opportun sans utiliser trop de memoire et sans trop de probleme de synchronisation.
[^] # Re: Eh ben...
Posté par lolop (site web personnel) . Évalué à 8.
Les contentions d'accès au système d'affichage peuvent avoir un très gros impact. Beaucoup de systèmes d'interface graphique ne permettaient pas à d'autres threads que le thread principal (1er lancé) d'une application d'avoir accès à l'API graphique de façon correcte. (quid actuellement?)
Le framework, qui définit comment tu organises ton code de rendu[*] + la pile graphique sont essentiels.
Je confirme que, malgré les années passées et l'explosion de la puissance des machines et des cartes graphiques, aucun des OS Linux, Windows, MacOS ne donne la réactivité au niveau de l'interface graphique qu'avait BeOS; il y a toujours des petits blocages, des trucs qui marchent par a coup.
[*] Par exemple (de mémoire), avec BeOS l'affichage d'un menu popup crée un thread de rendu spécifique pour ce menu, il n'est pas bloqué dans la boucle principale de l'application et son traitement des événements.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Eh ben...
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 5.
Il y a deux projets basés sur Linux qui visaient à recréer BeOS et qui se sont plantés. HaikuOS est celui qui réussi là où ceux qui ont tenté ta solution se sont plantés.
[^] # Re: Eh ben...
Posté par Sébastien Koechlin . Évalué à 9.
C'est dommage, parce que se farcir toute la couche des drivers nécessaire pour utiliser une machine moderne nécessite un travail considérable et peu intéressant.
Hurd a les mêmes problèmes, les BSD également dans une moindre mesure.
Pour se démocratiser, gagner en visibilité, en parc d'utilisateurs, le système doit être très utilisable. Ca ne plait à personne d'être obligé de rebooter sur un autre OS pour pouvoir utiliser sa carte son son scanner, sa webcam… Ca tue un peu l'intérêt. On comprends que quelques passionnés fassent vivre le projet selon leurs besoins, avec leur matériel; mais est-ce que la base des utilisateurs grossis ? Si ça n'est pas le cas, le projet est condamné à mon avis.
Et pour avoir ce support matériel varié:
1. soit on l'écrit soit même et c'est lourd et pénible (et ça n'intéresse pas les développeurs),
2. soit on se base sur l'existant comme Linux; c'est moins efficace, le compromis fait hurler les puristes; mais ça permet de donner une visibilité sans commune mesure.
Le problème se pose également pour les cartes graphiques…
[^] # Re: Eh ben...
Posté par zurvan . Évalué à 2.
Apparemment ils reprennent souvent des parties de freebsd pour les pilotes, cf. https://www.haiku-os.org/tags/freebsd
et ici dans les sources : http://cgit.haiku-os.org/haiku/log/?qt=grep&q=bsd
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Eh ben...
Posté par LupusMic (site web personnel, Mastodon) . Évalué à -1.
C'est bien joli de vouloir des utilisateurs, mais si c'est pour finir comme GNOME et tomber dans une grossière caricature de MacOSX, autant ne pas créer un projet différent.
J'avais quitté RedHat avec GNOME 1.2 pour BeOS, bien plus stable (surtout le navigateur) et ergonomique.
Après la mort de BeOS, j'étais retourné sous Linux et bénéficié de GNOME 2 qui avait le mérite d'être ergonomique et utilisable. Ce n'était pas aussi bon que BeOS, mais ça me permettait d'utiliser des navigateurs web récents.
Mais là, avec GNOME 3 et la maturité de HaikuOS, je sens que je vais à nouveau migrer.
Hurd a un autre problème que le support matériel : son image de projet trusté par quelques développeurs qui savent mieux que tout le monde ce qu'un noyau doit être. Tiens, ça me rappelle un autre projet libre.
Quand à la prétendue visibilité, tu me fais doucement rire. Développer par dessus un noyau Linux, c'est surtout se noyer au milieu de toutes ses distributions. Sauf bien sûr, quand on maîtrise le matériel, et qu'on a une armée de développeurs.
[^] # Re: Eh ben...
Posté par reno . Évalué à 2.
Vrai, les projets qui se plantent, c'est fréquent.
Ça fait des années que Haiku essaye de faire une béta sans y arriver, donc dire que Haiku réussit c'est tout de même un peu prématuré..
On pourra dire qu'ils ont réussi le jour ou ils auront sorti une version stable (ce que je leur souhaite!!), pas avant..
[^] # Re: Eh ben...
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
Un projet qui existe depuis 14 ans, avec un développeur à plein temps (c'est moi!) financé par les dons des utilisateurs, je trouve que c'est déjà pas mal.
Le fait que les 4 versions de Haiku déjà disponibles aient "Alpha" écrit en rouge dessus a l'air de faire peur aux gens. On aurait certainement du les appeler 0.1, 0.2, 0.3 et 0.4 ou quelque chose dans ce goût là.
Personellement j'utilise Haiku sur mes ordinateurs depuis plusieurs années et ça marche bien. Oui, c'est pas fini, y'a plein de bugs chiants et ça manque d'applications. Mais mon expérience de Linux auparavant n'a pas été forcément meilleure, et il est nettement plus facile de contribuer à Haiku. L'équipe des développeurs est disponible pour répondre aux questions, prend le temps d'aider les gens à s'y retrouver dans le code, et le code est propre. Et surtout, tout est dans un seul projet, ce qui facilite énormément la coordination. Pas besoin de trouver si le bug vient de systemd, du noyau, de udev, de dbus ou de quelque autre bibliothèque obscure pour savoir à qui demander de l'aide.
[^] # Re: Eh ben...
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
En ce qui concerne les autres projets morts, il s'agit de BlueEyedOS (une implémentation des API de BeOS sur une base GNU/Linux/X classique) et de Cosmoe (un portage de l'espace utilisateur de Haiku sur un noyau Linux ou BSD). Ce dernier est de nouveau vivant depuis le coding sprint BeGeistert, ça se passe sur github. Les contributions sont les bienvenues pour Cosmoe aussi bien que pour Haiku.
Le noyau de Haiku est l'un des seuls (le seul?) à être implémenté principalement en C++. Mon avis est que ça permet d'avoir un code plus simple, plus lisible, et plus facile à maintenir que le C utilisé par Linux. Il reste la question des drivers, mais on utilise par exemple pour le support réseau les drivers de FreeBSD via une couche de compatibilité. On pourrait étendre ce principe à d'autres drivers si c'est nécessaire. Pour les cartes graphiques, on nous avait promis que Gallium allait régler tous les problèmes, que les drivers seraient portables, et tout ça, et finalement, il faut faire du kernel mode setting, et absolument implémenter DRI/DRM dans le noyau et les drivers pour que ça marche. Et comme les APIs ne sont pas stables dans le noyau Linux, le temps que tout ça soit porté, ça aura changé et il faudra recommencer (on y était presque arrivé en 2008).
[^] # Re: Eh ben...
Posté par Le Gab . Évalué à 8.
T'inquiète, c'est bientôt un problème réglé, l'équipe de systemd s'y emploi!
[^] # Re: Eh ben...
Posté par Le Gab . Évalué à 3.
Et si Haiku devenait l'OS des machines ARM? il a tout pour plaire.
Bravo en tous cas.
ps: Ce message est ecrit depuis WebPositive(Haiku) via Qemu.
[^] # Re: Eh ben...
Posté par gide . Évalué à 3.
Bonsoir,
A ce propos, comment avance le port sur ARM ?
https://www.haiku-os.org/blog/dnivra/2014-05-04_gsoc_2014_arm_port_week_1_and_2
car j'espère pouvoir bientôt utiliser Haiku sur Raspberry Pi. (j'ai de très bons souvenirs de BeOS 5 personal edition)
Autre question, que donne Qt sur Haiku, niveau "performances" ?
[^] # Re: Eh ben...
Posté par Astaoth . Évalué à 4.
J'avoue qu'en lisant la dépêche et les commentaires je me suis fait la même remarque. Je pense qu'Haiku aurait tout à gagner à essayer de rester le plus léger possible et à être compatible avec les plateformes ARM.
Emacs le fait depuis 30 ans.
[^] # Re: Eh ben...
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
ça avance. Mais ce n'est pas une question de légèreté, c'est une question de réactivité. Même sur un Pi avec 512Mio de RAM, Haiku peut tourner sans problème. Par contre, sans accélération de l'affichage, ça va pas être si intéressant que ça. Le Pi a un GPU très puissant, et il faudrait l'exploiter au maximum pour le rendu graphique ce qui permettrait de libérer le CPU pour des choses importantes.
Sous Linux ça devient de plus en plus difficile. Pour que ça marche bien on a besoin d'un serveur graphique qui coordonne toutes les opérations de dessin. X le fait, mais comme il ne fait pas d'antialiasing, c'est moche, et du coup les toolkits majeurs (Qt, GTK) n'utilisent plus X et font le rendu côté client. Et du coup il y a Wayland qui se prépare et qui supprime définitivement le rendu côté serveur.
Dans le cas de Haiku, c'est toujours app_server qui fait le rendu pour les applications natives, et donc si on fait un backend de l'app_server qui utilise le GPU pour le tracé 2D (par exemple via OpenVG), toutes les applications en bénéficieront. Mais ça reste pas mal de travail à faire.
Pour le port ARM lui même, ça avance doucement (le kernel se lance, maintenant il faut modifier le pilote USB qui n'est pas capable de fonctionner sans un bus PCI, de façon a faire marcher le stockage de masse USB et pouvoir charger le reste du système de fichiers pour booter plus loin). Par contre on cible pour le moment les ARMv7 ce qui exclut le Raspberry Pi. Il y a un peu de support à faire pour ARMv6 (pour les opérations atomiques, qui n'ont pas d'instruction dédiée et doivent être implémentées autrement, si je me souviens bien). Le manque de support du Pi dans QEMU est aussi un peu embêtant pour démarrer le travail.
[^] # Re: Eh ben...
Posté par philippe.houdoin . Évalué à 4.
Si y'a bien une erreur marketing, c'est d'avoir appeler la dernière version Alpha4 "Alpha", alors que clairement sa maturité relevait bien plus dans l'inconscience collectif des geeks d'une "Béta".
Nombre de systèmes d'exploitations seraient considérés en situation d'échec avec une telle définition !
;-)
[^] # Re: Eh ben...
Posté par gpe . Évalué à 7.
Pour le look, celui de fin des années 90 est bien plus plaisant que le flat design à la mode en 2014 !
Quand je vois l'horreur que vient de sortir Google avec lollipop …
[^] # Re: Eh ben...
Posté par woprandi . Évalué à 3.
Chacun ses goûts…
# oué !
Posté par dinomasque . Évalué à -3.
Chipotage : le fs de BeOS était BeFS et pas BFS cf. https://en.wikipedia.org/wiki/Be_File_System
BeOS le faisait il y a 20 ans !
[^] # Re: oué !
Posté par vincent LECOQ (site web personnel) . Évalué à 10.
Chipotage bis issu de l'article wikipedia en question : (BFS, occasionally misnamed as BeFS — the name BeFS is used in the Linux kernel to avoid any confusion with Boot File System)
[^] # Re: oué !
Posté par dinomasque . Évalué à 3.
Honte à moi !
C'était pourtant dans les Écritures : http://www.haiku-os.org/legacy-docs/bebook/TheStorageKit_Overview_FileSystemArchitecture.html
/o\
BeOS le faisait il y a 20 ans !
# Yes!
Posté par gaston . Évalué à 10.
Pour l'avoir testé il y'a un an ou deux sur un vieux celeron, ca donne clairement une nouvelle vie aux vieux coucous, mais aussi comme liveusb sur un netbook.. Meme si c'est de l'alpha, c'est stable, utilisable et fonctionnel au quotidien, et ca fourmille d'idées sympa dans l'UI, qui fournit un ensemble cohérent. On ne peut que se réjouir de voir arriver cette béta qui pourra amener plus d'utilisateurs et contributeurs!
# Petites machines
Posté par karteum59 . Évalué à 4.
Et maintenant ? Est-ce que Haiku est aussi efficace et permettrait de rendre une nouvelle jeunesse aux vieux PC ? (e.g. j'ai un PII-400/256Mo RAM qui dort chez moi, et sur lequel même Debian/LXDE se traine un peu…)
[^] # Re: Petites machines
Posté par Le Gab . Évalué à 2.
Debian/LXDE ou Firefox/Chrome?
[^] # Re: Petites machines
Posté par karteum59 . Évalué à 3.
J'utilise Qupzilla sur des machines de ce type (mais ça reste Webkit, avec bien sûr tout ce que ça implique…). En fait, tu as raison et je reste globalement très content de Debian/LXDE (ou Fluxbox) et j'ai bien dit "se traine un peu", j'ai juste toujours un peu la nostalgie de la réactivité de mon Amiga 1200… Faudra que je teste Haiku (et Syllable) un de ces jours :)
[^] # Re: Petites machines
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 7.
La configuration minimale pour utiliser Haiku est "un processeur x86 avec MMX et 128Mio de RAM". Mais bon, soyons honnêtes, sur une configuration de ce genre on ne pourra pas faire grand chose. Il y a plusieurs problèmes, mais en particulier le gestionnaire de paquets de Haiku se comporte mieux quand il y a plus de RAM. D'autre part, nos drivers graphiques n'utilisent plus l'acceleration 2D qui permettait à BeOS de bien fonctionner sur ce genre de machines, d'abord parce qu'on veut faire du rendu avec antialiasing et que ça ne s'accélère pas aussi facilement, mais aussi parce que sur les machines récentes, le processeur est de toutes façons plus rapide que la carte graphique pour ce genre de choses (c'est différent pour la 3D, mais on a pas encore d'accélération 3D).
Sur un "petit" netbook avec un CPU ATOM et 1Go de RAM, par contre, Haiku devient tout à fait utilisable. Je pense que c'est plutôt sur ce genre de machines qu'il est intéressant de se concentrer, on est en 2014, les Celeron vendus il y a 15 ans, il n'en reste plus beaucoup en service.
[^] # Re: Petites machines
Posté par dinomasque . Évalué à 3.
Comment ça se fait ?
Sur mon Pentium 100 avec 32Mo de RAM, BeOS R5 était rapide comme l'éclair.
BeOS le faisait il y a 20 ans !
[^] # Re: Petites machines
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
Déjà, le noyau de Haiku est toujours en mode "debug" (avec plein de vérifications, écrasement systématique de la mémoire libérée, etc) de façon à détecter et pouvoir déboguer plus facilement les problèmes (et il y en a!). Recompiler le noyau en mode "release" sans tous ces controles permet de gagner en vitesse.
Comme je l'ai indiqué, il n'y a pas d'accélération 2D, et tout l'affichage se fait avec de l'antialiasing; c'est beau, mais c'est lent. Et en plus c'est en double buffer (ce n'était pas le cas pour BeOS) et l'un des deux buffers est en RAM centrale (l'accès en lecture à la RAM vidéo via le BUS AGP étant trop lent).
Enfin, le gestionnaire de paquets qui est implémenté sous forme d'un système de fichiers virtual a besoin de RAM pour garder en cache les fichiers extraits des paquets (un peu comme un DriveSpace pour ceux qui connaissent). Et plein d'autres choses que BeOS ne faisait pas, comme la gestion du wifi, par exemple.
Un navigateur web de l'époque de BeOS (NetPositive ou Opera 3) fonctionnera sous Haiku par exemple, mais pour naviguer sur internet, c'est difficile. Meme chose pour lire la moindre vidéo, de nos jours tout est en full-HD en h.264 que meme mon Core 2 duo a un peu de mal à décoder en temps réel. Alors pour faire la meme chose qu'il y a 15 ans, ça pourrait marcher sur le matériel d'époque (avec un peu d'efforts), mais il est je pense plus intéressant de fonctionner sur des machines un peu plus récentes (disons moins de 10 ans) et d'avoir des fonctionalités modernes pour une utilisation moderne. De toutes façons, sur un Pentium avec 32Mio de mémoire, BeOS continue de fonctionner comme il le faisait déjà il y a 15 ans, non?
[^] # Re: Petites machines
Posté par karteum59 . Évalué à 4.
C'est un choix délibéré (parce que sur des machines récentes vous estimez que c'est plus rapide) ou c'est essentiellement un manque de temps/contributions (les drivers graphiques c'est difficile) qui ont guidé ce choix ?
[^] # Re: Petites machines
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
En fait, le problème vient surtout du matériel. Pour l'accélération 2D, à l'époque de BeOS les cartes savaient faire des copies et des remplissages de rectangles, mais aussi du tracé de lignes et d'autres opérations utiles. Déjà à l'époque certaines cartes étaient plus lentes que le CPU sur certaines opérations, et donc c'était délicat de bien utiliser ces fonctions.
Aujourd'hui, les fonctions 2D cablées ont disparu des cartes graphiques, l'accélération se fait via un GPU générique. Il faut donc un driver plus complexe permettant de programmer ce GPU et exposer une API qui va bien (OpenGL pour la 3D, OpenVG pour la 2D). Quand on aura ça, on pourra faire de nouveau de l'accélération 2D.
Le support est présent dans certains drivers (pour les vieilles cartes, donc) et on peut même utiliser les pilotes de BeOS dans Haiku puisqu'ils sont compatibles au niveau binaire. Mais l'app_server (notre équivalent de X11) n'utilise pas ces fonctions, pour les 2 raisons mentionnées: c'est plus lent et c'est moche car il n'y a pas d'antialiasing. Si quelqu'un se propose pour maintenir la version accélérée de l'app_server, les patches seraient acceptés sans problème. Mais, à mon avis, il est plus intéressant d'avoir d'abord la 3D accélérée (car là le CPU n'est pas encore assez puissant - encore que, on fait tourner de la 3D d'il y a 15 ans en rendu logiciel aujourd'hui). Pour la 2D on verra plus tard.
Enfin, quand je parle de machines "récentes", pour moi c'est "moins de 10 ans". J'ai encore un PC qui date de 2003 en état de marche (avec un peu plus de RAM qu'à l'origine il est vrai). Sur cette machine les performances de Haiku sont tout à fait acceptables (c'est un Athlon XP 2200+ avec 1Go de RAM). Je ne pense pas qu'on puisse avoir des performances acceptables sur une machine d'il y a 20 ans (un des tout premiers pentium de 1994): même si l'OS pouvait fonctionner, il serait impossible de lire une vidéo dans un format moderne (et même un MP3 ça risque d'être compliqué), ou d'afficher la moindre page web pleine de CSS et de Javascript. ça ferait donc un système rapide, mais quasi inutile.
[^] # Re: Petites machines
Posté par reno . Évalué à 5.
Bah, ça te fera une belle jambe tes 32Mo de RAM quand tu essayera de naviguer sur le web!
Je me souviens d'un site web pas spécialement graphique ou Chrome indiquait que la page faisait 300 Mo (probablement un bug du blog)..
Alors une machine ou tu ne peux pas vraiment naviguer sur le web, ça restreint beaucoup l’intérêt..
[^] # Re: Petites machines
Posté par Maclag . Évalué à 2.
J'espère que c'est pas la page, parce que ça fait lourd de la bande passante.
Pis avec une connexion à seulement 20Mbits/s (seulement?!) ça ferait 2min de chargement en supposant qu'on atteigne le max de la vitesse, ce qui n'arrive pas tous les jours non plus.
Ou alors c'est plutôt le script JS qui est dedans…
[^] # Re: Petites machines
Posté par reno . Évalué à 3.
Probablement oui. En tout cas, je n'aimerai pas naviguer sur le Web avec 32Mode mémoire..
[^] # Re: Petites machines
Posté par karteum59 . Évalué à 3. Dernière modification le 25 novembre 2014 à 11:39.
OK mais je trouve dommage que Haiku fasse le choix de ne marcher bien que sur des machines récentes (l'offre d'OS qui exige des machines récentes est assez vaste, alors que l'offre d'OS qui marche bien sur des machines anciennes est assez restreinte…)
L'antialiasing c'est sympa, mais ça reste de priorité secondaire pour moi (par rapport à avoir une machine rapide et fluide)
# dactylographie
Posté par ɹǝıʌıʃO . Évalué à 10.
Feuille de pommier,
micronoyau, nostalgie :
un appeau à geeks.
[^] # Re: dactylographie
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à 3.
Ho ! Une forme poétique codifiée d'origine japonaise !
Proverbe Alien : Sauvez la terre ? Mangez des humains !
[^] # Re: dactylographie
Posté par zurvan . Évalué à 3.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
# Qu'est devenu le code source officiel de BeOS
Posté par Emeric . Évalué à 4.
Bonjour,
ce que je n'ai toujours pas compris (et comprendrait peut-être jamais), c'est que Palm n'a rien fait, à priori, du code source de BeOS.
Puisque le projet était mort, Palm aurait pu libéré le code source non ?
[^] # Re: Qu'est devenu le code source officiel de BeOS
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 3.
Il y avait des problèmes de licences, de droits, de brevets. Bref, libérer le code source aurait coûté de l'argent à une société qui n'en avait déjà plus beaucoup.
[^] # Re: Qu'est devenu le code source officiel de BeOS
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
Avant la fin de Be, il y a eu un effort désespéré et de dernière minute pour libérer le code. Mais c'était déjà trop tard. On a quelques indices:
- Le code de la DeskBar (la barre des tâches) et du Tracker (le navigateur de fichiers) ont été libérés, et sont utilisés par Haiku.
- Une version "fuitée" de BeOS appelée "Dano" a été diffusée. Elle comporte plusieurs petits changements, mais en particulier remplace une bibliothèque SSL propriétaire par OpenSSL dans le navigateur web.
- Binder était une nouveauté prévue pour BeOS. Ce projet a été publié par Palm sous la forme d'OpenBinder, et il est nu des composants principaux d'Android. D'ailleurs une partie des développeurs de BeOS sont aujourd'hui employés par Google pour travailler sur Android.
Quelques fonctions de BeOS ont été intégrées dans PalmOS (dans la version 6, "Cobalt"). Donc on ne peut pas non plus dire que Palm n'a rien fait avec.
D'autre part, la socciété allemande Yellowtab a pu continuer pendant quelque temps le développement de BeOS (sous le nom de Zeta) après la fin de Be. Une possible collaboration entre Yellowtab (ou Palm) et Haiku était envisagée dès les débuts de Haiku, c'est d'ailleurs la raison du choix de la license MIT plutôt que de la GPL (afin de permettre l'utilisation du code de Haiku dans un projet commercial réuitlisant également des parties de BeOS). Cela a fonctionné quelques temps avec Yellowtab, mais ils n'ont pas trouvé de modèle commercial viable. Par la suite, une société appelée Magnussoft a continué à distribuer Zeta mais il n'y a plus vraiement eu d'évolutions, et finalement ils ont eu des soucis avec Access corporation (qui a récupéré les droits de BeOS après que PalmSource ait coulé… vous suivez?) car il semblerait que le contrat qui leur permettait d'utiliser les sources de BeOS se soit perdu en route quelque part.
[^] # Re: Qu'est devenu le code source officiel de BeOS
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 3.
Merci de ces infos, ça complète les zones d'ombres dans l'histoire de BeOS/Palm qu'on peut lire ailleurs.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
# wifi et imprimantes
Posté par palm123 (site web personnel) . Évalué à 3.
Je n'ai pu trouver dans les docs Haiku une liste de cartes wifi et d'imprimantes supportées.
Quelqu'un sait où trouver cela ?
ウィズコロナ
[^] # Re: wifi et imprimantes
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 7.
Il y a une liste des pilotes ici: https://dev.haiku-os.org/wiki/HardwareInfo
http://haikuware.com a également une liste de machines supportées.
# Parallels desktop
Posté par fredix . Évalué à 2.
Salut,
j'essaye de booter l'iso dans parallels desktop mais je n'ai que l'image de boot puis ca fige :( une possibilité ou il faut vraiment vmware ?
[^] # Re: Parallels desktop
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6.
ça marche aussi avec qemu et virtualbox, pour parallels je ne sais pas.
Si tu as essayé la version alpha de novembre 2012, peut être il vaut mieux tester un nightly build récent: http://download.haiku-os.org. Et inversement…
[^] # Re: Parallels desktop
Posté par fredix . Évalué à 4.
Bon j'ai suivi ce tuto avec l'image anyboot et ca marche pas mal meme le réseau https://www.haiku-os.org/guides/virtualizing/parallels-desktop
Merci !
# Clang ?
Posté par David Carlier . Évalué à 2.
J'ai cru voir quelquepart qu'une migration vers Clang est prevue dans le futur… toujours d'actu ?
[^] # Re: Clang ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
Pour l'instant, le truc qui coince c'est la compatibilité binaire avec BeOS qui nous force à utiliser un gcc 2.95.3 (avec pas mal de patchs…). C'est la principale raison qui motive cette tentative de faire une version 1 rapidement (c'est dans la roadmap du projet, la version 1 doit etre compatible avec BeOS). Une fois qu'on a sorti cette version 1, on pourra enfin démarrer le travail de mise à jour de l'API (il y a eu des améliorations, mais on commence à atteindre les limites de ce qui peut etre fait sans casser la compatibilité).
Comme à ce moment là il y aura une version stable et supportée de Haiku, de nouvelles applications pourront etre développées, et (on espère) remplaceront les quelques applications BeOS pour lesquelles il n'y a pas encore d'alternative crédible. Ensuite il n'y aura plus de problème pour casser la compatibilité et on pourra avancer.
Cela ne s'applique que pour la version x86 (et pas les versions x86_64 et ARM) de Haiku, c'est la seule ou la compatibilité est assurée. On a aussi un compilateur gcc4 pour compiler les applications modernes, bien sur. Donc, actuellement on peut remplacer gcc4 par clang (et ne pas avoir de compatiblité gcc2). Il reste un peu de travail pour:
- Améliorer le code en supprimant les warnings levés par clang (mais ce n'est pas toujours possible si le code doit continuer à compiler avec gcc2)
- Supprimer ou réduire le plus possible l'utilisation des extensions de gcc (idem)
- Tester le système ainsi compilé et vérifier qu'il n'y a pas de régressions (a priori non, ça a l'air de tourner comme il faut), et que le code généré est au moins aussi performant (ça n'est pas nécessairement le cas, la plupart des benchmarks de clang le teste avec un jeu d'instruction moderne (SSE, SSE2, SSSE, …) mais Haiku est toujours compilé pour une cible 586 (MMX, et rien d'autre) (pour la version x86 uniquement).
Donc, ça fonctionne déjà, mais c'est peu testé, donc il semble raisonable de sortir une version R1 dont on est surs qu'elle est stable et de faire ce changement ensuite (pour la version R1.1 ou R2, par exemple).
# Permissions
Posté par claudex . Évalué à 6.
Dans une précédente news, il était dit qu'il n'y avait aucune gestion des permissions. Ça avance de ce côté ou ça n'intéresse personne ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Permissions
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
"aucune", c'est pas tout à fait vrai. Il y a un support minimal t il ya eu dernièrement quelques corrections. Mais ça reste un des points qui ne sont pas prévus pour la version R1 de Haiku, c'est prévu pour plus tard (sauf si quelqu'un se lance là dedans…)
Il y a des réflexions en cours sur la façon de faire, on a des permissions de type UNIX mais il faut voir ce qu'on en fait, peut etre qu'elles seront utilisées pour sandboxer les applications comme dans Android.
# Haïku OS et l'éducation nationale
Posté par kuniyoshi . Évalué à 1.
@ pulkomandy : "Un projet qui existe depuis 14 ans, avec un développeur à plein temps (c'est moi!) financé par les dons des utilisateurs, je trouve que c'est déjà pas mal."
J'ai toujours regardé ce système évoluer de loin depuis ses débuts. (C'était effectivement il y a une quinzaine d'année car j'avais testé BeOS juste avant que cet OS disparaisse prématurément avec l'entreprise qui l'a créé… et j'avais bien aimé !) À cette époque, je cherchais un système capable de remplacer Windows Me. Non convaincu par le jeune OpenBeOS (je crois !), j'avais alors choisi la distribution Mandrake Linux.
Là je te tiens un (le ?) développeur d'Haïku OS. Donc, j'ai quelques questions à te poser pulkomandy :
Tu es français (ou du moins francophone ?), alors :
(1) Peut-on avoir Haïku OS 100 % dans la langue maternelle d'Évariste Galois ?
(2) Existe de une doc officielle dans la langue d'adoption d'Alexander Grothendieck ? Existe-t-il un site officiel 100 % traduit dans la langue maternelle d'Henri Poincaré ?
(3) Peut-on utiliser Haïku OS comme poste de travail (navigation sur le WEB + bureautique --> LibreOffice) et ce de façon stable et rapide (fluide) ?
Les réponses à ces questions peuvent conditionner le fait qu'un jour, Haïku OS se retrouve sur de vieilles machines (10 à 15 ans) du réseau pédagogique d'un collège… ;-)
Merci d'avance pour d'éventuelles réponses.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.