Là, franchement, il est hyper complexe, il peut remplacer le
vénérable init mais aussi fstab,
mais supporte encore /etc/fstab.
crontab
mais supporte encore crontab comme avant. Rajouter l'execution periodique, ç'est quasiment logique (cf upstart et launchd). Entre lancer un soft sur un event (genre tel autre soft vient de se lancer) et lancer un soft sur un event temporel, y a pas grand chose de différent, donc y a du sens de faire les 2.
iptables
non. ce que systemd fait, c'est d'activer des regles de nat pour lancer des containers. C'est pas vraiment remplacer iptables, sauf si tu as une vision vachement réduite d'iptables.
su
pas vraiment. su va juste changer le userid, et parfois suivant les options, lancer ou pas l'initialisation. machinectl shell va te lancer une session, mais aussi dans un container. Le fait de lancer ça sans changer de namespace est juste une feature logique (vu que le namespace par defaut est juste un namespace comme un autre).
udev...
udev a été mergé par les devs upstreams, au cas ou tu as oublié.
En fait, je pense que si tu prends "le systeme d'init" comme "/bin/init", oui, tu va pas comprendre. Si tu prends en compte "/bin/init et /etc/rc.d" et les fichiers afférants, alors ça prends plus de sens. Genre /etc/rc.d/network, qui va gérer le réseau (comme networkd), /etc/rcS.d/S08mountall.sh va gérer le montage des partoches (d'ou le fait d'avoir un type mount, qui n'est que l'exposition du type interne de systemd pour les montages), et tout les sous morceaux de script qui font l'init.
Ou pour les distros RH-like, le gros bousin de /etc/rc.sysinit
avec des choix très discutables sur la gestion de l'UEFI
Alors, je suppose que tu parles des machines de MSI (https://github.com/systemd/systemd/issues/2402). Comme dit dans le rapport de bug, il y a des raisons de vouloir écrire dans efivars pour des programmes externes. Et on l'a vu avec les gens de tmux, quand on soumet des demandes pour adopter le comportement d'un soft à un changement de systemd, c'est non car c'est à systemd de rien changer, et quand systemd ne change pas pour ne pas casser les programmes, c'est "très discutables" et le comportement aurait du changer.
On pourrait presque croire qu'il y a aucun moyen de faire le bon choix.
ou plus récemment sur la survie des process après logout
(nohup ca veut dire ce que ca veut dire, il n'y a pas besoin
d'une option pour ca).
Le pourquoi du comment est pourtant expliqué dans les divers bug reports pour qui veut savoir ce qui est le souci derrière.
Et je vois pas en quoi nohup change grand chose. Ni même ce que ça veut dire en pratique, vu que ça ne s'applique que pour les programmes avec un concept de tty (vu que tout ce que ça fait, c'est d'ignorer le signal qui est envoyé quand tu perds ton port série, et par extension, ton terminal virtuel). Ça ne veux pas vraiment dire "lance ça en background", et par définition, ça n'a aucun sens sur un programme non lié à un tty (genre certains demons utilise SIGHUP pour autre chose que voir qu'il y a plus personne face à eux ).
S'il faut à tout prix remplacer l'init,
alors en fait, si tu regardes un peu l'histoire:
- gentoo a remplacé son init (openrc)
- ubuntu a remplacé son init (upstart)
- apple a remplacé son init (launchd)
- sun a remplacé son init (smf)
Fedora avait adopté upstart (et RHEL 6 en a hérité), Suse et Mandriva voulait faire de même. Et je pense que certains BSD ont aussi refait leur init (genre openbsd).
Donc ouais, depuis un bout de temps, les unix veulent changer leur init.
il y a d'autres
alternatives mais qui ont a priori le tort de ne faire que ce
qu'ils doivent faire (par exemple openrc souvent cité, mais
aussi runit qui est, lui, vraiment impressionnant de rapidité).
En fait non, le tort, c'est d'avoir intéressé personne.
Sur les tonnes de distros de distrowatch, y en a aucune dans le top 30 qui s'est dit depuis que runit existe "tiens, on va mettre ça".
Openrc, c'est pire. Dans le débat du TC de Debian, personne n'a poussé. Le packager qui s'en occupait était grosso modo tout seul alors que ça aurait collé sans doute mieux aux problématiques de debian. Et dans gentoo, personne n'a corrigé les bugs du au lancement de service en parallèle présent pendant 4 ou 5 ans. Et tout comme upstart, c'était bien dormant avant que systemd n'arrive.
Donc non, leur seul tort, c'est que ça n'a motivé personne. Et en général, si un truc motiv e personne, y a des chances que ça soit pas si bien que ça, que ça répondes pas aux problèmes des gens. Y a pas à
Donc non, je ne comprends pas ce mouvement de foule qui ne
jure que par systemd.
C'est pourtant pas faute d'avoir eu largement le temps de lire les discutions des 5 dernières années.
[^] # Re: LinuxFR est pro-Systemd
Posté par Misc (site web personnel) . En réponse à la dépêche Debian Jessie, 1 an plus tard. Évalué à 10.
mais supporte encore /etc/fstab.
mais supporte encore crontab comme avant. Rajouter l'execution periodique, ç'est quasiment logique (cf upstart et launchd). Entre lancer un soft sur un event (genre tel autre soft vient de se lancer) et lancer un soft sur un event temporel, y a pas grand chose de différent, donc y a du sens de faire les 2.
non. ce que systemd fait, c'est d'activer des regles de nat pour lancer des containers. C'est pas vraiment remplacer iptables, sauf si tu as une vision vachement réduite d'iptables.
pas vraiment. su va juste changer le userid, et parfois suivant les options, lancer ou pas l'initialisation. machinectl shell va te lancer une session, mais aussi dans un container. Le fait de lancer ça sans changer de namespace est juste une feature logique (vu que le namespace par defaut est juste un namespace comme un autre).
udev a été mergé par les devs upstreams, au cas ou tu as oublié.
En fait, je pense que si tu prends "le systeme d'init" comme "/bin/init", oui, tu va pas comprendre. Si tu prends en compte "/bin/init et /etc/rc.d" et les fichiers afférants, alors ça prends plus de sens. Genre /etc/rc.d/network, qui va gérer le réseau (comme networkd), /etc/rcS.d/S08mountall.sh va gérer le montage des partoches (d'ou le fait d'avoir un type mount, qui n'est que l'exposition du type interne de systemd pour les montages), et tout les sous morceaux de script qui font l'init.
Ou pour les distros RH-like, le gros bousin de /etc/rc.sysinit
Alors, je suppose que tu parles des machines de MSI (https://github.com/systemd/systemd/issues/2402). Comme dit dans le rapport de bug, il y a des raisons de vouloir écrire dans efivars pour des programmes externes. Et on l'a vu avec les gens de tmux, quand on soumet des demandes pour adopter le comportement d'un soft à un changement de systemd, c'est non car c'est à systemd de rien changer, et quand systemd ne change pas pour ne pas casser les programmes, c'est "très discutables" et le comportement aurait du changer.
On pourrait presque croire qu'il y a aucun moyen de faire le bon choix.
Le pourquoi du comment est pourtant expliqué dans les divers bug reports pour qui veut savoir ce qui est le souci derrière.
Et je vois pas en quoi nohup change grand chose. Ni même ce que ça veut dire en pratique, vu que ça ne s'applique que pour les programmes avec un concept de tty (vu que tout ce que ça fait, c'est d'ignorer le signal qui est envoyé quand tu perds ton port série, et par extension, ton terminal virtuel). Ça ne veux pas vraiment dire "lance ça en background", et par définition, ça n'a aucun sens sur un programme non lié à un tty (genre certains demons utilise SIGHUP pour autre chose que voir qu'il y a plus personne face à eux ).
alors en fait, si tu regardes un peu l'histoire:
- gentoo a remplacé son init (openrc)
- ubuntu a remplacé son init (upstart)
- apple a remplacé son init (launchd)
- sun a remplacé son init (smf)
Fedora avait adopté upstart (et RHEL 6 en a hérité), Suse et Mandriva voulait faire de même. Et je pense que certains BSD ont aussi refait leur init (genre openbsd).
Donc ouais, depuis un bout de temps, les unix veulent changer leur init.
En fait non, le tort, c'est d'avoir intéressé personne.
Sur les tonnes de distros de distrowatch, y en a aucune dans le top 30 qui s'est dit depuis que runit existe "tiens, on va mettre ça".
Openrc, c'est pire. Dans le débat du TC de Debian, personne n'a poussé. Le packager qui s'en occupait était grosso modo tout seul alors que ça aurait collé sans doute mieux aux problématiques de debian. Et dans gentoo, personne n'a corrigé les bugs du au lancement de service en parallèle présent pendant 4 ou 5 ans. Et tout comme upstart, c'était bien dormant avant que systemd n'arrive.
Donc non, leur seul tort, c'est que ça n'a motivé personne. Et en général, si un truc motiv e personne, y a des chances que ça soit pas si bien que ça, que ça répondes pas aux problèmes des gens. Y a pas à
C'est pourtant pas faute d'avoir eu largement le temps de lire les discutions des 5 dernières années.