Bayonne à l'extrêmité de la France? Alors qu'on peut, en partant de Bayonne, prendre un train pour Irun ou St Jean Pied de Port, qui sont encore plus loin?
Le codage de source vient des télécommunications où on a souvent une chaîne de traitement comportant un codage de source (consistant à encoder les données efficacement pour supprimer la redondance, c'est à dire, compresser), suivi d'un codage de canal, consistant lui à rajouter de la redondance, mais prédictible cette fois-ci (contrôle d'erreur, parité, CRC, …) afin que le récepteur puisse en tirer parti pour corriger les erreurs qui surviendront pendant la transmission du message.
On peut reconnaître que Windows 95 a fait un très gros travail sur l'ergonomie du système et obtenu un résultat plutôt réussi. Il a beaucoup influencé tout ce qui s'est fait par la suite, y compris de nombreux environnements de bureau Linux.
De là à les qualifier de clones, par contre, il faut peut-être pas exagérer.
Dans le cas de chez.com, il ne s'agit pas du propriétaire historique du service. Free a racheté le domaine et y propose une version de son offre "pages perso" non liée à un abonnement chez free.
L'hébergement proposé est extrêmement minimaliste (pas du tout de console d'administration par exemple) mais fonctionnel.
Chez Haiku on a fait le choix de réutiliser WebKit. ça se passe globalement bien, mais WebKit est 2 fois plus gros que tout le reste du système d'exploitation, et 10x plus long à compiler (environ 1h contre quelques minutes).
Pour WebKit je passe la plupart de mon temps à juste fusionner les changements qui viennent de l'upstream avec le portage pour Haiku. Pour avoir le temps d'en faire plus il faudrait que je travaille à plein temps sur le sujet (ce qui n'est pas possible pour 2 raisons: j'ai un emploi salarié à côté parce qu'on ne reçoit pas de donations de 100 000$, et je suis aussi responsable de plein d'autres projets autour de Haiku donc je pourrais difficilement passer tout mon temps exclusivement sur WebKit).
Et puis, il semblerait que développer un nouveau moteur est plus excitant et intéressant. De la même façon que, il y a 20 ans, Haiku a pu démarrer en choisissant de ne pas réutiliser un noyau Linux et de faire son propre truc, et que ça a attiré un certain nombre de développeurs qui voulaient s'attaquer à l'écriture d'un noyau, et qui ont donc évité d'autres projets BeOS-like qui faisaient un choix plus pragmatique de réimplémenter les APIs au-dessus de la pile logicielle GNU/Linux existante (noyau Linux, serveur X, etc).
Il n'y a donc pas que des considérations purement techniques qui entrent en jeu. Surtout pour Serenity, dont, pour l'instant, l'objectif n'est pas vraiment de concurrencer les "vrais" OS, mais de s'amuser à développer un système d'exploitation et de partager les connaissances acquises au passage.
Il y a du Javascript dans NetSurf (utilisant le moteur Duktape), le problème est surtout de "brancher" le javascript avec le DOM, d'une part parce que de la façon dont c'est fait acutellement, il y a un peu de code à écrire à la main pour chaque 'classe' HTML, et d'autre part, parce que ça rend dynamique des choses que le moteur de rendu supposait être statique avant l'introduction de Javascript.
Ce deuxième problème fait que ce n'est peut-être pas tout à fait déraisonable de ne pas se baser sur le travail de NetSurf (qui est par ailleurs plutôt bien pensé pour ce que j'en ai vu). Et il y a bien sûr le fait que l'équipe de Serenity travaille en C++, et que l'utilisation de NetSurf qui est écrit en C est assez peu confortable quand on a l'habitude du C++.
Je suis assez d'accord sur les comptes rendus de Waddlesplash, moi-même je ne comprend pas tout. Je préférais les miens quand je m'en occupais :o)
Mais ce n'est pas facile de présenter et de mettre en contexte les choses sur lesquelles on travaille (avec un "on" qui est globalement plusieurs autres personnes dont je ne suis pas forcément le travail de près). Et aussi, peut-être que le travail en ce moment dans Haiku est beaucoup "sous le capot" avec des optimisations de performances, des corrections de bugs obscurs tout au fond du noyau, …
Quelquefois on est surpris parce qu'un patch de 2 lignes fait en 5 minutes se retrouve relayé par tous les sites de news informatiques (phoronix, osnews, …), alors que des choses beaucoup plus intéressantes à notre avis et qui on fait l'objet d'un gros travail de fond, passent inapperçues.
La complexité est surtout pour les utilisateurs, pour plusieurs raisons. Pour les développeurs, le BIOS, non merci…
Quelques raisons:
UEFI fournit beaucoup plus de services en "standard": réseau, affichage graphique, … alors que pour le BIOS c'étaient des extensions: VESA, PXE, … dont on avait pas forcément besoin de se préoccuper si pas utiles (tout le monde ne fait pas de boot sur le réseau)
UEFI peut être configuré depuis l'OS (par exemple sur les machines Apple, on peut configurer un dual boot entièrement depuis le système d'exploitation en mode graphique). On peut aussi le manipuler un peu plus directement via des fichiers dans la partition EFI, ou via le "shell EFI" qui permet d'explorer toutes les fonctionnalités offertes.
Quand aux autres sujets:
Secure boot: comme son nom l'indique, l'objectif est de sécuriser le démarrage en s'assurant qu'on ne charge qu'un système d'exploitation qui a été validé par "quelqu'un de confiance". C'est une bonne protection contre les "rootkits" qui se glissent habituellement à ce niveau. Le problème est que le "quelqu'un de confiance", sur certaines machines, c'est uniquement Microsoft (pas partout, sur mon PC portable je peux ajouter mes propres clés de signature). Et l'autre problème c'est que tout le monde n'a pas envie de faire de la cryptographie pour installer un OS.
GPT: prépare l'arrivée des disques plus grands que 4To et supprime la limite à 4 partitions "primaires" par disque. Supprime quelques autres limitations, par exemple le type de partition qui été codé sur un seul octet (presque toutes les valeurs étaient occupées par des systèmes d'exploitation obsolètes des années 80) et le remplace par un identifiant sur 8 octets.
La disparition du "legacy mode": tout simplement car il n'est plus nécessaire maintenant que tous les systèmes d'exploitation savent démarrer en mode UEFI. C'est moins de complications d'avoir une seule façon de démarrer la machine. C'est plus simple pour l'OS car le firmware UEFI s'occupe de l'initialisation du CPU en mode 64 bit. Avec un démarrage de type BIOS, on démarre le CPU en mode 16 bit (comme un processeur Intel 8086, puis il faut passer en 32bits (ce qui demande quelques "acrobaties" avec la gestion du mapping mémoire) et ensuite passer en mode 64bit. Plein de choses pénibles qu'aucun développeur d'OS n'a envie de faire.
L'implémentation de UEFI est fournie par U-Boot. Je ne comprend pas pourquoi tu parles de firmware fermé. C'est un logiciel libre, U-Boot.
En plus de ça, il transmet un device tree au système lors de son lancement, et ce, qu'on utilise l'interface EFI ou pas. Mais le device tree, ça dit juste "il y a à l'adresse 42 un périphérique qui s'appelle LM90". Il faut fournir un pilote pour ce périphérique. Ce qui bien sûr ne pose pas problème pour un système d'exploitation comme Linux, mais ça en pose pour les bootloaders. On parle par exemple de GRUB, de Refind, etc. Qui permettent d'avoir un menu permettant de choisir quel OS on veut démarrer, les options qu'on veut passer au noyau, etc.
Sans EFI, chacun de ces projets devrait récupérer le device tree et forunir ses propres drivers. Pour les ports série, pour l'affichage sur l'écran, pour utiliser des périphériques USB (comme un clavier), pour lire des secteurs depuis un disque, …
C'est juste irréaliste de s'attendre à ce que chaque bootloader fasse tout ce travail sur chaque carte ARM ou RISC-V qui existe.
Alors on a deux solutions:
Abandonner l'idée d'avoir un bootloader un peu avancé. Ce sera seulement u-boot avec son interface en ligne de commande sur un port série uniquement, et puis on démarre directement un noyau Linux. Pas de dual boot, pas de moyen facile de changer les options du noyau si on a cassé un truc, etc.
Ou alors, il faut bien une interface un peu standardisée avec des trucs simples comme "affiche un pixel sur l'écran", "récupère les entrées au clavier", "charge un secteur depuis un disque" pour pouvoir avoir un outil simple qui se lance avant l'OS, et que cet outil n'aie pas besoin d'implémenter lui-même des drivers spécifiques pour tout le matériel comme ce serait le cas avec un device tree.
C'est aussi un projet qui est plutôt bon en marketing pour attirer les gens, en particulier avec beaucoup de vidéos youtube qui ont aidé à construire une grosse communauté.
Chez Haiku, on regarde et on se dit qu'on a raté un truc à ce niveau là, avec nos 15 contributeurs et nos donations annuelles au total qui arivent péniblement à 1/4 de cette unique donation pour un navigateur web
u-boot implémente un environnement EFI et peut lancer les exécutables EFI.
C'est le standard maintenant sur toutes les plateformes x86 et ARM64 et il n'y a aucune raison de faire autre chose pour RISC-V.
De mon point de vue de développeur, cela facilite pas mal le travail, on développe une fois un bootloader compatible EFI et il fonctionne partout en ayant juste besoin de le recompiler.
Open Firmware faisait presque la même chose, mais la standardisation n'est pas allée assez loin, par exemple, les versions PowerPC et SPARC utilisent des formats d'exécutables différents, ce qui oblige à avoir une édition de liens différente. Plein de choses n'étaient pas exposées de la même façon dans le device tree, ce qui entraîne beaucoup de code spécifique à chaque plateforme.
Avec EFI, tout est beaucoup mieux standardisé et c'est vraiment facile de faire tourner un bootloader sur n'importe quelle plateforme. Les "boot services" permettent d'afficher facilement un menu à l'écran, de trouver où est le rootfs et le noyau qu'on veut charger, et même de faire du boot en réseau.
Clairement, sur la version ARM de Haiku, c'est ce qui a permis de débloquer la situation qui n'avançait pas depuis 15 ans à essayer d'implémenter des drivers pour chaque cible qu'on a essayé d'utiliser. À chaque fois il fallait tout recommencer: nouveau pilote pour le port série, puis pour l'affichage, et pour les supports de stockage… tout ça avant d'avoir même pu commencer à charger le noyau et à avoir un quelconque outil de debug un peu pratique.
Avec EFI, on passe par le "firmware" (u-boot la plupart du temps sur les cartes ARM) qui va se charger pour nous de tous ces détails. Et donc notre bootloader n'a plus besoin d'aucun code spécifique à chaque plateforme.
La seule "bizarrerie" est le choix d'avoir des exécutables au format PE (le même que les .exe de Windows) plutôt que des ELF (comme Linux). Mais c'est un problème à régler une fois (avec un convertisseur de ELF vers PE) pour toutes les plateformes, et c'est juste un format de fichier.
Je ne tente même pas la comparaison avec u-boot avant EFI, ou y'avait… rien. Linux prenait le contrôle total de la carte, et devait venir avec ses propres drivers, toute la complexité étant donc dans le noyau Linux, et dupliquée dans tous les autres OS. Ou avec le BIOS sur les PC ou il faut comprendre 30 ans d'histoire de l'informatique et des machines à base de x86 (mode protégé, mode réel, utilisation d'instructions spéciales INT pour appeler les fonctions du BIOS, un peu de PCI pour trouver où se trouve la carte graphique…) avant de pouvoir faire quoi que ce soit.
Pour les systèmes à base de BIOS et de VESA, le serveur graphique de Haiku se retrouve à embarquer un émulateur de CPU x86 pour pouvoir appeler des fonctions VESA une fois que l'OS est lancé, sans devoir retourner en mode réel. Et on a rien inventé, on a repris quelque chose développé dans X11.
Et du côté du matériel, c'est pas mieux puisque les cartes graphiques qui embarquent un BIOS VESA ne fonctionnent que sur les machines x86. EFI permet de régler ce problème (comme le faisait Open Firmware) en définissant un format de bytecode qui sera interprété par le firmware. Résultat, on peut brancher une carte graphique PCI express sur un système avec un processeur RISC-V ou ARM64, et ça fonctionne, y compris pour afficher le bootloader sur l'écran.
Donc, oui, UEFI est nouveau et un peu plus compliqué, mais il règle tout un tas de problèmes et rend la vie beaucoup plus facile aux gens qui ont besoin d'interagir avec le bootloader.
Personellement les choses dont je me souviens le mieux à l'école, c'est plutôt par exemple:
La fois ou on nous a demandé de mesurer l'épaisseur d'une feuille de papier. La solution était de mesurer l'épaisseur d'un tas de 100 feuilles et de "découvrir" le principe de la division.
La fois ou on nous a demandé de tracer un triangle avec des côtés de 3 longueurs données, et il fallait comprendre comment utiliser un compas pour y arriver
Le "flowchart" pour l'accord du participe passé (si l'auxiliaire est 'être', aller à droite, sinon à gauche, si le COD est placé avant le verbe, etc)
Les exposés faits devant la classe, avec des sujets assez variés. Il y avait une élève qui a fait plusieurs exposés sur la pomme de terre, le riz, … avec dégustation à la fin (un gâteau à la fécule de pomme de terre par exemple)
Les pièces de théâtre basées sur des règles de grammaire (il y en avait plusieurs, une avec un jeu télévisé où l'animateur devait donner un mot et les candidat donner le masculin ou le féminin, et ça se terminait par des insultes entre les candidats: "- mandarin!" "- mandarine!")
La construction d'un jeu éducatif où il fallait relier les principaux fleuves français à leur nom à l'aide de trombones attachés à un fil électrique, permettant de compléter un circuit et allumer une ampoule en cas de bonne réponse
Apprendre à faire des recherches sur Minitel (à l'époque) pour trouver une addresse, puis écrire un courier pour demander des informations pour proposer une sortie scolaire. J'avais contacté le Futuroscope qui m'avait envoyé plusieurs brochures d'information
Une session de défis scientifiques ou il fallait par exemple faire entrer un oeuf dans une bouteille sans le casser, transpercer un ballon sans qu'il se dégonfle, etc.
Je crois que les idées de manquent pas pour enseigner les choses en faisant participer les élèves sans qu'ils aient besoin d'apprendre et de réciter une information qu'ils auraient pu trouver sur Internet en deux clics.
Par contre l'apprentissage par coeur des tables de multiplications, ça n'a jamais fonctionné malgré les tentatives de mes parents, pour fabriquer par exemple un jeu de "memory" ou il fallait appairer une opération avec son résultat. J'ai fini par développer un logiciel pour m'entraîner, ça m'a occupé pendant plusieurs années (au début j'avais rentré à la main les résultats de toutes les opérations, je n'avais pas pensé à demander à l'ordinateur de les calculer à ma place). Je galère toujours un peu avec le calcul mental, mais maintenant je suis devenu ingénieur en informatique et j'ai juste eu à installer une calculatrice dans mon ordinateur pour m'en sortir dans la vie.
Reddit’s revenue per monthly user is roughly $1.19, up from 2021 when it was about $0.81. Compare that to ~$10 per monthly active user for Twitter, ~$45 for Facebook, and ~$35 for Instagram.
Il y a donc une certaine marge entre simplement être rentable, et atteindre les attentes des potentiels investisseurs pour une introduction en bourse.
Introduction en bourse prévue dans quelques mois. Il vaut mieux être rentable avant, pour avoir une chance de se faire racheter par Elon où un autre milliardaire équivalent.
Je ne vois pas d'où vient l'impression de régularité face à d'autres sujets moins en rapport avec le site et qui reviennent au moins aussi fréquemment.
Personne n'a dit que le fait que ça revienne régulièrement soit exclusif à ce sujet en particulier.
Par contre, le fait que ça tourne en rond, je pense que si. Les sujets sur les banques il y a un nouveau truc de pire en pire à chaque fois, où bien ça ne parle pas tout le temps de la même banque.
Là, on parle du même système de notation sur le même site.
Après ça tourne en rond parce que personne ne sait vraiment décrire à quoi ça sert et que le status quo est préféré par les personnes les plus concernés,
Cet argument est facile à retourner: ça tourne en rond parce que personne parmi les gens qui trouvent le système actuel mauvais n'a proposé ni implémenté une meilleure solution
On joue le jeu de ce qui est proposé dans le journal, on met des commentaires pour dire "ce journal ne sert à rien" au lieu de cliquer sur inutile, et des commentaires pour dire "ce journal est super intéressant" au lieu de cliquer sur pertinent.
Si les gens auxquel le système actuel de vote ne plait pas étaient tous partis, on aurait pas ce journal ni tousles commentaires en-dessous.
Et le fait que oes notes négatives décourage les gens de poster, ben… c'est un peu le but du système. Oui, ça crée une "bulle" où on favorise certains contenus (pour des raisons propres à chacun des votants). Personellement je trouve que ça marche bien.
Pour reprendre l'exemple des commentaires de Zenitram, en général son premier commentaire où il dit un truc intéressant aura une note positive. Les 28 réponses en dessous où il répète à peu près la même chose parceque quelqu'un a esayé de lui répondre, c'est en général beaucoup moins intéressant à lire et ça finit avec une note négative. Je ne crois pas qu'on y perde grand chose, et si le sujet est vraiment passionnant on peut toujours déplier les commentaires pour les lire.
La probabilité qu'il se passe quelque chose est assez faible.
La lettre dit: "si vous utilisez les APIs YouTube, vous n'en respectez pas les conditions d'utilisations". Mais Invidious n'utilise pas ces APIs. Ce qui donne donc: "Google n'est pas content mais ils ne peuvent rien faire".
Je ne comprend pas bien le problème pour les inscrits, on peut configurer le site pour masquer les contenus avec une note négative, où avec une note très négative, où ne rien masquer du tout.
Donc si on ne veut pas que des choses soient masquées pour raison de note négative (si on aime lire les trolls inutiles, après tout, pourquoi pas), c'est possible. Et si on ne veut pas les voir, c'est possible aussi.
Si on supprimait le système de notes, on aurait plus que l'option "tout est visible, obligé de lire les messages qui sont collectivement considérés comme inutiles/pénibles/hors sujet/méchants/…". Option qui est déjà disponible pour les inscrits si ils le souhaitent.
[^] # Re: Ca me fait sourire cet article .....
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Le futur, c'est XML. Évalué à 4.
Ça a été remplacé par JSON et YAML qui font… la même chose en moins bien.
On aurait peut-être mieux fait de garder XML, en fait. Avec ses fonctionnalités innovantes comme par exemple:
[^] # Re: Toolinux rebrandé goodtech pour keep upstream avec Linagora
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Pub ou vrai attaque ?. Évalué à 5.
Ils ont perdu leur procès contre Bluemind qu'ils accusaient je crois de leur avoir volé leur code (open source), leurs clients, et leurs développeurs.
Cette histoire commence en 2014: https://linuxfr.org/users/ceciestuncompte-0/journaux/linagora-vs-bluemind
Continue ici: https://linuxfr.org/users/ceciestuncompte-0/journaux/linagora-vs-bluemind-la-suite
Puis ensuite en cours d'appel: https://www.lemondeinformatique.fr/actualites/lire-affaire-bluemind-linagora-retour-en-appel-maj-84811.html
Et en cours de cassation: https://www.lemondeinformatique.fr/actualites/lire-la-justice-donne-raison-a-bluemind-face-a-linagora-88805.html
[^] # Re: Villes à l'extrémité
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Isochrones de transports en commun. Évalué à 2.
Bayonne à l'extrêmité de la France? Alors qu'on peut, en partant de Bayonne, prendre un train pour Irun ou St Jean Pied de Port, qui sont encore plus loin?
[^] # Re: Compression sans perte ou encodage ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Des formats d'image. Évalué à 7.
Le codage de source vient des télécommunications où on a souvent une chaîne de traitement comportant un codage de source (consistant à encoder les données efficacement pour supprimer la redondance, c'est à dire, compresser), suivi d'un codage de canal, consistant lui à rajouter de la redondance, mais prédictible cette fois-ci (contrôle d'erreur, parité, CRC, …) afin que le récepteur puisse en tirer parti pour corriger les erreurs qui surviendront pendant la transmission du message.
[^] # Re: SerenityOS
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Cent mille dollars pour un navigateur. Évalué à 2.
On peut reconnaître que Windows 95 a fait un très gros travail sur l'ergonomie du système et obtenu un résultat plutôt réussi. Il a beaucoup influencé tout ce qui s'est fait par la suite, y compris de nombreux environnements de bureau Linux.
De là à les qualifier de clones, par contre, il faut peut-être pas exagérer.
[^] # Re: il y a plus de 3 ans
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Swift pour Mac OS 9. Évalué à 4.
Ce n'est pas récent en effet, mais ça fonctionne pour de vrai malgré la date de publication, et la lecture de l'article est intéressante.
Dans la catégorie des toolchains improbables publiées un 1er avril, il y a au moins un précédent, avec cette version de GCC pour les processeurs Intel 8086 et 8088: http://web.archive.org/web/20171029055208/https://blogs.mentor.com/embedded/blog/2017/04/01/announcing-sourcery-codebench-lite-for-ia16/
[^] # Re: Laché vos com
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Fermeture de la plateforme Skyblog. Évalué à 3.
Dans le cas de chez.com, il ne s'agit pas du propriétaire historique du service. Free a racheté le domaine et y propose une version de son offre "pages perso" non liée à un abonnement chez free.
L'hébergement proposé est extrêmement minimaliste (pas du tout de console d'administration par exemple) mais fonctionnel.
[^] # Re: L’art nous apprend-il quelque chose ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Cent mille dollars pour un navigateur. Évalué à 10.
Chez Haiku on a fait le choix de réutiliser WebKit. ça se passe globalement bien, mais WebKit est 2 fois plus gros que tout le reste du système d'exploitation, et 10x plus long à compiler (environ 1h contre quelques minutes).
Pour WebKit je passe la plupart de mon temps à juste fusionner les changements qui viennent de l'upstream avec le portage pour Haiku. Pour avoir le temps d'en faire plus il faudrait que je travaille à plein temps sur le sujet (ce qui n'est pas possible pour 2 raisons: j'ai un emploi salarié à côté parce qu'on ne reçoit pas de donations de 100 000$, et je suis aussi responsable de plein d'autres projets autour de Haiku donc je pourrais difficilement passer tout mon temps exclusivement sur WebKit).
Et puis, il semblerait que développer un nouveau moteur est plus excitant et intéressant. De la même façon que, il y a 20 ans, Haiku a pu démarrer en choisissant de ne pas réutiliser un noyau Linux et de faire son propre truc, et que ça a attiré un certain nombre de développeurs qui voulaient s'attaquer à l'écriture d'un noyau, et qui ont donc évité d'autres projets BeOS-like qui faisaient un choix plus pragmatique de réimplémenter les APIs au-dessus de la pile logicielle GNU/Linux existante (noyau Linux, serveur X, etc).
Il n'y a donc pas que des considérations purement techniques qui entrent en jeu. Surtout pour Serenity, dont, pour l'instant, l'objectif n'est pas vraiment de concurrencer les "vrais" OS, mais de s'amuser à développer un système d'exploitation et de partager les connaissances acquises au passage.
[^] # Re: \o/
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Cent mille dollars pour un navigateur. Évalué à 4.
Il y a du Javascript dans NetSurf (utilisant le moteur Duktape), le problème est surtout de "brancher" le javascript avec le DOM, d'une part parce que de la façon dont c'est fait acutellement, il y a un peu de code à écrire à la main pour chaque 'classe' HTML, et d'autre part, parce que ça rend dynamique des choses que le moteur de rendu supposait être statique avant l'introduction de Javascript.
Ce deuxième problème fait que ce n'est peut-être pas tout à fait déraisonable de ne pas se baser sur le travail de NetSurf (qui est par ailleurs plutôt bien pensé pour ce que j'en ai vu). Et il y a bien sûr le fait que l'équipe de Serenity travaille en C++, et que l'utilisation de NetSurf qui est écrit en C est assez peu confortable quand on a l'habitude du C++.
[^] # Re: SerenityOS
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Cent mille dollars pour un navigateur. Évalué à 5.
Je suis assez d'accord sur les comptes rendus de Waddlesplash, moi-même je ne comprend pas tout. Je préférais les miens quand je m'en occupais :o)
Mais ce n'est pas facile de présenter et de mettre en contexte les choses sur lesquelles on travaille (avec un "on" qui est globalement plusieurs autres personnes dont je ne suis pas forcément le travail de près). Et aussi, peut-être que le travail en ce moment dans Haiku est beaucoup "sous le capot" avec des optimisations de performances, des corrections de bugs obscurs tout au fond du noyau, …
Quelquefois on est surpris parce qu'un patch de 2 lignes fait en 5 minutes se retrouve relayé par tous les sites de news informatiques (phoronix, osnews, …), alors que des choses beaucoup plus intéressantes à notre avis et qui on fait l'objet d'un gros travail de fond, passent inapperçues.
[^] # Re: UEFI
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Premiers pas avec la carte Visionfive 2. Évalué à 6.
La complexité est surtout pour les utilisateurs, pour plusieurs raisons. Pour les développeurs, le BIOS, non merci…
Quelques raisons:
Quand aux autres sujets:
[^] # Re: UEFI
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Premiers pas avec la carte Visionfive 2. Évalué à 4.
L'implémentation de UEFI est fournie par U-Boot. Je ne comprend pas pourquoi tu parles de firmware fermé. C'est un logiciel libre, U-Boot.
En plus de ça, il transmet un device tree au système lors de son lancement, et ce, qu'on utilise l'interface EFI ou pas. Mais le device tree, ça dit juste "il y a à l'adresse 42 un périphérique qui s'appelle LM90". Il faut fournir un pilote pour ce périphérique. Ce qui bien sûr ne pose pas problème pour un système d'exploitation comme Linux, mais ça en pose pour les bootloaders. On parle par exemple de GRUB, de Refind, etc. Qui permettent d'avoir un menu permettant de choisir quel OS on veut démarrer, les options qu'on veut passer au noyau, etc.
Sans EFI, chacun de ces projets devrait récupérer le device tree et forunir ses propres drivers. Pour les ports série, pour l'affichage sur l'écran, pour utiliser des périphériques USB (comme un clavier), pour lire des secteurs depuis un disque, …
C'est juste irréaliste de s'attendre à ce que chaque bootloader fasse tout ce travail sur chaque carte ARM ou RISC-V qui existe.
Alors on a deux solutions:
[^] # Re: SerenityOS
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Cent mille dollars pour un navigateur. Évalué à 8.
C'est aussi un projet qui est plutôt bon en marketing pour attirer les gens, en particulier avec beaucoup de vidéos youtube qui ont aidé à construire une grosse communauté.
Chez Haiku, on regarde et on se dit qu'on a raté un truc à ce niveau là, avec nos 15 contributeurs et nos donations annuelles au total qui arivent péniblement à 1/4 de cette unique donation pour un navigateur web
[^] # Re: SerenityOS
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Cent mille dollars pour un navigateur. Évalué à 4.
Peut être parce qu'il y avait déjà GNUtep, Haiku et Arca Noe sur ces créneaux là, et il ne restait que Windows 95 de disponible?
[^] # Re: UEFI
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Premiers pas avec la carte Visionfive 2. Évalué à 7.
u-boot implémente un environnement EFI et peut lancer les exécutables EFI.
C'est le standard maintenant sur toutes les plateformes x86 et ARM64 et il n'y a aucune raison de faire autre chose pour RISC-V.
De mon point de vue de développeur, cela facilite pas mal le travail, on développe une fois un bootloader compatible EFI et il fonctionne partout en ayant juste besoin de le recompiler.
Open Firmware faisait presque la même chose, mais la standardisation n'est pas allée assez loin, par exemple, les versions PowerPC et SPARC utilisent des formats d'exécutables différents, ce qui oblige à avoir une édition de liens différente. Plein de choses n'étaient pas exposées de la même façon dans le device tree, ce qui entraîne beaucoup de code spécifique à chaque plateforme.
Avec EFI, tout est beaucoup mieux standardisé et c'est vraiment facile de faire tourner un bootloader sur n'importe quelle plateforme. Les "boot services" permettent d'afficher facilement un menu à l'écran, de trouver où est le rootfs et le noyau qu'on veut charger, et même de faire du boot en réseau.
Clairement, sur la version ARM de Haiku, c'est ce qui a permis de débloquer la situation qui n'avançait pas depuis 15 ans à essayer d'implémenter des drivers pour chaque cible qu'on a essayé d'utiliser. À chaque fois il fallait tout recommencer: nouveau pilote pour le port série, puis pour l'affichage, et pour les supports de stockage… tout ça avant d'avoir même pu commencer à charger le noyau et à avoir un quelconque outil de debug un peu pratique.
Avec EFI, on passe par le "firmware" (u-boot la plupart du temps sur les cartes ARM) qui va se charger pour nous de tous ces détails. Et donc notre bootloader n'a plus besoin d'aucun code spécifique à chaque plateforme.
La seule "bizarrerie" est le choix d'avoir des exécutables au format PE (le même que les .exe de Windows) plutôt que des ELF (comme Linux). Mais c'est un problème à régler une fois (avec un convertisseur de ELF vers PE) pour toutes les plateformes, et c'est juste un format de fichier.
Je ne tente même pas la comparaison avec u-boot avant EFI, ou y'avait… rien. Linux prenait le contrôle total de la carte, et devait venir avec ses propres drivers, toute la complexité étant donc dans le noyau Linux, et dupliquée dans tous les autres OS. Ou avec le BIOS sur les PC ou il faut comprendre 30 ans d'histoire de l'informatique et des machines à base de x86 (mode protégé, mode réel, utilisation d'instructions spéciales INT pour appeler les fonctions du BIOS, un peu de PCI pour trouver où se trouve la carte graphique…) avant de pouvoir faire quoi que ce soit.
Pour les systèmes à base de BIOS et de VESA, le serveur graphique de Haiku se retrouve à embarquer un émulateur de CPU x86 pour pouvoir appeler des fonctions VESA une fois que l'OS est lancé, sans devoir retourner en mode réel. Et on a rien inventé, on a repris quelque chose développé dans X11.
Et du côté du matériel, c'est pas mieux puisque les cartes graphiques qui embarquent un BIOS VESA ne fonctionnent que sur les machines x86. EFI permet de régler ce problème (comme le faisait Open Firmware) en définissant un format de bytecode qui sera interprété par le firmware. Résultat, on peut brancher une carte graphique PCI express sur un système avec un processeur RISC-V ou ARM64, et ça fonctionne, y compris pour afficher le bootloader sur l'écran.
Donc, oui, UEFI est nouveau et un peu plus compliqué, mais il règle tout un tas de problèmes et rend la vie beaucoup plus facile aux gens qui ont besoin d'interagir avec le bootloader.
# Les paris sont ouverts
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Nouveaux développements pour Opensource.com. Évalué à 6.
Pour l'instant il n'y a rien sur http://opensource.net , et https://opensource.network est déjà occupé par un serveur Mastodon avec 3 utilisateurs.
Quel est votre pari pour la nouvelle URL?
[^] # Re: Mince
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien ChatGPT est comme une calculatrice pour les mots. Les devoirs à la maison ne seront plus les mêmes.. Évalué à 8.
Personellement les choses dont je me souviens le mieux à l'école, c'est plutôt par exemple:
Je crois que les idées de manquent pas pour enseigner les choses en faisant participer les élèves sans qu'ils aient besoin d'apprendre et de réciter une information qu'ils auraient pu trouver sur Internet en deux clics.
Par contre l'apprentissage par coeur des tables de multiplications, ça n'a jamais fonctionné malgré les tentatives de mes parents, pour fabriquer par exemple un jeu de "memory" ou il fallait appairer une opération avec son résultat. J'ai fini par développer un logiciel pour m'entraîner, ça m'a occupé pendant plusieurs années (au début j'avais rentré à la main les résultats de toutes les opérations, je n'avais pas pensé à demander à l'ordinateur de les calculer à ma place). Je galère toujours un peu avec le calcul mental, mais maintenant je suis devenu ingénieur en informatique et j'ai juste eu à installer une calculatrice dans mon ordinateur pour m'en sortir dans la vie.
[^] # Re: racheté par Musk ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Pourquoi Reddit s’apprête à connaître un immense blackout . Évalué à 5.
Il y a donc une certaine marge entre simplement être rentable, et atteindre les attentes des potentiels investisseurs pour une introduction en bourse.
[^] # Re: racheté par Musk ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Pourquoi Reddit s’apprête à connaître un immense blackout . Évalué à 7.
Introduction en bourse prévue dans quelques mois. Il vaut mieux être rentable avant, pour avoir une chance de se faire racheter par Elon où un autre milliardaire équivalent.
[^] # Re: Pas que GNU/Linux
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Debian 12 : le début d'une nouvelle ère. Évalué à 5.
Et n'oublions pas les "ports" vers des architectures non officiellement supportées, les téléchargements se trouvent ici: https://cdimage.debian.org/cdimage/ports/12.0/
En plus du hurd i386, on y trouve du dec alpha, hp pa-risc, itanium, motorola 68000, powerpc gros-boutiste 32 et 64 bits, et sparc64.
[^] # Re: Pertinent et pourtant mal noté
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Suggestion : supprimer complètement les notes du site. Évalué à 7.
Personne n'a dit que le fait que ça revienne régulièrement soit exclusif à ce sujet en particulier.
Par contre, le fait que ça tourne en rond, je pense que si. Les sujets sur les banques il y a un nouveau truc de pire en pire à chaque fois, où bien ça ne parle pas tout le temps de la même banque.
Là, on parle du même système de notation sur le même site.
Cet argument est facile à retourner: ça tourne en rond parce que personne parmi les gens qui trouvent le système actuel mauvais n'a proposé ni implémenté une meilleure solution
(les deux sont probablement vrais).
[^] # Re: Pertinent et pourtant mal noté
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Suggestion : supprimer complètement les notes du site. Évalué à 4.
On joue le jeu de ce qui est proposé dans le journal, on met des commentaires pour dire "ce journal ne sert à rien" au lieu de cliquer sur inutile, et des commentaires pour dire "ce journal est super intéressant" au lieu de cliquer sur pertinent.
[^] # Re: Tu as une meilleure méthode à proposer ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Suggestion : supprimer complètement les notes du site. Évalué à 6.
Si les gens auxquel le système actuel de vote ne plait pas étaient tous partis, on aurait pas ce journal ni tousles commentaires en-dessous.
Et le fait que oes notes négatives décourage les gens de poster, ben… c'est un peu le but du système. Oui, ça crée une "bulle" où on favorise certains contenus (pour des raisons propres à chacun des votants). Personellement je trouve que ça marche bien.
Pour reprendre l'exemple des commentaires de Zenitram, en général son premier commentaire où il dit un truc intéressant aura une note positive. Les 28 réponses en dessous où il répète à peu près la même chose parceque quelqu'un a esayé de lui répondre, c'est en général beaucoup moins intéressant à lire et ça finit avec une note négative. Je ne crois pas qu'on y perde grand chose, et si le sujet est vraiment passionnant on peut toujours déplier les commentaires pour les lire.
[^] # Re: Campagne de communication
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien YouTube legal team contacted us · Issue #3872 · iv-org/invidious · GitHub. Évalué à 4.
La probabilité qu'il se passe quelque chose est assez faible.
La lettre dit: "si vous utilisez les APIs YouTube, vous n'en respectez pas les conditions d'utilisations". Mais Invidious n'utilise pas ces APIs. Ce qui donne donc: "Google n'est pas content mais ils ne peuvent rien faire".
[^] # Re: Considered harmful?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Suggestion : supprimer complètement les notes du site. Évalué à 5.
Je ne comprend pas bien le problème pour les inscrits, on peut configurer le site pour masquer les contenus avec une note négative, où avec une note très négative, où ne rien masquer du tout.
Donc si on ne veut pas que des choses soient masquées pour raison de note négative (si on aime lire les trolls inutiles, après tout, pourquoi pas), c'est possible. Et si on ne veut pas les voir, c'est possible aussi.
Si on supprimait le système de notes, on aurait plus que l'option "tout est visible, obligé de lire les messages qui sont collectivement considérés comme inutiles/pénibles/hors sujet/méchants/…". Option qui est déjà disponible pour les inscrits si ils le souhaitent.