Renault a écrit 7813 commentaires

C'est du reverse engineering de bitkeeper effectué par Linus Torwald. Après il a fait des choix techniques différents, mais l'inspiration est là.

Linus Torvalds n'a pas fait de reverse engineering, il s'est inspiré de la conception mais n'a pas copié le fonctionnement interne de Bitkeeper ni tenté d'analyser le binaire ou autre pour comprendre les arcanes pour pondre git.

Et en plus de cela, Linus Torvalds n'a jamais caché que Bitkeeper a inspiré git pour certains concepts afin d'avoir le workflow adapté à son travail avec git.

Ici on est dans un autre registre tout de même.

Première conclusion : à partir du moment où une personne possède une voiture, ça n'a plus trop d'importance de déployer de grands moyens pour l'aider à l'utiliser MOINS.

Cela dépend car :

• Si la personne peut se passer de voiture, ça peut permettre à quelqu'un d'autres de se débarrasser de sa thermique par ailleurs car pour l'instant le parc reste essentiellement thermique encore ;
• Si la personne va dans des endroits avec peu de place de stationnement, pour circuler ou avec des bouchons, ça permettrait aussi d'améliorer le bilan de ce côté là ;
• Moins de voitures sur les routes facilite la circulation des vélos et transports en commun de manière générale ;
• Il y a des bénéfices sur la santé pour l'usager comme le reste de la population (pollution de l'air) à s'en servir le moins possible.

Il y a d'autant plus des effets dominos, si tu as de plus en plus de gens qui font des petits déplacements à pied ou à vélos dans ton entourage, tu es plus enclin à le considérer aussi.

Vivre à Paris n'est il pas une forme de torture ?

Cela dit, c'est affreux que la France (et d'autres) pratiquent la torture sous quelque forme que ce soit.

Il ne fallait pas fonder la ville de Paris.

Parce que pour monter jusqu'à 50°C, ça embarque une sorte de clim réversible, ces frigos ???

Une clim réversible et un frigo dans l'absolu c'est pareil pour la partie production de froid.

Exactement, donc rien à voir avec une quelconque amélioration de l'empreinte écologique telle qu'amenée en début de fil de discussion.

D'ailleurs pour analyser l'impact potentiellement positif de l'IA au travail d'un point de vue écologique, il faut faire une analyse contre factuelle ce qui est délicat en particulier ici où les hypothèses et possibilités sont nombreuses.

Par exemple pour expliquer l'idée.
Admettons que l'IA permette de rendre un informaticien plus productif de manière significative. Plusieurs scénarios s'ouvrent :

• L'informaticien utilise l'IA au boulot et fait globalement le même genre de tâches mais plus vite (et donc plus de tâches) => l'impact environnemental est clairement cumulatif
• On réduit le temps de travail des employés à effectif constant, la question est : qu'est-ce qui font durant leur temps libre ? Vont-ils polluer plus ou moins qu'en travaillant ? Et c'est délicat à dire, même en considérant qu'ils feront par exemple moins de trajets quotidiens pour bosser.
• On réduit le nombre de postes, et donc même chose, est-ce que les licenciés vont travailler encore ? Si oui, un travail plus ou moins émetteur ? Avec ou sans IA ? Si non, durant leur temps libre qu'est-ce qu'ils vont faire et si cette activité est plus ou moins écologique que leur travail.

Car l'humain qui travaille ou non a un impact écologique relativement constante pour la partie "survie", et le remplacer à son travail ne conduit pas à son retrait de la vie sur Terre (ou alors j'ai loupé un impact important) et comme l'humain continue de vivre et de s'occuper par le travail ou le loisir il faut prendre en compte ces impacts "nouveaux" pour tirer un bilan écologique de l'IA au travail de manière global.

Notons, cette approche contrefactuelle est valable pour étudier les impacts systémiques d'autres choses, genre est-il écologique de télétravailler où la réponse est comme souvent : sous certaines conditions.

Moi je crois qu'on voit le problème dans le mauvais sens. Le problème du sandboxing ne devrait pas être résolu avec flatpak ou snap mais directement avec l'intégration du système. On déplace le problème au mauvais endroit.

