• [^] # Re: Moins de liberté, pour plus de sécurité

    Posté par . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 10.

    à quel moment systemd va lui donner plus de boulot qu'avant ?

    Exemple:

    You need the userspace code to set up the bus and its policy and handle
    activation. That's not a trivial task. For us, that's what sytemd does
    in PID 1. You'd need to come up with an alternative for that.

    Lennart Poettering

    Note aux altercomprenants qui sévissent dans le coin. Je ne dis pas (je précise : je ne sous-entend même pas) que les devs systemd sont obligés de faire ce qu’on dit parce qu’ils sont nos esclaves (oui, aussi bizarre que ça puisse paraître, il faut préciser ça si on veut pas se faire traiter d’esclavagiste). Tout ce que je dis, c’est que l’assertion « le mouvement dans l’écosystème Linux initié par systemd impose plus de boulot aux développeurs de solutions alternatives » est un fait admis par Lennart lui-même, ce n’est pas une lubie des anti-systemd. D’ailleurs, ceux qui ont un peu de mémoire se souviendront que ça a même été un argument utilisé par Lennart lors du débat systemd/upstart chez Debian : avec tous les changements à venir (chamboulement des cgroups, intégration kdbus/wayland, changements udev...), upstart va avoir beaucoup de difficultés à tenir le rythme :

    Anyway, summary is: I wish them good luck, they are now going their own way, stuck in a legacy stack with little new engineering, becoming an island of their own. In the short time frame they might save money with this decision, in the long run this is going to be quite expensive for them, since as our stacks start to diverge more and more adopting systemd later on will get more and more expensive.

    Autrement dit : dans le futur, les alternatives à systemd seront forcées de suivre le rythme d’évolution imposé par systemd, et ce sera quelque chose loin d’être trivial.