Linus Torvalds Won't Stop Fighting People In Linux
Cette vidéo explore les emportements célèbres de Linus Torvalds sur les listes de diffusion du noyau Linux, montrant comment ces colères — souvent justifiées — ont façonné les règles de développement, la culture du projet et même son évolution communautaire.
SYNTHÈSE STRUCTURÉE
Les jurons comme outil de communication (1996)
Linus défend l’usage des jurons dans les commentaires du noyau, non comme une provocation gratuite, mais comme un vecteur de clarté émotionnelle et contextuelle. Il s’oppose à une suppression systématique des gros mots, qu’il compare à un « nettoyage moral » arbitraire.
« Profanities communicate something, be it good or bad, and they certainly tell you something about the mindset of the person who wrote the code. »
Il précise que le problème n’est pas le juron en soi, mais le contexte : un commentaire insultant sans justification technique est inacceptable, mais une censure aveugle est pire. Cette position explique pourquoi le noyau contient encore des jurons aujourd’hui.
Les fausses alertes des outils de vérification (2017)
Répondant à une proposition de Kees Cook, Linus fustige l’introduction de code qui tue la machine en cas de détection d’un problème par un outil de vérification. Il insiste sur le fait que ces outils produisent des faux positifs et que la bonne approche est de prévenir plutôt que de planter.
« Introducing new code that kills the machine, and then not owning the fact that it was your code that was broken, and instead saying, but we had to kill the machine. »
Il recommande que le code émette un avertissement (warn) pour collecter des rapports utiles, plutôt que de rendre la machine inutilisable sans explication. Cela illustre une règle clé : ne jamais sacrifier la stabilité pour un outil de vérification.
O_DIRECT et la tentation de contourner l’OS (2007)
Linus explique pourquoi l’option O_DIRECT (qui contourne le cache du système) est souvent mal utilisée par les développeurs de bases de données. Il rappelle que l’OS est un gestionnaire de ressources central, garantissant la sérialisation des I/O, l’allocation des blocs disque et la cohérence des états intermédiaires.
« The whole point of an OS is to be a resource manager, to make sure that people cannot walk all over each other. »
Il critique sévèrement ceux qui pensent pouvoir ignorer cette couche : « It sounds simple, but it sounds simple only to an idiot who writes databases and doesn’t even understand what an OS is meant to do. » Le message : contourner l’OS est rarement une bonne idée, sauf cas très spécifiques et maîtrisés.
La sécurité n’est pas plus importante que le reste (2008)
Linus refuse de hiérarchiser les failles de sécurité par rapport aux bugs classiques. Il dénonce le « cirque de la sécurité » qui glorifie les chercheurs et donne une importance démesurée à certains problèmes.
« I don’t think some spectacular security hole should be glorified or cared about as being any more special than a random spectacular crash due to bad locking. »
Il compare la mentalité des « security people » à celle de l’équipe OpenBSD, qu’il qualifie de « masturbating monkeys » pour leur obsession exclusive. Sa position : tous les bugs sont importants, et la sécurité n’est qu’un aspect parmi d’autres.
Le refus des patches non sollicités (2002)
Linus explique que l’intégration d’un patch dans son arbre dépend de la confiance qu’il accorde à l’auteur, basée sur son historique et la qualité de son travail. Il rejette toute notion de droit à être fusionné.
« The only thing you’re entitled to is to have your own tree. »
Il conseille aux contributeurs de ne pas « pleurnicher » pour obtenir une fusion, mais de convaincre par la qualité et la pertinence. Cette règle informelle est toujours en vigueur : la confiance se gagne, elle ne se réclame pas.
Les pull requests tardives et le code générique (2025)
Linus critique vertement des patches RISC-V envoyés en retard dans la fenêtre de fusion, contenant des helpers génériques inutiles comme make_u32_from_two_u16. Il dénonce l’ajout de code obscur dans des fichiers partagés, qui rend le code moins lisible et plus difficile à maintenir.
« That thing makes the world actively a worse place to live. »
Il exige que les pull requests soient envoyées tôt et que le code générique reste propre. Cette sortie montre l’importance de respecter les fenêtres de fusion et de ne pas polluer les fichiers communs avec des abstractions douteuses.
Les liens inutiles dans les messages de commit (2025)
Linus exprime sa frustration face aux liens Link: ajoutés automatiquement dans les messages de commit, qui pointent souvent vers des informations déjà présentes ou sans valeur ajoutée.
« Stop adding pointless link arguments that waste people’s time. Add the link if it has additional information. »
Il menace de ne plus fusionner les patches concernés et demande une explication réelle plutôt qu’un lien auto-référentiel. Cela souligne une règle de communication : chaque élément d’un commit doit avoir une utilité claire.
D-Bus et la performance du user space (2015)
Linus s’oppose à l’intégration de KDBus dans le noyau, arguant que les problèmes de performance de D-Bus viennent du code user space, pas du noyau.
« We don’t merge kernel code just because user space was written. »
Il refuse d’utiliser le noyau pour compenser les faiblesses d’un logiciel applicatif. Cette position rappelle que le noyau doit rester minimal et générique, et que les problèmes de performance doivent être résolus à la source.
Les signatures PE et la frontière kernel/userland (2013)
Linus rejette une proposition visant à intégrer la vérification de signatures PE dans le noyau, la jugeant inutile et mal conçue. Il suggère de faire ce travail en userland sur une machine de confiance.
« Do this in userland on a trusted machine. There is zero excuse for doing it in the kernel. »
Il critique également l’idée de « deepthroat Microsoft », montrant son opposition à toute dépendance inutile à des formats propriétaires. Le principe : le noyau ne doit pas absorber des fonctionnalités spécifiques à un fournisseur.
La règle d’or : ne jamais casser le user space (2012)
Linus s’emporte contre un mainteneur qui a introduit un changement cassant PulseAudio et a osé blâmer l’application. Il rappelle la règle fondamentale du noyau :
« If a change results in user programs breaking, it’s a bug in the kernel. We never, ever blame the user programs. »
Il critique aussi l’utilisation de ENOENT comme code d’erreur pour un ioctl, expliquant que ce code est réservé aux opérations sur les chemins de fichiers. Cette sortie est un rappel brutal : la stabilité de l’API user space est sacrée.
GitHub et la qualité des pull requests (2016)
Linus explique pourquoi il refuse d’utiliser GitHub pour les pull requests, dénonçant la perte d’informations essentielles (adresse email, diff stat complet) et la qualité médiocre de l’interface.
« GitHub throws away all the relevant information, like having even a valid email address for the person asking me to pull. »
Il encourage à utiliser git request-pull à la place. Cette position montre l’importance de préserver les métadonnées et le contexte dans les échanges techniques.
Le tournant : Sarah Sharp et le code de conduite (2013)
Linus répond à Sarah Sharp qui critique son comportement verbal. Il défend son style direct, arguant que l’honnêteté émotionnelle est nécessaire dans un environnement où les nuances se perdent par email.
« On the internet, nobody can hear you being subtle. »
Il refuse de « faire semblant d’être professionnel », associant cela à de la fausseté et de la politique de bureau. Cette confrontation a conduit à l’introduction du code de conduite et à son retrait temporaire du projet. Leçon : la communication dans un projet open source doit être explicite, mais le respect des autres reste essentiel.
GPLv3 et la défense du juste milieu (2006)
Linus critique la GPLv3, qui selon lui restreint la liberté des développeurs et divise la communauté. Il défend la GPLv2 comme un compromis acceptable pour tous.
« I want to be a passionate moderate. »
Il voit dans la GPLv3 une tentative de l’FSF d’imposer sa vision, au détriment de la diversité des contributeurs. Cette position illustre son attachement à un licensing pragmatique et fédérateur.
CONCEPTS CLÉS
- O_DIRECT : option d’ouverture de fichier qui contourne le cache du noyau pour les I/O directes, souvent mal comprise et utilisée.
- Fenêtre de fusion : période limitée après une release où les nouvelles fonctionnalités sont acceptées dans le noyau.
ENOENT: code d’erreur signifiant « No such file or directory », réservé aux opérations sur les chemins, pas auxioctl.- KDBus : projet avorté visant à intégrer le bus D-Bus dans le noyau, rejeté par Linus.
- GPLv2 vs GPLv3 : deux versions de la licence GNU, la v3 étant jugée trop restrictive par Linus.
- Code de conduite : ensemble de règles de comportement introduit dans le noyau après les controverses sur le ton des échanges.
CONCLUSION
Cette vidéo montre que les colères de Linus Torvalds, bien que parfois excessives, sont presque toujours motivées par des principes techniques solides : stabilité du user space, lisibilité du code, respect des processus de développement. Elles ont contribué à établir des règles informelles qui structurent encore le développement du noyau. Le tournant de 2013 avec Sarah Sharp a cependant forcé la communauté à réfléchir à la manière de concilier franchise et respect, aboutissant au code de conduite. Pour un administrateur système, la leçon est double : les règles techniques doivent primer sur les egos, mais la communication reste un facteur clé de la santé d’un projet.