Je verrais la chose autrement en fait.

Déjà, quoiqu'on en dise, vues les polémiques autour de systemd, PolicyKit, PAM, etc. je ne doute pas un seul instant que si une distro traditionnelle faisait du sandboxing au niveau système comme tu dis, ça râlerait quand même avec des arguments souvent assez mauvais.

Ensuite, il faut voir aussi que ce n'est pas une tâche triviale. Beaucoup d'applications ne sont pas conçues pour fonctionner dans ces conditions, pour d'autres il faut avoir la capacité d'avoir des autorisations à la volée et non permanentes, c'est difficile de dire "on fait un système complet sandboxer" plutôt que d'apporter une technologie indépendante qui évolue à son propre rythme, permet de pousser la réflexion et de faire l'implémentation.

On peut aussi se poser la question dans le cas d'un système dit immuable comme Fedora Silverblue où les paquets Flatpak sont la référence et non l'exception, en quoi ces applications ne font pas partis du système en fait ? On peut considérer que d'inclure Flatpak pour en gérer toutes les applications de l'ordinateur comme pas très différent que d'utiliser n'importe quel système de bac à sable "intégré au système" comme le fait par exemple un Android. Finalement ça revient au même et rien n'empêche de reprendre les APIs et concepts pour fournir une alternative au besoin.

Mais là on parle de logiciels inclus par la distrib: Firefox, GIMP, etc. Ces logiciels n'ont pas d'effort particulier à fournir de leur côté, c'est le mainteneur qui s'en occupe.

Et chaque distribution doit avoir son propre mainteneur, ça duplique l'effort.

D'ailleurs, Mozilla ne fourni pas de snap pour Firefox: l'effort de packaging reste donc là. C'est sûr que c'est plus simple car on compile et exécute dans un environnement isolé, mais bon c'est quand même l'intérêt d'une distrib à la base d'avoir cette intégration…

Il y a des difficultés propres à chaque distribution dont il faut tenir compte. Cela peut être l'arborescence des systèmes de fichiers systèmes qui varient même si c'est moins le cas aujourd'hui, ou le fait que certaines bibliothèques ou utilitaires sont présents dans une version commune à tout le monde sauf que le logiciel n'a pas tenu compte de cette contrainte : tel paquet ne compile pas avec la dernière version de GCC, utiliser une version plus récente ou ancienne d'une bibliothèque introduit des bogues, ou la distribution active des options de compilations pour tout le système pour des raisons de performances ou de sécurité et cela ne fonctionne pas bien avec certains paquets, etc.

Toutes ces difficultés sont propres à chaque distributions et n'existent que parce que les distributions mutualisent un maximum de choses. Cela a des aspects bénéfiques bien connus mais l'effort en maintenance est réelle et n'a rien à voir avec l'effort de faire un Flatpak unique correspondant pour un logiciel donné.

Tout le monde est d'accord avec ça. Mais les paquets natifs ont un seul inconvénient : c'est une plaie à maintenir. D'où le snap/flatpak, surtout pour les applis qui bougent le plus (le browser est un excellent exemple).

Je ne dirais pas qu'ils n'ont qu'un seul inconvénient, il y en a un peu plus que cela quand même.

Le fait d'isoler les processus c'est un plus niveau sécurité / confidentialité ce que peu de paquets natifs offrent car il n'y a pas de solutions génériques pour le mettre en place en standard proprement, ou encore la flexibilité pour installer le paquet de son choix. Un Flatpak peut être installé dans ton système peu importe ta distribution et tu peux installer la version du Flatpak de ton choix facilement. Sans Flatpak tu es tributaire de la présence du paquet dans la distro et dans la version qu'elle propose ce qui peut être un problème.

Ce sont vraiment deux visions différents du systèmes avec plusieurs avantages et inconvénients. Mais petit bonus, rien n'empêche de mixer les deux selon les besoins aussi.

