45 ans après sa sortie, le code source du tout premier 86-DOS vient d'atterrir sur GitHub . Microsoft a profité de cet anniversaire pour publier les listings d'assembleur originaux, accompagnés de plusieurs versions de PC-DOS 1.00 et de MS-DOS 1.25, sous licence MIT. Tout ceci est dans le dépôt DOS-History/Paterson-Listings, et oui, le tout est compilable.

Ces listings, c'est Tim Paterson en personne qui les avait conservés dans ses tiroirs depuis 1980. À cette époque, il bossait chez Seattle Computer Products, une boîte de matos qui faisait des cartes pour processeurs Intel 8086.

Il avait écrit en quelques mois un OS rudimentaire baptisé 86-DOS pour faire tourner les machines de SCP. Microsoft a fini par racheter le code à SCP pour 75 000 dollars, l'a légèrement retravaillé, et l'a refilé à IBM sous le nom PC-DOS pour équiper le tout premier IBM PC. Ce code-là est le grand-père de Windows.

On parle ici de dix paquets de listings papier (le bon vieux papier à bandes vertes), dont huit ont déjà été transcrits par Yufeng Gao et Rich Cini, deux passionnés de préservation. À l'intérieur : le noyau de 86-DOS 1.00, plusieurs snapshots de développement de PC-DOS 1.00, et des utilitaires comme CHKDSK.

Plus intéressant encore, les listings contiennent les annotations manuscrites de Paterson lui-même, des notes en marge qui montrent les hésitations et les corrections d'un ingénieur en plein travail.

Le code est prêt à être compilé avec l'assembleur SCP d'origine, ce qui veut dire qu'on peut générer des binaires fonctionnels et les faire tourner dans un émulateur comme par exemple PCem ou 86Box. C'est rare en archéologie logicielle d'avoir des snapshots aussi complets, et c'est encore plus rare quand l'auteur original est toujours là pour répondre aux questions. Les originaux papier vont d'ailleurs rejoindre l'Interim Computer Museum, donnés par Paterson lui-même.

Ce n'est pas la première fois que Microsoft ouvre du code un peu ancien. En 2018, ils avaient déjà open-sourcé MS-DOS 1.25 et 2.11. En 2024, c'était MS-DOS 4.0. Mais cette fois on remonte carrément à la racine, à la version SCP avant rachat, avec les fragments de l'évolution vers PC-DOS. Du coup, pour les nostalgiques et les chercheurs en histoire de l'informatique, c'était la pièce manquante.

Petite cerise sur le gâteau : les scans bruts des listings papier sont aussi sur Archive.org, donc même la version "préhistorique" est consultable. Et si vous avez envie de contribuer à la transcription des deux paquets restants, ce projet est ouvert.

Bref, le grand-père de Windows est désormais lisible ligne par ligne, annotations comprises. Pour les fans d'archéologie informatique, c'est carrément chouette.

Source : Hackaday

PS5-Linux est là !!

Andy Nguyen, le security engineer alias theflow0, vient de publier le hack qui transforme une PS5 Phat (les modèles originaux, pas les Slim ni les Pro) en PC 100% Linux. Et le truc cool c'est que ça marche désormais sur les firmwares 3.xx et 4.xx, et pas seulement sur les premières consoles oubliées dans leur boîte !

Pour rappel, en mars dernier, Andy Nguyen avait fait tourner GTA 5 Enhanced en ray tracing sur sa PS5 , mais l'exploit était limité aux firmwares 1.xx et 2.xx, donc autant dire à des consoles qui n'avaient jamais vu Internet. Mais depuis hier, le projet est officiellement sorti sur GitHub avec un guide d'installation complet, et il a élargi son périmètre.

Concrètement, le hack utilise une vulnérabilité patchée de l'hyperviseur PS5 (corrigée dans les firmwares récents, d'où la liste fermée) pour débloquer le hardware. Une fois en place, la PS5 expose son CPU 8 cores (16 threads) à 3.5 GHz max et son GPU à 2.23 GHz max (les fréquences de boost de la console, en pratique ça tape souvent un peu plus bas pour éviter la surchauffe), ce qui suffit largement pour faire tourner Steam et des émulateurs sans que ça rame.

Et surtout, la sortie HDMI 4K à 60 Hz fonctionne, l'audio aussi, et tous les ports USB de la console sont opérationnels !

