Qu'est-ce qu'il y avait de mal à avoir un soft qui règle un et un seul problème, par rapport à un systemd tentaculaire qui va finir par devenir un OS à lui tout seul ?
Lennart le redit dans sa présentation : leur objectif est de fournir une solution pour démarrer un OS. Et pour faire ça bien, en fait on touche plein de choses.
Mais en réalité systemd c'est très modulaire. On pourrait se dire qu'on n'a pas besoin de networkd, nspawn, resolved... et c'est vrai, et ça tombe bien, ces composants sont optionnels.
Par exemple pour ton histoire de configuration réseau : aucune obligation d'utiliser NetworkManager si tu n'en veux pas, c'est normalement possible de faire comme avant.
Mais systemd, c'est aussi une standardisation, un ensemble plus cohérent et unifié. Ça change forcément l'existant, mais ça simplifie grandement la vie des gens flemmards comme moi. Tu installes un nouveau service, tu sais direct comment t'en servir, et notamment que tu peux avoir ses logs en lançant journalctl -fu service par exemple. grep, tail, tout ça, tu peux continuer à les utiliser en apprenant une commande : journalctl -u service; c'est pas la mort. En général il y a un flag pour faire ça mieux direct dans l'outil, mais c'est toujours possible.
Cette standardisation, ça demande effectivement un apprentissage initial, mais sur le long terme, c'est moins la pagaille, l'ensemble est plus facile à comprendre et au final c'est moins d'effort.
Après, c'est clair que si tu n'aimes pas la vision, ça va mal se passer pour toi. Je ne crois pas qu'il faut rester sur l'impression laissée par une mauvaise expérience de migration au début, et plutôt analyser ce qu'on a aujourd'hui, sinon c'est sûr que tu resteras bloqué sur ça mais ça ne parait pas méga constructif.
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par raphj (site web personnel) . En réponse au lien 14 ans de systemd. Évalué à 10. Dernière modification le 18 février 2025 à 17:39.
Lennart le redit dans sa présentation : leur objectif est de fournir une solution pour démarrer un OS. Et pour faire ça bien, en fait on touche plein de choses.
Mais en réalité systemd c'est très modulaire. On pourrait se dire qu'on n'a pas besoin de networkd, nspawn, resolved... et c'est vrai, et ça tombe bien, ces composants sont optionnels.
Par exemple pour ton histoire de configuration réseau : aucune obligation d'utiliser NetworkManager si tu n'en veux pas, c'est normalement possible de faire comme avant.
Mais systemd, c'est aussi une standardisation, un ensemble plus cohérent et unifié. Ça change forcément l'existant, mais ça simplifie grandement la vie des gens flemmards comme moi. Tu installes un nouveau service, tu sais direct comment t'en servir, et notamment que tu peux avoir ses logs en lançant
journalctl -fu servicepar exemple. grep, tail, tout ça, tu peux continuer à les utiliser en apprenant une commande :journalctl -u service; c'est pas la mort. En général il y a un flag pour faire ça mieux direct dans l'outil, mais c'est toujours possible.Cette standardisation, ça demande effectivement un apprentissage initial, mais sur le long terme, c'est moins la pagaille, l'ensemble est plus facile à comprendre et au final c'est moins d'effort.
Après, c'est clair que si tu n'aimes pas la vision, ça va mal se passer pour toi. Je ne crois pas qu'il faut rester sur l'impression laissée par une mauvaise expérience de migration au début, et plutôt analyser ce qu'on a aujourd'hui, sinon c'est sûr que tu resteras bloqué sur ça mais ça ne parait pas méga constructif.