Lennart Poettering est un développeur Red Hat/Fedora connu pour être remarquablement prolifique. Après Avahi et Pulseaudio c'est maintenant le démon d'init systemd qui l'occupe depuis plusieurs mois et qui a fait une entrée tonitruante dans le monde du libre.

Lennart ne déguise pas sa pensée et il ne craint pas de choquer en dévoilant ses opinions. Il est d'avis que seuls les systèmes basés sur Linux peuvent vraiment concurrencer les OS propriétaires et, en conséquence, ses choix techniques ne tiennent pas compte des autres systèmes libres.

Son franc-parler a parfois provoqué des batailles homériques sur les listes de discussion des différents projets et les gens du GCU-Squad sont à deux doigts de lancer un tueur à gages à ses trousses.

Pour toutes ces raisons, il est sans doute bon de faire le point avec lui et de l'interroger calmement sur ses projets et sur sa vision du libre.

LinuxFr a donc effectué un entretien avec Lennart, dont vous trouverez une traduction en seconde partie de la dépêche.

Encore une fois les anglophones sont incités à lire la version originale de l'entretien qui est postée en commentaire de la dépêche.

NdM : Ceci est la traduction française de l'entretien, voir le premier commentaire pour la version en langue anglaise.

LinuxFr.org : D'abord Avahi, ensuite Pulseaudio et maintenant systemd. Tu sembles être très polyvalent non ? Comment est-il possible de contribuer ainsi dans des champs aussi éloignés les uns des autres ?

Lennart : Et bien, en réalité, ces champs sont plus liés que ce que les gens pensent. Par exemple j'ai fini par écrire Avahi quand j'étais à la recherche d'un bon moyen de découvrir les périphériques audio sur le réseau, lors de l'écriture de Pulseaudio. J'ai appris de tas de trucs sur mDNS/DNS-SD (c'est-à-dire le protocole de découverte via le réseau qu'Avahi implémente) et à cette époque l'implémentation appellée Howl était la plus utilisée des piles mDNS/DNS-SD, donc je me suis penché dessus pour voir si il était possible d'ajouter sa prise en charge dans Pulseaudio.

Cependant je me suis vite rendu compte de ses défauts techniques et de ses problèmes de licence. Après avoir lu les RFC sur mDNS/DNS-SD, j'ai décidé que c'était assez simple pour que je me lance dans une ré-implémentation propre en quelques jours (cela n'a pas été si simple que ça, mais c'est une autre histoire...).

Quand je travaillais sur Avahi, j'ai appris pas mal de choses sur la complexité de faire tourner de manière sûre et pérenne des services système et sur comment les sécuriser du mieux possible, ce qui est très important pour les services réseau comme Avahi. J'ai implémenté beaucoup de petites fonctionnalités intéressantes dans ce domaine avec Avahi. Par exemple, Avahi est encore quasiment le seul démon dans une installation traditionnelle de Linux qui se chroot(e) lui-même par défaut. Bon, c'est vrai qu'il y a aussi le démon Realtimekit... mais c'est également moi l'auteur.

Avahi a aussi été l'un des premiers démons qui diminuait ses capacités par défaut.

À l'époque j'ai commencé à réfléchir sur le fait qu'un système d'init devrait vraiment s'occuper de toutes ces choses de façon à ce que les complexités d'implémentation disparaissent. Et oui, j'ai toujours continué à penser à ce truc, et finalement Kay et moi nous avons décidé que nous en avions vraiment besoin. Et nous l'avons fait.

LinuxFr.org : Durant les premiers mois de Pulseaudio il y a eu beaucoup de critiques. Est-ce que tu penses que ces critiques étaient justifiées parce que PA était encore immature ou bien est-ce que tu penses que ces critiques étaient irrationnelles ou malvenues ?

Lennart : Je peux comprendre pourquoi les gens étaient en colère, mais franchement nous n'avions pas vraiment d'autre option que de le pousser dans les distributions quand nous l'avons fait.

Certes Pulseaudio n'était pas un logiciel sans bug quand les distributions l'ont intégré, mais en réalité la plupart des problèmes n'étaient pas dans Pulseaudio mais simplement dans les pilotes audio.

L'ordonnancement de Pulseaudio se fait via des compteurs de temps (timer-based scheduling) et cela nécessite des informations au timing correct venant du pilote. À l'époque, les pilotes ne nous fournissaient pas les bonnes informations. Ce n'est pas qu'ils étaient pourris, c'est plutôt le matériel qui l'était, et les pilotes n'avaient pas encore tous les bons contournements et toutes les corrections pour compenser ça.

