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.
ça ne sera pas un TPM mais par exemple une carte à puces (accessible avec PC/SC) ou une Yubikey. Les outils et bibliothèques à utiliser ne sont pas les mêmes, ça serait trop facile :(
La commission ne se réunit que tous les 6 mois normalement. De là, 2 options possibles par exemple :
La pétition atteint le nombre de signatures nécessaires et doit être examinée cette fois-ci,
Le gouvernement organise une réunion spéciale de la commission pour classer la pétition à nouveau (mais ça va se voir qu'ils y mettent de la mauvaise volonté, non?)
Ça marche aussi pour les associations "d'intérêt général", qui doivent juste respecter quelques critères sans avoir besoin de démarches particulières. En cas de doute on peut demander à la préfecture de vérifier si une association est vraiment d'intérêt général, mais cette vérification n'est pas obligatoire.
[^] # 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.
[^] # Re: Rapport coût/bénéfice
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal LUKS, TPM et boulette. Évalué à 5.
ça ne sera pas un TPM mais par exemple une carte à puces (accessible avec PC/SC) ou une Yubikey. Les outils et bibliothèques à utiliser ne sont pas les mêmes, ça serait trop facile :(
[^] # Re: ctrl-c, ctrl-v
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Pétition pour la dissolution de la BRAV-M - Episode 2. Évalué à 2.
La commission ne se réunit que tous les 6 mois normalement. De là, 2 options possibles par exemple :
[^] # Re: Un peu HS, mais y avait le notre (Framasoft)
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Et les poissons d'avril ?. Évalué à 3.
Ça marche aussi pour les associations "d'intérêt général", qui doivent juste respecter quelques critères sans avoir besoin de démarches particulières. En cas de doute on peut demander à la préfecture de vérifier si une association est vraiment d'intérêt général, mais cette vérification n'est pas obligatoire.