Ça dépend sûrement des enfants mais discuter des limites et surveiller gentillement à la main c'est ce que je préfère.
Au contraire, mettre un blocage technique pourrait être une incitation à le hacker et le début de quelque chose.

Tout dépend des situations, en tout cas je ne vois aucun problème à imaginer le scénario où les parents ne parviennent plus à réguler l'enfant / ado sur la question après avoir été souple au début et la mesure technique permet temporairement de mettre une limite forte avant de lâcher du lest au cours du temps.

Ce n'est pas exactement pareil que des parents qui mettraient ces limitations techniques d'entrée de jeux et qui restent actives sur une très longue période.

Pour le coup vérifier si la sortie a viré le canari, tu peux utiliser un script avant soumission des commits, c'est plus efficace que de lancer un agent de relecture.

Avant d'utiliser l'argument écologique, posez-vous cette questions : est-ce que si par magie on avait de l'IA sans aucun impact écologique, est-ce que ça changerait votre opinion ?
SI NON
Alors utilisez plutôt les autres arguments que vous avez : ils seront probablement plus solides.

Et qu'est-ce qui empêche d'avoir plusieurs arguments valables en même temps et qui fait qu'ensemble ce soit un problème ?

Tout le monde a des sensibilités différentes, cela ne me paraît pas aberrant de sortir tous les arguments valables à disposition même si certains sont plus forts dans l'absolu. Tant que cela a un sens évidemment.

C'est à dire que, parmi tous les trucs bénéfiques qui ont un impact écologique, pourquoi refuser spécifiquement le dernier arrivé ?

Je ne pense pas que ce soit systématiquement contre le dernier arrivé, c'est plutôt une question de structure.

Notre société, qu'on le veuille ou non, s'est structurée avec beaucoup de choses ce qui fait que décarboner / réduire l'impact écologique de ses éléments ne peut que prendre du temps. On pense au transport du quotidien (voiture), le chauffage des locaux / logements, les habitudes alimentaires, etc. Sans considérer que d'ailleurs ces éléments répondent souvent à des besoins vitaux.

C'est beaucoup plus facile de remettre en cause quelque chose de totalement nouveau dont la société n'a pas encore de dépendance pour éviter un impact important plutôt que de remettre en cause ce qui est déjà là.

Le défi est déjà important pour que chaque ajout d'un élément significatif nécessite des précautions plutôt que de renoncer à réguler sous prétexte qu'il y a pire ailleurs.

Et dans le contexte des années 2010, même si le PACS n'était pas un équivalent au mariage sur un certain nombre de points (de tête, l'héritage automatique en cas de décès, et une histoire de pension), je pense que le non accès au mariage n'était pas l'injustice la plus criante par rapport à l'interdiction d'adopter (qui est passé en même temps que le mariage en 2013), et l’accès à la PMA pour les couples de femmes (qui a été sacrifié en 2013 et qui est passé en 2021).

Il y a aussi, même si ça a peu d'importance au niveau national, le mariage est reconnu à l'international en tant que tel ce qui est rarement le cas des contrats type PACS ce qui a beaucoup d'impacts en cas de déplacement ou d'expatriation à l'étranger.

Évidemment un pays qui interdit le mariage homosexuel ne le reconnaîtra pas forcément (même si certains pays le font quand même), mais pour pas mal de pays avec une législations favorables cela a un impact non négligeable.

Je ne vois absolument pas pourquoi tu écris ça ⸮…

Je ne vois pas en quoi c'est lié, ni même que ça ait un sens.
Personnellement je ne comprends pas l'argument, les enfants ont de grosses journées à l'école, mais en quoi c'est une garderie ? Il y a des enseignements, du cadre, etc.

Oui les horaires en France ont un avantage certain de permettre aux parents qui travaillent aux heures de bureau habituels de pouvoir déposer et récupérer les enfants sans devoir finir le travail à la maison ou de choisir des boulots avec des horaires allégés et sans dépenser une fortune en garderie / baby siter / autres. C'est je pense une bonne chose aussi pour les mères qui sont dans de nombreux pays confrontés à une temps partiel très important pour cette difficulté.