Côté firmwares supportés, c'est précis, attention ! Les versions 3.00, 3.10, 3.20 et 3.21 fonctionnent, mais sans support M.2. Les versions 4.00, 4.02, 4.03, 4.50 et 4.51, elles, supportent en plus le SSD M.2 dédié à Linux.

Du coup, plus la console est récente dans cette plage, plus on a de flexibilité. Pour les firmwares 5.xx, ça pourrait ensuite arriver plus tard, mais Linux tournera dans un environnement virtualisé restreint à côté de GameOS, donc avec des perfs et des fonctionnalités un peu dégradées.

Maintenant, pour vérifier votre firmware avant de tenter le coup, c'est dans Paramètres > Système > Informations console.

Pour l'install, il vous faudra une clé USB de 64 Go minimum (un SSD externe est recommandé), un clavier/souris USB, un adaptateur Ethernet ou Wi-Fi USB, et en option un dongle Bluetooth si vous voulez utiliser la DualSense. Le Bluetooth interne de la PS5 n'est pas encore supporté par contre.

Les ports recommandés pour booter sont l'USB Type-C en bas à l'avant ou les Type-A à l'arrière.

Pour réussir ce tour de passe-passe, l'exploit passe par umtx2 , qui simule un faux DNS sur l'URL manuals.playstation.net pour envoyer le payload via socat. Du pur travail de hacker, mais le README est plutôt bien fichu et vous tiendra la main tout au long de l'install.

Évidemment, c'est encore expérimental.... Pas de dual-boot, donc il faut relancer l'exploit à chaque démarrage en mode Linux, le mode standby ne fonctionne pas, le screen saver est buggé, et certains écrans ont du mal avec la sortie HDMI. C'est donc pas pour du grand public et il vaut mieux être à l'aise avec la ligne de commande pour s'y mettre.

Reste que voir Andy Nguyen continuer son bon boulot sur la sécurité de la PlayStation, c'est toujours cool. Le mec est derrière plusieurs jailbreaks PS4 et début PS5, et combiné avec la fuite des clés BootROM PS5 fin 2025 , l'écosystème commence enfin à respirer un air plus "libre".

Donc si vous avez une PS5 Phat sortie entre 2020 et début 2022 qui traîne avec un firmware d'époque, c'est peut-être le moment de la ressortir du placard.

Source : Notebookcheck

La norme HDMI 2.1, avec ses 4K@120 Hz et ses 8K, est un serpent de mer dans le monde Linux. Depuis trois ans, le HDMI Forum refuse aux développeurs AMD l'accès aux spécifications de la Fixed Rate Link, le composant-clé qui permet de faire passer ces gros débits.

Résultat, les utilisateurs Linux avec une carte AMD récente sont coincés en HDMI 2.0, donc en 4K@60 Hz. C'est quand même frustrant quand votre écran coûte plus cher que votre GPU.

Côté NVIDIA, Nouveau (le pilote open-source historique) s'apprête à contourner ce blocage par une pirouette plutôt élégante. Karol Herbst, contributeur de longue date du projet, explique que puisque tout le logiciel HDMI 2.1 de NVIDIA se trouve déjà dans le firmware GSP de la carte (le fameux blob propriétaire que NVIDIA a commencé à distribuer il y a quelques années), il suffit à Nouveau de le charger et de lui dire quoi faire.

L'open-source n'a pas besoin de connaître les spécifications HDMI 2.1, parce que c'est le firmware fermé qui s'en occupe. Le HDMI Forum ne peut rien objecter. Plutôt malin.

C'est la différence-clé avec la situation AMD. Le pilote AMDGPU fait tourner une grosse partie de la logique d'affichage dans le code open-source, justement parce que c'est la philosophie maison. Du coup, implémenter HDMI 2.1 dans AMDGPU reviendrait à exposer des morceaux de la spec que le HDMI Forum protège jalousement.

Sur Nouveau, NVIDIA a externalisé toute cette logique dans le firmware GSP, donc le pilote open-source reste "naïf", et par chance, c'est exactement ce qui le sauve juridiquement.

À noter que la chose n'est pas encore dans le noyau Linux. Herbst est confiant sur le principe, mais il reste du travail pour finaliser l'intégration, gérer les capacités dynamiques du firmware, et s'assurer que ça marche sur toutes les cartes Ampere, Ada et Blackwell.

Les utilisateurs AMD regarderont ça avec une certaine amertume, parce que leur blocage, lui, est juridique, pas technique.

Bref, la philosophie "tout open" d'AMD se retourne contre elle sur ce dossier, et Nouveau s'en sort par une faiblesse architecturale transformée en avantage.