On ne devrait jamais oublier qu'il y a, dans toute l'industrie, environ 3,5 personnes qui sont payés à plein temps pour faire la maintenance générique de la pile audio de Linux (ce que je considère être ALSA et Pulseaudio et quelques trucs autour).

Avec aussi peu de ressources, je peux seulement dire que ce qui a été obtenu est vraiment bon. Certes nous ne pouvons pas encore égaler complètement les piles audio concurrentes comme CoreAudio mais nous sommes bien plus proches que nous ne l'avons jamais été.

J'espère que les gens qui se plaignent constamment seront un peu plus reconnaissants quand ils comprendront ça.

Mais tous ces problèmes c'est du passé. De nos jours les vendeurs de matériel comprennent que quand Pulseaudio ne marche pas correctement avec leurs produits c'est sans doute de leur faute, pas celle de Pulseaudio. D'une certaine façon Pulseaudio est devenu un test standardisé que les vendeurs de matériel utilisent pour évaluer leurs pilotes.

Bien entendu, en particulier avec du matériel très récent, vous pouvez continuer d'avoir des problèmes. Mais c'est simplement dû au fait qu'en dépit des spécifications standard des cartes sons HDA ou USB, les designers trouvent toujours des manières nouvelles et créatives de les implémenter de façon pourrie et incorrecte.

Et puis quelle autre option est-ce que nous aurions eu ? C'est très naïf de croire que, si nous avions attendu plus longtemps avant de pousser Pulseaudio vers les distributions, les choses auraient été différentes : vous ne pouvez pas corriger les bugs que vous ne connaissez pas, et les incitations et les ressources humaines sont trop faibles pour avoir des corrections avant qu'il y ait la pression inhérente à un logiciel déjà intégré dans une distribution.

Enfin la pile CoreAudio de MacOS a, elle aussi, nécessité quelques itérations avant d'arriver à maturité. Maintenant CoreAudio est d'une grande qualité et c'est l'étalon des piles audio, mais vous pourrez trouver des tas de personnes qui vous diront comment c'était vraiment au moment de son introduction. Et ce ne sont pas des histoires pleines d'amour.

D'ailleurs, même maintenant, ce n'est toujours pas licornes et arcs-en-ciel. La dernière fois que j'ai essayé de combiner une carte USB avec la carte audio interne sur MacOS, le noyau n'a pas beaucoup aimé ça.

Une pile audio qui fait du timer-based scheduling est nécessairement complexe et c'est difficile d'arriver au bout. Je suis certain que la plupart des gens s'en rendront compte quand ils essaieront d'en implémenter une et de bien la stabiliser.

LinuxFr.org : Si tu compares la situation dans le domaine de l'audio entre MacOSX, Windows et Linux, penses-tu que nous sommes au niveau des systèmes propriétaires ?

Lennart : Que ce soit Windows ou MacOS, ils ont des piles audio bien mieux intégrées que ce qui est disponible chez nous. Nous avons quelques fonctions qu'ils n'ont pas, comme la prise en charge du réseau, des latences plus faibles ou encore des pipelines audio sans flottants, mais en général la pile CoreAudio est vraiment plus avancée que la nôtre. Cependant, l'écart est bien plus réduit que ce qu'il était avant.

La pile audio Windows est bien moins adéquate en tant qu'étalon, et nous nous comparons à elle bien plus facilement que pour CoreAudio. Mais il ne fait pas de doute que le développement audio sous Windows reste mieux intégré.

LinuxFr.org : Quels sont les avantages d'ALSA/PA par rapport à OSSv4 ? À ton avis pourquoi est-ce que les BSD continuent d'utiliser OSS au lieu de réimplémenter ALSA/PA ?

Lennart : OSS est une pile audio simpliste dans le style des années 90. Elle n'a pas vraiment la moindre pertinence pour faire face aux besoins d'un bureau moderne. Mais c'est OK, les BSD ne se concentrent pas sur le bureau, et pour un serveur vous n'avez pas besoin de la moindre pile audio.

Et puis, et c'est un point clé : l'une des raisons pour laquelle les BSD et Solaris sont coincés avec OSS, c'est qu'ils n'ont pas vraiment d'autre option.