En soi ce n'est pas une mauvaise chose, quand je compare à la Belgique où les parents temps plein font souvent 8h de travail par jour (et non 7h) et que les cours font du 8h30 - 15h30 en général, ça coince aussi pour l'équilibre vie perso / vie pro. D'ailleurs il faut constater l'armée de grands parents qui sont là en sortie des classe pour ceux qui ont cette possibilité car finalement pas le choix.

Le problème pour moi n'est pas là, c'est sans doute que la France surcharge trop les enfants d'enseignement dans la journée, et a de plus longues vacances pour compenser mais cela ne respecte pas le rythme des enfants. Peut être que l'alternative serait de suivre certains pays, des cours plus allégés en volume horaire quotidien mais du temps sportif / détente dédié et encadré pour combler le temps restant permettant aux parents de venir chercher les enfants. Et cela pourrait justement aider des enfants à prendre du plaisir à venir en cours en voyant autre chose que école = cours magistral pendant trop d'heures.

• l'inefficacité chronique de la fonction publique (coût du traitement d'une facture, de l'établissement d'une fiche de paye…)

Et tu as des éléments qui montrent qu'ailleurs ils sont bien mieux sur ce point ?
Car personnellement quand je regarde l'administration à l'étranger sur de nombreux points la France ne se démarque pas spécialement. Les administrations publiques partagent de nombreux problèmes de part le monde par nature, et c'est d'ailleurs visible aussi au niveau des grandes entreprises en général d'ailleurs (pour les mêmes raisons).

• la gestion "exemplaire" des RH dans la fonction publique

Pareil, ça se passe comment à l'étranger sur ce point ?

• le mille-feuille administratif des responsabilités et des financements (qui paye les chaises, qui paye les profs, qui paye les surveillants, qui organise le transport scolaire, les sorties, les équipements sportifs…), avec toutes les réunions de coordination nécessaires

Cf premier point.

Bizarrement pour avoir lu des comptes rendus PISA précédents (oui, ce n'est pas qu'un score, il y a des analyses plus détaillées), ce ne sont pas spécialement ces points qui sont mis en avant pour expliquer le score français.

À noter que ça n'est pas qu'une question de budget non plus. Question budget, on reste à peine sous la médiane de l'OCDE, donc en plus on n'est pas performants.

Comme d'habitude, prendre un chiffre sans le contextualiser un minimum ne permet pas de voir de potentiels problèmes.

Typiquement pour un coût égal par élève entre deux pays, les impacts peuvent être forts différents. Par exemple tu as plus d'établissements plus petits (car le territoire est plus grand et moins dense par exemple) cela induit des coûts plus important par enfant sans que cela ne se reflète dans la qualité du dit enseignement. De même tu peux dépenser plus pour certaines filières ou certaines classes d'âge ce qui peut avoir un impact sur le résultat final.

Si on lit l'analyse de l'OCDE de l'an dernier on peut avoir un début de problème :

Les dépenses par élève dans les établissements d’enseignement, provenant de sources publiques et privées, varient fortement selon les niveaux d’éducation en 2022. La France dépense 13 % de moins que la moyenne de l’OCDE par élève dans l’enseignement élémentaire (11 135 USD contre 12 730 USD), 5 % de moins dans le premier cycle du secondaire (13 622 USD contre 14 315 USD), mais 24 % de plus dans le deuxième cycle du secondaire (18 127 USD contre 14 562 USD) (Tableaux C3.1 et C4.1).

Source : https://www.oecd.org/fr/publications/2025/09/education-at-a-glance-2025-country-notes_9749f4ff/france_0639c7fb.html

Rappel, le PISA se fait sur des élèves de 15 ans donc fin de collège voire seconde. Or la France semble surtout mettre le paquet au niveau des lycées au détriment des collèges et écoles primaires.

Donc écarter la question du budget me semble bien prématuré. Après est-ce seulement une question de budget ? J'en doute fortement.

Oui enfin là clairement le noyau présenté n'est pas à jour, ni maintenu, du tout.

De toute façon il n'y a rien à perdre à tenter la chose.