Source : Phoronix

Quelqu'un a fait tourner l'interface Steam sur une Nintendo Switch. Pas via un hack douteux ni un émulateur bricolé, mais en utilisant la beta officielle de Proton 11 que Valve a publiée avec, pour la première fois, le support des appareils ARM sous Linux.

Le résultat a été posté sur BlueSky ( par ici ) par AAGaming, qui a aussi partagé les fichiers pour reproduire la manip chez vous.

[Embed: https://bsky.app/profile/did:plc:owu62bybwircbrojnru5axov/post/3mjnka7iur22l]

Concrètement, Proton 11.0-Beta1 embarque FEX 2604, un traducteur d'instructions x86 vers ARM qui permet de faire tourner du code Windows x86 sur un appareil ARM sous Linux. C'est ce qui rend le tout possible. Cette Switch rootée tourne sous Ubuntu, Proton s'installe par-dessus, et l'UI Steam parvient bien à se lancer. Alors, certes, pour l'instant, on en est surtout au stade de la démonstration, et pas franchement au stade "jouer à Elden Ring sur sa Switch", mais le client fonctionne.

Si Valve a bossé sur ce support ARM, c'est en fait pour le Steam Frame, son casque de jeu qui tourne sur un Snapdragon 8 Gen 3 avec 16 Go de LPDDR5X. L'appareil avait été montré en novembre dernier, présenté comme un appareil de streaming d'abord, mais avec la capacité de faire tourner des jeux en local aussi.

Lors d'une démo, un représentant Valve avait fait tourner Hades 2 en standalone à 1400p sur ARM, avec des performances correctes. "C'est du Linux, sur ARM", avait-il précisé. Du coup, le support public dans Proton n'est que la suite logique.

L'intérêt va au-delà de la Switch. Tous les handhelds ARM sous Linux (Retroid, AYN, Ayaneo, et les futurs modèles) deviennent des cibles potentielles pour Steam. Valve travaille d'ailleurs sur un système de certification "Verified" pour le matériel ARM, comme ce qui existe déjà sur Steam Deck. 

Les joueurs sauront quels jeux tournent bien en local et lesquels il vaut mieux streamer.

Côté jeux, la beta Proton 11 certifie aussi une fournée de titres pour SteamOS : Resident Evil, Dino Crisis, Warhammer Vermintide 2, SHOGUN Total War, Breath of Fire IV, entre autres. Et Valve a corrigé le Steam Overlay qui ne marchait pas avec les jeux EA, un bug qui traînait depuis un moment.

Bref, Steam sur Switch c'est surtout un proof of concept pour l'instant, mais Valve pose les bases d'un écosystème ARM qui pourrait devenir très concret avec le Steam Frame.

Source : Tom's Hardware

Le noyau Linux 7.1 devrait supprimer la possibilité de compiler un noyau pour les processeurs Intel 486. C'est la première fois depuis 2012 qu'une architecture processeur est retirée du noyau, et le minimum requis passera du 486 au Pentium. L'Intel 486 a 37 ans.

Un processeur de 1989

L'Intel 486 est sorti en 1989. C'est le processeur qui a fait passer les PC de la ligne de commande au monde graphique, et il a été vendu pendant une bonne partie des années 90.

Le 486SX, sa version sans coprocesseur mathématique, et l'AMD Elan, une variante embarquée, sont aussi concernés par cette suppression. Le patch a été proposé par Ingo Molnar, un des développeurs historiques du noyau Linux.

La dernière fois que Linux a retiré le support d'une architecture processeur, c'était en 2012, quand le 80386 avait été abandonné. Ca fait donc 14 ans que personne n'avait touché à ce genre de nettoyage.

Du ménage dans le code

Le patch supprime trois options de configuration du noyau : M486, M486SX et MELAN. Sans ces options, il ne sera plus possible de compiler un noyau Linux spécifiquement pour un 486. Le processeur minimum deviendra le Pentium, qui supporte les instructions TSC et CMPXCHG8B, deux fonctions que le 486 ne gère pas.

Molnar explique que le code de compatibilité pour ces vieux processeurs pose régulièrement des problèmes et demande du temps de maintenance que les développeurs préfèrent consacrer à autre chose. Linus Torvalds avait d'ailleurs déclaré dès 2022 que les processeurs 486 n'étaient plus utilisés que comme pièces de musée.

Et le 32 bits, alors ?

Le retrait du 486 ne veut pas dire que Linux abandonne le 32 bits. Le noyau continue de supporter les architectures 32 bits, et il y a encore suffisamment de processeurs Atom et de systèmes embarqués 32 bits en circulation pour que ça reste le cas un moment.

Mais la tendance est claire : l'avenir de Linux sur x86 est en 64 bits, et le code 32 bits finira par suivre le même chemin que le 486.

Aucune distribution Linux récente ne proposait de toute façon un noyau compilé pour 486. Les utilisateurs qui font tourner Linux sur ce type de matériel pourront continuer avec des noyaux plus anciens.

Ca concerne très peu de monde en pratique, mais c'est quand même un petit moment d'histoire informatique. Le 486 a été le premier vrai processeur grand public chez Intel, et le voir disparaître du noyau Linux après 37 ans de bons et loyaux services, ça fait quelque chose.

En tout cas les développeurs du noyau semblent soulagés de pouvoir enfin faire le ménage. Pour la petite histoire, mon premier PC était un 386 SX25, et je suis ensuite passé directement au Pentium 60 (celui qui avait le bug de la virgule flottante), je trouve ça dingue qu'avec tous les ordinateurs que j'ai eu chez moi, je n'ai jamais eu de 486 !

Source : Phoronix

Le système de distribution d'applications Linux vient de publier la version 1.16.4, qui corrige quatre failles de sécurité découvertes dans son mécanisme de bac à sable.

La plus critique permettait à une app de sortir de son environnement isolé pour accéder à tous les fichiers de la machine et y exécuter du code. Le Steam Deck et la plupart des grandes distributions sont concernés.

Quatre failles, dont une critique

Flatpak, c'est le format de distribution d'applications qui s'est imposé sur Linux ces dernières années. Son principe : chaque application tourne dans un bac à sable isolé du reste du système, un peu comme sur iOS. C'est aussi le format utilisé par le Steam Deck de Valve pour installer des applications en mode bureau.

La version 1.16.4, publiée le 7 avril, corrige quatre failles de sécurité. La plus grave, référencée CVE-2026-34078, est une vraie mauvaise surprise : une application pouvait exploiter des liens symboliques dans les options d'exposition du portail Flatpak pour accéder à l'intégralité des fichiers de la machine hôte, et même y exécuter du code.

Des fichiers supprimés et des téléchargements détournés

La deuxième faille (CVE-2026-34079) permettait de supprimer des fichiers sur la machine hôte en passant par un bug dans le cache du chargeur dynamique ld.so. Flatpak supprimait les fichiers de cache obsolètes sans vérifier que le chemin fourni par l'application pointait bien vers le bon répertoire.

Deux autres problèmes ont aussi été corrigés : l'un permettait de lire des fichiers via le service système de Flatpak, l'autre de perturber le téléchargement d'une application lancé par un autre utilisateur, sans possibilité de l'arrêter proprement.

Qui doit mettre à jour

Toutes les distributions Linux qui utilisent Flatpak sont concernées, et c'est un paquet de monde : Fedora, Ubuntu, Linux Mint, SteamOS sur le Steam Deck, et bien d'autres.

La mise à jour vers la version 1.16.4 est disponible, ou le sera très vite, via les canaux habituels de chaque distribution. Si vous utilisez un Steam Deck en mode bureau avec des apps Flatpak installées via Discover, la mise à jour devrait arriver automatiquement.

C'est quand même un comble : un système conçu pour isoler les applications qui laisse une porte grande ouverte vers tout le système. Que Flatpak se fasse prendre en défaut sur son coeur de métier, ça fait un peu désordre.

Bon par contre, la réactivité a été bonne : la faille a été identifiée et corrigée, et les détails n'ont été publiés qu'avec le correctif disponible. C'est la base, mais au moins c'est fait.

Source : Phoronix

Et si je vous disais qu'il existe un scheduler Linux qui prend ses décisions en fonction de l'astrologie. Non, c'est pas une blague, le premier avril c'est pas avant quelques jours. Ce scheduler s'appelle scx_horoscope et c'est un vrai module BPF qui se charge dans le noyau et qui décide quel processus a droit au CPU selon la position des planètes dans le zodiaque. Et ça fonctionne pour de vrai !

En gros, le principe c'est ça : chaque planète du système solaire se voit attribuer un domaine. Le Soleil gère les processus critiques (PID 1, init), la Lune s'occupe de vos shells et éditeurs de texte, Mars prend en charge la compilation et l'encodage vidéo, et Jupiter veille sur vos bases de données. Les positions sont alors calculées en temps réel grâce au crate Rust astro, donc oui, c'est de la vraie mécanique céleste, pas un random(). En fait, le binaire calcule les éphémérides géocentriques pour déterminer dans quel signe se trouve chaque planète à l'instant T.

L'outil en train de déterminer le bulletin météo cosmique de votre CPU

Et c'est là que ça devient franchement tordu car chaque signe du zodiaque est associé à un élément (Feu, Air, Eau, Terre) qui modifie les priorités CPU. Votre compilateur tourne pendant que le Soleil est dans le Bélier ? Hop, boost x1.5 pour les tâches CPU-intensive. Par contre, si c'est un signe d'Eau qui domine... 0.6x sur la compilation. Pas de bol ! Et si en plus une planète est en rétrograde (genre elle recule dans le ciel), tous les time slices sont divisés par deux. Votre make -j8 se fera par exemple interrompre deux fois plus souvent, parce que Vénus fait sa diva.

Le module utilise sched_ext, le framework du kernel Linux (6.12 minimum) qui permet de coder des ordonnanceurs en espace utilisateur via eBPF. Et c'est pas un proof-of-concept bidon, car ça charge vraiment dans le noyau. Un cargo build --release, un sudo devant, et hop votre machine tourne au rythme des astres. Y'a même un mode --cosmic-weather qui affiche un bulletin météo cosmique avec les phases de la Lune et les positions planétaires du moment.

Notez par exemple que la pleine lune booste les tâches interactives de 40%. Donc si vous tapez du code à 3h du mat' un soir de pleine lune, votre terminal sera techniquement plus réactif. Coïncidence ? Bah non, c'est Cyber Madame Soleil qui gère !

Le projet propose aussi un flag --ophiuchus pour activer le 13e signe du zodiaque (celui que l'Union Astronomique Internationale reconnaît mais que les astrologues ignorent royalement qui s'appelle en français Serpentaire).

Ce projet est donc clairement à classer dans la catégorie "parce qu'on peut" mais le niveau technique est loin d'être ridicule puisque c'est codé en Rust, en C pour la partie BPF, que ça embarque de vrais calculs d'éphémérides, et une intégration kernel qui tient la route. Et les issues sur le GitHub sont un festival... quelqu'un a par exemple demandé le support des éclipses solaires, tandis qu'un autre veut du chaos pendant les éruptions solaires. Internet à son meilleur ! Top of the top de l'indispensable inutile !

Bref, si vous voulez que Jupiter booste vos bases de données ou votre génération de site statique, foncez . Et merci à Camille Roux pour le partage !

Le pilote Vulkan open source d'Intel pour Linux vient de recevoir une optimisation qui améliore les performances des jeux DirectX 12 tournant via Proton.

La modification a été intégrée à Mesa 26.1 et concerne les cartes graphiques Arc Alchemist et Battlemage. Le patch avait été proposé pour la première fois en 2020, il aura donc fallu plus de cinq ans pour le voir arriver.

Ce qui change pour les joueurs Linux

L'optimisation porte sur la façon dont le pilote ANV gère le cache d'état graphique. En utilisant une combinaison de deux identifiants internes (Binding Table Pointer et Binding Table Index) au lieu d'un seul pour référencer les textures, le pilote peut supprimer certaines étapes de synchronisation qui ralentissaient le rendu.

Les développeurs d'Intel indiquent que le gain est mesurable sur tous les jeux DirectX 12 qu'ils ont testés via VKD3D-Proton, la couche de traduction utilisée par Steam pour faire tourner les jeux Windows sur Linux.

Pas de chiffres précis dans la note technique, mais une autre modification récente du même pilote (un simple changement d'une ligne de code pour le prefetch des tables de textures) avait déjà montré des gains allant jusqu'à 3 à 4 % sur God of War et Destiny 2.

Un patch qui a mis cinq ans à arriver

L'anecdote vaut quand même le détour. Ce patch a été proposé pour la première fois en novembre 2020, et il vient d'être fusionné dans Mesa en mars 2026.

Plus de cinq ans entre la proposition et l'intégration, ce qui donne une idée du rythme de développement des pilotes graphiques open source. Le code nécessite aussi un correctif au niveau du noyau Linux (dans le pilote Xe), qui devrait arriver avec Linux 7.1.

Les GPU concernés sont les Intel Arc à partir de la génération Alchemist (Arc A770, A750, etc.) et les plus récents Battlemage (Arc B580, B570).

Quelques limites quand même

L'optimisation ne fonctionne bien qu'avec les jeux DirectX 12. Sur les titres DirectX 11, les développeurs ont constaté des baisses de performances, ce qui fait que le mécanisme est activé automatiquement pour DX12 et désactivé pour DX11. Il est aussi possible de forcer son activation ou sa désactivation via un réglage dans la configuration DRI.

C'est le genre de petite avancée qui, mise bout à bout avec les autres, finit par rendre les GPU Intel Arc de plus en plus viables sous Linux pour le jeu. Cinq ans pour un patch, c'est long, mais le résultat est là. Et puis ça montre aussi que l'approche open source d'Intel sur ses pilotes graphiques continue de porter ses fruits, même si le chemin est quand même un peu plus lent que chez NVIDIA ou AMD.

Source : Phoronix

Un développeur américain a soumis en une semaine des modifications à trois projets Linux majeurs pour y ajouter un champ de date de naissance, au nom de lois californiennes et brésiliennes qui entreront en vigueur en janvier 2027.

Le plus gros morceau, systemd, a accepté la modification et refuse de revenir en arrière. La communauté open source est depuis en ébullition.

Un développeur solitaire, trois projets visés

Dylan M. Taylor, ingénieur DevOps basé en Caroline du Nord, a soumis des pull requests à systemd, Ubuntu et Arch Linux en mars 2026. Son objectif : ajouter un champ "date de naissance" dans la base de données utilisateur de chaque système, pour se conformer à trois lois qui entrent en vigueur le 1er janvier 2027.

La loi californienne AB-1043, la loi du Colorado SB26-051 et la loi brésilienne Lei 15.211 imposent aux systèmes d'exploitation de collecter l'âge des utilisateurs dès la création du compte, puis de transmettre cette donnée aux magasins d'applications via une API.

Le plus surprenant, c'est que personne ne lui a demandé de faire ça. Taylor a lu les textes de loi, estimé que Linux devait s'y conformer, et s'est mis au travail tout seul.

Il a lui-même reconnu dans sa pull request pour Arch Linux que le système serait "totalement inefficace pour empêcher quiconque de mentir sur son âge". Il a qualifié sa propre fonctionnalité de "hilarante d'inutilité", mais a quand même insisté pour l'intégrer.

systemd a accepté, et le revert a été refusé

Côté systemd, la modification a été acceptée par Luca Boccassi, un mainteneur qui travaille chez Microsoft. La pull request a généré 945 commentaires. Quand un autre développeur a tenté de faire annuler la fusion, Lennart Poettering, le créateur de systemd (ancien Red Hat, passé par Microsoft), a personnellement rejeté la demande le 19 mars.

Son argument : le champ est optionnel, systemd ne force rien, et les distributions sont libres de l'utiliser ou non. Le champ date de naissance reste donc dans le code.

Côté Ubuntu, les deux pull requests sont restées à l'état de brouillon. Un vice-président de Canonical a précisé qu'il n'y avait "aucun plan concret" pour intégrer cette fonctionnalité.

Côté Arch Linux, le mainteneur a verrouillé la discussion en attendant un avis juridique. Et Artix Linux a pris la position la plus claire : jamais de vérification d'identité ni d'âge dans leur distribution.

Des lois qui posent un vrai problème technique

Ces lois partent du principe que c'est au système d'exploitation de jouer le rôle de contrôleur d'identité. Sauf que Linux n'est pas Windows ou macOS : c'est un projet communautaire, maintenu par des bénévoles et des entreprises aux intérêts variés.

Collecter des données personnelles dans un système open source pour les transmettre à des magasins d'applications, c'est un changement de philosophie assez radical.

Un développeur d'Ubuntu a proposé une approche différente : une interface D-Bus optionnelle, sans stocker de date de naissance brute. Plus respectueux de la vie privée, mais ça ne fait pas non plus l'unanimité.

On a donc là un ingénieur qui admet que sa propre fonctionnalité ne sert à rien, et qui l'intègre quand même dans un des composants les plus utilisés de Linux. Le tout validé par un mainteneur employé chez Microsoft. Difficile de ne pas remarquer le problème.

Que des lois imposent la vérification d'âge aux systèmes d'exploitation, c'est une chose. Mais que ça passe par un bénévole qui pousse du code dans un projet open source sans que personne ne s'en rende compte avant la fusion, c'est un peu particulier quand même.

Source : Sambent