Le modèle utilisé par OSS est trop simple et il n'expose pas correctement les fonctions du matériel audio moderne. On ne peut pas implémenter une logique de type timer-based scheduling (ce qui est obligatoire pour gérer correctement plus d'un client ayant différentes contraintes de latence et tout cela en minimisant la consommation). Et puis faire le mixage et l'échantillonnage directement dans le noyau est assez discutable. L'interface de mixage est simpliste et elle n'est pas utilisable pour les périphériques modernes.

Ces périphériques audio ont changé ; maintenant vous avez de l'audio via Bluetooth, via UPnP, par port USB et d'autres technologies audio complexes. Le modèle d'OSS est presque entièrement conçu pour des cartes comme la série classique des SoundBlaster. Avoir un tel modèle comme interface avec les périphériques audio n'est plus vraiment possible si vous êtes intéressés par des technologies plus modernes.

LinuxFr.org : OpenBSD utilise le serveur de son aucat. Est-ce que tu le connais ? Qu'est-ce que tu en penses ? Plus généralement est-ce que tu es intéressé par les autres systèmes pour découvrir de nouvelles idées ?

Lennart : Une pile audio qui n'est pas capable de faire du timer-based scheduling et donc du contrôle dynamique de la latence n'est pas utile pour les périphériques grand-public. D'après ce que je sais, Pulseaudio est la seule implémentation libre de ce design qui, à l'origine, a été rendu populaire par CoreAudio. En outre, l'architecture zéro-copie de Pulseaudio (qui permet d'échanger directement en mémoire les références aux données audio plutôt que les données elle-même entre la pile et les applications) est aussi inégalée.

