Les composants de systemd, à quelques exceptions près, peuvent se limiter au boot et
au lancement de services. Tu peux garder /etc/fstab, le /etc/network/interfaces ou
netplan ou networkmanager, ton client DHCP, un resolv.conf manuel, un /etc/hosts,
ton client ntp, syslog, cron, etc...
Sauf que dans la réalité la plupart des utilisateurs sont piégés par les choix faits par les mainteneurs de leurs distributions préférées.
Ex. Debian a remplacé rsyslog par journald. Certes on peut toujours installer rsyslog mais c'est une étape de plus, de la conf en plus et il faudra serrer les fesses à la prochaines mise à jour.
Et rien n'est plus déconcertant que de voir en commentaire en haut d'un fichier de conf aussi simple que /etc/resolv.conf ou autre, une ligne du style "ce fichier n'est plus géré directement par tel programme, veuillez d'abord vous fader la doc absconse de tel sous-composant à systemd qui vous renverra sur Internet alors que vous n'avez pas d'accès réseau et que vous êtes dans une situation d'urgence sur une machine de production". Je caricature à peine mais c'est du déjà vu.
Donc, oui systemd est modulaire, non, il n'est pas si simple d'outrepasser les choix faits par les mainteneurs et non ces choix ne sont pas toujours judicieux et surtout les utilisateurs n'y sont pas toujours préparés. Il n'y a qu'à voir la longueur de cette dépèche pour ce rendre compte du travail que devra représenter l'analyse du changelog ainsi que la formation des équipes avant une intégration en environnement de production.
À titre pro j'utilise beaucoup Debian et les dérivés de RedHat sans soucis mais pour rien au monde je n'en voudrais sur mes machines perso qui roulent Slackware sans sourciller depuis... bientôt 25 ans !
[^] # Re: osctl
Posté par Doug Le Tough (site web personnel) . En réponse à la dépêche Systemd v256. Évalué à 10. Dernière modification le 21 juin 2024 à 06:23.
Sauf que dans la réalité la plupart des utilisateurs sont piégés par les choix faits par les mainteneurs de leurs distributions préférées.
Ex. Debian a remplacé
rsyslogparjournald. Certes on peut toujours installerrsyslogmais c'est une étape de plus, de la conf en plus et il faudra serrer les fesses à la prochaines mise à jour.Et rien n'est plus déconcertant que de voir en commentaire en haut d'un fichier de conf aussi simple que
/etc/resolv.confou autre, une ligne du style "ce fichier n'est plus géré directement par tel programme, veuillez d'abord vous fader la doc absconse de tel sous-composant à systemd qui vous renverra sur Internet alors que vous n'avez pas d'accès réseau et que vous êtes dans une situation d'urgence sur une machine de production". Je caricature à peine mais c'est du déjà vu.Donc, oui
systemdest modulaire, non, il n'est pas si simple d'outrepasser les choix faits par les mainteneurs et non ces choix ne sont pas toujours judicieux et surtout les utilisateurs n'y sont pas toujours préparés. Il n'y a qu'à voir la longueur de cette dépèche pour ce rendre compte du travail que devra représenter l'analyse du changelog ainsi que la formation des équipes avant une intégration en environnement de production.À titre pro j'utilise beaucoup Debian et les dérivés de RedHat sans soucis mais pour rien au monde je n'en voudrais sur mes machines perso qui roulent Slackware sans sourciller depuis... bientôt 25 ans !