C'est ces électeurs qui vont te faire gagner ou perdre et de ce que j'ai compris les démocrates n'ont, pour ainsi dire, pas fait de campagne.

Le fait d'avoir maintenu Biden dans la course si longtemps malgré les difficultés de santé qui commençaient à se voir n'a pas aidé non plus. Cela a repoussé la possibilité d'entamer la campagne, ça a divisé les démocrates pendant trop longtemps, et certains ont abordé le masquage des soucis de santé de Biden comme une méfiance envers eux.

Sans compter qu'il y a eu comme ailleurs dans le monde une inflation importante qui a été mis sur le dos de la politique de Biden alors que la réalité est plus complexe.

Donc oui je doute que Kamala a été rejetée en particulier car c'était une femme, il y a bien d'autres raisons pour expliquer cet échec électoral. D'ailleurs Hilary Clinton était aussi en bonne voie pour l'emporter mais la campagne n'a pas été bonne non plus.

Alors, est-ce que ça prend 10 ans ? Eh bah ça dépend. On peut grossièrement dichotomiser : il y a les progrès marginaux et les game changers. Le dernier game changer que j'ai en tête, c'est contre la mucoviscidose, mais celui que je connais le mieux, c'est contre l'hépatite C.

J'aurais pensé que tu aurais évoqué le COVID. :D

Parce que bon, on parle d'effondrement de modèle, mais c'est pas une problématique de LLM, c'est une problématique de toute analyse de données, dont il se trouve que le réseau de neurones est un cas particulier. Simuler des patients, fût-ce avec un réseau de neurones, c'est juste une méthode pour mettre de la jolie techno autour de "j'ai pas essayé mais t'inquiète je suis sûr ça marche". Bah non. Si ça marche, tu le donnes à des vrais patients et tu le prouves. Les cimetières sont remplis de gens qui ont pris des médicaments dont on était sûrs qu'ils allaient marcher.

En fait je suis étonné de cette approche par la simulation en l'état actuel des choses.
Le corps humain étant une grande usine chimique organique qui tourne H24 et dont de nombreuses choses restent à découvrir, je vois mal en quoi la simulation permettra de détecter une interaction non souhaitée entre le médicament et une autre partie du corps qui n'a rien à voir, ou encore s'assurer du bon absorption, la bonne tolérance du traitement malgré une alimentation, activité physique, rythmes ou métabolisme différents avec juste de la simulation.

À la fin il faut faire le test sur un patient et évaluer l'effet ce qui prend du temps selon les maladies considérées.

Plus sérieusement, l'équipe décide et je pense peut prendre cette décision peut importe l'avis de la communauté. Le texte reste intéressant. ;)

Ou alors une conspiration de l'équipe pour te demander de choisir un livre et voir si tu vas les engueuler car ils t'ont ajouté une charge mentale. :D

J'utilise GNU/Linux depuis 1999 et, durant toutes ces années, j'ai contribué à beaucoup de logiciels libres (Owncloud, KDE, GNOME, LineageOS…) et travaillé sur plusieurs projets perso (Lollypop, Mobile Power Saver…). Mais un composant m'a toujours fait peur : le noyau Linux. Dans ce journal, je vais montrer comment j'ai fini malgré moi par mettre le nez dedans, et pourquoi, pour du débogage, il n'est pas forcément nécessaire d'être une brute en programmation.

La noyau Linux est gros et un peu spécifique mais c'est loin d'être si complexe d'y contribuer, il ne faut clairement pas avoir peur d'y mettre son nez dedans. Il y a certainement des projets plus complexes fondamentalement selon la zone qui nous intéresse comme un navigateur web ou un compilateur.

Une partie de la difficulté du noyau c'est sa compilation, ça reste plus difficile de compiler et tester que la plupart des logiciels mais avec un peu de lecture et de connaissance générique en programmation ça n'est pas réellement un obstacle. Le test peut être plus difficile aussi, mais il y a maintenant beaucoup d'outils efficaces ou la possibilité d'utiliser des machines virtuelles par exemple pour s'en sortir. Je pense que la plupart des programmeurs même non experts du C ou C++ peuvent aborder cela avec un peu de lecture préalable.