L'ironie, c'est que les piles audio pour les applications professionnelles peuvent généralement être implémentées beaucoup plus simplement que celles pour l'audio grand-public et pour les périphériques mobiles. Dans le monde de l'audio pro, la consommation est sans importance et la latence est le seul paramètre. De ce fait, le contrôle de la latence devient très simple (on veut juste qu'elle soit aussi réduite que possible) et les technologies comme le zéro-copie ne sont pas pertinentes (puisque les blocs audio deviennent aussi petits que les références qui les décrivent). Donc arriver à obtenir une pile PCM audio utile pour le grand-public est bien plus dur que pour le marché PCM pro. Toute pile audio qui n’implémente pas le timer-based scheduling et le design zéro-copie n'est pas pertinente sur ce marché des périphériques grand-public. C'est pour cette même raison que Jack et Pulseaudio ne sont pas vraiment en compétition.

Toutes les piles audio libres que j'ai vu jusqu'à présent (à l'exception d'ALSA/PA) n'ont pas du tout de timer-based scheduling et de zéro-copie. Tant que ce sera le cas, vous comparerez toujours des pommes et des oranges quand vous vous demanderez quelle est la meilleure entre la pile audio OpenBSD ou PulseAudio.

LinuxFr.org : À l'exception d'Ubuntu il semble que systemd va être le futur système d'init pour la plupart des grandes distributions. Est-ce que tu t'attendais à ce succès rapide ?

Lennart : Nous avons rapidement su que nous avions créé quelque chose de vraiment bon, mais cela a été bien plus facile de le faire accepter que nous ne l'anticipions. Il a fallu un an depuis l'annonce initiale jusqu'à la sortie dans Fedora 15, et pour autant que je le sache ça marche bien.

Cela a été comme de courir le long d'un grand corridor et de donner des coups de pieds dans des portes ouvertes.

Je suis assez sûr que nous finirons par intégrer Ubuntu également. Déjà Upstart ne peut pas vraiment suivre le rythme de systemd et je pense que Canonical va s'en apercevoir un jour ou l'autre. Depuis que Scott n'est plus le mainteneur d'Upstart le projet a perdu son visionnaire, donc je pense qu'ils vont finir par s'apercevoir que le projet ne va nulle part. Au fur et à mesure, l'écart va s'agrandir et ils vont finir par laisser tomber.

Mais bon c'est juste mon estimation et je ne travaille pas pour Canonical, donc je ne sais pas vraiment et seul le temps nous en dira plus. Peut-être que tout ça n'est qu'un vœu pieu de ma part...

LinuxFr.org : En plus de ton travail de codage tu as été capable de faire la promotion de systemd avec des posts très détaillés sur ton blog. Est-ce que tu penses que cela fait partie de ton travail de remplir ces tâches de « communication » ?

Lennart : Oui. Nous sommes supposés bloguer au sujet de notre travail. C'est l'un des bons côtés de travailler pour Red Hat: ils vous encouragent à être ouvert et à bloguer à propos de la technologie sur laquelle vous bossez.

LinuxFr.org : Quels sont les avantages techniques de systemd par rapport à Upstart ? Est-ce que tu penses que Canonical va finir par changer de système d'init ?

Lennart : Il y a tellement d'avantages à utiliser systemd par rapport à Upstart ! Je pense que ce post déjà ancien sur mon blog résume tout.

Et oui, je pense que Canonical va finir par adopter systemd, voir ma réponse au-dessus. Mais je ne peux que spéculer.

LinuxFr.org : Est-ce que tu peux expliquer un peu ta phrase : « systemd est le premier système d'init pour Linux qui vous permet de tuer proprement un service » ?

Lennart : Un service comme Apache peut avoir un certain nombre de sous-processus en cours d'exécution, comme des scripts CGI par exemple. Ces derniers peuvent avoir été écrits par des tiers et sont donc très peu contrôlés. Cela leur donne la possibilité de se détacher presque complètement du service Apache principal, et ce cas se rencontre vraiment dans la réalité.

Avec systemd cela n'est plus possible et les processus ne peuvent plus s'échapper ainsi. Cela nous permet, pour la toute première fois, de tuer complètement un service et tous ses processus d'aide de façon à ce que nous soyons certains qu'aucun script CGI ne s'est échappé.

Pour les détails voir cette entrée de blog.

C'est assez ironique de constater que le fait de tuer un service apparait comme une tâche simple alors qu'en réalité c'est assez difficile de faire ça bien. C'est seulement maintenant que nous sommes en mesure de corriger ça proprement. On aurait pu espérer que ce problème soit corrigé bien plus tôt sous Linux.

LinuxFr.org : J'ai entendu dire que tu projetais d'utiliser systemd afin d'étendre ou de remplacer les gestionnaires de sessions des bureaux. Est-ce que tu peux détailler un peu ? Quels sont les atouts de systemd pour cette tâche ?

Lennart : Le travail qui consiste à lancer un certain nombre de services de façon rapide et fiable n'est pas l'apanage du boot système. À peu près la même chose doit s'effectuer quand l'utilisateur se logue et que les services utilisateurs sont lancés. La technologie qu'offre systemd pour accélérer le boot est également utile pour accélérer le lancement de la session et donc nous voulons aussi rendre systemd utile pour cette tâche.

Ce n'est d'ailleurs pas une idée complètement nouvelle. Par exemple sous MacOS le démon launchd est utilisé de manière identique pour lancer le boot du système et la session utilisateur.

Ceci étant dit, nous en profiterons également pour corriger d'autre trucs. Par exemple nous voulons être certains que l'ordonnancement des services système dans des cgroups se fera de la même façon pour les services utilisateurs. Nous voulons aussi corriger une bonne fois pour toutes le support multi-sièges.

Pour de plus amples détails voir ce document google doc.

LinuxFr.org : Dans un entretien au FOSDEM tu as dit : « 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 ». Comprends-tu le vacarme que cette déclaration a provoqué chez les développeurs BSD quand ils ont lu ça ?

Lennart : Oui je le comprends parfaitement. Ce n'est pas particulièrement surprenant qu'ils n'aiment pas ce genre de recommandation n'est-ce pas ?

LinuxFr.org : systemd utilise des tas de technologies qui n'existent que dans Linux (cgroups, udev, fanotify, timerfd, signalfd, etc). Est-ce que tu penses vraiment que l'API Linux joue maintenant le rôle de l'API POSIX et que les autres systèmes ne comptent pas ?

Lennart : Oui, je ne pense pas que les BSD soient encore vraiment pertinents. Et je pense que l'obligation implicite de compatibilité avec ces systèmes, quand quelqu'un code un logiciel pour un bureau libre ou pour l'écosystème du Libre, est une charge qui nous tire en arrière pour très peu de bénéfices.

Je suis certain que ces systèmes ne sont pas inutiles pour tout le monde, après tout il y a bien des gens qui codent dessus. C'est juste que je ne pense pas qu'il soit vraiment dans notre intérêt de les laisser nous ralentir si nous voulons être sûrs que Linux puisse pénétrer le marché dans tous les secteurs (et pas seulement sur les serveurs ou les mobiles, et pas de façon restreinte comme pour Android).

Ces systèmes sont non pertinents pour le but qui est de mettre du logiciel libre entre les mains de tout le monde, et je pense que cela devrait être notre but.

Mais bon, c'est juste mon opinion. Je suis certain que les gens font du logiciel libre pour pleins de raisons. J'ai les miennes et les autres ont les leurs.

LinuxFr.org : Peut-être que Debian ne va pas pouvoir basculer vers systemd du fait de la nécessité de supporter le système alternatif Debian GNU/kFreeBSD. Que penses-tu de cette situation ?

Lennart : Et bien, ce sont eux qui vont y perdre je suppose.

Debian kFreeBSD est juste un joujou et les gens ne doivent pas s'y tromper. C'est bien si les gens font des OS joujoux, tout le monde aime les joujoux après tout. Mais si le projet Debian pense qu'il doit limiter ses développements à cause des rêves d'OS joujou de certains de ses développeurs, alors c'est son problème. Si Debian était mon projet, j'essaierais de me concentrer sur le fait de le rendre (ou de le maintenir) professionnellement pertinent, et je laisserais tomber kFreeBSD. Mais je ne suis pas un développeur Debian.

Ceci dit, je ne vois pas pourquoi il serait impossible de fournir un système init BSD pour kFreeBSD et systemd pour la version Linux de Debian. Un paquet qui fournit à la fois un init systemd et script SysV constitue une solution acceptable et systemd gérera ça très bien.

Je pense que le fait d'invoquer le support kFreeBSD pour bloquer l'adoption de systemd dans Debian ne reflète pas la vérité.

LinuxFr.org : Après avoir lu certains de tes posts sur LWN et ailleurs, j'ai vu que tu ne craignais pas les débats passionnés et les flamewars. Est-ce que tu apprécies ça en tant que folklore du libre ou bien est-ce que ça t'ennuie ?

Lennart : Pas vraiment non. Être capable de gérer les gens empoisonnants fait partie du job si on veut pousser des gros changements dans le monde du logiciel libre. Et en réalité, je doute d'être très bon dans ce domaine, je ferais mieux d'arrêter de répondre bien plus rapidement dans toutes ces flamewars.

Très probablement, ce que nous devrions faire en cas de conversation qui tourne en flamewar, c'est simplement de dire « Il faut reconnaitre que nous sommes en désaccord » et ensuite de nous taire.

LinuxFr.org : À ton avis pourquoi est-ce que Linux n'a pas percé sur le bureau des utilisateurs ? Linus Torvalds semble penser qu'il s'agit d'un problème social et pas technique. Es-tu d'accord avec lui ?

Lennart : Je pense que nous n'avons pas été assez innovants dans le domaine de l'interface, et que nous n'avons pas eu un message convaincant et une plate-forme claire. Si on accepte MacOS en tant qu'étalon de référence pour les interfaces utilisateurs, alors nous ne l'égalons pas, au mieux nous le copions.

Je pense que c'est en train de changer maintenant, avec GNOME 3 qui est un grand pas en avant en tant qu'interface pour Linux et qui, pour la première fois, a été conçu strictement en suivant des directives pour les interfaces utilisateur.

Donc maintenant, nous avons une meilleure interface, ce qui nous laisse le message et la plate-forme.

Linux reste trop fragmenté et les développeurs qui veulent coder pour Linux vont devoir choisir entre un grand nombres d'API, un bazar de trucs qui fonctionnent parfois ensemble mais qui sont la plupart du temps seulement des choix chaotiques qui marcheront sur certains systèmes et pas sur d'autres. Je pense que ce serait dans notre intérêt de rationaliser complètement la plate-forme et donc d'avoir un message clair sur ce qu'est Linux. Et, bien entendu, je crois que mon travail de nettoyage des couches basses de notre plate-forme utilisateur est une avancée dans cette direction.

Avoir un message clair sur ce que Linux est supposé être est complètement un problème social, mais pour que tout fonctionne bien il faut d'abord revoir techniquement notre plate-forme. Et ça, c'est une tâche technique qui n'est pas encore terminée.

LinuxFr.org : Après tous ces projets, es-tu fier d'avoir changé le paysage des bureaux libres ? Était-ce ta motivation dès le début ?

Lennart : Bien sûr que je suis fier ;-)

En fait j'aime tout simplement hacker et je trouve que les logiciels fermés sont impraticables, donc j'espère jouer un petit rôle dans la création d'un OS libre compétitif qui peut rivaliser avec les autres dans tous les domaines et pas seulement dans quelques-uns.

Et je suis certain que nous allons y arriver.

LinuxFr.org : Merci beaucoup pour tes réponses à mes questions et bonne chance pour systemd.

Aller plus loin