Le BASIC du Thomson TO8 a des instructions "turtle" pour utiliser une tortue comme en Logo. Je ne sais pas si c'est le cas d'autres versions du BASIC Microsoft, mais en tout cas, la tortue en BASIC, ça existe!
Le site passera en mode "lecture seule", puis dans un deuxième temps en mode "archive", proposant de télécharger une archive de chaque projet pour en extraire les données et les remettre en ligne ailleurs.
Ils ont également fourni des outils pour faciliter la migration sur d'autres plateformes (sans avoir besoin d'être administrateur du projet du côté google code).
De plus, avec un hébergement décentralisé (git ou mercurial par exemple), on peut de toutes façons retrouver tout l'historique du repo à partir d'un checkout des sources, donc il y a peu de chance d'avoir des choses définitivement perdues.
Conclusion: ça se passe beaucoup mieux que lors de la fermeture de berlios ou d'opensvn.
Ils ne sont pas partis d'un cadavre, ils ont développé tout ça y'a 10 ans quand Sourceforge, c'était cool, et que gitlab, ça n'existait pas. Et maintenant ça tourne, alors pourquoi migrer?
L'exercice est intéressant en tout cas, même si le résultat n'est pas forcément utilisable. ça permet de voir dans quelle mesure les langages de programmation existants sont plus ou moins influencés par l'anglais, par les notations mathématiques, etc.
Si on regarde les conventions de codage et de nommage souvent utilisées, on va trouver des choses du genre:
- une fonction doit être nommée par un verbe
- une variable doit être nommée par un nom
- utilisation de la notation hongroise pour marquer le type ou le rôle d'un objet dans son nom
Pourquoi ne pas inclure ces conventions directement dans un langage de programmation? Et du coup, est-ce qu'on ne pourrait pas enlever les mots clés utilisés actuellement pour exprimer la même chose?
Là, on se rapproche peut-être du BASIC, ou a$ est une chaîne de caractères, a% est un entier, etc (et le suffixe suffit au compilateur pour connaître le type des variables).
En utilisant le Latin dans Perligata, on obtient un langage assez verbeux, mais qui a la particularité d'identifier le rôle des objets utilisés par leurs déclinaisons et autres suffixes, plutôt que par leur position dans la phrase. Après, on peut "optimiser" le langage de programmation obtenu et utiliser des suffixes symboliques et plus concis, en essayant de conserver cette idée que l'ordre des mots n'est pas important.
Donc, le passage par l'Esperanto ou une autre langue permet peut-être d'exprimer des concepts d'une façon différente de l'Anglais, et du coup, d'arriver à un langage de programmation qui fonctionne différement, et éventuellement qui sera plus facile à prendre en main, même si au final on y met quand même de la notation symbolique.
L'anglais est concis en programmation parce que beaucoup de développeurs ont l'habitude de réfléchir en anglais, et de nommer les choses dans cette langue. Du coup dans les autres langues on a que des traductions, pas toujours heureuses, des concepts anglais.
Il est donc intéressant de voir ce qu'il peut se passer si on essaie de travailler avec un autre langage. L'utilisation de déclinaisons en Latin, et de préfixes et suffixes en Esperanto, par exemple (voir les commentaires au dessus et en dessous) permettent une conception assez différente d'un langage de programmation. Les mots dans ces langues sont "fortement typés" (verbe, sujet, complément) et du coup Lingua::Romana::Perligata arrive à se passer complètement de notations symboliques (du genre = pour l'affectation). ça ne serait pas possible avec l'anglais comme base car il y aurait souvent des ambiguïtés (sujet/complément en particulier).
C'est donc intéressant juste pour voir ce qu'il en ressort, à condition que ça soit un peu plus que juste un rechercher/remplacer des mots clés du langage et des noms de fonctions des bibliothèques standard.
J'ai entendu parler de Purism (https://puri.sm/) avec un projet de laptop entièrement libre (pas de blob firmware, etc) et avec du matériel qui n'a pas l'air mal. C'est encore en précommande, et je ne sais pas ce que ça donnera au niveau de la qualité et de la solidité (mais ils ont pas l'air d'etre du genre à faire des compromis). A surveiller, en tout cas…
Ce n'est pas impossible d'avoir un GC dans un système temps réel (ou n'importe quel autre système de gestion dynamique des allocations mémoire). ça complique un peu les choses, il faut avoir un GC exécutable de façon planifiée et avec un temps 'exécution borné, mais dont on est sur qu'il peut libérer au moins autant de mémoire qu'il en a été allouée depuis sa dernière exécution.
Le but du C est d'etre proche du matériel. Et toutes les architectures ne font pas la meme chose en cas d'overflow. ça peut faire un modulo, ou bien ça peut déclencher une exception matérielle. Dans le deuxième cas, tout le programme s'arrete (sauf si on intercepte le signal, etc). Donc: comportement indéfini pour tout le programe dans la norme C. Dans le cas contraire, soit certaines machines devraient intercepter le signal et faire le calcul du modulo, soit les autres devraient intercepter les overflows et lever une "exception" (ah mais ça n'existe pas en C ça).
Il y a pour cela plein de langages de plus haut niveau tout à fait appropriés et que le C n'essaie pas de remplacer. Avec des solutions différentes selon les cas: une machine virtuelle connue et maitrisée pour Java (avec un comportement bien défini), un système d'exception qui permet d'intercepter le problème en Ada, etc.
Sur les machines ou l'overflow d'un entier déclenche une erreur matérielle, Rust va devoir l'intercepter et reprendre l'exécution du programme. C n'a pas besoin de le faire. D'ou une simplification du runtime pour le C quelle que soit l'architecture cible.
En plus de ça, un git qui forcerait tout en minuscules ne serait pas pratique. On a besoin de versionner des fichiers avec des noms localisés et sensibles à la casse dans certains cas, et c'est bien que les outils puissent le gérer correctement.
Il y a plein de problèmes de ce genre avec git (par exemple, s'il y a un caractère non-ASCII dans le nom d'un fichier, pour que ça marche correctement sous Mac OS X qui code cela différement, il y a une option). Même chose pour l'encodage des caractères de fin de ligne, git peut les convertir automatiquement, ou pas, et c'est une option, configurable globalement ou par dépôt.
D'autres logiciels ont le même genre de problèmes, par exemple zip et unzip qui doivent convertir des noms de fichiers entre l'encodage "natif" du système et celui de la destination (ça peut être ASCII vers EBCDIC et inversement, une des codepages spécifiques de Windows vers de l'UTF8 et inversement, etc).
Sans ça, on reste avec le plus grand sous ensemble commun, c'est à dire que de l'ASCII, en minuscules, sans caractères spéciaux, et probablement avec des noms en 8.3 pour que tout le monde soit content. C'est bien, mais on est plus en 1980, et pouvoir nommer ses fichiers librement, c'est bien pratique.
Sinon, il y a Haiku qui est libre et qui fait les 2: une API stable et assez riche pour qu'on puisse developper des applications qui n'ont pas d'autres dependances que l'OS ; et aussi un gestionnaire de paquets qui permet d'avoir plusieurs versions d'une bibliotheque installees en fonction des besoins des applications. Et le tout avec un gestionnaire de paquets qui fait les mises a jour tout seul quand on le lui demande, en plus.
Mais justement, speedtest est parfait pour tester le lien ADSL ou fibre entre la maison et l'operateur auquel on s'interesse ici. Tandis que iperf permet de tester en plus le lien operateur <> internet (et c'est un autre probleme)
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.
ç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.
"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.
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).
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.
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!)
ç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…
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.
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.
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.
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?
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: Objectif, en pratique?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Ming Tea. Évalué à 1.
Le BASIC du Thomson TO8 a des instructions "turtle" pour utiliser une tortue comme en Logo. Je ne sais pas si c'est le cas d'autres versions du BASIC Microsoft, mais en tout cas, la tortue en BASIC, ça existe!
[^] # Re: quelques pépites perdues à jamais
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Fermeture progressive de Google Code. Évalué à 2.
Le site passera en mode "lecture seule", puis dans un deuxième temps en mode "archive", proposant de télécharger une archive de chaque projet pour en extraire les données et les remettre en ligne ailleurs.
Ils ont également fourni des outils pour faciliter la migration sur d'autres plateformes (sans avoir besoin d'être administrateur du projet du côté google code).
De plus, avec un hébergement décentralisé (git ou mercurial par exemple), on peut de toutes façons retrouver tout l'historique du repo à partir d'un checkout des sources, donc il y a peu de chance d'avoir des choses définitivement perdues.
Conclusion: ça se passe beaucoup mieux que lors de la fermeture de berlios ou d'opensvn.
[^] # Re: Et SourceSup
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Fermeture progressive de Google Code. Évalué à 2.
Ils ne sont pas partis d'un cadavre, ils ont développé tout ça y'a 10 ans quand Sourceforge, c'était cool, et que gitlab, ça n'existait pas. Et maintenant ça tourne, alors pourquoi migrer?
[^] # Re: Intérêt
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Et vous, à votre avis, pour où commencer une quête pour une chaîne de compilation espérantophone ?. Évalué à 3.
L'exercice est intéressant en tout cas, même si le résultat n'est pas forcément utilisable. ça permet de voir dans quelle mesure les langages de programmation existants sont plus ou moins influencés par l'anglais, par les notations mathématiques, etc.
Si on regarde les conventions de codage et de nommage souvent utilisées, on va trouver des choses du genre:
- une fonction doit être nommée par un verbe
- une variable doit être nommée par un nom
- utilisation de la notation hongroise pour marquer le type ou le rôle d'un objet dans son nom
Pourquoi ne pas inclure ces conventions directement dans un langage de programmation? Et du coup, est-ce qu'on ne pourrait pas enlever les mots clés utilisés actuellement pour exprimer la même chose?
Là, on se rapproche peut-être du BASIC, ou a$ est une chaîne de caractères, a% est un entier, etc (et le suffixe suffit au compilateur pour connaître le type des variables).
En utilisant le Latin dans Perligata, on obtient un langage assez verbeux, mais qui a la particularité d'identifier le rôle des objets utilisés par leurs déclinaisons et autres suffixes, plutôt que par leur position dans la phrase. Après, on peut "optimiser" le langage de programmation obtenu et utiliser des suffixes symboliques et plus concis, en essayant de conserver cette idée que l'ordre des mots n'est pas important.
Donc, le passage par l'Esperanto ou une autre langue permet peut-être d'exprimer des concepts d'une façon différente de l'Anglais, et du coup, d'arriver à un langage de programmation qui fonctionne différement, et éventuellement qui sera plus facile à prendre en main, même si au final on y met quand même de la notation symbolique.
[^] # Re: Intérêt
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Et vous, à votre avis, pour où commencer une quête pour une chaîne de compilation espérantophone ?. Évalué à 2.
L'anglais est concis en programmation parce que beaucoup de développeurs ont l'habitude de réfléchir en anglais, et de nommer les choses dans cette langue. Du coup dans les autres langues on a que des traductions, pas toujours heureuses, des concepts anglais.
Il est donc intéressant de voir ce qu'il peut se passer si on essaie de travailler avec un autre langage. L'utilisation de déclinaisons en Latin, et de préfixes et suffixes en Esperanto, par exemple (voir les commentaires au dessus et en dessous) permettent une conception assez différente d'un langage de programmation. Les mots dans ces langues sont "fortement typés" (verbe, sujet, complément) et du coup Lingua::Romana::Perligata arrive à se passer complètement de notations symboliques (du genre = pour l'affectation). ça ne serait pas possible avec l'anglais comme base car il y aurait souvent des ambiguïtés (sujet/complément en particulier).
C'est donc intéressant juste pour voir ce qu'il en ressort, à condition que ça soit un peu plus que juste un rechercher/remplacer des mots clés du langage et des noms de fonctions des bibliothèques standard.
# Lingua::Romana::Perligata
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Et vous, à votre avis, pour où commencer une quête pour une chaîne de compilation espérantophone ?. Évalué à 5.
ça me fait penser à Lingua::Romana::Perligata, un module Perl qui permet de programmer en… Latin:
http://www.csse.monash.edu.au/~damian/papers/HTML/Perligata.html
Un exemple est donné sur cette page avec l'algorithme du cribble d'Erathostène:
# Purism
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Superfish ou: j'ai rien compris au logiciel propriétaire. Évalué à 1.
J'ai entendu parler de Purism (https://puri.sm/) avec un projet de laptop entièrement libre (pas de blob firmware, etc) et avec du matériel qui n'a pas l'air mal. C'est encore en précommande, et je ne sais pas ce que ça donnera au niveau de la qualité et de la solidité (mais ils ont pas l'air d'etre du genre à faire des compromis). A surveiller, en tout cas…
[^] # Re: Un langage complexe ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 2.
Ce n'est pas impossible d'avoir un GC dans un système temps réel (ou n'importe quel autre système de gestion dynamique des allocations mémoire). ça complique un peu les choses, il faut avoir un GC exécutable de façon planifiée et avec un temps 'exécution borné, mais dont on est sur qu'il peut libérer au moins autant de mémoire qu'il en a été allouée depuis sa dernière exécution.
ça a été fait par exemple ici avec du Java: http://www.ghs.com/news/20100302_IS2T_java_support.html
[^] # Re: Une chose que j'ai oublié d'ajouter
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 10.
Le but du C est d'etre proche du matériel. Et toutes les architectures ne font pas la meme chose en cas d'overflow. ça peut faire un modulo, ou bien ça peut déclencher une exception matérielle. Dans le deuxième cas, tout le programme s'arrete (sauf si on intercepte le signal, etc). Donc: comportement indéfini pour tout le programe dans la norme C. Dans le cas contraire, soit certaines machines devraient intercepter le signal et faire le calcul du modulo, soit les autres devraient intercepter les overflows et lever une "exception" (ah mais ça n'existe pas en C ça).
Il y a pour cela plein de langages de plus haut niveau tout à fait appropriés et que le C n'essaie pas de remplacer. Avec des solutions différentes selon les cas: une machine virtuelle connue et maitrisée pour Java (avec un comportement bien défini), un système d'exception qui permet d'intercepter le problème en Ada, etc.
Sur les machines ou l'overflow d'un entier déclenche une erreur matérielle, Rust va devoir l'intercepter et reprendre l'exécution du programme. C n'a pas besoin de le faire. D'ou une simplification du runtime pour le C quelle que soit l'architecture cible.
[^] # Re: Est-ce vraiment une vulnérabilité de git ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Vulnérabilité dans Git et Mercurial sur certains systèmes de fichiers (FAT, NTFS, HFS+, etc.). Évalué à 5.
En plus de ça, un git qui forcerait tout en minuscules ne serait pas pratique. On a besoin de versionner des fichiers avec des noms localisés et sensibles à la casse dans certains cas, et c'est bien que les outils puissent le gérer correctement.
Il y a plein de problèmes de ce genre avec git (par exemple, s'il y a un caractère non-ASCII dans le nom d'un fichier, pour que ça marche correctement sous Mac OS X qui code cela différement, il y a une option). Même chose pour l'encodage des caractères de fin de ligne, git peut les convertir automatiquement, ou pas, et c'est une option, configurable globalement ou par dépôt.
D'autres logiciels ont le même genre de problèmes, par exemple zip et unzip qui doivent convertir des noms de fichiers entre l'encodage "natif" du système et celui de la destination (ça peut être ASCII vers EBCDIC et inversement, une des codepages spécifiques de Windows vers de l'UTF8 et inversement, etc).
Sans ça, on reste avec le plus grand sous ensemble commun, c'est à dire que de l'ASCII, en minuscules, sans caractères spéciaux, et probablement avec des noms en 8.3 pour que tout le monde soit content. C'est bien, mais on est plus en 1980, et pouvoir nommer ses fichiers librement, c'est bien pratique.
[^] # Re: Probablement bientôt?!
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Sans OS. Évalué à 3.
Sinon, il y a Haiku qui est libre et qui fait les 2: une API stable et assez riche pour qu'on puisse developper des applications qui n'ont pas d'autres dependances que l'OS ; et aussi un gestionnaire de paquets qui permet d'avoir plusieurs versions d'une bibliotheque installees en fonction des besoins des applications. Et le tout avec un gestionnaire de paquets qui fait les mises a jour tout seul quand on le lui demande, en plus.
[^] # Re: Débit symétrique
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Numéricable et moi.. Évalué à 4.
Mais justement, speedtest est parfait pour tester le lien ADSL ou fibre entre la maison et l'operateur auquel on s'interesse ici. Tandis que iperf permet de tester en plus le lien operateur <> internet (et c'est un autre probleme)
[^] # Re: Eh ben...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku se lâche enfin. É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 pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku se lâche enfin. É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: Permissions
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku se lâche enfin. É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.
[^] # Re: Clang ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku se lâche enfin. É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).
[^] # Re: Eh ben...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku se lâche enfin. É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 pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku se lâche enfin. É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: Parallels desktop
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku se lâche enfin. É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: Qu'est devenu le code source officiel de BeOS
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku se lâche enfin. É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: wifi et imprimantes
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku se lâche enfin. É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.
[^] # Re: Eh ben...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku se lâche enfin. É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: Petites machines
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku se lâche enfin. É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 pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku se lâche enfin. É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: Eh ben...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku se lâche enfin. É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.