Pas trop envie de m'étendre sur mon opinion de systemd, ça n'apporterais rien. Je préfère apporter des solutions aux «problèmes» soulevés par cette personne, ça me semble plus constructif.
Je note personnellement que l'auteur du billet n'est pas aussi compétent qu'il veut le faire croire avec Debian.
1: le meta-paquet "init" dépends, au choix, de:
systemd-sysv aka systemd (oui, le nom est a chier, probablement un héritage du fait que lors de l'introduction ça dépendait de sysv-rc);
sysvinit-core aka sysvinit qui dépend de sysv-rc;
runit-init aka... bah, runit, ui dépend de sysv-rc pour une raison simple: il faut du temps pour implémenter un système d'init complet (de mémoire, dans Jessie systemd-sysv aussi en dépendait);
2: si la séparation de / et /usr lui est si chère, pourquoi ne pas conserver cette séparation?
Pour ce qui est du point 1, le seul truc que je peux regretter est l'absence de nosh dans la liste, j'aurait bien aimé qu'on me mâche le boulot avec celui-la, ça m'aurait permis de le découvrir in-situ.
Parmi ses avantages supposés (de mémoire):
possibilité de convertir les unit systemd en scripts nosh
un "DSL shell" (pour domain specific language shell, l'appellation est de moi)
correction du problème "thundering herd solution" qui est l'apanage des héritiers des daemon tools
mais faut que lise la doc, donc la flemme :)
Je reconnais que, pour ne pas avoir systemd installé par défaut (et donc devoir le désinstaller via apt après l'install) et/ou pour conserver la séparation de / et /usr il faut passer par une procédure plus complexe:
démarrer sur l'iso
ne pas sélectionner "install" mais "rescue"
Une fois dans le "rescue mode", il faut ensuite faire l'installation de la façon qui se fait sur d'autres distributions, qui ciblent des utilisateurs avancés (ça tombe bien, il semble en être un!): préparer le système cible, utiliser deboostrap avec les paramètres qui vont bien, configurer le système, configurer le bootloader.
Oui, c'est compliqué, mais plutôt que râler, il aurait été plus efficace de rappeler que c'est possible, j'ai émis plusieurs journaux sur ce genre de manipulations, donc en fouillant il devrais même ne pas avoir trop de boulot a faire pour construire son propre script.
Mais non, comme «tous» les «anti-systemd»(1) il préfère râler en ignorant (volontairement?) le fait que systemd est loin d'être obligatoire, surtout sur la distribution dont il parle qui propose quand même 2 alternatives pour ceux qui le veulent!
Et, vraiment? 1Go de RAM pour systemd?
Heureusement que ça n'est pas vrai, parce que sinon cette collection d'outils, qui nécessiterait sur mon système l'usage de 14.4Mio de disque, doit leak quelque chose de bien! Pas crédible.
Oui, systemd est plus gourmand en ressources.
C'est normal: il gère réellement les processus, il ne se contente pas de les lancer et faire comme si ça ne plante jamais!
D'ailleurs, c'est encore plus important sur un système embarqué qui va se retrouvé exposé a des conditions bien éloignée du labo. J'ai déjà vu un système freezer par le simple fait de recevoir un appel téléphonique trop près (bon, dans ce cas, c'était le hard qui partait en couilles, certes, il aurait fallu un watchdog hard, mais bon...)!
Par contre, je serais curieux de savoir la consommation mémoire (réelle) de systemd. Dans le cas de runit compilé avec glibc, j'ai:
Dans la plupart des instances de runsv, svlogd, runit et runsvdir, RSS chute a 4 dans le cas d'une compilation avec musl. Je ne sais pas pourquoi certaines instances de runsv montent a plus d'1Mo...
Si quelqu'un peut mesurer l'impact de systemd compilé avec glibc ou mieux, si possible, avec musl?
Bon, sur la plupart des machines, ces quelques megs de mémoire consommés ne sont pas gênant, mais je me dis que sur de l'embarqué très serré (genre, avec moins de 64Mo de RAM, comme certains routeurs ou autres) ça peut compter.
Perso, je vois surtout le fait que je serais capable de lire et maintenir le code de runit si besoin est, alors que ce n'est pas le cas pour systemd.
1: dont, techniquement, je fais partie puisque je n'utilise pas cet init. Cela dis, je préférerais utiliser systemd que revenir à sysvinit + rc.d, sans hésitation, surtout sur des machines sur lesquelles je n'ai pas la possibilité d'avoir un accès physique!
[^] # Re: le principe "KISS" est-il devenu obsolète?
Posté par freem . En réponse au lien Grandeur et décadence de Linux (et j'ajoute: sic transit Linux regnum). Évalué à 5.
Pas trop envie de m'étendre sur mon opinion de systemd, ça n'apporterais rien. Je préfère apporter des solutions aux «problèmes» soulevés par cette personne, ça me semble plus constructif.
Je note personnellement que l'auteur du billet n'est pas aussi compétent qu'il veut le faire croire avec Debian.
1: le meta-paquet "init" dépends, au choix, de:
2: si la séparation de / et /usr lui est si chère, pourquoi ne pas conserver cette séparation?
Pour ce qui est du point 1, le seul truc que je peux regretter est l'absence de nosh dans la liste, j'aurait bien aimé qu'on me mâche le boulot avec celui-la, ça m'aurait permis de le découvrir in-situ.
Parmi ses avantages supposés (de mémoire):
mais faut que lise la doc, donc la flemme :)
Je reconnais que, pour ne pas avoir systemd installé par défaut (et donc devoir le désinstaller via apt après l'install) et/ou pour conserver la séparation de
/et/usril faut passer par une procédure plus complexe:Une fois dans le "rescue mode", il faut ensuite faire l'installation de la façon qui se fait sur d'autres distributions, qui ciblent des utilisateurs avancés (ça tombe bien, il semble en être un!): préparer le système cible, utiliser
deboostrapavec les paramètres qui vont bien, configurer le système, configurer le bootloader.Oui, c'est compliqué, mais plutôt que râler, il aurait été plus efficace de rappeler que c'est possible, j'ai émis plusieurs journaux sur ce genre de manipulations, donc en fouillant il devrais même ne pas avoir trop de boulot a faire pour construire son propre script.
Mais non, comme «tous» les «anti-systemd»(1) il préfère râler en ignorant (volontairement?) le fait que systemd est loin d'être obligatoire, surtout sur la distribution dont il parle qui propose quand même 2 alternatives pour ceux qui le veulent!
Et, vraiment? 1Go de RAM pour systemd?
Heureusement que ça n'est pas vrai, parce que sinon cette collection d'outils, qui nécessiterait sur mon système l'usage de 14.4Mio de disque, doit leak quelque chose de bien! Pas crédible.
Oui, systemd est plus gourmand en ressources.
C'est normal: il gère réellement les processus, il ne se contente pas de les lancer et faire comme si ça ne plante jamais!
D'ailleurs, c'est encore plus important sur un système embarqué qui va se retrouvé exposé a des conditions bien éloignée du labo. J'ai déjà vu un système freezer par le simple fait de recevoir un appel téléphonique trop près (bon, dans ce cas, c'était le hard qui partait en couilles, certes, il aurait fallu un watchdog hard, mais bon...)!
Par contre, je serais curieux de savoir la consommation mémoire (réelle) de systemd. Dans le cas de runit compilé avec glibc, j'ai:
Dans la plupart des instances de runsv, svlogd, runit et runsvdir, RSS chute a 4 dans le cas d'une compilation avec musl. Je ne sais pas pourquoi certaines instances de runsv montent a plus d'1Mo...
Si quelqu'un peut mesurer l'impact de systemd compilé avec glibc ou mieux, si possible, avec musl?
Bon, sur la plupart des machines, ces quelques megs de mémoire consommés ne sont pas gênant, mais je me dis que sur de l'embarqué très serré (genre, avec moins de 64Mo de RAM, comme certains routeurs ou autres) ça peut compter.
Perso, je vois surtout le fait que je serais capable de lire et maintenir le code de runit si besoin est, alors que ce n'est pas le cas pour systemd.
1: dont, techniquement, je fais partie puisque je n'utilise pas cet init. Cela dis, je préférerais utiliser systemd que revenir à sysvinit + rc.d, sans hésitation, surtout sur des machines sur lesquelles je n'ai pas la possibilité d'avoir un accès physique!