Dans un article posté sur Chatinux, je parlais de la balkanisation que les distributions GNU/Linux allait subir avec la généralisation de la technologie SecureBoot et le support par les distributions. Je ne reviendrais pas sur la polémique, cette technologie est pour moi une mauvaise réponse à une bonne question.
Dans l’article en question, je disais :
Car outre les deux [Ubuntu et Fedora] qui ont déjà annoncé les moyens mis en oeuvre pour supporter le duo UEFI + Secure Boot, que vont faire les autres ? Que va faire Debian GNU/Linux ? Archlinux ? Frugalware ? Gentoo ? Slackware ? OpenSuSE ?
Va-t-on avoir un clan prenant en charge le SecureBoot, et un clan ne le prenant pas en charge ? Cela serait une bonne chose sur un seul point : cela réduirait de manière drastique le nombre de distributions existantes, au dépend des utilisateurs de distributions alternatives.
En avril 2012, l’équipe en charge de systemd a décidé d’intégrer le code d’udev. Pour les personnes qui ne savent ce qu’est udev, c’est : « un gestionnaire de périphériques remplaçant devfs sur les noyaux Linux de la série 2.6. Sa fonction principale est de gérer les périphériques dans le répertoire /dev. »
En gros, il permet de dire au noyau quels sont les périphériques installés pour les gérer par la suite. Et bien entendu, quand des personnes sont mécontentes d’une évolution, la logique est de faire un fork. Donc, udev a été forké.
Le problème est que de plus en plus de distributions passent à systemd. Pour ma propre expérience – autant parlé de ce qu’on vit – je n’ai pas le moindre ennui avec systemd 189 (sur mon Archlinux avec Gnome 3.4), ni avec mon portable sous Viperr 02 (donc une Fedora 17 et systemd 44).
Coté distribution qui utilise systemd, en dehors de la Fedora Linux, de Frugalware Linux, d’Archlinux (il est assez simple de passer en systemd complet), on peut rajouter la Manjaro Linux pour sa version 0.8.1 (prévue pour le 18 septembre), Chakra Linux (en cours de migration), OpenSuSE, Mageia, pour rester dans les grands noms.
Le problème qui se pose sera pour la prochaine génération de distribution. Ubuntu 12.10 est en phase de finition (la béta 1 est sorti il y a une grosse semaine), et les distributions qui se baseront sur elles, comme la Linux Mint 14 (??) utiliseront la version 175 d’udev qui date de novembre 2011.
Mais pour la 13.04 ? Que va faire Canonical ? Utiliser le fork d’udev ? Ce serait logique pour continuer à supporter upstart, sa version maison de gestionnaire de démarrage.
Au dela de l’utilisation ou non du fork d’udev se pose une question. Son interface maison Unity se repose sur les logiciels gnome. Or, dixit le mainteneur de Gnome pour Archlinux, Ionut Biru, dans un message d’août 2012 :
I wonder if we manage to do the switch before gnome 3.6 comes out. I’m sick and tired of supporting ck and seats and become harder to do so.
I plan to drop consolekit support from gnome and compile it with systemd full support.
Ce qu’on peut traduire par :
Je me demande si on peut gérer l’échange [entre les anciens scripts et systemd] avant que Gnome 3.6 sorte. Je suis fatigué de supporter ck [ConsoleKit] et seats car cela devient de plus en plus difficile.
Je compte laisser tomber le support de consolekit pour Gnome et le compiler avec le support compler de systemd.
Donc, cela veut dire que si Canonical veut continuer à utiliser une base gnome pour son interface Unity, il faudrait encore rajouter des patchs pour contourner le code fonctionnant (presque) uniquement avec systemd ? Voire même forker gnome pour l’adapter à ses besoins ?
Et que va faire gentoo ? Suivre le chemin de Canonical pour continuer à utiliser leur gestionnaire de démarrage, OpenRC ?
Et Debian GNU/Linux, sur laquelle Canonical récupère du code tous les 6 mois pour préparer une nouvelle version ?
Autant dire que l’intégration des deux outils va encore une fois de plus balkaniser le petit monde des distributions GNU/Linux qui n’en avait pas besoin.
Il y aura d’un coté les distributions avec le duo systemd et udev et de l’autre celle qui auront leurs gestionnaires de démarrage et la version forkée d’udev.
Ca va être un sacré merdier cette histoire pour le plus grand bonheur du duo / duel Microsoft – Apple.
Arch gere l’UEFI non? me semble avoir vu qqch à propos de ça dans leur guide d’installation …
UEFI ne veut pas dire forcément SecureBoot. Je me souviens d’avoir vu il y a environ un an et des bananes un portable non mac avec de l’UEFI au démarrage.
Super s’ils nous collent le duo, je voit déjà dans le magasin « y’a secure boot et UEFI? », les vendeurs vont vachement aider, et ca pue le truc bien caché dans la doc constructeur …
Je plains les vendeurs. Ma prochaine machine ? L’assembleur du coin 🙂
Il est clair que les distros non-systemd vont devoir se serrer les coudes ! Sauf qu’entre l’init SysV, à la BSD, Upstart, OpenRC, init-ng, Mùdur et Çomar… Va falloir faire du tri. Pardus à l’air de comater, init-ng n’est utilisé par personne pourtant ça a l’air intéressant, Upstart sera abandonné un jour ou l’autre par Canonical au profit de systemd je pense (à moins que comme avec Unity, ils veulent de l’exclusivité même si c’est pourri). Donc grosso merdo OpenRC je sais pas ce que ça vaut mais les scripts sont simples à faire, les init BSD ben c’est toujours mieux que SysV… init-ng existe depuis un moment donc je pense qu’on va commencer à l’utiliser maintenant, et le duo Mùdur/Çomar doit être difficile à porter ailleurs (comme les scripts Bash différents entre les distros).
systemd finira par s’imposer faute de concurrence sérieuse.
Pour info, voici à quoi ressemble le fichier service qui permet de gérer NetworkManager et qui se trouve dans le fichier /usr/lib/systemd/system/NetworkManager.service :
[Unit]
Description=Network Manager
After=syslog.target
Wants=network.target
Before=network.target
[Service]
Type=dbus
BusName=org.freedesktop.NetworkManager
ExecStart=/usr/sbin/NetworkManager –no-daemon
# Suppress stderr to eliminate duplicated messages in syslog. NM calls openlog()
# with LOG_PERROR when run in foreground. But systemd redirects stderr to
# syslog by default, which results in logging each message twice.
StandardError=null
[Install]
WantedBy=multi-user.target
Alias=dbus-org.freedesktop.NetworkManager.service
Je ne trouve pas cela si horriblement complexe.
L’activation : sudo systemctl enable NetworkManager.service
La désactivation : sudo systemctl disable NetworkManager.service
Pas plus compliqué de lancer / éteindre le service que de faire un sudo /etc/rc.d/networkmanager start ou sudo /etc/rc.d/networkmanager stop
Enfin, je suis personnellement convaincu que c’est un outil d’avenir. Ensuite, je peux me planter, mais seul l’avenir me le dira 😉
Quand je vois ce qui se passe chez Gnome je me conforte dans l’idée que Canonical a bien fait de partir sur sa propre interface pour que Ubuntu soit indépendant de tout cela. Systemd en est la preuve. Vu qu’ils sont habitués à patcher à tout va et à remplacer des composants, espérons que systemd ne leur posera pas de problème.
Bon personnellement j’ai rien contre systemd ça a l’air très utile et sur une distro desktop comme Fedora c’est totalement transparent. Mais en tant qu’amoureux de FreeBSD/NetBSD/OpenBSD je me méfie de ces technos « linux-only » surtout quand on voit par qui tout ceci est orchestré.
Ubuntu est en train de faire comme Apple, toute proportion gardée : sa petite sauce chez elle. Qu’elle vire systemd, elle n’en sera que plus isolée d’un nombre croissant de distribution.
udev est déjà forké, mais je ne donne pas long feu de la version forkée, tout comme certains développeurs d’Archlinux, l’article est très long, je cite le morceau sur l’utilisation du fork :
http://allanmcrae.com/2012/09/replacing-systemd-in-arch-linux/
« Lets start with choice number one. Where are you going to get udev from? I see two choices here. Firstly, you could just create a package containing on the udev files from the systemd tarball. This is the approach used by Linux From Scratch and you could even use their Makefile. The original email announcing the merge of udev into systemd states that udev can still be built for usage outside of systemd systems and that will be supported officially. So I personally would choose that option. However, I know people are concerned that udev will become more fully dependent on systemd. Here is the email that people cite as the end on non-systemd udev. I read that as saying that genuine issues when using udev outside of systemd will be fixed. There is also nothing saying that patches for udev that do not impact its usage in systemd will not be applied. Anyway, for those people there is a fork of udev being developed. If you select this option, there are a couple of things to be aware of. Firstly, there is is no guarantee of compatibility with the udev from systemd so the libudev. In fact, the fork has a different soname and that means you will need to recompile all software that links to it (~30 packages in the Arch repos). Secondly, the development of this fork currently appears to be porting relevant commits from the systemd tree to a snapshot of the udev codebase before the merge happened. It will be of interest to see what happens as these code-bases diverge and whether any independent development (excluding the build system…) occurs in the fork. »
30 paquets pour ne pas utiliser systemd, cool 😉
Je te conseille le reste de l’article, c’est très intéressant.
Oh, la belle attaque sur la personnalité. J’aime bien OpenBSD qui est pourtant dirigé par un sacré trou du cul. Comme quoi…