Attention, systemd aujourd'hui ne me fait pas peur du tout. Il est 100% compatible avec l'existant. Les scripts sont réécris distrib par distrib, il n'est pas nécessaire au fonctionnement de la machine ou des applis et il est finalement assez discret.
Mais j'insiste sur le "aujourd'hui". Je ne veux pas faire un procès d'intention mais j'ai vu ce qui est arrivé à DBus ou à HAL, et honnêtement l'avenir de systemd me panique. Même pour un truc aussi idiot que pulse-audio on est déjà au point ou ca devient très compliqué de s'en passer sous Linux. GStreamer est devenu indispensable et DBus est un must absolu.
Lennart Poettering a de grands projets pour son produit, il veut remplacer rien de moins que l'init, le cron, pas mal de scripts utilisateurs génériques (startx par exemple) et la supervision de tout ce petit monde.
Et si systemd devient très présent, les gens voudront s'en servir. Et comme tu le dis, sur un serveur j'aime bien avoir les services qui se lancent un par un, dans l'ordre que j'ai choisi avec des dépendances que ej rajoute à la mano.
Et si un autre admin système passe derrière moi il a de relativement bonnes chances de pouvoir modifier un script d'init pour qu'il fasse ce qu'il veut.
Maintenant systemd peut lancer n'importe quoi, n'importe quand et depuis n'importe ou. Le but avoué de systemd est de pouvoir interragir complètement avec l'ensemble de l'espace utilisateur. Et là oui j'ai peur. J'ai peur de conditions de courses incompréhensibles, j'ai peur d'évènement DBus imbittables qui entrainnent des effets de bords incompréhensibles à moins de passer trois jours à debugguer. J'ai peur de scripts fait à la mimine par un autre (ou oublié) et qui explosent à la suite d'un deprecated quelconque.
En ce qui concerne la simplicité de systemd, pour rester en place au fur et à mesure que les scripts seront traduit il va falloir rigidifier l'arborescence de fichiers. Pas question de fouiller l'ensemble des répertoires à la recherche de la bonne lib, ou de passer des dizaines #ifdef dans les scripts. Lennart l'a dit : ca sera le même régime pour tout le monde. En fait c'est même un des buts premiers de systemd.
Enfin bon mon opinion personelle est la suivante : on va se retrouver avec deux linux très différents : un utilisant systemd à fond, y compris dans le code de certains de ses services, et un autre qui rejette systemd, ou tout du moins le cantone à des rôles très précis. Et ca va pas être beau à regarder.
[^] # Re: SystemD
Posté par phxonx . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 10.
Attention, systemd aujourd'hui ne me fait pas peur du tout. Il est 100% compatible avec l'existant. Les scripts sont réécris distrib par distrib, il n'est pas nécessaire au fonctionnement de la machine ou des applis et il est finalement assez discret.
Mais j'insiste sur le "aujourd'hui". Je ne veux pas faire un procès d'intention mais j'ai vu ce qui est arrivé à DBus ou à HAL, et honnêtement l'avenir de systemd me panique. Même pour un truc aussi idiot que pulse-audio on est déjà au point ou ca devient très compliqué de s'en passer sous Linux. GStreamer est devenu indispensable et DBus est un must absolu.
Lennart Poettering a de grands projets pour son produit, il veut remplacer rien de moins que l'init, le cron, pas mal de scripts utilisateurs génériques (startx par exemple) et la supervision de tout ce petit monde.
Et si systemd devient très présent, les gens voudront s'en servir. Et comme tu le dis, sur un serveur j'aime bien avoir les services qui se lancent un par un, dans l'ordre que j'ai choisi avec des dépendances que ej rajoute à la mano.
Et si un autre admin système passe derrière moi il a de relativement bonnes chances de pouvoir modifier un script d'init pour qu'il fasse ce qu'il veut.
Maintenant systemd peut lancer n'importe quoi, n'importe quand et depuis n'importe ou. Le but avoué de systemd est de pouvoir interragir complètement avec l'ensemble de l'espace utilisateur. Et là oui j'ai peur. J'ai peur de conditions de courses incompréhensibles, j'ai peur d'évènement DBus imbittables qui entrainnent des effets de bords incompréhensibles à moins de passer trois jours à debugguer. J'ai peur de scripts fait à la mimine par un autre (ou oublié) et qui explosent à la suite d'un deprecated quelconque.
En ce qui concerne la simplicité de systemd, pour rester en place au fur et à mesure que les scripts seront traduit il va falloir rigidifier l'arborescence de fichiers. Pas question de fouiller l'ensemble des répertoires à la recherche de la bonne lib, ou de passer des dizaines #ifdef dans les scripts. Lennart l'a dit : ca sera le même régime pour tout le monde. En fait c'est même un des buts premiers de systemd.
Enfin bon mon opinion personelle est la suivante : on va se retrouver avec deux linux très différents : un utilisant systemd à fond, y compris dans le code de certains de ses services, et un autre qui rejette systemd, ou tout du moins le cantone à des rôles très précis. Et ca va pas être beau à regarder.