Après niveau code, une bonne partie du noyau sont des pilotes de périphériques et c'est ce qui intéresse la plupart des personnes d'ailleurs. Nombre d'entre eux sont assez simples et se ressemblent ce qui aide à en écrire ou à corriger. Y toucher est relativement facile pour ceux là et ne sont pas plus complexes que beaucoup de code orienté objet qu'on peut croiser.

Pour les composants plus complexes (type carte graphique) ça peut être effectivement délicat, mais c'est souvent plus le périphérique lui même qui est complexe que le code noyau associé en tant que tel. Toucher aux sous systèmes entiers peut être aussi difficile car notamment le code est générique et couvre des sujets complexes, avec des optimisations et doit gérer des cas d'usage très variés. En général la meilleure approche c'est de se familiarisé par étape, par exemple si on veut toucher à la partie générique du système de fichiers (VFS), il peut être judicieux de d'abord s'attaquer à un système de fichiers simple avant de regarder le code générique qu'il appelle pour comprendre les contextes d'utilisation. Regarder l'historique des changements est aussi utile.

Par contre je pense que maintenir ces sous systèmes génériques est un grand challenge car il faut prendre en compte cette variété de cas d'usage et en avoir conscience des impacts potentiels de chaque changement ce qui n'est pas trivial du tout.

En tout cas n'hésitez pas à bidouiller un peu, si vous avez déjà programmé le noyau Linux n'est pas si spécial que ça, il n'a jamais été aussi facile de tester des changements rapidement et sans grandes conséquences. Le code est pour une bonne part pas si complexe qu'on pourrait le croire.

Ce n'est pas parce que tu passes par un prestataire externe que les employés ne sont pas formés et que c'est juste on installe un composant et hop.

Typiquement chez mon client l'aspect IT est délégué, c'est une entreprise externe qui configure et gère les serveurs, le réseau, les PCs, etc. Ce sont eux qui mettent en oeuvre les politiques de sécurité dans la boîte, avec les bonnes pratiques, des formations internes, installer des composants dans le parc, font la maintenance, etc.

Bref, ce que ferait une entreprise si elle avait des employés en interne pour cela sauf qu'ici c'est externalisé.

Est-ce mieux ou moins bien ? Je suppose que ça dépend des cas, il y a des avantages de l'externaliser aussi, des inconvénients, il y a parfois des contraintes pratiques aussi, bref au cas par cas.

Après si tout le monde délègue, toutes les fuites seront forcément à cause d'un prestataire.

Cela ne veut pas dire que si c'était géré en interne cela fonctionnerait mieux.

Vu la perte de TIPP, ils doit bien y en avoir qui planchent sur le moyen de récupérer une taxe quelconque sur les recharges de bagnole.

Alors ça s'évalue budgétairement mais il y a aussi des différences fondamentaux entre une voiture thermique et électrique pour un État non pétrolier.

Économiquement pour la France faire le plein c'est une bonne part de l'argent qui file surtout dans un pays étranger et qui quitte donc le territoire national pour financer une industrie et un État étranger.

Avec une voiture électrique c'est assez différent si la production électrique est essentiellement locale (donc pas à base de fossile). L'argent du plein électrique reste majoritairement dans l'économie nationale et finance l'infrastructure locale et une partie de celle-ci reste taxée même si moins fortement.

Sans compter que la pollution due au fossile (climat, qualité de l'air) mais aussi l'impact économique quand le pétrole ou gaz flambent diminuent dans le cadre d'un parc électrifié.

Donc peut être que malgré cet écart, le budget de l'État a besoin de compenser mais c'est normalement pas nécessaire de taxer aussi fortement car l'équation est radicalement différente.

En tout cas personnellement je pense qu'une taxation au kilomètre peut facilement être une usine à gaz qui pourrait être fait autrement : taxe spécifique pour la recharge publique, et pour la maison taxation supplémentaire de l'électricité au delà d'un certain volume.