Articles
Il est bien difficile de déterminer la date de naissance exacte du noyau Linux. Est-ce qu’elle se situe en avril 1991, quand Linus Torvalds a réellement commencé à travailler sur son projet de nouveau noyau ? Est‐ce le 25 août 1991, quand il a posté son célèbre message (« just a hobby, won’t be big and professional like GNU ») sur le newsgroup comp.os.minix ? Est‐ce que nous devons retenir le mois de septembre 1991 quand la version 0.01a été déposée sur le serveur FTP de l’Université de technologie d’Helsinki ?
Quelle que soit l’option retenue, l’année 2011 marque le vingtième anniversaire de ce prodigieux projet et, pour participer aux célébrations, LinuxFr a réalisé une interview de Linus Torvalds, dont vous trouverez une traduction en seconde partie de la dépêche.
Bien entendu, je recommande vigoureusement aux anglophones de lire la version originale de l’interview qui est présente en commentaire. Linus utilise souvent des expressions idiomatiques et le « Traduttore, traditore » est plus que jamais valable !
- Fêtez les 20 ans de Linux (700 clics)
- L’histoire du noyau (354 clics)
- Noyau Linux sur Wikipédia (223 clics)
LinuxFr : Tu travailles sur le noyau Linux depuis 20 ans maintenant et c’est un boulot difficile. Est‐ce que c’est toujours fun ?
Linus Torvalds : Oh absolument, c’est toujours fun. Et en partie parce que je fais ça depuis 20 ans, je ne dirais pas que c’est difficile. Cela reste stimulant et intéressant, mais je pense que je suis bon dans ce domaine.
LinuxFr : Pourquoi est‐ce que tu as choisi de passer le noyau sous licence GPL, alors que ta première licence n’était pas la GPL ? Est‐ce que c’était un choix pratique ou bien un choix éthique ?
Linus Torvalds : Pratique. Je pense que ma première licence contenait les parties éthiques qui étaient importantes pour moi, mais il s’est avéré qu’elle était trop stricte en ce qui concerne la partie « non‐commerciale », et en plus, elle n’était pas assez reconnue. Le passage sous licence GPL a corrigé les problèmes que les gens avaient avec ma première licence. En plus, cela nous a permis de rejoindre une licence connue qui avait bien plus de chance de tenir debout devant une cour de justice, par rapport au truc succinct que j’avais écrit à l’origine.
LinuxFr : Je sais que tu te considères comme une personne pragmatique et pas comme un prophète… Mais, est‐ce que tu serais d’accord pour dire qu’il y a un contenu de nature éthique dans la licence GPL ?
Linus Torvalds : Je vais répondre à ça de deux façons différentes, et je vais essayer d’expliquer pourquoi je réponds de deux façons différentes.
La première réponse, très négative, c’est que je méprise complètement les gens qui tentent de pousser la GPL comme étant de type « éthique ». Je pense que c’est de la pure connerie. Pourquoi ? Parce que l’éthique, pour moi, c’est quelque chose de privé. Chaque fois que vous l’utilisez dans un argument pour dire pourquoiquelqu’un d’autre devrait faire un truc, alors vous n’êtes plus éthique. Vous devenez juste une tête de con moralisatrice.
Mais la seconde réponse, c’est que personnellement je pense que la GPL (version 2) correspond à ce que je veux faire. J’aime vraiment programmer et je veux rendre disponible mon travail pour que les autres puissent en profiter. Mais je pense vraiment que tout le « vous pouvez faire ce que vous voulez, mais vos améliorations doivent être disponibles de la même manière que le code d’origine » est très juste, et que c’est un très bon moyen de faire du développement.
Donc, personnellement, je pense que la GPLv2 correspond d’assez près à ce que je pense être « la bonne manière de vivre ma vie ». Et par « bonne manière », je ne veux pas dire que ce soit la seule manière. J’ai fait aussi du développement sous licence commerciale et j’ai beaucoup aimé ça. Je pense que c’est aussi correct et approprié (Eh, ils m’ont payé pour le faire).
Donc, je pense que la GPLv2 est une bonne licence et je l’utilise pour mes propres raisons personnelles. Je pense que c’est aussi vrai pour de nombreuses autres personnes, mais je veux vraiment préciser que ce n’est pas la licence qui est éthique en elle‐même. Beaucoup d’autres personnes pensent que la licence BSD, avec ses libertés encore plus étendues, est une meilleure licence pour eux. Et d’autres préféreront utiliser une licence qui conserve tous les droits au propriétaire ducopyright et qui ne donnera aucun droit sur les sources aux autres personnes. Et pour eux, c’est leur réponse. Et c’est bien, c’est leur choix.
Essayer de promouvoir une licence particulière comme étant « le choix éthique » me rend malade. Vraiment.
LinuxFr : Pourquoi est‐ce que le « desktop » est si spécial et tellement plus difficile à investir que les autres marchés ?
Linus Torvalds : Parce qu’il est bien plus intéressant. C’est le marché sur lequel les gens font tant de choses différentes.
Un serveur typique ne fait presque rien. C’est vrai, il peut avoir une grosse puissance processeur, un réseau rapide et des tonnes d’entrées-sorties, mais il fait le même truc encore et encore, et ce « même truc » est vraiment limité. Cela consiste à gérer une base de données, un serveur de courrier ou de pages Web, à faire de l’analyse de données, etc.. C’est peut être important pour une entreprise, mais ce n’est pas une charge de travail très variée et ce n’est pas une chose à laquelle les gens sont attachés.
Par contraste, le desktop, c’est ce que vous voyez tous les jours et auquel vous devenez attaché. Cet attachement peut être une sorte de « syndrome de Stockholm » où vous ne l’aimez pas forcément (pensez à tous ces gens qui ont grandi en connaissant les ordinateurs à travers DOS ou Windows et son salut à trois doigts Ctrl-Alt-Suppr), mais même dans ce cas, cela devient une sorte de dépendance où vous êtes habitués et où vous vous reposez dessus bien plus que vous ne pourriez le faire par rapport au mainframe de l’entreprise.
Et sur une machine de bureau, vous pouvez faire tant de choses en plus. Vous jouez à des jeux, vous faites du traitement de texte dessus. Vous faites vos développements sur cette machine. Ce n’est pas limité à un seul truc.
Bien entendu, pour beaucoup de monde, c’est aussi devenu « vous utilisez un navigateur dessus » et pas grand chose d’autre. Mais, même cette seule utilisation tend à être une charge de travail bien plus complexe que la plupart des charges de travail des serveurs.
Ce qui est intéressant, c’est que les smartphones commencent lentement à partager certaines de ces complexités avec les desktops. Ce n’est pas encore exactement pareil (et ça ne le sera peut‐être jamais vraiment), mais les téléphones ont déjà une bonne part des problèmes riches et complexes qui caractérisent les ordinateurs de bureau, et en plus, ils ont des modes d’utilisation plus variés.
LinuxFr : Pourquoi Linux sur les machines de bureau n’a pas été adopté par la majorité des utilisateurs ? Est‐ce qu’il est possible pour la communauté du noyau d’améliorer la situation, ou bien est‐ce qu’il s’agit surtout d’un problème qui se situe au niveau des applications ?
Linus Torvalds : Je ne crois pas qu’il y ait grand chose que nous puissions faire au niveau du noyau, à part continuer à améliorer les choses en général et faire en sorte que nous restions techniquement le meilleur choix.
Et ce n’est pas comme si nous n’avions pas d’utilisateurs dans le grand public. Android est un exemple d’utilisation grand public de Linux. Le problème, c’est que ledesktop est un marché qu’il est difficile d’atteindre. Il y a un énorme « effet réseau » qui fait que lorsque vous avez beaucoup d’utilisateurs, c’est une bonne raison pour les retenir et pour en conquérir de nouveaux.
Il y a aussi le fait que beaucoup de gens ne veulent vraiment, vraiment pas changer leur environnement ; et s’ils sautent le pas, alors ils veulent de l’aide et du support. Ici, « support » n’est pas nécessairement du support commercial, c’est aussi savoir que vous avez des gens autour de vous qui connaissent le système et qui peuvent vous donner des conseils, etc..
Passer ce cap est difficile. Et ce n’est pas quelque chose qui se fait en pointant des problèmes techniques spécifiques. C’est souvent un problème social.
LinuxFr : Je sais que c’est une question étrange (et probablement stupide), mais est‐ce que tu es encore capable de comprendre complètement toutes les parties du noyau Linux, ou bien est‐ce que tu as vraiment besoin de tes mainteneurs ? Par exemple, en ce qui concerne le patch très complexe du « pathname lookup » de Nick Piggin, comment as‐tu fait pour choisir entre cette solution et celle de Dave Chinner ? Est‐ce que tu as reçu des conseils d’Al Viro ou bien est-ce que ça a été une décision solitaire ?
Linus Torvalds : Oh, je ne prétends absolument pas connaître et comprendre toutes les parties du noyau. J’en connais bien plus que la plupart des autres développeurs du noyau, mais il y a des endroits où je me repose presque entièrement sur les mainteneurs. Parce que je n’en connais tout simplement pas assez (ou bien je m’en fiche complètement — nous avons tous nos centres d’intérêt) sur un sous‐système particulier.
Ceci dit l’exemple que tu as choisi ne fait pas partie de ces zones. La couche VFS et la plus grande part du sous‐système de la mémoire virtuelle sont des endroits qui me sont parfaitement familiers, et donc je n’ai aucun problème à prendre moi‐même des décisions et à m’occuper du résultat, même sans aide. Bien entendu, cela ne veut pas dire que je ne m’attends pas à ce que des gens comme Al m’aident, et cela ne veut pas dire que je ne parle pas avec eux à ce sujet. Mais en ce qui concerne le pathname lookup, j’étais bien plus impliqué personnellement que dans la plupart des autres domaines.
Bien entendu, en temps normal, je ne veux pas vraiment me sentir obligé d’intervenir personnellement. Les patches du pathname lookup ont été disponibles pendant près d’un an et nous ne faisions pas beaucoup de progrès dessus (il y a eu des tonnes de discussions, mais pas assez d’avancées par rapport à ce que je voulais). J’ai fini par me faire le champion de ces patches avec un peu plus d’intensité que je ne l’aurais fait en temps normal. J’aurais été parfaitement content de passer par le canal des mainteneurs, comme d’habitude.
Dans d’autres cas, je ne peux pas faire le coup du « je m’implique et je prends la décision finale », parce que je ne connais pas nécessairement le sujet assez bien. Ou alors, parce que je ne me sens pas vraiment pour maintenir moi‐même le truc, si jamais j’emmerde vraiment trop le mainteneur officiel.
Dans ces cas‐là, je me contente de bousculer les gens et de tenter de susciter des discussions à propos des problèmes, mais au final, je dois faire confiance à celui qui s’empare du sujet et qui prend la bonne décision.
D’ailleurs, « bonne décision » n’est peut‐être pas le terme approprié. Parfois, vous devez juste prendre une décision. Il n’est pas toujours évident de savoir quelle est la « bonne » décision, et parfois il peut être bon de se contenter de dire « nous n’en savons rien » et de ne pas prendre de décision du tout. Dans d’autres cas, vous devez vraiment choisir entre des alternatives techniques. La bonne nouvelle, c’est que la plupart des choix techniques peuvent être changés si, plus tard, il s’avère qu’ils étaient erronés. Cela peut être douloureux, mais parfois il vaut mieux faire un choix, même si vous ne savez pas si c’est le bon. Même s’il y a une chance que vous ayez à revenir sur votre décision plus tard.
Je dois dire que ce genre de situation est en réalité assez rare. La plupart du temps, le processus de développement fonctionne sans que personne n’ait à faire de choix particulièrement difficile. La plupart du temps, la direction à prendre est très claire, et ce qui est le plus difficile, c’est de trouver les gens pour écrire vraiment le code :).
LinuxFr : Qu’est‐ce que tu penses de cette citation de Lennart Poettering ? : « En fait, de la façon dont je vois les choses, l’API Linux joue maintenant le rôle de l’API POSIX, et Linux est devenu le point focal de tout le développement du logiciel libre. De ce fait, je ne peux que recommander aux développeurs d’essayer de “hacker” avec seulement Linux en tête, et de faire l’expérience de la liberté que cela apporte et des opportunités que cela vous ouvre. Procurez‐vous une copie du livre “The Linux Programming Interface”, ne vous préoccupez pas de tout ce qui est écrit dedans au sujet de la compatibilité POSIX et écrivez votre super logiciel Linux. Ça soulage ! ».
Linus Torvalds : Eh bien, je pense que cela peut être une façon raisonnable de simplifier un problème très difficile (la portabilité).
Une raison pour laquelle cela peut être une bonne idée, c’est que nous n’essayons vraiment pas d’étendre trop — et jamais gratuitement — les interfaces standard. Même si vous décidez de ne vous préoccuper que de Linux, c’est vraiment dur d’arriver à un résultat final qui sera horriblement non portable. Linux est vraiment un UNIX tout à fait standard dans bien des aspects et, même en dehors des systèmes UNIX, la plupart des frameworks que vous allez utiliser sous Linux sont aussi disponibles sous d’autres plates‐formes (souvent parce que ces frameworks sont open source).
Donc, si vous décidez par la suite qu’après tout, vous voulez être portable, commencer uniquement par Linux n’est probablement pas un mauvais choix. Et cela peut simplifier le processus de décision initial dans un projet.
LinuxFr : Est‐ce que tu penses que systemd est une grosse amélioration par rapport à l’init SysV ? Est‐ce que c’est susceptible de bouleverser la situation ?
Linus Torvalds : Là aussi, j’opterai pour une attitude du type « attendons de voir ». Pour l’instant, ce n’est pas encore assez utilisé pour se faire une opinion. Je suis d’accord pour penser que le temps de démarrage est un facteur important, et tout changement qui peut améliorer les choses et rendre le processus plus flexible, est une bonne chose.
Est‐ce que j’appellerais ça un « bouleversement de la situation » ? Probablement pas.
LinuxFr : Est‐ce que tu utilises Btrfs ? Quand penses‐tu qu’il sera prêt à remplacer ext4 comme système de fichiers recommandé par défaut ?
Linus Torvalds : J’ai utilisé Btrfs sur les quelques portables que j’ai ; mais franchement, quand il s’agit d’utilisation d’un système de fichiers, le facteur principal, c’est le support des distributions. À peu près rien d’autre ne compte, du moment que les fonctions de base sont présentes. Donc, la manière, pour un système de fichiers, de devenir la solution recommandée par tous, c’est qu’il y ait une distribution qui opte pour ce système de fichiers par défaut. Tout simplement parce que les gens ne privilégient pas les fonctions ni les performances, mais la stabilité.
En ce qui me concerne personnellement, je ne me soucie plus de ce genre de truc. J’ai eu des problèmes avec ext3 (en particulier, des performances fsynchorribles), mais la plupart de ce que je fais est totalement dominé par la couche VFS, parce qu’elle permet si bien de tout mettre en cache (j’ai les sources du noyau en RAM tout le temps et le système de fichiers n’a aucune importance, parce que toute la mise en cache est effectuée par les routines génériques).
LinuxFr : Avec Linux et Git, tu as créé deux logiciels qui ont changé le monde de l’informatique. Comment est-il possible d’avoir à son actif deux gigantesques succès comme ceux‐là ? Quelle est la différence entre toi et les simples mortels ?
Linus Torvalds : Je pense qu’une bonne part vient juste de ma persévérance obstinée. Spécialement Linux. J’étais au bon endroit et au bon moment, mais d’autres auraient pu créer leur propre système d’exploitation. Et d’ailleurs, d’autres l’ont fait. Mais très peu de gens l’ont fait avec autant d’obstination que moi. Je suis sur ce truc depuis vingt ans.
La plupart des autres développeurs qui bossent sur un quelconque projet privé pour leur propre plaisir, ne persistent pas assez longtemps pour qu’il devienne prêt pour une publication. Encore moins quand on compte en décennies.
Avec Git, les choses sont un peu différentes. En partie parce que j’avais un cas d’utilisation qui était suffisamment important (le noyau) pour que je puisse le lancer, mais aussi en partie parce que je suis vraiment arrivé avec une nouvelle vision sur un problème ancien. Et je pense que j’ai fait du bon boulot en tant qu’architecte du projet. Je pense vraiment que Git a fondamentalement une bonne conception (dans le cas de Linux, je pouvais tout simplement m’appuyer sur la conception d’UNIX qui avait déjà été créé), et j’ai pu l’imposer parce que Linux avait besoin de plus que ce que pouvaient offrir les autres gestionnaires de code.
Mais avec Git, une grande partie de la reconnaissance est en réalité due à Junio Hamano. Il a vraiment été un grand mainteneur. Les gens comme ça sont importants. Oui, c’est vrai, la programmation open source est un sport d’équipe, mais trouver la bonne personne est vraiment d’une importance cruciale (la même chose est évidemment aussi valable en ce qui concerne le noyau — je pense vraiment que nous avons un excellent groupe de mainteneurs. Je peux parfois me plaindre d’eux et je suis tristement célèbre pour mes engueulades quand les choses ne marchent pas, mais en même temps, je suis convaincu qu’il y a quelques‐uns des meilleurs programmeurs existants qui travaillent à maintenir le noyau).
LinuxFr : J’ai vu que tu lisais beaucoup de trucs sur la biologie et la théorie de l’évolution (par exemple, Richard Dawkins). Est‐ce que ces connaissances sont utiles pour le processus de développement de Linux ? Est‐ce qu’il s’agit surtout d’un modèle de compétition darwinien ou bien plutôt d’un modèle coopératif ?
Linus Torvalds : Je ne crois pas que ce soit utile pour le noyau, mais c’est un fait qu’il s’agit d’un domaine qui m’intéresse. La biologie, l’évolution, le comportement humain — ce sont tous des sujets fascinants. Et je pense qu’il y a des parallèles entre le développement technologique et l’évolution. Évidemment, je ne crois pas à l’« intelligent design » quand il s’agit de biologie (et je pense que quiconque croit en ça est dramatiquement mal éduqué), mais après tout, je pense souvent que l’« intelligent design » est aussi très surfait dans le domaine technologique. Beaucoup d’améliorations technologiques semblent vraiment relever d’un mode de développement plus « organique » et très peu d’entre elles sont complètement conçues dès le début.
En fait, je pense que la plupart des problèmes techniques intéressants sont trop compliqués pour pouvoir faire un « design » à leur sujet. La manière d’arriver à une solution, c’est surtout d’avoir des améliorations progressives et de faire des essais et des erreurs.
LinuxFr : Tu es maintenant un citoyen américain. Qu’est‐ce que tu penses de la loi sur les brevets logiciels aux États‐Unis ? Est‐ce que ta voix est suffisamment écoutée pour que tu puisses aider à combattre cette loi dans ce pays ?
Linus Torvalds : Je dois admettre que, même si je n’aime pas les brevets, j’essaie également de me tenir à l’écart pour ne pas être trop impliqué dans des problèmes de cette nature. Je suis bon dans ce que je fais et je pense qu’il y a des gens qui sont meilleurs que moi pour combattre ce bordel des brevets. Et je pense que ça doit être combattu depuis l’intérieur du système — donc je m’attends à ce que la solution vienne en réalité des entreprises qui seront impactées par tout ce bazar.
LinuxFr : Tu écris souvent des messages détaillés sur realworldtech.com, mais je ne t’ai jamais vu poster sur lwn.net. Pourquoi ? Est‐ce que tu lis régulièrement lwn.net ?
Linus Torvalds : Eh, rwt, c’est l’endroit où je vais pour « enflammer » les gens et pour me disputer au sujet des architectures des ordinateurs. J’aime les gens qui répliquent et j’aime aussi le fait que ce ne soit pas des gens impliqués dans Linux, ou même que ce soit sans aucun rapport avec Linux. Donc, je peux balancer mes opinions et voir ce que je reçois en retour.
Avec lwn, ce serait une histoire complètement différente.
LinuxFr : Plusieurs personnes ont critiqué la sécurité du noyau. Est‐ce que tu penses que les développeurs travaillent suffisamment sur les mécanismes de sécurité et sur les revues de code ? Est‐ce que tu penses que des parties de GRSecurity devraient être importées dans la branche principale ?
Linus Torvalds : Je pense que nous avons fait un assez bon travail, mais l’un des problèmes avec le monde de la sécurité, c’est que c’est très noir et blanc. Pour certaines personnes dans la sécurité, même le fait d’employer l’expression « assez bon travail » est un signe d’alerte rouge. Ils ne pensent pas qu’un « assez bon travail » est assez bon. Ils pensent que la sécurité est, en quelque sorte, tout ce qui importe.
Et je ne suis pas d’accord. La plupart des problèmes de sécurité sont juste des bogues. Nous devons essayer d’éviter les bogues, mais les bogues arrivent. C’est un truisme, mais je pense que c’est vraiment à quoi cela se réduit au final. Est‐ce que nous sommes meilleurs pour éviter les bogues que les autres projets ? Je pense que nous ne nous débrouillons pas trop mal, spécialement si on considère la quantité démentielle de code que nous écrivons ou modifions chaque jour.
Je ne crois pas que ce soit utile d’essayer de séparer les « bogues de sécurité » des autres bogues. Ce sont juste des bogues et presque chaque bogue peut être un bogue de sécurité en fonction des circonstances.
Quant à GRSecurity, je pense que nous avons pris les choses importantes et que nous avons laissé de côté les trucs extrêmes (les choses qui gênent vraiment l’utilisation ou qui sont extrêmement intrusives).
En général, la meilleure manière de faire face aux problèmes de sécurité consiste à avoir plusieurs couches de défense. On ne peut jamais éradiquer complètement les bogues dans un quelconque programme digne d’intérêt, mais avec des couches successives de sécurité, l’une d’entre elles finira, je l’espère, par protéger contre un bogue qu’il aurait été possible d’exploiter sans.
Donc, dans le noyau, nous avons tendance à essayer d’avoir des couches génériques qui ont des mécanismes de contrôle de sécurité, le plus tôt possible. Comme ça, même s’il y a un bogue dans un système de fichiers ou dans un pilote, c’est plus difficile de rendre ce bogue exploitable. Et quand nous trouvons un débordement quelque part, nous le corrigeons et en même temps nous ajoutons (quand c’est possible) des vérifications de plus haut niveau pour empêcher qu’il ne se reproduise. C’est pour ça que dans la plupart des cas, nous finissons par corriger plusieurs trucs pour un même problème — chacun des patches aurait corrigé un truc en lui‐même, mais mis ensemble, nous espérons qu’ils seront plus résistants au cas où un problème similaire apparaîtrait ailleurs (ou soit réintroduit au même endroit — c’est embarrassant quand ça arrive, mais c’est déjà arrivé).
LinuxFr : Est‐ce que tu penses que les experts en sécurité et les créateurs d’exploitations de failles de sécurité ont une mentalité différente, si on la compare aux autres développeurs du noyau ?
Linus Torvalds : Oh, oui. Certains des « exploits » les plus intéressants m’ont fait penser que « ça nécessite vraiment un esprit tordu pour arriver à ce truc », et j’ai été carrément impressionné.
Mais il ne s’agit pas toujours d’être impressionné. Très souvent, je suis plutôt déprimé par le caractère sordide des milieux de la sécurité. C’est vraiment un cirque. Une grande partie de tout ça se réduit à des effets de manche et à des communiqués de presse (de tous les côtés : les vendeurs, les gens de la sécurité, les créateurs d’« exploits », etc.).
LinuxFr : J’ai réalisé une entrevue avec Brad Spengler (GRSecurity) et je lui ai posé une question sur son opinion à propos de toi et de la sécurité du noyau. La réponse de Brad a été : « Il peut à l’occasion comprendre les problèmes de sécurité mieux que les autres développeurs, mais la sécurité ne fait pas partie de ses buts principaux. Ses idées en ce qui concerne la sécurité ont conduit à la politique officielle des développeurs du noyau, qui est de ne pas mentionner les informations de sécurité dans les journaux des modifications (changelogs) et de traiter tous les bogues de la même façon. Ses idées sont destructrices. »
Est‐ce que tu penses que tous les bogues devraient être traités de la même façon ? Et pourquoi ?
Linus Torvalds : J’ai tendance à penser que tous les bogues devraient être traités de la même manière, et je ne veux ni signaler ni cacher nos problèmes de sécurité.
Le fait est que même les gens qui travaillent dans le domaine de la sécurité ne sont pas d’accord entre eux. Un bon nombre exige une transparence totale. D’autres veulent une transparence limitée (juste les vendeurs et les grosses institutions financières). D’autres encore veulent maintenir un secret total, à la fois pour éviter d’être embarrassés, mais aussi en partie pour éviter le risque de dissémination des infos vers les « black hats » qui écrivent des exploits.
Et il y a aussi les controverses au sujet des fuites. Tout le monde sait qu’il y a différentes sortes de « bad guys ». Cela va du type sympa qui veut juste essayer un truc (Eh, les gamins à l’université qui ont entendu parler d’un exploit et qui veulent le tester pour voir si ça ça fait vraiment tomber le gros ordinateur de leur fac), au« script kiddie » qui aime bien emmerder les autres, mais qui n’a pas nécessairement des connaissances ou des compétences impressionnantes, ou encore des gens qui sont vraiment intelligents et qui pourraient faire des trucs criminels pour gagner un maximum.
Comment est-il est possible de concilier ces points de vue divergents ? Ma position est que ce n’est pas possible.
Il n’y a pas de « réponse unique » et les gens qui essaient d’imposer leur point de vue en matière de dissémination (ou pas) de l’information font plus de mal que de bien.
Donc mon opinion personnelle est que la seule approche saine consiste à réaliser que le problème n’est pas soluble, et à juste traiter les bogues comme des bogues. On essaie en premier lieu de les éviter, mais quand ils surviennent, alors on les corrige. Et on les corrige sans crier sur les toits tous les détails sur comment écrire unexploit en partant du bogue, ou sans essayer de faciliter le boulot de ceux qui voudraient trouver des bogues à exploiter.
Oui, cela peut impliquer de ne pas dire dans le journal des modification tout ce que nous savons sur comment il est possible d’exploiter le bogue, ou même pointer vers une alerte de sécurité à son propos.
Est‐ce que les gens de la sécurité sont toujours d’accord avec moi ? Putain, non. Mais ils ne sont pas non plus d’accord entre eux, alors qu’est‐ce que ça prouve ?
LinuxFr : Est‐ce que tu as une opinion sur la qualité d’OpenBSD ? Ils mettent énormément l’accent sur la sécurité. Est‐ce qu’il y aurait des leçons à tirer de ce projet ?
Linus Torvalds : Je pense que tous les projets de système d’exploitation qui se concentrent sur un seul but sont des échecs, et cela quel que soit le but.
La sécurité en elle‐même n’est pas un but digne d’intérêt — vous avez besoin d’avoir des utilisateurs pour que la sécurité ait une quelconque importance.
Donc, je pense que la concentration exclusive sur la sécurité dans OpenBSD rend juste le projet moins intéressant et utile en définitive.
Mais là encore, il s’agit de ma mentalité générale qui consiste à penser que « les bogues sont juste des bogues ». La sécurité est importante, mais les performances aussi et les fonctionnalités également. Le monde n’est pas juste blanc ou noir. Il n’y a pas un seul truc qui soit plus important que tout le reste.
LinuxFr : Le compilateur LLVM fait de grands progrès. Qu’est-ce que tu penses de ce projet ? Est-ce que l’architecture de LLVM est meilleure que celle de GCC, et est-ce que tu penses qu’à long terme il va remplacer GCC ?
Linus Torvalds : Remplacer ? C’est possible, mais je ne pense pas que ce soit très probable. Je trouve effectivement que les compilateurs constituent un sujet intéressant, et je pense que c’est bien d’avoir un peu de compétition dans ce domaine, donc j’apprécie de voir LLVM faire cet effort.
LinuxFr : Il y a un noyau Linux dans ma box ADSL envoyée par mon fournisseur d’accès à Internet. Il y a aussi un noyau Linux dans ma télévision Sony et dans mon imprimante. Pourtant, je ne suis pas libre de « hacker » le code de ma box ADSL, de ma télévision ou de mon imprimante (du fait des raisons légales ou du fait de la « tivoisation »). Qu’est‐ce que tu penses de cette situation ?
Linus Torvalds : Personnellement, je suis d’avis que les matériels flexibles sont plus intéressants que les matériels verrouillés, mais en même temps, pour moi, la notion « d’échange équitable » a toujours été une notion liée au code et aux idées, pas au matériel.
Donc, tout mon problème au sujet de Tivo et des autres entreprises de ce type, a toujours été « Eh, ils ont conçu et construit ce matériel, le fait qu’ils aient utilisé mon code dedans ne me donne aucun droit spécifique sur ce matériel ».
Comme ils utilisent Linux, j’attends d’eux qu’ils rendent disponibles leurs patches sur le code de Linux, comme la licence l’exige. Il y a évidemment des entreprises qui ne font même pas ça, mais c’est une exception plutôt que la règle.
Donc, vous pouvez récupérer le code de Linux avec leurs modifications, et vous pouvez concevoir et construire votre propre box ADSL ou votre télévision ou tout ce que vous voulez, et utiliser toutes les améliorations de Linux qu’ils ont pu faire. Ou bien, plus important, vous pouvez utiliser leurs améliorations de Linux même si vous ne construisez pas une box ADSL — vous pouvez utiliser leurs patches sur votre desktop ou sur une machine sans aucun rapport. C’est là où les améliorations deviennent vraiment intéressantes — quand vous les utilisez pour autre chose que ce qui était prévu à l’origine.
Maintenant, bien entendu, la plupart des entreprises qui utilisent Linux dans ce domaine n’ont pas besoin de faire tant de changements que ça dans le noyau, donc il n’y a peut être aucune amélioration. C’est bien comme ça aussi. Si Linux marche pour eux sans changements, alors tout va bien. De la même manière, il marchera pour vous sans changements si vous voulez créer un matériel identique.
Donc, j’ai toujours pensé que toute cette histoire de « tivoisation » était un truc stupide. Si vous voulez faire votre propre machine Tivo, alors faites-la. Ne pensez pas que juste parce qu’elle se base sur du code open source, vous devriez contrôler le matériel. C’est de l’open source. Si vous voulez faire de l’open hardware, alors faites de l’open hardware.
Ceci dit, je pense qu’il existe de sérieux problèmes au sein de l’industrie du contenu, quand les fournisseurs de contenu utilisent la loi ou des mesures techniques de protection (MTP / DRM) pour essayer en réalité d’entraver les gens et de se créer des situations de monopole. Je n’aime pas les MTP. Mais je pense que c’est un problème différent de celui des licences de logiciels, et je pense aussi que c’était une faute grave de la part de la FSF d’essayer d’utiliser la GPLv3 comme une manière de transformer les projets des autres en armes dans leur lutte contre les MTP.
Je suis très content d’avoir rendu clair le fait que Linux est un projet uniquement GPLv2, et cela des années avant que tout ceci n’arrive.
LinuxFr : Quelle est ton opinion au sujet d’Android ? Es‐tu surtout content qu’ils aient rendu les téléphones portables très utilisables, ou bien es‐tu triste, parce qu’il s’agit en fait d’un « fork » du noyau ?
Linus Torvalds : Je pense que les forks sont une bonne chose, ils ne me rendent pas triste. Pas de mal de développement dans Linux s’est fait via des forks, et c’est la seule manière de continuer à avoir des développeurs intègres — la menace que quelqu’un d’autre puisse faire un meilleur travail et mieux satisfaire le marché en faisant les choses de façon différente. Le but même de l’open source, pour moi, est vraiment la possibilité de « forker » (mais aussi la possibilité pour toutes les parties de réintégrer le contenu qui a été « forké », s’il s’avère que c’était le « forkeur » qui avait eu raison !).
Donc je pense que le fork d’Android a obligé les développeurs de la branche principale à regarder sérieusement certains des problèmes que rencontrait Android. Je pense que nous avons résolu tout ça en mainline et j’espère (et je crois) qu’Android finira par réintégrer la branche principale. Mais cela prendra probablement un certain temps et nécessitera des efforts.
Je pense que le problème le plus sérieux, à long terme, que nous ayons actuellement dans le noyau, c’est l’incroyable prolifération sauvage du code des plates‐formes pour l’embarqué. Surtout ARM, pas parce qu’ARM est en quoi que soit fondamentalement plus délirant que le reste, c’est juste en raison du fait qu’ARM est de loin la plate‐forme qui rencontre le plus grand succès. Le monde de l’embarqué a toujours eu tendance à éviter les plates‐formes standardisées : ils avaient trop de contraintes de ressources, etc., donc ils ont conçu des puces et des chipsets sur mesure, et ils ont toujours pensé qu’ils ne pouvaient pas se permettre une trop grande abstraction de la plate‐forme.
Cela provoque pas mal de problèmes de maintenance, parce que ces plates‐formes semblent toutes un peu différentes vues du noyau, et que nous avons des quantités démentes de lignes de code, juste pour supporter toutes ces variations, alors que fondamentalement ce ne sont que des petites variations arbitraires autour d’un même truc.
Mais tout ça se produit à la fois au sein et en dehors d’Android, ce n’est en rien lié spécifiquement à Android.
LinuxFr : Qu’en est‐il des différences techniques entre Android et la branche principale ? Peut‐on résoudre la controverse autour de « wakelock » ?
Linus Torvalds : Je pense que techniquement tout est déjà largement résolu (comme dans « on doit s’occuper des détails, mais il n’y a rien de fondamentalement effrayant »), mais dans les faits, une fois que vous avez une interface et du code qui l’utilise, c’est un gros travail de faire un changement. Peut‐être qu’il n’y a pas assez de motivation pour faire ces changements rapidement. Donc, ça prendra du temps et probablement plusieurs versions (que ce soit dans la branche principale ou dans Android) avant que cela n’arrive.
LinuxFr : Windows 8 va fonctionner sur l’architecture ARM. Est‐ce que c’est une menace réelle pour la domination de Linux sur le marché de l’embarqué ?
Linus Torvalds : Ce n’est pas comme ça que je raisonne, je ne m’en préoccupe pas. Linux n’est en compétition qu’avec lui‐même, pas avec Windows. Autrement dit, du moins en ce qui me concerne, la seule chose dont je veux m’assurer, c’est que Linux s’améliore.
Cependant, je suspecte que pour arriver à gérer ARM, Microsoft va finir par exiger une certaine standardisation des plates‐formes pour les configurations qu’ils vont supporter. Cela rendra notre travail plus facile. Et je n’ai aucune objection contre ça.
LinuxFr : Peux‐tu expliquer pourquoi tu n’es pas vraiment content des patches ARM qui te sont envoyés lors de la « fenêtre d’intégration » ? Est-ce qu’il existe une solution évidente à ce problème de fragmentation ?
Linus Torvalds : Une solution évidente ? Non. Le problème, c’est la variété démentielle du matériel, et le fait que dans beaucoup de cas le code Linux des plates‐formes ARM (pas le support des processeurs ARM, juste le code de certaines puces avec tous ces problèmes de code glu autour du processeur) a souvent consisté en d’infâmes copier‐coller venant de fichiers concernant d’autres plates‐formes ARM, avec juste les modifications minimales pour permettre le support du nouveau matériel.
Et le résultat est un bordel impossible à maintenir. Tout ça devient vraiment pénible quand quelqu’un corrige un problème au cœur de l’infrastructure et que cela implique de changer des centaines de fichiers ARM différents qui utilisent tous cette infrastructure. C’est arrivé avec le boulot de nettoyage des pilotes IRQ que Thomas a effectué récemment (en fait, il a bossé là‐dessus depuis longtemps, et ce qui a été incorporé récemment, c’est juste la suppression de certaines vieilles interfaces pourries).
Cela provoque également d’autres problèmes de maintenance — les patches qui deviennent énormes —, cela signifie que les gens ne les regarderont pas d’aussi près, etc., etc.. Donc, la situation est vraiment mauvaise. La plupart de ces problèmes devraient pouvoir se résoudre en ayant de meilleures solutions génériques et en branchant dessus le code vraiment spécifique à chaque plate‐forme.
LinuxFr : Quelle est ton opinion sur les micro‐noyaux ? Est‐ce que tu continues de penser qu’ils sont un échec technique ?
Linus Torvalds : Oui, je suis toujours convaincu qu’il s’agit d’une de ces idées qui sonnent bien sur le papier, mais qui sont finalement des échecs en pratique. Parce que dans la vraie vie, la complexité se trouve dans les interactions, pas dans les modules individuels.
Et les micro‐noyaux s’efforcent de rendre les modules encore plus indépendants, ce qui rend les interactions encore plus compliquées et indirectes. Cette séparation aboutit au fait de supprimer pas mal de canaux de communication qui sont simples et évidents.
LinuxFr : Et à propos des systèmes d’exploitation à code géré (managed code), comme Singularity ? Est‐ce que c’est plutôt un projet de recherche, ou bien penses‐tu que ça peut vraiment marcher ?
Linus Torvalds : Moi, je suis plutôt du genre dur et pragmatique. À l’heure actuelle, cela ressemble uniquement à un projet de recherche. En fait, le diable est dans les détails. Un bon paquet de ces merveilleux projets théoriques de nouveaux environnements se contentent d’évoquer des grandes idées générales, et ne parlent pas de tous les petits détails dont vous devez prendre soin quand vous avez des tas d’utilisateurs bien allumés qui font des trucs bizarres et merveilleux.
En fait, je n’en vois pas l’intérêt. Les systèmes d’exploitation ne sont pas si compliqués que ça, après tout. Il n’y a rien de fondamentalement mauvais dans le modèle UNIX. C’est vrai, nous avons beaucoup de code et je ne prétends pas que ce code est simple, mais c’est parfaitement possible gérer. Les plus gros problèmes que nous ayons, concernent surtout le support des pilotes et des plates‐formes — et ces trucs ne se règlent pas avec des nouveaux modèles de programmation.
Les micro‐noyaux ou les systèmes d’exploitation en code géré ? Cela ne résout aucun des grands problèmes que je connais.
LinuxFr : Imagine que nous sommes en 2031 et que le noyau Linux a maintenant quarante ans. Es‐tu toujours le leader du projet ? Penses‐tu que le noyau est toujours plus ou moins le même qu’en 2011, ou bien de nouvelles innovations radicales ont‐elles été incluses ?
/troll mode: Est‐ce que le noyau a été réécrit en C++ ?
Linus Torvalds : J’espère vraiment, vraiment, qu’en 2031 nous aurons dépassé le stade où le système d’exploitation est le lieu approprié pour les idées radicales. C’est clair que les machines auront toujours un système d’exploitation, et j’espère que ce sera Linux, mais il vaudrait mieux que tout le travail radical et intéressant soit fait en espace utilisateur, afin de nous permettre d’interagir de façon plus excitante avec toute cette puissance de calcul.
Donc, à titre personnel, je pense que le modèle du noyau sera toujours valide — et que les changements se situeront à un niveau différent.
Après tout, nous avons eu quarante ans avec Unix, et toute l’approche du type « noyau monolithique en C » n’est pas devenue invalide au cours de ces quarante années. Oui, les détails ont changé, le langage a évolué, et nous avons des interfaces bien plus complexes. Mais la conception de base est encore tout à fait reconnaissable. Je ne pense pas que vingt ans de plus vont nécessairement changer tout ça.
LinuxFr : Eh bien, merci beaucoup Linus pour tes réponses aux questions… Et, bon anniversaire au noyau ! ;-)
Who would have thought these formal United States of America would be so far gone to now have a Super Congress of Twelve Elders and One Usurper making all the dictatorial decisions now.
END the WARS NOW!
BANK WRITE OFF NOW!
END THE FED!
ARREST THE TRAITORS NOW!
We live in a dangerous and exciting age. It is a time of both crisis and opportunity. Now is the time to shake off the yoke of disempowering fear and apathy and make a stand for what is right, what the framers of the US Constitution intended to be held as a light of freedom for all the world to follow.