On peut lancer un terminal sans serveur graphique via le pilote consoled, qui utilise la même méthode d'affichage que le debugger noyau et le debugger de l'espace utilisateur quand un service plante.
Cette console est lente, très incomplète, et globalement inutilisable à part pour dire "oui, techniquement c'est possible".
Ce qui fait le succès de Arduino, ce n'est pas la vente de matériel, c'est l'écosystème logiciel autour: une bibliothèqe standard facile à utiliser et portableur de nombreux modèles de cartes et de microcontrôleurs, un IDE pratique avec de la programmation facile (on branche un port usb et ça juste marche). Ça permet d'aller assez loin dans lwélectronique sans jamais toucher un fer à souder ou un datasheet de composant.
il y a une dizaine d'années, beaucoup de cartes et de microcontrôleurs étaient vendus sans un tel support, les fabricants vendaient juste le matériel et laissaient le soin à d'autres (Keil, IAR, …) de fournir les compilateurs et environnements de développement, et aux acheteurs des composants de se développer leurs propres bibliothèques. Maintenant ils ont pour la plupart compris l'intérêt de proposer une olution complète et des outils de développement accessibles gratuitement (ou encore mieux, libres). Et c'est un peu cette partie là qui fait toute la valeur d'un microcontrôleur aujourd'hui, alors que c'est celle qui n'est pas vendue (on paie le matériel, mais le choix d'un composant plutont qu'un autre va se faire surtout sur le logiciel disponible)
Il n'y a pas forcément de ligne directrice. Du point de vue de la qualité du code, un processus de revue existe depuis très longtemps, au départ c'était fait via une mailing list et après l'envoi de commits (c'était la façon la plus simple de procéder avec SVN), aujourd'hui, cela passe par Gerrit avec une revue avant commit. L'inconvénient est que parfois c'est un peu trop exigeant et c'est difficile d'intégrer un changement qui n'est pas parfait, cela peut décourager certains contributeurs.
Du côté de l'interface graphique, il y a un document "Haiku interface guidelines", mais c'est vrai qu'il y a une attention aux détails. C'est peut-être plus facile de se consacrer à ça quand le gros de l'interface a très peu changé depuis 25 ans, que pour d'autres projets qui sont un peu dans un changement continu de technologie ou de thèmes ou d'objectifs?
La roadmap avance doucement. Pour s'en rendre compte on peut regarder année par année:
Il faut noter que les tickets résolus sont déplacés vers la beta "en cours" au moment de la résolution. Chaque version beta reçoit plusieurs centaines de corrections, mais de nouveaux problèmes sont également découverts. Donc le nombre de tickets dans l'objectif "R1" baisse beaucoup plus doucement (mais ça baisse quand même). Si on garde le même rythme de -120 tickets tous les 4 ans (environ 30 par ans), on devrait voir la version R1 d'ici environ 18 ans.
Il s'agit d'un rapport trimestriel qui liste les avancées de ces 3 derniers mois uniquement. Pour les 3 mois précédents il faut regarder le rapport précédent, et ainsi de suite. L'équipe est toujours assez réduite (un développeur salarié, une grosse poignée de contributeurs sur leur temps libre, et quelques personnes qui participent de façon plus occasionelle). Cette année, on a entre 7 et 22 contributeurs chaque mois avec un total de 44 personnes différentes sur l'année (la dernière année où il y a eu aussi peu de monde, c'était en 2010, et les chiffres pour 2010 et avant sont faussés parce que on utilisait encore SVN qui ne préservait pas l'auteur pour les contributions externes). On est donc plutôt en effectif réduit par rapport à d'habitude, avec un seul contributeur qui réalise a lui tout seul plus de la moitié des commits (c'était le cas l'an dernier pour la première fois, jusque là, les choses étaient beaucoup plus réparties, mais il n'y avait pas un contributeur salarié à plein temps). Avec environ 1000 à 1500 commits par an, on est loin du record de 2009 ou on avait dépassé 5500 commits. Cependant, les changements de mode de revue du code font que les changements ont tendance à apparaître sous forme d'un seul commit bien testé et finalisé, au lieu de multiples petits changements et correctifs.
On peut aussi regarder du côté de Haikuports, les courbes se sont croisées avec l'introduction en 2012 du gestionnaire de paquets, et on voit beaucoup d'activité sur le portage et le développement de logiciels, plutôt que sur le système lui-même.
Ça fait longtemps que ce n'est plus du tout rentable de miner du bitcoin avec une carte graphique, il existe maintenant des puces dédiées exclusivement à cet usage qui sont (un peu) moins gourmandes en énergie
(c'était une plaisanterie, plus personne n'a de chaîne hifi ni de CD à écouter avec, et je suis prêt à parier qu'on pourra très facilement envoyer le son de Spotify en MP3 compressé vers une enceinte Bluetooth avec un protocol de compression audio avec perte, en utilisant la Steam Machine).
Peut-être que j'aurais plutôt du parler d'une sortie péritel pour éviter tout risque d'être pris au sérieux?
Ça veut aussi dire que le mot de passe se retrouve dans le buffer du terminal, qui potentiellement se retrouve swappé et donc enregistré sur le disque dur, où on peut le récupérer une fois la machine éteinte (ou de façon sûre, en mettant la machine en hibernation prolongée). Normalement on fait attention que les mots de passe ne soient stockés que dans des zones non enregistrables sur disque et de bien l'effacer avant de libérer la mémoire en question.
Tu noteras que les problèmes du C sont connus, bien documentés et malgré tout avec les années on a toujours un taux de faille élevé dans un domaine qui pourrait être réduit à presque zéro dans d'autres langages.
Il peut être réduit à strictement zéro, en fait, avec des environnements à machine virtuelle comme LISP (dont les supporters ralaient dans le;années 60 sur les développeurs utilisant des langages compilés unsafe avec exactement les mêmes arguments que les supportes de Rust utilisent aujourd'hui) ou SmallTalk. La raison pour laquelle ça n'a pas pris, c'est qu'il y avait un coût en performances relativement important. Rust a fait tomber cette limite (et encore, je vais faire grincer des dents des développears Ada en disant ça).
Je développe moi aussi beaucoup de C++, mais il faut arrêter d'essayer de présenter les inconvénients du langage (pas memory safe, pas de système de build standardisé, pas d'outil de gestion des dépendances, par de règle de formattage et de nommage standardisées) comme des avantages.
Avec Cargo, on peut récupérer plein de bibliothèques bien implémentées pour tout un tas de trucs,et personellement j'ai tendance à avoir plus confiance dans ces bibliothèques oue dans ma capacité (ou celle de mes collègues) à réimplémenter les choses de façon sécurisée et avec de bonnes performances. Et puis en plus, j'ai autre chose à faire que développer pour la 72000ème fois un arbre binaire ou une autre structure de base…
mise-a-jour par les mainteneurs de ta distribution Linux,
Je ne vois pas trop bien pourquoi on fait une confiance aveugle aux distributions Linux mais pas à Cargo. Par exemple, Arch avec AUR ne fait pas mieux d'un point de vue validation de la sécurité des dépendences incluses? Qu'en est-il de Debian par exemple? Si Debian package une bibliothèque avec des failles de sécurité, volontairement ou non, qu'est-ce que ça change par rapport à une vulnérabilité arrivée par Cargo? Est-ce que Debian a un process de relecture complète du code de chaque version des logiciels qu'ils packagent pour que tu n'aies pas besoin de le faire? Je ne crois pas. Tout ça repose sur de la confiance.
Surtout que les dépendances dans les projets Rust ne se mettent pas à jour toutes seules dans le dos des développeurs, il faut faire soi-même la montée en version (et vérifier au moins que cela fonctionne bien).
Et puis quand ta distribution ne package pas le logiciel dont tu as besoin, en C ou C++, tu te retrouves avec… ben rien du tout pour faire le suivi, il faut gérer ça soi-même. Et de mon expérience, ça arrive relativement souvent.
Je ne comprend pas pourquoi le débat est parti sur l'authentification pour grosboobs.com et parissportifs.fr. Le texte de départ parle de fournisseurs de mail, chat, et services de messagerie (d'ailleurs, le projet s'appelle ChatControl).
Ce qui pose d'autres problèmes, par exemple si vous hébergez un serveur IRC, est-ce que c'est à vous de vérifier l'identité des personnes se connectant à ce serveur, et comment ça se met en place dans ce cas où le protocole n'est pas vraiment prévu pour?
Je confirme: on a beau mettre en places tous ces trucs, le nombre de bugs causés par une mauvaise gestion de la mémoire reste important (sans forcément parler de failles de sécurité, à ma connaissance personne n'en a trouvé dans le projet). On a plutôt de bêtes déréférences de pointeurs null, des use after free, ou des hroblèmes de partage de données entre threads.
Je ne suis pas développeur dans le noyau Linux et si je peux éviter de faire du C, j'en suis très content. Je n'ai donc pas de "il faudrait" à leur donner ou personne à convaincre. Siequelqu'un proposait l'intégrationde code Rust dans un projet auquel je participe (disons: Haiku), ça ferait par contre partie des questions que je vais poser afin de me faire un avis sur la question [il y en aurait plein d'autre, par exemple dans le cas de Haiku ce serait un problème pour le portage motorola 68000 qu'il faudrait officiellement abandonner dans l'état actuel des toolchains Rust). J'ai juste posé une question: quels sont les motifs utilisés dans le code du noyau Linux qui ne se prêteraient pas à un interfaçage avec Rust?
Avec une réponse à cette question, je pourrais apprendre des choses sur les limites de Rust et sur d'autres façons de gérer la mémoire, ou juste redécouvrir des façons de faire auxquelles je n'ai pas pensé. Ou peut-être que ce sema l'occasion de découvrir une interface qui est, en fait, mal définie. Je sais que dans Haiku, on a plein d'endroits où la resposabilité de libérer de la mémoire pointée par un pointeur est implicite et pas documentée, et il faut aller lire le code source pour vérifier, et en plus ce n'est pas forcément cohérent d'un objet à l'autre. Bien sûr c'est un problème qui peut être résolu oe plein de façons: avec du C++ "moderne" et des smart pointers, avec de la documentation, avec des outils d'analyse statique, … mais l'approche de Rust de vérifier ça à la compilation semble quand même être une très bonne idée?
La différence est entre "on peut avoir des interfaces bien définies" dans un autre langage et Rust oblige à avoir des interfaces bien définies (par exemple pour indiquer qui est propriétaire de la mémoire et responsable de la libération, ou assurer la synchronisation entre threads). Oui bien sûr c'est contraignant et parfois ça empêche de faire des choses qui pourraient très bien |onctionner par ailleurs. De la même façon que le C n'a pas de coroutines (alors que c'est facile en assembleur) ou que le C++ ne permet pas de modifier la vtable d'un objet à la volée pendant l'exécution (alors que c'est tout à fait possible en smalltalk, ou si on implémente des vtables en C à la main). Ce sont bien évidement des choix pour contraindre les choses à fonctionner d'une certaine façon: une exécutioneavec une pile d'appel unique par thread, des possibilités d'optimisation des appels de méthodes, par exemple.
La qaestion oevient donc: en pratique, quelles sont les fonctions du noyau Linux qui ont une interface bien définie (en terme de gestion de la mémoire et des threads), mais une approche "inhabituelle" qui fait que ça ne peut pas s'interfacer avec du Rust?
Il me semble que la difficulté de sudo est que cwst un hrogramme complexe avec beaucoup de fonctionnalités (pas forcément souvent utilisées). Par exemple on peut autoriser un utilisateur à lancer seulement certaines commandes avec sudo.
L'outil concurrent doas prend le parti de retirer certaines fonctionnalités pour que le code critique exécuté avec des privilèges élevé reste le plus simple possible. Alors que sudo-rs semble vouloir conserver toute les fonctionnalités.
Moi j'ai mis un 429 (too many requests) qui m'a semblé approprié (IA ou pas, je surveille les statistiques du site une fois de temps en temps et je bannis des range d'IP à la main si ils génèrent trop de requêtes).
Si on veut conserver la version original, alors il garder les couleurs d'origine mais en les considérant dans l'espace de couleurs imposé par les films de l'époque.
La difficulté est surtout de savoir quelles étaient les couleurs originales lors de la sortie du film. Si toutes les copies originales en 35mm avaient été détruites, comment ferait-on pour le savoir? Et ces copies se dégradent avec le temps, bien sûr.
Il y a donc plusieurs questions:
Comment conserver une trace de quelles étaient les couleurs que les gens ont vu lors de la sortie au cinéma,
Comment reproduire au mieux ces couleurs sur une copie numérique moderne,
Pourquoi Disney+ a choisi de ne pas le faire et de sortir une version visuellement très différente
Et c'est important parce que ces couleurs peuvent complètement changer la perception du film. On passe d'un truc qui peut avoir l'air presque réaliste à une copie numérique en HD où on se rend beaucoup plus compte que les modèles 3D sont relativement simples et peu texturés, par exemple. La version en film 35mm permettait de gommer plein de choses et de faire en sorte que la magie opère et qu'on oublie un peu le rendu 3D finalement pas si bon que ça. Et c'est quelque chose auquel l'équipe qui a réalisé le film a réfléchi, c'est donc un choix de leur part qu'il convient de préserver dans certains cas.
C'est loin d'être la seule oeuvre pour laquelle c'est le cas. Par exemple, la série originale Star Trek a été filmée et montée en 35mm, mais en ayant en tête que ce serait diffusé à la télévision, avec une définition d'image assez faible. Les trucages qui fonctionnaient relativement bien à l'époque ne fonctionnent donc pas du tout pour une version en haute définition (on voit toutes les ficelles). Le choix qui a été fait dans ce cas, c'est de refaire tous les effets spéciaux en images de synthèse pour la sortie en Blueray de la série (et autres canaux de diffusion en HD). Mais c'est important de préserver aussi la version originale qui a été diffusée, sinon, on pourrait croire en voyant la nouvelle version, que les trucages étaient à des années-lumières devant les possibilités de l'époque où la série a été réalisée!
Et d'autre part, on sait que les grosses entreprises exploitants ces médias ne sont pas forcément les mieux placées pour assurer cette préservation historique et s'assurer que les versions originales restent facilement disponibles.
Si tu pars d'une base de code "toute unsafe" pour essayer de la rendre "safe" (en gardant la compatibilité C au max) tu te retrouves, intuitivement, à avoir le même problème que craignent certains mainteneurs du noyau Linux j'ai cru comprendre et à avoir à réécrire les API ou de grosses parties du code existant parce que les restrictions vont se propager dans le code dont il dépend, à la manière de la propagation des "async / await" dans du code qu'on veut rendre asynchrone dans certains langages comme le js. En plus velu parce que ça va rendre impossible l'utilisation de certaines constructions et peut être obliger à des changements d'architectures du code ou du gros refactoring.
J'ai du mal à voir en quoi c'est une mauvaise chose. Le code Rust obligerait les interfaces à être propres et bien définies, et mettrait alors en évidences les endroits où ce n'est pas le cas et où il y a du code à retravailler.
Habtiuellement on met plutôt une gzip bomb: une réponse avec un content-encoding gzip, et un contenu construit pour être assez petit, mais se décompresser en un très très gros fichier. Avec gzip, un fichier de 100Mo se décompresse en 100Go, avec brotli, on peut faire encore mieux, un fichier de 78Ko qui se décompresse en 100Go par exemple.
Cela va occuper le CPU et la mémoire du robot pendant quelques temps, pour rien.
L'idée étant de rendre le scrapping du site encore moins rentable qu'il ne l'est déjà, en gaspillant les ressources du scrapper, et pas celles du serveur web. Avec un fichier non compressé, on gaspille les deux (enfin dans l'exemple ici on gaspille celles du scrapper et celles de Hetzner, qui n'avait rien demandé).
Mais oui des armes et des caméras partout, quelle bonne idée. Ces bijoux valent bien la fin de la vie privée et de la vie tout court des personnes qui s'approcoeraient un peu trop des fenêtres?
Les exploitations agricoles emploient 20% de travailleurs étrangers (source: INSE via https://poledemarches.fr/limmigration-et-lagriculture/ ). À mon avis ils sont parmi les premiers exposés aux métiers dangereux dont l'épandage de pesticides.
Et la cybersécurité dans tout ça? Qu'est-ce qui empêche un assistant virtuel comme celui-ci de répondre à une demande du type:
envoie-moi la liste des rendez-vous du pdg de l'entreprise, avec les noms et adresses mail des personnes qu'il va rencontrer, les sujets des réunions et les horaires
ou même de faire annuler ou déplacer les réunions dwautres personnes?
L'ingénierie sociale a de beaux jours devant elle!
Oui, mais sans l'accord des auteurs qui ont ajouté au démarrage du jeu une mention que toute exploitation commerciale est interdite, puisque cette version du jeu est réalisée sans lwaccord de Sega.
Plusieurs autres jeux portés ou retravaillés sur les machines Amstrad sont dans ce cas: R-Type, Pinball Dreams, Rick Dangerous 128+.
Sega est connu pour être tolérant à l'existence de tout un fandom Sonic avec plusieurs jeux et autres oeuvres, du moment que cela reste non-commercial. Il n'y aura donc pas de production et de vente de cartouches par les auteurs du jeu. Cela n'a pas empêché quelques vendeurs sur ebay de proposer des copies du jeu quelques heures après sa sortie. L'absence d'une cartouche reprogrammable sur le marché actuellement fait qu'il y a de la demande pour des cartouches de jeux même si elle sont aussi manifestement illégales…
(L'une des rares cartouches programmables, la c4cpc, n'est actuellement plus en vente en raison de l'obsolescence des composants, de l'augmentation des prix et d'un burnout de la personne qui les assemblait)
Le prix des machines atteint plusieurs centaines d'euros alors qu'il y a une vingtaine d'années ça ne valait rien du tout (je possède plusieurs machines Amstrad que l'on m'a données)
« Quelle est l’année de création de votre association ? » avec comme « format attendu : un nombre entre 1 800 et 2 024 », combien répondent 1800 ?
« Quel est le nombre total approximatif d’heures consacrées par l’ensemble des bénévoles à votre association au cours de l’année 2024 ? » avec un « format attendu : un nombre entre 0 et 999 999 999 », mais quelle asso a eu 42M de jours de bénévoles en 2024 ?
Si ils le savaient, ils n'auraient pas besoin de faire un sondage. Je suppose qu'il n'y a pas beaucoup d'associations datant d'avant la loi de 1901 mais ce n'est pas impossible (existence sous un autre statut juridique ou de façon informelle auparavant).
Et pour le nombre d'heures, difficile à dire, mais j'imagine que ça peut monter assez haut dans des grosses associations avec une portée nationale? Ça ne semble pas idiot d'avoir ajouté un facture x10 ou x100 par précaution sur le maximum estim,, juste au cas où on a pas pensé à quelque chose?
[^] # Re: Haiku : toujours incroyable
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Nouvelles de Haiku - Automne 2025. Évalué à 8 (+5/-0).
On peut lancer un terminal sans serveur graphique via le pilote consoled, qui utilise la même méthode d'affichage que le debugger noyau et le debugger de l'espace utilisateur quand un service plante.
Cette console est lente, très incomplète, et globalement inutilisable à part pour dire "oui, techniquement c'est possible".
[^] # Re: fourche ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Qualcomm tire le frein à main sur l’Open Source d’Arduino. Évalué à 6 (+3/-0).
Ce qui fait le succès de Arduino, ce n'est pas la vente de matériel, c'est l'écosystème logiciel autour: une bibliothèqe standard facile à utiliser et portableur de nombreux modèles de cartes et de microcontrôleurs, un IDE pratique avec de la programmation facile (on branche un port usb et ça juste marche). Ça permet d'aller assez loin dans lwélectronique sans jamais toucher un fer à souder ou un datasheet de composant.
il y a une dizaine d'années, beaucoup de cartes et de microcontrôleurs étaient vendus sans un tel support, les fabricants vendaient juste le matériel et laissaient le soin à d'autres (Keil, IAR, …) de fournir les compilateurs et environnements de développement, et aux acheteurs des composants de se développer leurs propres bibliothèques. Maintenant ils ont pour la plupart compris l'intérêt de proposer une olution complète et des outils de développement accessibles gratuitement (ou encore mieux, libres). Et c'est un peu cette partie là qui fait toute la valeur d'un microcontrôleur aujourd'hui, alors que c'est celle qui n'est pas vendue (on paie le matériel, mais le choix d'un composant plutont qu'un autre va se faire surtout sur le logiciel disponible)
[^] # Re: plein de questions
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Nouvelles de Haiku - Automne 2025. Évalué à 9 (+6/-0).
Il n'y a pas forcément de ligne directrice. Du point de vue de la qualité du code, un processus de revue existe depuis très longtemps, au départ c'était fait via une mailing list et après l'envoi de commits (c'était la façon la plus simple de procéder avec SVN), aujourd'hui, cela passe par Gerrit avec une revue avant commit. L'inconvénient est que parfois c'est un peu trop exigeant et c'est difficile d'intégrer un changement qui n'est pas parfait, cela peut décourager certains contributeurs.
Du côté de l'interface graphique, il y a un document "Haiku interface guidelines", mais c'est vrai qu'il y a une attention aux détails. C'est peut-être plus facile de se consacrer à ça quand le gros de l'interface a très peu changé depuis 25 ans, que pour d'autres projets qui sont un peu dans un changement continu de technologie ou de thèmes ou d'objectifs?
La roadmap avance doucement. Pour s'en rendre compte on peut regarder année par année:
Il faut noter que les tickets résolus sont déplacés vers la beta "en cours" au moment de la résolution. Chaque version beta reçoit plusieurs centaines de corrections, mais de nouveaux problèmes sont également découverts. Donc le nombre de tickets dans l'objectif "R1" baisse beaucoup plus doucement (mais ça baisse quand même). Si on garde le même rythme de -120 tickets tous les 4 ans (environ 30 par ans), on devrait voir la version R1 d'ici environ 18 ans.
Il s'agit d'un rapport trimestriel qui liste les avancées de ces 3 derniers mois uniquement. Pour les 3 mois précédents il faut regarder le rapport précédent, et ainsi de suite. L'équipe est toujours assez réduite (un développeur salarié, une grosse poignée de contributeurs sur leur temps libre, et quelques personnes qui participent de façon plus occasionelle). Cette année, on a entre 7 et 22 contributeurs chaque mois avec un total de 44 personnes différentes sur l'année (la dernière année où il y a eu aussi peu de monde, c'était en 2010, et les chiffres pour 2010 et avant sont faussés parce que on utilisait encore SVN qui ne préservait pas l'auteur pour les contributions externes). On est donc plutôt en effectif réduit par rapport à d'habitude, avec un seul contributeur qui réalise a lui tout seul plus de la moitié des commits (c'était le cas l'an dernier pour la première fois, jusque là, les choses étaient beaucoup plus réparties, mais il n'y avait pas un contributeur salarié à plein temps). Avec environ 1000 à 1500 commits par an, on est loin du record de 2009 ou on avait dépassé 5500 commits. Cependant, les changements de mode de revue du code font que les changements ont tendance à apparaître sous forme d'un seul commit bien testé et finalisé, au lieu de multiples petits changements et correctifs.
On peut aussi regarder du côté de Haikuports, les courbes se sont croisées avec l'introduction en 2012 du gestionnaire de paquets, et on voit beaucoup d'activité sur le portage et le développement de logiciels, plutôt que sur le système lui-même.
[^] # Re: Nvidia
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Chute du Bitcoin : plus d’un milliard de dollars s’est évaporé du marché crypto en l’espace de 24 h. Évalué à 8 (+5/-0).
Ça fait longtemps que ce n'est plus du tout rentable de miner du bitcoin avec une carte graphique, il existe maintenant des puces dédiées exclusivement à cet usage qui sont (un peu) moins gourmandes en énergie
[^] # Re: Usage multimedia
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Valve annonce la Steam Machine, sa minimachine de jeu. Évalué à 8 (+5/-0).
(c'était une plaisanterie, plus personne n'a de chaîne hifi ni de CD à écouter avec, et je suis prêt à parier qu'on pourra très facilement envoyer le son de Spotify en MP3 compressé vers une enceinte Bluetooth avec un protocol de compression audio avec perte, en utilisant la Steam Machine).
Peut-être que j'aurais plutôt du parler d'une sortie péritel pour éviter tout risque d'être pris au sérieux?
[^] # Re: Usage multimedia
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Valve annonce la Steam Machine, sa minimachine de jeu. Évalué à 3 (+0/-0).
Par contre ça manque d'un lecteur CD alors qu'il y aurait pile la place vu les dimensions de la machine. J'espère que ce sera un add-on plus tard.
[^] # Re: DDOS
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Incident Cloudfare ou la centralisation c’est le mal, la preuve. Évalué à 7 (+4/-0).
C'est la nouvelle définition du DDOS, le déni de service distribué, qui permet de faire tomber la roitié de l'internet en cassant un seul site!
[^] # Re: "Vulnérabilités"
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 3 (+0/-0).
Ça veut aussi dire que le mot de passe se retrouve dans le buffer du terminal, qui potentiellement se retrouve swappé et donc enregistré sur le disque dur, où on peut le récupérer une fois la machine éteinte (ou de façon sûre, en mettant la machine en hibernation prolongée). Normalement on fait attention que les mots de passe ne soient stockés que dans des zones non enregistrables sur disque et de bien l'effacer avant de libérer la mémoire en question.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 7 (+4/-0).
Il peut être réduit à strictement zéro, en fait, avec des environnements à machine virtuelle comme LISP (dont les supporters ralaient dans le;années 60 sur les développeurs utilisant des langages compilés unsafe avec exactement les mêmes arguments que les supportes de Rust utilisent aujourd'hui) ou SmallTalk. La raison pour laquelle ça n'a pas pris, c'est qu'il y avait un coût en performances relativement important. Rust a fait tomber cette limite (et encore, je vais faire grincer des dents des développears Ada en disant ça).
Je développe moi aussi beaucoup de C++, mais il faut arrêter d'essayer de présenter les inconvénients du langage (pas memory safe, pas de système de build standardisé, pas d'outil de gestion des dépendances, par de règle de formattage et de nommage standardisées) comme des avantages.
Avec Cargo, on peut récupérer plein de bibliothèques bien implémentées pour tout un tas de trucs,et personellement j'ai tendance à avoir plus confiance dans ces bibliothèques oue dans ma capacité (ou celle de mes collègues) à réimplémenter les choses de façon sécurisée et avec de bonnes performances. Et puis en plus, j'ai autre chose à faire que développer pour la 72000ème fois un arbre binaire ou une autre structure de base…
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 3 (+1/-1). Dernière modification le 14 novembre 2025 à 17:05.
Je ne vois pas trop bien pourquoi on fait une confiance aveugle aux distributions Linux mais pas à Cargo. Par exemple, Arch avec AUR ne fait pas mieux d'un point de vue validation de la sécurité des dépendences incluses? Qu'en est-il de Debian par exemple? Si Debian package une bibliothèque avec des failles de sécurité, volontairement ou non, qu'est-ce que ça change par rapport à une vulnérabilité arrivée par Cargo? Est-ce que Debian a un process de relecture complète du code de chaque version des logiciels qu'ils packagent pour que tu n'aies pas besoin de le faire? Je ne crois pas. Tout ça repose sur de la confiance.
Surtout que les dépendances dans les projets Rust ne se mettent pas à jour toutes seules dans le dos des développeurs, il faut faire soi-même la montée en version (et vérifier au moins que cela fonctionne bien).
Et puis quand ta distribution ne package pas le logiciel dont tu as besoin, en C ou C++, tu te retrouves avec… ben rien du tout pour faire le suivi, il faut gérer ça soi-même. Et de mon expérience, ça arrive relativement souvent.
[^] # Re: Esprit critique
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Finalement, Chat Control va passer en trilogue. Évalué à 5 (+2/-0).
Je ne comprend pas pourquoi le débat est parti sur l'authentification pour
grosboobs.cometparissportifs.fr. Le texte de départ parle de fournisseurs de mail, chat, et services de messagerie (d'ailleurs, le projet s'appelle ChatControl).Ce qui pose d'autres problèmes, par exemple si vous hébergez un serveur IRC, est-ce que c'est à vous de vérifier l'identité des personnes se connectant à ce serveur, et comment ça se met en place dans ce cas où le protocole n'est pas vraiment prévu pour?
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 3 (+0/-0).
Je confirme: on a beau mettre en places tous ces trucs, le nombre de bugs causés par une mauvaise gestion de la mémoire reste important (sans forcément parler de failles de sécurité, à ma connaissance personne n'en a trouvé dans le projet). On a plutôt de bêtes déréférences de pointeurs null, des use after free, ou des hroblèmes de partage de données entre threads.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 10 (+7/-0).
Je ne suis pas développeur dans le noyau Linux et si je peux éviter de faire du C, j'en suis très content. Je n'ai donc pas de "il faudrait" à leur donner ou personne à convaincre. Siequelqu'un proposait l'intégrationde code Rust dans un projet auquel je participe (disons: Haiku), ça ferait par contre partie des questions que je vais poser afin de me faire un avis sur la question [il y en aurait plein d'autre, par exemple dans le cas de Haiku ce serait un problème pour le portage motorola 68000 qu'il faudrait officiellement abandonner dans l'état actuel des toolchains Rust). J'ai juste posé une question: quels sont les motifs utilisés dans le code du noyau Linux qui ne se prêteraient pas à un interfaçage avec Rust?
Avec une réponse à cette question, je pourrais apprendre des choses sur les limites de Rust et sur d'autres façons de gérer la mémoire, ou juste redécouvrir des façons de faire auxquelles je n'ai pas pensé. Ou peut-être que ce sema l'occasion de découvrir une interface qui est, en fait, mal définie. Je sais que dans Haiku, on a plein d'endroits où la resposabilité de libérer de la mémoire pointée par un pointeur est implicite et pas documentée, et il faut aller lire le code source pour vérifier, et en plus ce n'est pas forcément cohérent d'un objet à l'autre. Bien sûr c'est un problème qui peut être résolu oe plein de façons: avec du C++ "moderne" et des smart pointers, avec de la documentation, avec des outils d'analyse statique, … mais l'approche de Rust de vérifier ça à la compilation semble quand même être une très bonne idée?
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 6 (+3/-0).
La différence est entre "on peut avoir des interfaces bien définies" dans un autre langage et Rust oblige à avoir des interfaces bien définies (par exemple pour indiquer qui est propriétaire de la mémoire et responsable de la libération, ou assurer la synchronisation entre threads). Oui bien sûr c'est contraignant et parfois ça empêche de faire des choses qui pourraient très bien |onctionner par ailleurs. De la même façon que le C n'a pas de coroutines (alors que c'est facile en assembleur) ou que le C++ ne permet pas de modifier la vtable d'un objet à la volée pendant l'exécution (alors que c'est tout à fait possible en smalltalk, ou si on implémente des vtables en C à la main). Ce sont bien évidement des choix pour contraindre les choses à fonctionner d'une certaine façon: une exécutioneavec une pile d'appel unique par thread, des possibilités d'optimisation des appels de méthodes, par exemple.
La qaestion oevient donc: en pratique, quelles sont les fonctions du noyau Linux qui ont une interface bien définie (en terme de gestion de la mémoire et des threads), mais une approche "inhabituelle" qui fait que ça ne peut pas s'interfacer avec du Rust?
[^] # Re: Go brrrrrrrr
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 7 (+5/-1).
Il me semble que la difficulté de sudo est que cwst un hrogramme complexe avec beaucoup de fonctionnalités (pas forcément souvent utilisées). Par exemple on peut autoriser un utilisateur à lancer seulement certaines commandes avec sudo.
L'outil concurrent doas prend le parti de retirer certaines fonctionnalités pour que le code critique exécuté avec des privilèges élevé reste le plus simple possible. Alors que sudo-rs semble vouloir conserver toute les fonctionnalités.
[^] # Re: code erreur HTTP
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Tenter de limiter les nuisances liées aux robots d'IA. Évalué à 8 (+5/-0).
Moi j'ai mis un 429 (too many requests) qui m'a semblé approprié (IA ou pas, je surveille les statistiques du site une fois de temps en temps et je bannis des range d'IP à la main si ils génèrent trop de requêtes).
[^] # Re: Étalonnage des couleurs
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Le "Toy Story" de vos souvenirs. Évalué à 5.
La difficulté est surtout de savoir quelles étaient les couleurs originales lors de la sortie du film. Si toutes les copies originales en 35mm avaient été détruites, comment ferait-on pour le savoir? Et ces copies se dégradent avec le temps, bien sûr.
Il y a donc plusieurs questions:
Et c'est important parce que ces couleurs peuvent complètement changer la perception du film. On passe d'un truc qui peut avoir l'air presque réaliste à une copie numérique en HD où on se rend beaucoup plus compte que les modèles 3D sont relativement simples et peu texturés, par exemple. La version en film 35mm permettait de gommer plein de choses et de faire en sorte que la magie opère et qu'on oublie un peu le rendu 3D finalement pas si bon que ça. Et c'est quelque chose auquel l'équipe qui a réalisé le film a réfléchi, c'est donc un choix de leur part qu'il convient de préserver dans certains cas.
C'est loin d'être la seule oeuvre pour laquelle c'est le cas. Par exemple, la série originale Star Trek a été filmée et montée en 35mm, mais en ayant en tête que ce serait diffusé à la télévision, avec une définition d'image assez faible. Les trucages qui fonctionnaient relativement bien à l'époque ne fonctionnent donc pas du tout pour une version en haute définition (on voit toutes les ficelles). Le choix qui a été fait dans ce cas, c'est de refaire tous les effets spéciaux en images de synthèse pour la sortie en Blueray de la série (et autres canaux de diffusion en HD). Mais c'est important de préserver aussi la version originale qui a été diffusée, sinon, on pourrait croire en voyant la nouvelle version, que les trucages étaient à des années-lumières devant les possibilités de l'époque où la série a été réalisée!
Et d'autre part, on sait que les grosses entreprises exploitants ces médias ne sont pas forcément les mieux placées pour assurer cette préservation historique et s'assurer que les versions originales restent facilement disponibles.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 5 (+2/-0).
J'ai du mal à voir en quoi c'est une mauvaise chose. Le code Rust obligerait les interfaces à être propres et bien définies, et mettrait alors en évidences les endroits où ce n'est pas le cas et où il y a du code à retravailler.
[^] # Re: Intéressant
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Tenter de limiter les nuisances liées aux robots d'IA. Évalué à 10 (+7/-0).
Habtiuellement on met plutôt une gzip bomb: une réponse avec un content-encoding gzip, et un contenu construit pour être assez petit, mais se décompresser en un très très gros fichier. Avec gzip, un fichier de 100Mo se décompresse en 100Go, avec brotli, on peut faire encore mieux, un fichier de 78Ko qui se décompresse en 100Go par exemple.
Cela va occuper le CPU et la mémoire du robot pendant quelques temps, pour rien.
L'idée étant de rendre le scrapping du site encore moins rentable qu'il ne l'est déjà, en gaspillant les ressources du scrapper, et pas celles du serveur web. Avec un fichier non compressé, on gaspille les deux (enfin dans l'exemple ici on gaspille celles du scrapper et celles de Hetzner, qui n'avait rien demandé).
[^] # Re: Sécurité
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Le mot de passe du Louvre était « LOUVRE », oui, oui !. Évalué à 7.
Mais oui des armes et des caméras partout, quelle bonne idée. Ces bijoux valent bien la fin de la vie privée et de la vie tout court des personnes qui s'approcoeraient un peu trop des fenêtres?
[^] # Re: Votes
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien La pétition contre la loi Duplomb (2,13 millions de signatures) arrive à l’Assemblée Nationale. Évalué à 10.
Les exploitations agricoles emploient 20% de travailleurs étrangers (source: INSE via https://poledemarches.fr/limmigration-et-lagriculture/ ). À mon avis ils sont parmi les premiers exposés aux métiers dangereux dont l'épandage de pesticides.
Du coup ta blague n'est pas du tout drôle…
[^] # Re: 10 € par mois
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Quand éclatera la bulle IA…. Évalué à 7.
Et la cybersécurité dans tout ça? Qu'est-ce qui empêche un assistant virtuel comme celui-ci de répondre à une demande du type:
ou même de faire annuler ou déplacer les réunions dwautres personnes?
L'ingénierie sociale a de beaux jours devant elle!
[^] # Re: cartouche?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Sonic le hérisson débarque enfin sur la console de jeux Amstrad GX4000. Évalué à 6.
Oui, mais sans l'accord des auteurs qui ont ajouté au démarrage du jeu une mention que toute exploitation commerciale est interdite, puisque cette version du jeu est réalisée sans lwaccord de Sega.
Plusieurs autres jeux portés ou retravaillés sur les machines Amstrad sont dans ce cas: R-Type, Pinball Dreams, Rick Dangerous 128+.
Sega est connu pour être tolérant à l'existence de tout un fandom Sonic avec plusieurs jeux et autres oeuvres, du moment que cela reste non-commercial. Il n'y aura donc pas de production et de vente de cartouches par les auteurs du jeu. Cela n'a pas empêché quelques vendeurs sur ebay de proposer des copies du jeu quelques heures après sa sortie. L'absence d'une cartouche reprogrammable sur le marché actuellement fait qu'il y a de la demande pour des cartouches de jeux même si elle sont aussi manifestement illégales…
(L'une des rares cartouches programmables, la c4cpc, n'est actuellement plus en vente en raison de l'obsolescence des composants, de l'augmentation des prix et d'un burnout de la personne qui les assemblait)
Le prix des machines atteint plusieurs centaines d'euros alors qu'il y a une vingtaine d'années ça ne valait rien du tout (je possède plusieurs machines Amstrad que l'on m'a données)
[^] # Re: No std::future ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Les ordis du coeur : "donner une seconde vie aux ordinateurs, changer des vies". Évalué à 4.
On attend toujours ton prochain journal sur le Da Nouille pour savoir comment avance le portage de Linux et l'upstreaming des patchs.
Pour les chromebooks basés sur un CPU Intel, le travail est déjà fait.
# Questions sans réponses
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal LinuxFr.org : première et seconde quinzaines d'octobre 2025. Évalué à 3.
Si ils le savaient, ils n'auraient pas besoin de faire un sondage. Je suppose qu'il n'y a pas beaucoup d'associations datant d'avant la loi de 1901 mais ce n'est pas impossible (existence sous un autre statut juridique ou de façon informelle auparavant).
Et pour le nombre d'heures, difficile à dire, mais j'imagine que ça peut monter assez haut dans des grosses associations avec une portée nationale? Ça ne semble pas idiot d'avoir ajouté un facture x10 ou x100 par précaution sur le maximum estim,, juste au cas où on a pas pensé à quelque chose?