Le 18 août 2001, le premier message sur la liste de diffusion de OpenBeOS était envoyé par Marcus Overhagen (« Ok, let’s start »). Quinze ans plus tard, le projet est toujours là, même si les progrès semblent un peu lents ces derniers temps.
Sommaire
- Le projet Haiku
- Historique du projet
- Évènements et conférences
- Vers une version bêta
- Nouveautés dans la communauté
Le projet Haiku
Haiku est un système d’exploitation compatible avec les applications et pilotes de périphériques écrits pour BeOS. Le but est de fournir un système léger et efficace pour les ordinateurs personnels.
Haiku est publié sous la licence MIT (en majorité, certains composants utilisent d’autres licences libres). Il propose une ABI stable, ce qui permet la diffusion de logiciels compilés, de façon durable.
Historique du projet
Durant les premières années du développement de Haiku, il n’était pas encore un système d’exploitation complet. Les premiers développements ont été faits sur la base de BeOS, dont l’architecture modulaire permettait le remplacement progressif des différentes parties du système. L’un des premiers développements complétés fut donc… la gestion des économiseurs d’écran.
Dès avril 2002, un premier prototype de l’app_server (l’équivalent du serveur X) permettait d’afficher une fenêtre. Mais, ce n’est que bien plus tard, en mars 2005, qu’il a enfin pu fonctionner sur un système intégralement compilé à partir des sources de Haiku, sans morceaux binaires de BeOS.
Les choses se sont enchaînées assez rapidement à cette période, avec la gestion du réseau (avril 2005), la mise en place du gestionnaire de fichiers Tracker (juillet 2005), puis le prise en charge de l’USB (septembre 2006). En 2007, s’ajoute le support des contrôleurs SATA, et en février 2008, il devient possible de compiler Haiku sous Haiku pour la première fois (auparavant la compilation s’effectuait depuis BeOS ou GNU/Linux).
Le 30 juillet 2008 voit les premiers commits de ce qui sera HaikuPorts, un équivalent des ports BSD. Assez simple au début, le format des recettes évoluera plus tard pour ressembler fortement au Ebuild de Gentoo, il est maintenant documenté sur le wiki du projet avec de nombreux conseils de portage. La catégorisation des ports reprend d’ailleurs celle de Gentoo.
En janvier 2009, c’est l’arrivée de GCC 4. Haiku continue d’utiliser principalement gcc 2.95.3 afin de maintenir la compatibilité avec les exécutables, pilotes et bibliothèques écrits pour BeOS, mais il est désormais possible d’utiliser gcc 4 pour les nouveaux logiciels, et donc de pouvoir bénéficier d’un support à jour des langages C et C++ (C99, puis C++11).
En septembre 2009, la première version (alpha 1) de Haiku est publiée. Elle est suivie d’une deuxième version alpha en 2010, apportant la prise en charge du Wi‐Fi (WEP) et un navigateur basé sur WebKit. La dernière version publiée est la version alpha 4, de novembre 2012. Elle apporte la gestion du WPA2 ainsi que de nombreuses autres améliorations (pilotes de périphériques, systèmes de fichiers, etc).
![WebPositive naviguant sur [[Gopher]]](http://img.linuxfr.org/img/687474703a2f2f70756c6b6f6d616e64792e746b2f64726f702f676f706865722e706e67/gopher.png "Source : http://pulkomandy.tk/drop/gopher.png")
Évènements et conférences
Les développeurs et utilisateurs de Haiku se retrouvent tous les ans au mois d’octobre à Düsseldorf pour BeGeistert, la conférence annuelle autour de BeOS et des systèmes compatibles. La conférence est suivie d'un « coding sprint », une semaine durant laquelle les développeurs sont réunis dans une salle pour travailler à plein temps sur le projet et faire avancer les choses.
Vous pouvez également rencontrer certains développeurs aux RMLL, au FOSDEM, au Capitole du Libre, aux JDLL ou à l’Alchimie tous les deux ans. Ce sont autant d’occasions pour donner des conférences et mieux faire connaître le projet.
Vers une version bêta
Depuis 2012, le développement continue, avec du travail sur le moteur HTML WebKit, les portages x86_64, PowerPC et ARM, la gestion des médias en streaming (webradios, par exemple), mais surtout la gestion de l’USB 3 (disponible dans les nightly builds depuis quelques semaines) et le gestionnaire de paquets, qui était la dernière grosse fonctionnalité manquante pour une version bêta de Haiku. Une grosse partie du travail consiste à mettre en place les serveurs qui se chargeront de compiler les paquets binaires pour les dépôts de logiciels, et de préparer les « recettes » contenant les instructions pour compiler ces paquets.
Malgré un délai un peu long depuis la dernière publication (plus de 3 ans), les choses avancent.
Les efforts de développement se concentrent actuellement sur plusieurs points, pour la livraison des versions bêta 1 puis R1 :
- le système de compilation automatique des paquets pour les dépôts de logiciels ;
- les pilotes de périphériques, en particulier l’USB 3 et les cartes graphiques Intel ;
- diverses nouveautés dans l’interface kit (l’API pour les interfaces graphiques) et des applications en bénéficiant ;
- l’intégration du « launch daemon », un gestionnaire de services. Auparavant, un simple script Bash suffisait à démarrer le système, mais cela ne s’interfaçait pas bien avec le découpage en paquets (chaque paquet devant modifier l’unique script pour s’intégrer dans la séquence de démarrage). Le launch daemon permet la déclaration des services chacun dans un fichier séparé, avec la gestion des dépendances et des évènements (montage des disques, connexion au réseau), ainsi que le redémarrage automatique des services en cas de crash.
Un travail de longue haleine est en cours pour corriger plusieurs problèmes détectés par Coverity et PVS Studio, deux outils d’analyse statique conçus pour détecter les problèmes de sécurité et certaines erreurs courantes. Ces deux outils commerciaux proposent une offre gratuite pour les projets libres, qui leur permet de tester leurs outils sur différentes bases de code. Les développeurs de PVS Studio ont également publié une analyse des problèmes détectés les plus intéressants.
La version bêta 1 de Haiku remplacera GCC 4 par GCC 5. Actuellement, c’est la version 5.3 qui est proposée dans les nightly builds, mais cela peut changer en fonction des versions publiées par le projet GCC.
Nouveautés dans la communauté
En dehors des évolutions de Haiku lui‐même, les choses bougent dans le projet et dans la communauté.
Le site Web de Haiku va migrer de Drupal 6 (en fin de vie) vers Hugo et Discourse. Cela le rendra plus adaptatif (responsive) et permettra de réorganiser un peu le contenu.
Haiku a cette année encore participé avec treize autres organisations au Google Code-In (GCI) donnant aux 13-17 ans une première expérience de contribution à des projets libres. Haiku participe à GCI depuis la première édition en 2010. Et, s’il n’a pas été retenu parmi les très nombreux candidats aux Google Summer of Code (GSoC) cette année, des participations antérieures ont apporté de nombreuses contributions (API de localisation, support IPv6, ext3, client natif NFSv4, additions invités pour VirtualBox, portage de libusb, du compilateur et runtime Go, d’OpenJDK, mise à jour du portage SDL 1.3, le support de l’architecture x86_64…), ainsi que des contributeurs réguliers.
Moins bonne nouvelle, les sites haikuware.com et bebits.com, qui étaient les dépôts de logiciels historiques pour Haiku et BeOS, sont maintenant hors ligne suite à des désaccords entre le propriétaire du site et le projet Haiku. Cependant, le nouveau gestionnaire de paquets les remplace avantageusement et plusieurs nouveaux dépôts apparaissent, qui sont compatibles avec ces nouveaux outils. On peut notamment consulter la liste des paquets en ligne sur Haiku Depot Server, le site qui permet d’annoter les paquets pour une belle présentation dans l’application Haiku Depot (icônes, captures d’écran, descriptions dans plusieurs langues, commentaires et évaluations).
D’autre part, le projet HaikuArchives rassemble le code source de nombreuses applications pour Haiku et BeOS, qui ont été abandonnées par leurs auteurs originaux. Ceci permet d’assurer la maintenance de ces applications, en attendant qu’elles soient reprises par de nouveaux développeurs. Pour la plupart de ces applications, les sources étaient déjà disponibles, mais certaines ont été diffusées pour la première fois par les auteurs originaux suite aux demandes du projet HaikuArchives. Une façon un peu inhabituelle, mais plutôt efficace, de produire du logiciel libre.
Enfin, Haikuports reçoit régulièrement des pull requests rajoutant de nouvelles recettes et correctifs. Plus de 140 personnes ont déjà participé.
Aller plus loin
- Le site de Haiku (979 clics)
- Page de téléchargement (228 clics)
# Comment ils font ?
Posté par yeahman . Évalué à 9.
Je me pose toujours la question: comment les développeurs font pour suivre et inclure dans leur OS toutes les avancées technologiques récente ?
Est-ce qu'ils n'ont pas l'impression de """"perdre leur temps"""" sur un OS qui n'aura probablement jamais de part de marché ou est-ce tout simplement pour le fun de construire / voir évoluer / utiliser un OS qui est finalement leur bébé ?
C'est une vraie question. Si quelqu'un a un retour d'expérience sur la question…
[^] # Re: Comment ils font ?
Posté par karchnu . Évalué à 10.
Une « part de marché » c'est avant tout un concept pour les entreprises qui font de l'argent sur un produit, ça ne s'applique pas à un logiciel basé sur du bénévolat. Les gens qui font des systèmes d'exploitation alternatifs, sauf s'il y a une entreprise derrière qui cherche à le vendre et qui n'a pas encore son public, ne se posera pas la question de la fameuse « part de marché ». On fait un système qu'on considère intéressant, qui apporte quelque-chose de nouveau, qui a une certaine philosophie.
Est-ce que les gens d'Haiku font ça uniquement pour le fun ? Peut-être. C'est aussi probable qu'ils y voient un fonctionnement différent des autres OS, plus intéressant. Quand on se lance dans ce genre de projet, on y voit surtout un intérêt personnel avant de penser aux autres.
[^] # Re: Comment ils font ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
Bonjour,
Pour ma part sur le projet Haiku, c'est l'OS que j'utilise sur mes machines chez moi, et je n'ai pas toujours le choix que de faire en sorte que ça fonctionne.
Il y a un côté expérience professionnelle (mettre sur son CV "j'ai codé une pile logicielle de gestion de l'USB3", ça fait classe). Et comme en plus le code est ouvert, un éventuel employeur peut aller fouiller dedans pour voir ce que ça vaut vraiment. Pour ma part, j'ai même eu la chance de travailler à plein temps sur Haiku pendant un an, en étant rémunéré par les dons de la communauté des utilisateurs. C'est une expérience enrichissante.
Avec Haiku, j'ai:
- Eu un job d'été pendant 2 ans lorsque j'étais étudiant (Google Summer of Code en 2009, puis un contrat directement avec Haiku, inc pendant l'été 2010),
- Appris le C++,
- Encadré des étudiants lors du Google Summer of Code, et des lycéens (13-17 ans) dans le cadre du Google Code-In,
- Appris à travailler en équipe dans un gros projet et à gérer des millions de lignes de code, avec svn puis git, et d'autres outils comme la gestion de tickets, les mailing lists, ou IRC,
- Appris à travailler à distance et en horaires décalés avec d'autres contributeurs, ce qui est bon pour l'autonomie,
- Travaillé à plein temps pendant un an sur un projet intéressant (la mise à jour du port de WebKit pour Haiku et de la pile HTTP en dessous),
- Rencontré plein de gens en animant des stands et présentations dans différentes conférences autour de Haiku et du logiciel libre,
- Le plaisir d'utiliser un OS auquel je peux contribuer pour résoudre des bugs et ajouter des fonctionalités,
- L'occasion de contribuer à plein d'autres projets (WebKit, SDL par exemple),
- Sûrement plein d'autres trucs que j'ai oublié où dont je ne me suis pas rendu compte.
En tout cas, j'ai appris plein de choses, rencontré plein de gens, et écrit des logiciels parfois plus utilisés que ce que j'ai fait dans le cadre d'un emploi "normal" d'ingénieur en informatique (ou il m'est arrivé de passer plus d'un an sur un projet qui a fini à la poubelle).
Dans les raisons qui ont conduit à la création de Haiku, il y avait aussi un besoin d'assurer une continuité après la fin de BeOS, pour la survie du petit écosystème qui s'était développé autour de ce dernier. Donc, on a des gens qui se sont mis à contribuer à un OS libre, pour pouvoir vendre leurs logiciels commerciaux, éventuellement non libres, fonctionnant dessus. On cite comme exemple (et c'est probablement le seul actuellement pour Haiku) TuneTracker Systems, qui fournit un système de gestion de stations radio fonctionnant entièrement sous Haiku depuis quelques années, et BeOS précédemment.
[^] # Re: Comment ils font ?
Posté par yeahman . Évalué à 1.
Merci pour le retour :)
[^] # Re: Comment ils font ?
Posté par Emeric . Évalué à 4. Dernière modification le 19 août 2016 à 11:49.
C'est exactement le problème qu'a rencontré SkyOS.
Le système est développé par une personne. Celle-ci en a eu assez de passer son temps à faire des drivers.
Après, ce type d'initiative est une bonne chose afin d'éviter de stériliser le marché des OS.
C'est grâce à ça qu'on peut choisir entre : Windows, MacOS X, les distributions linux, FreeBSD, OpenBSD, NetBSD, DragonFly BSD, les dérivés d'OpenSolaris…
[^] # Re: Comment ils font ?
Posté par Le Gab . Évalué à -6.
GhostBSD, NextBSD, Fusix d'Alan Cox et bientôt Fushia de Google.
Au moins, ce sont de vrais OS à part entière et non des abérrations telles qu'on le voit dans le monde Linux.
[^] # Re: Comment ils font ?
Posté par Tit . Évalué à 6.
Peux-tu préciser ta pensée ? qu'est-ce qu'un vrai OS ? Pourquoi des aberrations ?
[^] # Re: Comment ils font ?
Posté par Le Gab . Évalué à 10.
Les 2000 clones de debian qui se distinguent par un fond d'ecran et un nom à déchiffrer qui se disent toujours plus légères et réactives alors qu'ils utilisent la même base logiciel à quelques coups de awk/sed près.
Il y a un truc qui s'appelle "gestionnaire de paquet", un truc tres utile qui pourrait transformer une distro vanille, Debian, en Debian orienté sécu, dev, etc,… Inutile de créer une nième "entité légale" qui créera du bruit et ou pire (souvent) donnera une image cheap de GNU/Linux.
Les mainteneurs d'Haiku ont bien plus de mérite que les gus qui s'auto-proclament intégrateurs en defaçant la distro mère.
[^] # Re: Comment ils font ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 8.
Le monde serait plus triste sans http://hannahmontana.sourceforge.net/ et http://biebian.sourceforge.net/ .
[^] # Re: Comment ils font ?
Posté par Frank-N-Furter . Évalué à 6.
Ok! J'suis convaincu. J'install Hannah Montana Linux sur tous mes serveurs!
Depending on the time of day, the French go either way.
[^] # Re: Comment ils font ?
Posté par Le Gab . Évalué à 5.
T'as vu ce qu'elle est devenu au moins la Hannah Montana? :)
mmmoue? ou encore mokay…
L'art toussa…
[^] # Re: Comment ils font ?
Posté par ariasuni . Évalué à 2.
Y a une raison technique pour classer les distributions GNU/Linux ensemble mais pas les *BSD?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Comment ils font ?
Posté par barmic . Évalué à 9.
Les BSD et les distributions linux ne sont pas du tout organisées de la même façon.
Les distributions linux prennent une collections de projets (linux, une série de projets GNU, gnome, KDE,…) et font tout ce qu'il faut pour que ça fonctionne ensemble. Il y a pour chacun un projet upstream et l'intégration dans les distributions qui est au moins un minimum séparés.
Les BSD sont des projets qui font elle-même un base system qui constitue le socle de leur système (le kernel et les outils qui gravitent autour). Ça n'empêche pas de collaborer, mais il n'y a pas de séparation upstream/intégration comme pour l'univers linux.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Comment ils font ?
Posté par Vincent-Xavier JUMEL (site web personnel) . Évalué à 10.
[^] # Re: Comment ils font ?
Posté par chimrod (site web personnel) . Évalué à 8.
À cause de toi, depuis le retour de déjeuner je suis en train de relire la pièce depuis le début.
Je n'en suis qu'à l'acte 2, je ne te dis pas merci !
[^] # Re: Comment ils font ?
Posté par karteum59 . Évalué à 8.
Je t'invite à méditer cette citation qui a presque 25 ans :)
[^] # Re: Comment ils font ?
Posté par dinomasque . Évalué à 5.
La différence c'est que Linus a très rapidement obtenu quelque chose d'utilisable qui s'est transformé en succès planétaire au bout de quelques années.
Les développeurs de Haiku doivent avoir un moral d'acier pour avoir obtenu un semi-succès au bout de 15 ans : un clone un peu modernisé de BeOS mais qui n'est pas pleinement fonctionnel, a encore peu d'applications et surtout, a perdu toute son avance technologique.
Un "Media OS" (c'était la vocation annoncée par Be Inc. à l'époque) n'a plus beaucoup de sens aurjourd'hui. Bon gré mal gré, les OS grand public donne satisfaction pour la création multimédia (c'était le gros point fort de BeOS).
Ça m'attriste beaucoup de constater que BeOS (et ses dérivés) aujourd'hui est un hobby et est passé à coté de sa fenêtre d'opportunité.
BeOS le faisait il y a 20 ans !
[^] # Re: Comment ils font ?
Posté par Laurent Mouillart . Évalué à 10.
BeOS avait 15 ans d'avance, du coup avec 15 de retard Haiku OS est pile à l'heure. :-)
[^] # Re: Comment ils font ?
Posté par gnumdk (site web personnel) . Évalué à -2. Dernière modification le 19 août 2016 à 17:33.
Oui, mais BeOS n'avait pas 15 ans d'avance en IHM et ça se voit :-/
ps: je ne parle pas du thème hein…
[^] # Re: Comment ils font ?
Posté par xcomcmdr . Évalué à 4.
ça fait beaucoup penser à AmigaOS 3.9/4 ou à GNUStep.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Comment ils font ?
Posté par karteum59 . Évalué à 4.
Demi-succès ? Moi je trouve au contraire que c'est plutôt cool et valorisant d'aboutir à qqch qui marche aussi bien avec aussi peu de moyens :)
Et ce n'est pas le seul projet d'OS alternatif, il y en a des centaines, dont certains sont quand même pas mal aboutis ! Regarde par exemple Syllable ou AROS.
N.B. qqun sait-il ce que sont devenus Zeta et BlueEyedOS ? C'est mort ?
[^] # Re: Comment ils font ?
Posté par Guillaume Maillard (site web personnel) . Évalué à 9. Dernière modification le 19 août 2016 à 20:09.
Pour BlueEyedOS, on s'est fait piquer le nom de domaine en 2003… le plus drôle c'est que le malfrat héberge toujours un miroir du site de l'époque!
Les développements ont continué pendant quelques temps mais sans site pour communiquer, l’intérêt de tous a disparu. On avait pourtant une IHM pleinement fonctionnelle (app_server, etc…).
Il ne restait plus trop de travail pour avoir un desktop fonctionnel.
Le fait d'avoir comme kernel Linux (2.6 à l'époque) donnait un important gain de performance par rapport à BeOS sur la même machine. KDE et Gnome paraissait bien lent.
Avec les processeurs actuels, on ne peut plus trop se rendre compte des différences de vitesse.
Pour Zeta, n'ayant pas le code source et les droits nécessaires, ils n'ont pas pu faire évoluer l'OS. L'évolution matérielle a enterré rapidement le système qui ne bootait plus sur les machines modernes.
[^] # Re: Comment ils font ?
Posté par dinomasque . Évalué à 3.
C'est con pour BlueEyedOS :(
C'était le projet de "clone" de BeOS le plus prometteur (et de trèèèèèèès très loin le plus pragmatique).
BeOS le faisait il y a 20 ans !
[^] # Re: Comment ils font ?
Posté par zurvan . Évalué à 6.
Je viens de lire un article sur Fuchsia, le nouvel OS de Google, apparemment il y a 2 anciens de BeOS dessus (dont un, Travis Geiselbrecht, qui a également travaillé sur NewOS, base de Haiku), ainsi qu'un ancien de QNX : http://www.zdnet.fr/actualites/fuchsia-nom-de-code-du-mysterieux-nouvel-os-de-google-39840746.htm
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Comment ils font ?
Posté par reno . Évalué à 3.
Je pense que tu fais erreur: ces personnes ne cherchent pas "le succès rapidement": autrement ils auraient pris un noyau Linux ou *BSD et ils se seraient focalisés sur les couches hautes, mais ça n'est pas "sexy": réutiliser l'existant ça apporte des contraintes donc ça ne les attire pas, par contre développer quasiment tout depuis le début, ça oui ça leur plait donc le fait que ça dure longtemps n'est pas vraiment un problème pour eux.
Bien sûr (à mon avis), c'est juste reculer pour mieux sauter: à la fin il y a quand même le travail de 'peaufinage' chiant mais nécessaire (les pilotes de périphériques, les bugs bizarres, etc) et finalement les contraintes de l'existant.. ça explique pourquoi beaucoup de projets sont dans l'état 'presque fini' et y restent: les bureaux Linux sont champions pour ça..
Je suis plutôt d'accord avec ta conclusion: sur un ordinateur avec un CPU puissant, de la mémoire et un SSD, les OS classiques marchent (enfin) bien (merci les SSD).
[^] # Re: Comment ils font ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 9.
C'est (comme souvent) plus compliqué. Toujours dans le cas de Haiku, que je connaît bien.
Lorsque le projet a été lancé (en 2001, donc), Linux, c'était pas encore vraiment ça. Ubuntu n'existait pas, Debian était particulièrement compliquée à installer, la distribution à la mode, c'était Corel. Le support de l'USB arrivait à peine, le SMP était encore tout récent.
Il y avait en plus un problème de licence: dès le début, Haiku a choisi la licence MIT car elle permettrait, plus facilement que la GPL, de partager du code avec une éventuelle continuation propriétaire de BeOS. Utiliser un noyau Linux n'était donc pas possible.
Enfin, une des contraintes du projet était la compatibilité avec BeOS, sur tous les points, y compris les pilotes de périphériques (qui fonctionnent encore aujourd'hui sous Haiku). Et aussi, il y a des besoins spécifiques pour les APIs utilisateur auxquelles le noyau Linux n'aurait pas permis de répondre (je pense aux "ports", une IPC utilisée pour implémenter les BMessages et beaucoup d'autres choses dans Haiku).
D'ailleurs, le noyau de Haiku n'est pas parti de zéro, c'est un fork de NewOS, un noyau développé par un des ex-employés de Be qui travaille en ce moment sur Fuchsia chez Google.
Si c'était à refaire aujourd'hui, et sans la contrainte de compatibilité, il est probable qu'on utiliserait un noyau BSD (on emprunte du code chez FreeBSD, par exemple tous les drivers réseau).
Plus de lecture à ce sujet:
https://archive.fosdem.org/2016/schedule/event/could_haiku_become_bsd/
Et du code source (des morceaux de l'userland Haiku sur un noyau Linux ou BSD):
https://github.com/Ithamar/cosmoe
[^] # Re: Comment ils font ?
Posté par reno . Évalué à 3.
Mais Linux avait déjà une dynamique fortement positive et un avenir prometteur.
Oui enfin préférer miser sur "une éventuelle continuation propriétaire de BeOS" plutôt que sur Linux (même en 2001), comment dirais-je?
"il n'est pire aveugle que celui qui ne veut pas voir.."
Et ça n'explique pas pourquoi Haiku n'a pas pris un noyau BSD plutôt qu'un noyau développé par une seule personne.
[^] # Re: Comment ils font ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 7.
Cela a bien fonctionné avec Zeta, pendant plusieurs années, certains développeurs contribuant aux deux projets.
Pour les noyaux BSD et Linux, à l'époque le support du SMP était à base de Giant Lock, pas du tout en ligne avec ce que Haiku voulait faire. Il manquait la compatibilité des drivers avec BeOS qui était un des buts du projet. Et comme je l'ai indiqué, il manquait du support dans les noyaux Linux et BSD pour pas mal de choses, qu'il aurait fallu ajouter, en particulier au niveau des IPC qui permettent à différents processus de communiquer entre eux.
Il aurait donc fallu forker un de ces noyaux, et il aurait été difficile d'upstreamer les patches (encore aujourd'hui, Android a du mal à le faire pour des raisons similaires).
Alors c'est sûr que 15 ans plus tard avec un peu de recul, on peut dire que ça n'a pas été la meilleure décision prise dans l'histoire du projet. Mais ce n'était pas forcément évident à l'époque.
[^] # Re: Comment ils font ?
Posté par Francois Revol (site web personnel) . Évalué à 1.
Quand on fait une MàJ de Debian (ou n'importe-quelle autre distro) et qu'on attend 20min que les paquets se décompressent et se configurent, on sait qu'on a encore un peu d'avance avec Haiku :D
[^] # Re: Comment ils font ?
Posté par dinomasque . Évalué à 5.
Quand je subit une mise à jour Windows qui :
- met à genoux le CPU pendant 30 minutes à cause d'un bug qui met longtemps à être corrigé dans le téléchargement des mises à jour
- nécessite un redémarrage et une immobilisation complète du PC le temps que les mises à jour s'installe
… je me dit que 20 minutes de mise à jour en tâche de fond sous Linux c'est quand même super confortable :)
BeOS le faisait il y a 20 ans !
[^] # Re: Comment ils font ?
Posté par Francois Revol (site web personnel) . Évalué à 1.
Sauf que sous Haiku ça prend juste le temps de télécharger les paquets et ensuite c'est atomique et y a rien à décompresser.
Il me semble que certaines distros linux sur CD avaient déjà tenté ça aussi d'ailleurs.
[^] # Re: Comment ils font ?
Posté par Yth (Mastodon) . Évalué à 2.
Bah la compression sert en général à prendre - beaucoup - moins de bande passante, donc à avoir un téléchargement beaucoup plus rapide.
Mais ce que tu veux dire c'est que pour une mise à jour d'un logiciel ça ne récupère que les fichiers modifiés en laissant en place tout ce qui ne bouge pas ? Donc un gain par rapport à télécharger la nouvelle version toute entière, virer toute l'ancienne, mettre la nouvelle à la place, avec 95% des fichiers remplacés par eux-même ?
C'est une approche qui peut être pertinente pour des gros logiciels ou des jeux, mais pas pour des bibliothèques comme presque tout est binaire, presque tout est remplacé à chaque fois.
Et puis tout nettoyer et remettre au propre à aussi un certaine avantage de fiabilité face à une corruption d'un fichier d'un paquet, même si tu le remplaces par lui-même, s'il a été altéré sur ta machine (ça arrive, même sans virus ou fausse manip, on parle d'informatique quand même c'est de la magie et c'est chaotique) il sera remis au propre à la mise à jour.
Ou alors je n'ai pas compris :)
Yth.
[^] # Re: Comment ils font ?
Posté par ff9097 . Évalué à 2.
Sur Fedora, seul les deltas sont téléchargés
[^] # Re: Comment ils font ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2.
Les paquets sont stockés compressés sur le disque dur. Le format de compression utilisé (par blocs de 4K) permet de décompresser à la volée quand les fichiers du paquets sont lus (et la version décompressée est stockée dans le cache de fichiers en RAM).
Du coup, l'installation d'un paquet (ou même de centaines de paquets) est très rapide, il y a juste à copier les paquets dans /system/packages. Et la suppression est aussi très simple, puisqu'il y a juste à supprimer le paquet, et pas besoin de suivre les douzaines de fichiers installés un peu partout sur le disque.
[^] # Re: Comment ils font ?
Posté par Yth (Mastodon) . Évalué à 2.
Ah, c'est pas mal !
Mais du coup, une bibliothèque partagée va être dans un package compressé, ça gère comment les liens ?
Il maintient une liste virtuelle des fichiers, ou alors le chemin de la lib inclus le nom du package ?
Et question à la con, mais si tu veux par exemple utiliser l'icône d'un paquet donné dans un outil à toi, comme au pif un menu de sélection de navigateur web avec les icônes dedans. Tu y accèdes comment ? Il y a une facilité, type montage virtuel du fichier compressé (genre AVFS ou un pseudo-fs à-la-FUSE ?)
Yth.
[^] # Re: Comment ils font ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6.
Les paquets sont montés dans un "packagefs" qui fusionne les fichiers fournis par tous les paquets (plus des fichiers de configuration stockés directement sur la partition système dans certains dossiers). Du coup, c'est transparent pour les applications (sauf qu'elles ne peuvent plus écrire dans les dossiers qui sont composés uniquement du contenu des packages).
C'est un "vrai" système de fichier, pas de FUSE. D'ailleurs, le noyau de Haiku est lui-même stocké dans un paquet (non compressé, celui là), et il est extrait par le bootloader au démarrage du système.
Autre avantage: lors d'une mise à jour, on stocke les anciennes versions des paquets dans un dossier "state". Le bootloader est capable de booter une ancienne version du système stockée de cette façon, ce qui est très pratique en cas de mise à jour qui casse tout.
[^] # Re: Comment ils font ?
Posté par Yth (Mastodon) . Évalué à 3.
D'accord !
C'est super intéressant, ça donne un FS de base bien plus clair, et sans risque d'avoir des fichiers qui traînent.
C'est souvent la question que je me pose sous Linux : j'ai tout mes paquets installés proprement et tout, mais s'il y avait par erreur, hasard, bug, ou autre, des fichiers qui traînent de versions antérieures, comment je les trouverais ?
Sous Haiku cette question ne se pose pas, et basculer de version d'un logiciel se fait en deux secondes si tu as les deux versions du paquet sur ton disque.
De plus ils sont plus difficiles à modifier à ton insu.
Ça donne envie d'essayer Haiku tout ça…
Yth.
[^] # Re: Comment ils font ?
Posté par karteum59 . Évalué à 3.
En fait, ça n'est pas lié à Linux (au sens du kernel) stricto-sensu : il existe d'ailleurs des distros qui ne respectent pas le FHS :)
[^] # Re: Comment ils font ?
Posté par Yth (Mastodon) . Évalué à 2.
Oui, c'était un abus de langage, valable pour la grande majorité des cas, et tu as raison.
Bon, la solution GoboLinux qui fait des liens dans l'archi classique /usr /lib etc, ça a l'air un poil bourrin, et pas aussi souple puisqu'il faut un outil pour gérer ces liens. Je préfère, à choisir, une approche en filesystem d'union, mélanger des archives, ou des répertoires, dans une arborescence unique.
Plus élégant on va dire.
Yth.
[^] # Re: Comment ils font ?
Posté par Graveen . Évalué à 2.
C'est pas faux mais c'est difficilement applicable dans le cas présent :)
[^] # Re: Comment ils font ?
Posté par Francois Revol (site web personnel) . Évalué à 1.
Et si on arrêtait, sur qui pomperait-on pour "inventer" des trucs sympa dans Linux, comme le "tickless" que BeOS utilisait y a 15 ans déjà (et IRIX probablement avant aussi mais j'ai pas vérifié) ?
# Une autre philosophie
Posté par abriotde . Évalué à 4.
Il y a un véritable intérêt à avoir des OS comme Haiku ou ReactOS, ce sont les 2 seuls OS non "UNIX" Open-Source. Le seul autre OS non "UNIX" est Windows mais il est tellement propriétaire que même DOS n'est pas Open-Source. L'intérêt est donc de voir les avantages des système qui n'ont pas pour principes ceux du "tout est fichier" et du "tout sous forme de texte". L'intérêt aussi des BSD (ou Mac qui est basé sur BSD) par rapport à Linux, c'est que Linux est un OS au noyau monolithique alors que les BSD fonctionne sur une base de micro-noyau.
Alors certes vous me direz du moment que "ça marche". Ce qu'il se passe c'est que chaque solution a ses avantages et inconvénients. Alors certes ont peux tout faire avec un seul système et palier ses inconvénients mais d'un points de vue philosophique c'est bien dommage.
Dernier points, on peux voir dans un système peu utilisé un avantage en termes de sécurité (les virus classique ne fonctionneront pas dessus) mais c'est au pris d'une galère pour faire fonctionner le moindre logiciel…
[^] # Re: Une autre philosophie
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
Haiku est à peu près compatible POSIX, même s'il propose d'autres choses en plus et qu'il manque encore certains morceaux. Cela dit, c'est intéressant d'avoir un OS entier développé par la même équipe et ça permet d'expérimenter et de réaliser plein de choses qui seraient beaucoup plus difficiles autrement.
Et dans les OS libres, il y en a plein d'autres. Citons au hasard AROS, FreeDOS, OpenDOS, KolibriOS, Syllable. Certains beaucoup plus éloignés de POSIX que Haiku (je pense par exemple à Oberon
Utiliser Haiku pour la sécurité est une mauvaise idée, c'est de la sécurité par l'obscurité, ça ne marche pas très fort. On utilise quand même souvent les mêmes briques logicielles (OpenSSL, etc) et ce n'est pas forcément tout correctement intégré (on a pas de spécialistes en sécurité). Il vaut mieux aller voir du côté d'OpenBSD qui essaient de faire ça sérieusement, par exemple.
Par contre, tu as raison sur le fait que c'est bien d'avoir des systèmes différents pour des utilisations différentes. Haiku cible, pour cette raison, les ordinateurs personnels (pas les serveurs, pas les ordiphones, et pas non plus les systèmes embarqués). Le noyau Linux s'en sort plus ou moins bien dans chacun de ces domaines mais je ne pense pas qu'il puisse être parfait pour tout à la fois.
[^] # Oberon
Posté par macadoum . Évalué à -2.
Merci pulkomandy pour cette découverte, ça c'est vraiment bien perché comme OS !
[^] # Re: Une autre philosophie
Posté par flan (site web personnel) . Évalué à 5.
Tu oublies un peu vite Darwin ;) Darwin est un OS complet (mais sans interface graphique) qui est la base de macOS.
En gros, tu as le micro-noyau XNU, au-dessus tu as Mach (XNU + les outils BSD), encore au-dessus tu as Darwin (un OS complet en ligne de commande) et enfin tu rajoutes Cocoa et le reste de l'interface graphique pour obtenir macOS.
[^] # Re: Une autre philosophie
Posté par GuieA_7 (site web personnel) . Évalué à 10.
Les systèmes BSD classiques (FreeBSD, NetBSD, OpenBSD) utilisent aussi un noyau monolithique. En revanche XNU, le noyau de MacOS X (entre autres) est bien basé sur micro-noyau (mais c'est Mach, pas BSD), associé à un noyau BSD ; c'est du micro-noyau hybride puisque le noyau BSD reste monolithique et tourne en dans l'espace mémoire noyau (contrairement à un micro noyau tel que Hurd où les services sont fournis par des serveurs qui ne sont pas en espace noyau).
Sinon il y a plein d'autres OS libres alternatifs comme Plan 9 par exemple.
# Godot ?
Posté par macadoum . Évalué à 0.
J'ai vu Godot engine sur Haikuports, c'est fonctionnel actuellement sur Haiku ?
[^] # Re: Godot ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4.
Je pense que oui, mais sans accélération 3D, ça risque d'être lent. Je n'ai pas eu le temps de l'essayer.
[^] # Re: Godot ?
Posté par barmic . Évalué à 4.
C'est un port très attendu par la communauté !
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Haiku
Posté par ɹǝıʌıʃO . Évalué à 10.
À quinze printemps
Petit OS devient grand
Bêta droit devant !
# Toutes ces années de dev
Posté par Leniwce . Évalué à -8.
et tout ces OS pour aboutir a ce que faisait l'AmigaOS dans les années 90, afficher des fenetres et manipuler un curseur. LoL
attention chérie ça va moinsser
[^] # Re: Toutes ces années de dev
Posté par n0wic . Évalué à -10.
Et c'est quoi le défaut de l'AmigaOS au juste ? Il est pas stable ?
[^] # Re: Toutes ces années de dev
Posté par Leniwce . Évalué à -2.
Hein ?
attention chérie ça va moinsser
[^] # Re: Toutes ces années de dev
Posté par n0wic . Évalué à -10.
Je te demande en quoi AmigaOs a à rougir à coté de ces OS résolument modernes. Quelles sont les différences notables apportées selon toi par 20ans de progrès ?
Selon moi il n'y en aucune.
Sur AmigaOs tu pouvait dessiner un ballon qui tourne :
http://www.ioccc.org/2011/eastman/hint.html
Et on peu toujours le faire.
Peux tu le faire ?
Je ne vois aucun progrès. Les systèmes n'évoluent ni sur le plan technique ni sur le plan économique. Les vrai progrès sont à venir, il ne s'est RIEN passé en 20ans à cette échelle et l'actualité ne me fera pas mentir.
[^] # Re: Toutes ces années de dev
Posté par xcomcmdr . Évalué à 10. Dernière modification le 21 août 2016 à 16:11.
Depuis l'Amiga OS (liste non-exhaustive) :
- protection mémoire entre les processus
- PAE
- bit NX
- anti-virus & co. sophistiqués (ou toujours incroyablement stupides, c'est selon)
- ASLR
- avènement du 64 bits et prise en charge de plus de 4 Gio de mémoire
- séparation des pouvoirs entre les différents types d'utilisateurs (Administrateur ou non, basiquement)
- pilotes en espace utilisateur pour plus de stabilité
- prise en charge de autre chose que la plateforme m68k :p
- Avènement de OpenGL et DirectX
- Systèmes de fichiers sécurisés, journalisés, et avec compression transparente, liens symboliques, sparse files, etc… (genre, compare FFS et NTFS)
- prise en charge de l'UEFI et du Secure Boot
- j'en oublie beaucoup
je continue ? RIEN, vraiment ?!
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Toutes ces années de dev
Posté par zurvan . Évalué à 10.
n'oublie pas systemd
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Toutes ces années de dev
Posté par Leniwce . Évalué à 2.
Trop fort, je m'incline :D
attention chérie ça va moinsser
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Toutes ces années de dev
Posté par xcomcmdr . Évalué à 10. Dernière modification le 21 août 2016 à 17:09.
Aujourd'hui j'apprends que la stabilité, la sécurité, le multimédia, et la performance, et la robustesse du système de fichiers face aux crashs/etc, c'est pas utile…
Ok…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Toutes ces années de dev
Posté par n0wic . Évalué à -10.
Les pilotes les moins stables sont les pilotes graphiques propriétaires parsqu'ils apportent à chaque fois tout un lot de fonctionnalité qui ne sont pas forcément bien supportées et lorsqu'ils plantent peu importe qu'il soient en utilisateur ou pas tu perd ta session X.
Je ne suis pas sur que Wayland apporte beaucoup de sécurité à ce niveau là néanmoins le système n'a pas crashé, il peu freezer l'écran éventuellement mais reçois bien toujours des commandes.
Je n'ai jamais vu aucun pilote libre crasher totalement un noyau GNU/Linux.
[^] # Re: Toutes ces années de dev
Posté par ariasuni . Évalué à 2.
J’ai déjà eu des des gels du système avec nouveau. D’après ce que j’ai compris, c’est un cas particulier avec ma carte graphique et c’était y a un moment. Que ça soit le pilote non-libre ou celui développé en rétro-ingénierie, les deux ont longtemps été bugués (maintenant nouveau est plus stable et nvidia s’intègre mieux avec KMS).
Écrit en Bépo selon l’orthographe de 1990
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Toutes ces années de dev
Posté par Moonz . Évalué à 5. Dernière modification le 21 août 2016 à 16:51.
Je suis assez d’accord, mais il reste quand même selon moi une question vachement intéressante : est-ce que tout cela suffit à justifier le fait que l’on passe d’un OS + userland qui tourne sur 32-64 Mo de RAM (et je suis gentil, je remonte à l’époque de Amiga OS 3, pas 1.x) à l’obligation de posséder 4+ Go de RAM ?
Parce que je ne vois rien dans cette liste qui puisse réellement justifier « oui, on a besoin de 10x plus de RAM pour implémenter ça ».
[^] # Re: Toutes ces années de dev
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4.
On parle toujours de Haiku, là? Parce que la config minimale, c'est 192Mo de RAM, pour un système en version alpha (donc pas spécialement optimisé) et en plus, avec un noyau compilé en mode debug "paranoïaque" qui consomme un peu plus de ressources que la version "release". ça fait donc 3 à 6 fois plus de RAM.
Les OS qui ont besoin de 60 à 120 fois plus de RAM que AmigaOS3, je sais pas comment ils font pour tout remplir.
Et, oui, Haiku implémente l'ASLR, des systèmes de fichiers journalisés, la protection mémoire, la swap, etc.
[^] # Re: Toutes ces années de dev
Posté par xcomcmdr . Évalué à 5. Dernière modification le 21 août 2016 à 17:41.
Amiga OS (un OS pour plateforme m68k) se contente de 512 Ko de RAM. Et t'auras jamais besoin de plus de 8 Mo de RAM.
Mais t'auras jamais de protection mémoire avec Amiga OS < 4 (et la version 4 est pour PowerPC).
Tu compares Amiga OS 1/2/3 sur m68k à… quoi ? Windows 10 sur x86-64 ? Rien ne saurait être plus différent.
Mais bon, quelques faits historiques :
- Windows 95 (1995) : 4 Mo minimum, protection mémoire et mode préemptif uniquement pour les applications Win32. Win16/DOS tourne en mode multitâche coopératif et sans protection mémoire entre les processus (pour garder la compatibilité avec ces applis et un minimum vitale de mémoire requis très bas).
- Windows NT 4 Workstation (1996) - même IHM que Windows 95, kernel différent : 64 Mo requis, protection mémoire constante et constamment en mode multitâche préemptif.
Et aujourd'hui (30 ans après l'Amiga) :
Windows 10 se contente de 2 Go (alors qu'aujourd'hui tout le monde a au moins 4 Go), que ce soit en 32 bits ou 64 bits. Évidemment, la dedans il n'y a jamais que le kernel, il y a tout l'IHM, les services, Cortana, etc…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Toutes ces années de dev
Posté par Renault (site web personnel) . Évalué à 8.
On oublie la nécessité d'avoir le support de normes pour périphériques loin d'être triviaux et légers comme l'USB, le réseau, HDMI ou SATA…
On oublie la gestion de l'énergie, du plug and play, d'une pile de matérielle longue comme le bras, des langues (les traductions ça pèse), d'une meilleure intégration de tout ceci…
Ce qui est gourmand aujourd'hui, entre autre, c'est le multimédia et les IHM. Les fichiers sont de plus en plus lourds pour être de meilleure qualité (images, sons et vidéos) ce qui permet dans la foulée de concevoir des interfaces graphiques plus belles, plus riches et plus simples.
Et le Web a besoin de pas mal de ressources, certaines sites n'ayant pas grand chose à envier de certaines applications locales.
[^] # Re: Toutes ces années de dev
Posté par lockidor . Évalué à 1.
Techniquement parlant, les kernels modernes sont à l'aise dans ~100MB RAM (ce qui est partiellement explicable par le plus grand nombre de fonctions, les drivers divers et variés, les caches, les FS, etc.). Ce qui a besoin de 4GB de RAM, ce sont les DE, les navigos, les jeux, etc.
[^] # Re: Toutes ces années de dev
Posté par reno . Évalué à 7.
Tu es de très mauvaise foi avec ton exemple, la résolution d'un Amiga était pourrie et il n'y avais aucune sécurité, maintenant on a des moniteurs UHD et tout le monde est connecté à Internet, la sécurité n'est donc plus optionnelle, tout ça nécessite beaucoup de RAM.
En plus la "compétition" au niveau de l'OS et l’environnement de bureau qui utilise peu de RAM me parait plutôt ridicule quand on vois les besoins mémoires des browser web capable d'afficher les sites web actuels..
[^] # Re: Toutes ces années de dev
Posté par Moonz . Évalué à 0.
En quoi la sécurité nécessite beaucoup de RAM ?
(je suis tout à fait d’accord avec les résolutions d’écran)
[^] # Re: Toutes ces années de dev
Posté par reno . Évalué à 7.
Tu as raison, la sécurité en nécessite très peu de RAM (juste la gestion des droits d'accès des pages).
Après se faire la compétition sur qui a l'OS et la GUI qui prends 100, 200 ou 300 MO de RAM quand le navigateur web a besoin de plus de 4GO, bof..
[^] # Re: Toutes ces années de dev
Posté par Yth (Mastodon) . Évalué à 10.
La réponse tient à 90% en un seul mot : le web.
Plus précisément, le logiciel qui va te pomper tes 4Go de RAM, en cascade parce qu'il génère du travail dans les couches inférieures et par exemple va aussi accroître la RAM pompée par ton serveur X, c'est le navigateur internet.
Sans lui, tes 4Go sont inutiles.
Il peut y avoir des jeux qui pompent autant de ressources aussi, mais là personne ne niera les avancées énormes en terme de rendu et de puissance déployée pour en mettre plein la vue, mais comme c'est l'un des objectifs du jeu vidéo, c'est non critiquable.
Et dans un autre cas d'utilisation il y a les serveurs, qui peuvent utiliser des tonnes de RAM aussi, pour répondre plus vite et mieux. Typiquement un serveur de base de donnée, s'il gère 40Go de data, va répondre plus vite (a priori, dans le cas général bien sûr) avec 16Go de RAM qu'avec 128Mo.
Mais pour l'utilisateur desktop standard, toute ta réponse est à chercher dans le brouteur !
Et si tu veux faire tourner un brouteur modernement bloaté avec ses extensions indispensables, même sur Haiku, il continuera à te pomper des Go de RAM quand tu auras tes faceboucs, goggles mail, twitteur, et trois-cent trente quatre onglet et demi d'ouverts en parallèle dans dix-sept fenêtres différentes.
Maintenant tu as aussi d'autres couches modernement bloatées, inutile de nier qu'un Gnome ou un KDE pompe plus qu'il y a 15 ans, mais rien ne t'oblige à les utiliser pour profiter malgré tout à 100% des capacités de ta machine : l'apport est ergonomique pas fonctionnel (ergo ça unifie et simplifie ton utilisation, mais tu peux faire la même chose sans, avec d'autres moyens, moins intégrés, moins unifiés, en tout cas c'est leur objectif à Gnome et KDE).
Mais le brouteur, c'est devenu le cœur de l'utilisation, le vrai cœur de la machine, et c'est ça qui déglingue tes ressources à grands coups de Go, et de Ghz.
Et après une étude sérieuse digne des méthodes de la RACHE, il n'y a pas de différence significative (20% de ressources en plus ou en moins ne sont pas significatifs quand on parle de l'ordre de grandeur en Go de RAM) entre Firefox, Chrome, ou n'importe quel autre brouteur utilisant l'un des gros moteurs webs (Gecko, webkit, opéra…), pour avoir plus léger il faut taper dans des moteurs alternatifs, genre Vivaldi pour n'en citer qu'un.
Et ça restera malgré tout le gros point lourdeur de ta machine.
Le noyau Linux lui, il tourne toujours au poil avec une quantité de RAM pitoyable, ou même un processeur tout lambin (mon exemple d'utilisation est un ARM à 400Mhz, mono-cœur, avec 128Go de RAM, déjà bien assez gros pour Linux), et tu feras même très bien tourner un serveur X dessus avec un gestionnaire de fenêtre basique (type WindowMaker pour avoir un truc utilisable malgré tout), c'est l'étape d'après qui va tout foutre en l'air : ce que tu fais tourner DANS ton serveur X.
Yth.
[^] # Re: Toutes ces années de dev
Posté par Shuba . Évalué à 3.
Je pense que tu veux dire Mo ;)
[^] # Re: Toutes ces années de dev
Posté par Yth (Mastodon) . Évalué à 4. Dernière modification le 24 août 2016 à 11:44.
Oui, pardon ^^
Tellement plus l'habitude d'utiliser des Mo de nos jours, c'est « so XXème siècle » le Mo…
Ahem :)
Yth.
[^] # Re: Toutes ces années de dev
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
Mauvaise pioche: le navigateur Vivaldi utilise le moteur Blink (alors qu'il a été créé suite à la décision chez Opera d'utiliser… Blink!).
ça devient compliqué de trouver des moteurs alternatifs. Dans les libres, il y a bien NetSurf et Dillo, mais c'est loin d'avoir toutes les fonctionnalités nécessaires. Dans les non libres, il y a Presto (qui est toujours utilsé par Opera Mini, mais plus par Opera Desktop), et NetFront. Peut-être que Servo viendra un peu relancer les choses?
[^] # Re: Toutes ces années de dev
Posté par Gabbro . Évalué à 3.
Et le vénérable KHTML. Même si j'ignore s'il encore activement développé.
[^] # Re: Toutes ces années de dev
Posté par Yth (Mastodon) . Évalué à 5.
Ah fichtre, c'est la misère à suivre…
Bon, je récapépètte…
Gecko : Firefox, Icecat, Palemoon, Tor-browser, Seamonkey
Webkit/Blink : Arora, Chrome, Chromium, Dwb, Midori, Opera, Otter, Qupzilla, Rekonq, Surf, Vimb, Vivaldi, Xombrero
Netsurf
Dillo
Amaya
texte : elinks/links/lynx/w3m
Ça fait que des moteurs y'en a de moins en moins sur desktop en fait puisque Opera est passé à Webkit.
Et donc en gros il y a Netsurf en plus de Gecko et Webkit (et Trident, d'accord).
Donc une seule alternative non über-bloatée, mais forcément pas encore au niveau.
Webkit bouffe tout, c'est triste un peu :(
Yth.
[^] # Re: Toutes ces années de dev
Posté par whity . Évalué à 4.
Tu oublies le petit dernier, à savoir servo (le nouveau moteur made in mozilla, écrit en Rust).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Toutes ces années de dev
Posté par ariasuni . Évalué à 2.
Même si c’est extrêmement prometteur, il va sans doute falloir minimum un ou deux ans avant que ça puisse concurrencer les autres moteurs de rendu.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Toutes ces années de dev
Posté par Yth (Mastodon) . Évalué à 2.
Et puis c'est censé à terme remplacer Gecko non ?
Comme Blink par rapport à Webkit.
Et c'est la même équipe qui est à la base, donc même si le langage change, la culture restera la même, il devrait y avoir de grosses similitudes comportementales entre Gecko et Servo (ce qui n'est pas un mal, Gecko marche plutôt bien).
Yth.
[^] # Re: Toutes ces années de dev
Posté par ariasuni . Évalué à 4.
Ce n’était pas l’idée, mais si Servo tient toutes ses promesses, c’est probable qu’on commence à se poser la question. Pour le moment on y est pas encore et y a rien de prévu dans ce sens.
Sauf que Blink c’est juste un fork de Webkit, donc la situation est complètement différente.
Je ne crois pas que ça soit la même équipe (mais c’est difficile de trouver un résumé succinct de qui bosse sur Servo).
C’est pas vraiment le but justement. L’architecture de Servo est bien différente de celle de Gecko.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Toutes ces années de dev
Posté par Francois Revol (site web personnel) . Évalué à 1.
Oui enfin, le problème n'est pas tant le Web que ce que "les gens" (l'économie de marché ultra-libérale qui doit faire du profit par construction et donc vendre des trucs, donc mettre des pubs partout) en ont fait…
[^] # Re: Toutes ces années de dev
Posté par Michaël (site web personnel) . Évalué à 6.
C'est parceque la liste se concentre sur les innovations techniques et pas la partie “application.” Aujourd'hui n'importe quel ordinateur “grand public” peut-être utilisé pour faire du montage vidéo, audio, de la retouche photo, du calcul scientifique, de l'analyse de données, etc. alors que chacune de ces applications nécessitait des équipements spécialisés et onéreux à l'époque de l'Amiga OS et même jusqu'à l'aube des années 2000.
[^] # Re: Toutes ces années de dev
Posté par karteum59 . Évalué à 7. Dernière modification le 24 août 2016 à 21:22.
Linux fonctionne avec 16Mo de RAM sans souci (et probablement moins) avec un environnement uclibc/musl/busybox, etc. Je l'ai fait marcher sur des dongle routeurs à 5€ et j'ai quelques milliers d'OpenWRT en prod sur des machines avec 64Mo de RAM et 8 Mo de flash ! Par contre, si ta référence est une Ubuntu avec Unity (ou Gnome), des icônes en SVG, une résolution 4k, des drivers qui supportent OpenGL, la capacité de lire ou manipuler des photos/vidéos, plein de services qui tournent sur D-bus et plein de choses écrites en langage interprêté (Python/Perl/Bash), etc. effectivement les besoins hardware/RAM doivent être au dessus (mais on ne parle plus vraiment de la même chose dans ce cas :)
[^] # Re: Toutes ces années de dev
Posté par dinomasque . Évalué à 7.
Faisons un exercice de calcul simple.
Un écran en "HD" soit 1920*1080 pixels en 32bits = à peu près 8Mo.
8 Mo juste pour l'image affichée à l'écran. Sans compter les éventuels double/triple buffering (ni le fond d'écran)
Si on ajoute que les systèmes d'affichage modernes conservent dans un buffer l'affichage de chaque application, on arrive vite à des tas et des tas de mega-octets rien que pour l'affichage.
Et ça c'était avant l'arrivée des écrans 4K et 5K.
A quoi bon chipoter quelques (dizaines de) mega-octets pris par l'OS dans ce contexte ?
BeOS le faisait il y a 20 ans !
[^] # Re: Toutes ces années de dev
Posté par Francois Revol (site web personnel) . Évalué à 3.
Ah les icônes SVG… on a tenté dans ZETA, ça ramait à fond (surtout parce qu'on stocke les icônes dans des attributs étendus et que ça ne rentrait pas dans la place restante dans l'inoeud). Du coup pour Haiku on a créé un format spécifique, le HVIF.
[^] # Re: Toutes ces années de dev
Posté par Renault (site web personnel) . Évalué à 5. Dernière modification le 30 août 2016 à 10:21.
Ne prends pas les programmeurs pour des billes non plus. La plupart du temps le SVG des icônes d'interface est utilisé comme référence mais ce qui est affiché est un bête PNG généré par le cache logiciel dont il suffit de vérifier que les dimensions changent à nouveau pour réutiliser le SVG…
[^] # Re: Toutes ces années de dev
Posté par Francois Revol (site web personnel) . Évalué à 1.
Je prends les programmeurs pour ce qu'ils sont, j'en fais partie :P
Oui, sous GNU/Linux les thèmes peuvent avoir des icônes en SVG qui sont rendues en plusieurs résolutions, mais bon, c'est pas forcément le plus élégant. En tout cas Haiku tente de faire ça d'une autre manière.
[^] # Re: Toutes ces années de dev
Posté par Leniwce . Évalué à 0. Dernière modification le 21 août 2016 à 17:55.
Bien, c'est quand meme bien d'avoir 8/16/32G de RAM, ca permet avec gentoo/funtoo d'utiliser tmpfs pour la compilation.
PS: Comment fait-on pour continuer le fil de ce commentaire sans forcément répondre a quelqu'un ?
attention chérie ça va moinsser
[^] # Re: Toutes ces années de dev
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
Il y a un bouton « Envoyer un commentaire » en bas de page (différent de celui intitulé « Répondre »).
# Nostalgie
Posté par Nicolas Chevallier (site web personnel) . Évalué à 5.
Ca me rappelle des souvenirs, avec la démonstration de 4 vidéos QT sans saccade sur Bebox lors d'une Apple Expo à Paris. Le bon vieux temps ou on prenait le temps. Je trouvais cet OS révolutionnaire et j'ai toujours pensé qu'OS X serait basé sur Bebox…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.