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.
Le système crée lui-même son propre bruit, avec les discussions sur les notes, les accusations de cabale, des gens qui chouinent sur des méchants qui moinsseraient à vue au lieu de se demander s’il n’y aurait pas une vraie raison à ces notes négatives, etc.
En fait c'est ça le plus gros problème. Du coup je propose qu'on supprime les journaux qui parlent des notes, puisqu'on sait très bien que les notes ne seront jamais supprimées de toutes façons et qu'elle n'ont aucun effet comme tu l'as très bien expliqué.
Sur la question d'une carte de type SunPCI: je ne vois pas vraiment de problème supplémentaires sur les machines actuelles par rapport à celles de Sun. Mais le résultat sera tout aussi boiteux qu'à l'époque.
La carte n'est pas 100% compatible avec un PC normal, il y a besoin de plein de patchs dans Windows ou DOS pour la faire fonctionner, et le système pour intégrer l'image du système PC sur la station SPARC fonctionne mal, il vaut mieux passer par le port VGA dédié de la carte SunPCI avec un deuxième écran ou un boîtier commutateur pour switcher entre les deux.
Donc, oui, c'est faisable, mais l'intégration avec le système hôte pose pas mal problème. Peut être que ça marcherait mieux pour un OS moderne (pas Windows 3.11), où les applications font moins d'accès direct au matériel et on a peut-être une chance de tout intercepter au niveau des drivers.
Mais est-ce que ça vaut vraiment la peine de faire tout ça?
Quand j'ai besoin de gérer des signaux sous Linux, je le fait plutôt à l'aide d'tn signalfd qui permet de récupérer les évènements via un descripteur de fichiers et de les faire rentrer dans ma boucle d'évènements avec tous les autres trucs que mon code doit traiter. Ça rend pour moi les choses beaucoup plus simples, mais le traitement un petit peu moins immédiat.
Mais si le code est architecturé comme il faut, ça se comptera au pire en centaines de millisecondes.
Les optimisations sont déjà possibles en activant la "link time optimisation". Dans ce cas, les fichiers .o générés à partir de chaque .c contiennent un dump de l'AST plutôt que du code assembleur généré. Et c'est le linker qui finit le travail.
Mais ça pose 2 problèmes:
Par rapport aux "jumbo builds", on ne gagne pas de temps à re-parser les fichiers .h qui sont inclus plusieurs fois
La phase de link prend beaucoup de temps (puisque c'est à ce moment qu'on fait "vraiment" la compilation dans ce cas). Et cette phase est relancée systématiquement à chaque compilation pour le moindre changement d'un seul fichier
Donc ce n'est pas utile pour un build rapide.
Une approche intéressante serait peut-être d'avoir un "serveur" de compilation, un outil qui reste chargé en mémoire et qui conserve des morceaux de code précompilés, et qui recompile les parties nécessaires dès qu'on enregistre une modification sur un fichier. Un mélange de make, gcc et ccache avec des morceaux de distcc dedans? Mais ça remet beaucoup de choses en question, et quand on en arrive là, il faut peut-être se demander si on ne devrait pas passer à de la compilation just-in-time?
Le problème sur la NES est un peu compliqué, en résumé:
Sur la console originale, le port cartouche était sur le dessus et il n'y avait pas de protection contre la copie et pas de problème
Sur la NES, les cartouches contiennent un composant de protection contre la copie
Avec un port cartouche classique sur le dessus de la console, il serait facile pour un fabricant de cartouches pirates de fabriquer une cartouche dans laquelle on connecte une deuxième cartouche (originale). Ainsi, la puce de protection contre la copie de la cartouche originale est utilisée avec le jeu pirate
Pour éviter ça, le port cartouche est caché dans la console et protégé avec une trappe et un mécanisme de charnière. Impossible d'insérer 2 cartouches connectées ensemble
Ce mécanisme fait que la cartouche va légèrement forcer sur le connecteur dans la console et petit à petit, le déformer et rendre le contact moins efficace
Conclusion: c'est la faute des DRM et de l'obsolescence programmée.
Quant à la question sur la disponibilité des consoles: il n'est pas très difficile même aujourd'hui de trouver des consoles compatibles avec les cartouches de la NES. Des composants compatibles (appelés "NES on a chip") sont toujours fabriqués. En fait, certains ajoutent des fonctionalités supplémentaires tout en restant compatibles avec les jeux existants. L'avenir est donc assuré :)
Il y a aussi The toaster project ou l'auteur s'est dit: "tiens, si j'essayais de fabriquer un grille-pain en partant de rien, en allant chercher les matériaux nécessaires dans des mines?"
La conclusion est qu'il faut avoir beaucoup de temps à perdre, même en trichant sur plusieurs étapes (par exemple, il utilise un four à micro-ondes pour l'une des étapes de fabrication).
Je crois que je suis passé à l'école au bon moment (fin des années 90/début 2000) et j'ai appris les bases de l'informatique: les fichiers, le traitement de texte, un peu de tableur, et même à monter un site internet avec un éditeur wysiwyg et un client ftp. J'ai aussi appris à utiliser un fer à souder pour monter des circuits électroniques.
Quelques années avant, tout ça n'était pas enseigné à l'école ou au collège. Et quelques années après, je crois que ça a disparu, les gens pensant, apparament, que les enfants nés après 2800 ont toujours eu un téléhhone à la main et du coup ils sont capables de lire le code de la Matrice à l'oeuil nu. Et ben non, ça s'apprend et il faudrait remettre en place quelques cours d'informatique si on veut que les gens y comprennent quelque chose.
Il me semble (mais ça fait un petit moment que je n'ai pas relu ces livres…) que Atrus a essayé d'écrire une île avec un bateau déjà construit pour pouvoir facilement explorer l'océan autour.
Mais ça n'a pas fonctionné, et à la place, le bateau est étrangement fusionné avec la côte de l'île. Et ne peut pas servir à naviguer.
[^] # 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.
# Supprimer les contenus qui parlent des notes
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Suggestion : supprimer complètement les notes du site. Évalué à 10.
En fait c'est ça le plus gros problème. Du coup je propose qu'on supprime les journaux qui parlent des notes, puisqu'on sait très bien que les notes ne seront jamais supprimées de toutes façons et qu'elle n'ont aucun effet comme tu l'as très bien expliqué.
# SunPCI
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal fin de la compatibilité 16/32 bits pour l'architecture Intel X86: deux questions. Évalué à 2.
Sur la question d'une carte de type SunPCI: je ne vois pas vraiment de problème supplémentaires sur les machines actuelles par rapport à celles de Sun. Mais le résultat sera tout aussi boiteux qu'à l'époque.
La carte n'est pas 100% compatible avec un PC normal, il y a besoin de plein de patchs dans Windows ou DOS pour la faire fonctionner, et le système pour intégrer l'image du système PC sur la station SPARC fonctionne mal, il vaut mieux passer par le port VGA dédié de la carte SunPCI avec un deuxième écran ou un boîtier commutateur pour switcher entre les deux.
Donc, oui, c'est faisable, mais l'intégration avec le système hôte pose pas mal problème. Peut être que ça marcherait mieux pour un OS moderne (pas Windows 3.11), où les applications font moins d'accès direct au matériel et on a peut-être une chance de tout intercepter au niveau des drivers.
Mais est-ce que ça vaut vraiment la peine de faire tout ça?
[^] # Re: Utilisation
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal SIGUSR1, SIGUSR2,..., SIGUSR_N ?. Évalué à 3.
Quand j'ai besoin de gérer des signaux sous Linux, je le fait plutôt à l'aide d'tn signalfd qui permet de récupérer les évènements via un descripteur de fichiers et de les faire rentrer dans ma boucle d'évènements avec tous les autres trucs que mon code doit traiter. Ça rend pour moi les choses beaucoup plus simples, mais le traitement un petit peu moins immédiat.
Mais si le code est architecturé comme il faut, ça se comptera au pire en centaines de millisecondes.
# Réponse sérieuse
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal SIGUSR1, SIGUSR2,..., SIGUSR_N ?. Évalué à 6.
Il y a aussi les signaux entre SIGRTMIN et SIGRTMAX qui sont disponibles. Ça en fait une trentaine de plus sous Linux.
[^] # Re: compilateur ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Comment les "jumbo build" ont bavé dans les sources de Firefox. Évalué à 4.
Les optimisations sont déjà possibles en activant la "link time optimisation". Dans ce cas, les fichiers .o générés à partir de chaque .c contiennent un dump de l'AST plutôt que du code assembleur généré. Et c'est le linker qui finit le travail.
Mais ça pose 2 problèmes:
Donc ce n'est pas utile pour un build rapide.
Une approche intéressante serait peut-être d'avoir un "serveur" de compilation, un outil qui reste chargé en mémoire et qui conserve des morceaux de code précompilés, et qui recompile les parties nécessaires dès qu'on enregistre une modification sur un fichier. Un mélange de make, gcc et ccache avec des morceaux de distcc dedans? Mais ça remet beaucoup de choses en question, et quand on en arrive là, il faut peut-être se demander si on ne devrait pas passer à de la compilation just-in-time?
[^] # Re: Si seulement j'avais encore ma NES
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Premier jeu online pour Nintendo NES : Super Tilt Bro.. Évalué à 7.
Le problème sur la NES est un peu compliqué, en résumé:
Conclusion: c'est la faute des DRM et de l'obsolescence programmée.
Quant à la question sur la disponibilité des consoles: il n'est pas très difficile même aujourd'hui de trouver des consoles compatibles avec les cartouches de la NES. Des composants compatibles (appelés "NES on a chip") sont toujours fabriqués. En fait, certains ajoutent des fonctionalités supplémentaires tout en restant compatibles avec les jeux existants. L'avenir est donc assuré :)
[^] # Re: Mais comment faisait-on avant ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Facile à utiliser, Bug ou Feature?. Évalué à 3.
Il y a aussi The toaster project ou l'auteur s'est dit: "tiens, si j'essayais de fabriquer un grille-pain en partant de rien, en allant chercher les matériaux nécessaires dans des mines?"
La conclusion est qu'il faut avoir beaucoup de temps à perdre, même en trichant sur plusieurs étapes (par exemple, il utilise un four à micro-ondes pour l'une des étapes de fabrication).
# Ça s'apprend
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Facile à utiliser, Bug ou Feature?. Évalué à 8.
L'informatique, ça s'apprend.
Je crois que je suis passé à l'école au bon moment (fin des années 90/début 2000) et j'ai appris les bases de l'informatique: les fichiers, le traitement de texte, un peu de tableur, et même à monter un site internet avec un éditeur wysiwyg et un client ftp. J'ai aussi appris à utiliser un fer à souder pour monter des circuits électroniques.
Quelques années avant, tout ça n'était pas enseigné à l'école ou au collège. Et quelques années après, je crois que ça a disparu, les gens pensant, apparament, que les enfants nés après 2800 ont toujours eu un téléhhone à la main et du coup ils sont capables de lire le code de la Matrice à l'oeuil nu. Et ben non, ça s'apprend et il faudrait remettre en place quelques cours d'informatique si on veut que les gens y comprennent quelque chose.
# Précisions techniques
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal L’Art de l’écriture et le prompting . Évalué à 4.
Il me semble (mais ça fait un petit moment que je n'ai pas relu ces livres…) que Atrus a essayé d'écrire une île avec un bateau déjà construit pour pouvoir facilement explorer l'océan autour.
Mais ça n'a pas fonctionné, et à la place, le bateau est étrangement fusionné avec la côte de l'île. Et ne peut pas servir à naviguer.