Je trouve dommage que tout le paysage des distributions Linux se tourne vers systemd.
T'as eu la même réaction quand SysV s'est imposé ?
Peut-être que systemd s'impose car il est bien meilleur que SysV. Par exemple, plus besoin de maintenir des scripts : on prend l'unit file upstream et c'est plié.
Il reste peu, aujourd'hui, de distributions qui ne l'utilise pas (ou pour lesquels ce n'est pas prévu). On perd de la diversité et du choix.
De la diversité pour un système d'init. Comment dire... Tout ce que je demande à un système d'init (en gros), c'est que la machine boot sans problème. Au delà, qu'il soit SysV ou systemd importe peu.
Et puis là c'est pas de la diversité : c'est revenir sur SysV. Si au moins c'était un init nouveau, là il y aurait une vraie diversité.
Et que penses-tu de Mir alors ? Tu crois que c'est une chance d'avoir autre chose que Wayland pour le futur des serveurs d'affichage ? Deux APIs, deux serveurs d'affichages concurrents, deux fois plus de bugs potentiels : youpi... ;-)
Je pense qu'au contraire qu'avoir systemd partout permet :
- d'avoir une seule API pour l'init
- de même pour l'usage des cgroups par l'user-space
- d'éviter d'écrire 1000 fois a peu près le même script d'init pour le service X (1 fois par distribution. Et encore, 1000, c'est loin du compte du nombre de distribs).
Dans les faits, cela devient pénible pour une distribution de faire sans systemd de nos jours.
Faut croire que c'est pas tellement le cas vu que Crux, Gentoo, Slackware, Ubuntu (jusqu'à la 14.04 au moins, qui a 5 ans de support), la dernière Debian stable (d'ailleurs systemd a été choisi pour d'autres raisons que sa "pénibilité" supposée : après tout les arguments autres que techniques n'avaient pas leur place dans la discussion) et d'autres font bien sans.
Et je ne vais pas revenir sur les problèmes que cela pose avec udev, etc.
Bah systemd est très dépendant d'udev, et puis bon le seul "problème" c'est de pouvoir compiler udev sans systemd.
Les forks c'est bien, sauf quand on s'appelle eudev et qu'on a pas parlé à l'upstream avant de forker udev en "eudev". C'est sûr que si on coopère pas, rien ne changera.
systemd, ses outils (dont udev) sont développés ensemble, et sont sur un VCS commun à la BSD. Mais ça ne plaît pas à BSDiste. Et ça ne plaît pas aux linuxiens. Faut croire que le problème, c'est peut-être pas systemd...
Pour l'etc, je ne vois pas... (je suis pas devin ;-) )
Sinon, j'ai techniquement pas mal de reproches envers systemd.
Dommage que ce soit toujours les même arguments répétés 1000 fois et réfutés 1000 fois. :/
Honnêtement, pour la plupart de tes griefs, je me suis renseigné 30 secondes pour savoir que c'était faux...
D'une part, il en fait beaucoup trop en tant que PID 1 (oui, je suis au courant pas tout n'est dans le PID 1, et heureusement d'ailleurs).
"Mon" /sbin/init (systemd) ne fait guère de plus que SysV, il me semble (non seulement d'après la page de man, mais en lançant /sbin/init --help on voit qu'on a pas grand chose de compliqué :
Starts up and maintains the system or user services.
-h --help Show this help
--test Determine startup sequence, dump it and exit
--dump-configuration-items Dump understood unit configuration items
--unit=UNIT Set default unit
--system Run a system instance, even if PID != 1
--user Run a user instance
--dump-core[=0|1] Dump core on crash
--crash-shell[=0|1] Run shell on crash
--confirm-spawn[=0|1] Ask for confirmation when spawning processes
--show-status[=0|1] Show status updates on the console during bootup
--log-target=TARGET Set log target (console, journal, syslog, kmsg, journal-or-kmsg, syslog-or-kmsg, null)
--log-level=LEVEL Set log level (debug, info, notice, warning, err, crit, alert, emerg)
--log-color[=0|1] Highlight important log messages
--log-location[=0|1] Include code location in log messages
--default-standard-output= Set default standard output for services
--default-standard-error= Set default standard error output for services
Ou du moins, il n'y a rien de surprenant.
D'ailleurs, quand j'interagis (rarement, d'ailleurs) avec systemd, j'utilise en fait /usr/bin/systemctl
Cela a plusieurs conséquences: une étant que, en étant complexe il y a plus de risques de plantages et en tant que PID 1 ça ne pardonne pas puisqu'il n'y a personne pour récupérer l'orphelin;
Euh, ce n'est pas mon impression. Extrait du man :
--crash-shell
Run shell on crash.
(bon sauf que j'ai pas pu crasher systemd pour tester)
Et puis tant qu'on parle de fiabilité : quand je m'étais planté dans mon inittab, SysV empêchait le système de démarrer. C'était tellement mieux, SysV à ce niveau ?
J'ai jamais eu cette impression.
Quant à la sécurité de SysV : euh, quelle sécurité ? La sécurité d'avoir des scripts shells exécutés par root, sans usage des control groups qui plus est ?
Et puis bon, face à la complexité du kernel, de Firefox, ou de Xorg, systemd (le PID 1 pas si compliqué que ça en fait...) c'est rien du tout du tout du tout. Mais le kernel et Xorg ne sont pas des cibles de choix : après tout, ce n'est pas systemd. ;-)
une autre, le fait que certaines mises-à-jour de systemd demandent du coup un redémarrage.
Euh... lesquelles ?
J'ai jamais été obligé de redémarrer. Et pour profiter de la nouvelle version les mises à jours du kernel ou de Xorg nécessitent elles aussi un redémarrage : rien d'anormal là dedans (oui pour Xorg on peut "juste" redémarrer Xorg : mais c'est plus rapide pour moi de redémarrer tout court...).
Les logs binaires, je trouve ça vraiment stupide.
Bah d'un point de vue sécurité, c'est les logs textuels le plus "stupide" :
- N'importe qui ayant accès aux logs peut les modifier et effacer ses traces (ce qui n'est pas le cas avec journald)
- on ne peut pas mettre un core dump ou un dump de firmware avec les logs. Oh, on peut mettre ça à côté, mais ce n'est pas dans le journal binaire, le même journal qu'on veut pouvoir être lisible avec journalctl sur un autre système et authentifier facilement.
- on a pas un standard de notation des dates/heures, ce qui est particulièrement énèrvant quand on a des tonnes de logs
- Perso, je trouve bien plus vite les erreurs avec journald qu'avec des fichiers textes (pas besoin de me souvenir comment fonctionne awk, sed, & co.). Au bout d'un moment, avoir une abstraction qui m'évite cette peine a du sens.
Je veux les logs produits par Firefox ? Aucun problème :
max-laptop% journalctl /usr/bin/firefox
-- Logs begin at sam. 2014年01月11日 18:57:59 CET, end at lun. 2014年07月28日 21:31:10 C
févr. 25 20:06:54 max-laptop firefox[2419]: getaddrinfo*.gaih_getanswer: got typ
févr. 25 20:06:54 max-laptop firefox[2419]: getaddrinfo*.gaih_getanswer: got typ
-- Reboot --
mars 31 06:45:20 max-laptop firefox[2152]: getaddrinfo*.gaih_getanswer: got type
mars 31 06:45:20 max-laptop firefox[2152]: getaddrinfo*.gaih_getanswer: got type
-- Reboot --
avril 07 07:27:44 max-laptop firefox[2193]: getaddrinfo*.gaih_getanswer: got typ
avril 07 07:27:44 max-laptop firefox[2193]: getaddrinfo*.gaih_getanswer: got typ
lines 1-9/9 (END)
Je veux les logs du boot précédent ? OK :
max-laptop% journalctl -k -b -1
-- Logs begin at sam. 2014年01月11日 18:57:59 CET, end at lun. 2014年07月28日 21:42:15 C
juin 15 07:47:32 max-laptop kernel: Initializing cgroup subsys cpuset
juin 15 07:47:32 max-laptop kernel: Initializing cgroup subsys cpu
juin 15 07:47:32 max-laptop kernel: Initializing cgroup subsys cpuacct
juin 15 07:47:32 max-laptop kernel: Linux version 3.14.6-1-ARCH (nobody@var-lib-
juin 15 07:47:32 max-laptop kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-linux
juin 15 07:47:32 max-laptop kernel: e820: BIOS-provided physical RAM map:
juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x0000000000000000-0x0000000
juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x000000000009e000-0x0000000
juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x0000000000100000-0x0000000
juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x0000000020000000-0x0000000
juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x0000000020200000-0x0000000
juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x0000000040004000-0x0000000
juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x0000000040005000-0x0000000
juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x00000000c97a5000-0x0000000
juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x00000000c9da6000-0x0000000
juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x00000000c9da9000-0x0000000
juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x00000000c9dbf000-0x0000000
juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x00000000c9dc5000-0x0000000
juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x00000000c9dc7000-0x0000000
juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x00000000c9dd1000-0x0000000
juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x00000000c9f28000-0x0000000
juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x00000000c9f2c000-0x0000000
lines 1-23
Aux pros de awk/sed & co. : Bravo, mais il y a des gens qui sont de simples mortels. Désolé de vous décevoir.
Oui, je sais qu'aujourd'hui on peut encore envoyer vers syslog mais... pour combien de temps encore?
Euh, tu nous fais du FUD maintenant ?
Personne ne peut répondre à ce genre de questions, à part les auteurs de systemd ! D'ailleurs, tu leur a posé la question ?
Et à part ça, t'es au courant que c'est un logiciel libre, tout de même ?
Surtout qu'il te donne plus d'informations dans ton syslog que ne le fait SysV (parce que journald démarre plus tôt que ne peut le faire syslog, et que journald enregistre la sortie standard et la sortie d'erreurs de tout service système) : rien n'est caché à syslog. En rien, on ne te force d'utiliser journald.
Sinon, il y a aussi tout le bloat: systemd incluant notamment, un serveur http, de quoi servir des codes QR, etc.
Y'a pas de quoi fouetter un chat, surtout quand on sait à quoi ça sert.
(en gros, c'est une option pour ne pas avoir à copier des clés de vérification que l'utilisateur pourrait trouver trop longues).
Quant au serveur http (cela semble être systemd-journald-gatewayd) embarqué :
- il est embarqué (ou pas, si on le compile pas) pour éviter une dépendance
- sa compilation n'est pas activé par défaut
- son code est réduit au minimum
- il permet d'envoyer le journal de journald à travers le réseau. Rien de révoltant là non plus (on faisait pareil avec SysV)
- même s'il est compilé, il faut l'activer pour l'utiliser ou le désactiver si on en veut pas, comme n'importe quel autre service.
Je pense que systemd fait trop de choses.
Euh ouais... Tout comme le kernel monolithique linux, Xorg le très mauvais middle-man (c'est les devs Xorg qui le disent eux-mêmes !), ou Firefox si on en croit certains (c'est vrai que je largement mets moins de temps à compiler linux qu'à compiler Firefox), si on va par là...
Et c'est vrai que quand j'ai découvert (par exemple) que systemd s'occupait de l'ACPI, je me suis dit qu'il faisait trop de choses. Mais ça a du sens sur un système embarqué (c'est un marché ou systemd sembleêtreutilisé)
Ou si on veut pas utiliser de bureau : j'imaginerais bien un système utilisateur léger avec un WM de son choix, et systemd pour l'ACPI (pas xfce4-power-manager ni rien de tout ça !). :)
Niveau sécurité, je pense que systemd est également un problème. On a déjà vu passer quelques CVE concernant systemd mais à mon avis, cette tendance ne va aller qu'à la hausse puisque, vu son importance, il est une cible de choix.
Ce qui compte, c'est pas la tellement taille du code, c'est sa qualité. Sinon, on utiliserait tous nginx au lieu d'Apache (ben oui moins de code = plus de sécurité. Autant éteindre l'ordi et le débrancher : il y aura zéro code, donc un maximum de sécurité ;-) ).
[^] # Re: Quelques questions
Posté par xcomcmdr . En réponse à la dépêche Crux 3.1: une distribution KISS à la saveur BSD. Évalué à -6. Dernière modification le 16 septembre 2024 à 20:28.
T'as eu la même réaction quand SysV s'est imposé ?
Peut-être que systemd s'impose car il est bien meilleur que SysV. Par exemple, plus besoin de maintenir des scripts : on prend l'unit file upstream et c'est plié.
De la diversité pour un système d'init. Comment dire... Tout ce que je demande à un système d'init (en gros), c'est que la machine boot sans problème. Au delà, qu'il soit SysV ou systemd importe peu.
Et puis là c'est pas de la diversité : c'est revenir sur SysV. Si au moins c'était un init nouveau, là il y aurait une vraie diversité.
Et que penses-tu de Mir alors ? Tu crois que c'est une chance d'avoir autre chose que Wayland pour le futur des serveurs d'affichage ? Deux APIs, deux serveurs d'affichages concurrents, deux fois plus de bugs potentiels : youpi... ;-)
Je pense qu'au contraire qu'avoir systemd partout permet :
- d'avoir une seule API pour l'init
- de même pour l'usage des cgroups par l'user-space
- d'éviter d'écrire 1000 fois a peu près le même script d'init pour le service X (1 fois par distribution. Et encore, 1000, c'est loin du compte du nombre de distribs).
Faut croire que c'est pas tellement le cas vu que Crux, Gentoo, Slackware, Ubuntu (jusqu'à la 14.04 au moins, qui a 5 ans de support), la dernière Debian stable (d'ailleurs systemd a été choisi pour d'autres raisons que sa "pénibilité" supposée : après tout les arguments autres que techniques n'avaient pas leur place dans la discussion) et d'autres font bien sans.
Bah systemd est très dépendant d'udev, et puis bon le seul "problème" c'est de pouvoir compiler udev sans systemd.
Les forks c'est bien, sauf quand on s'appelle eudev et qu'on a pas parlé à l'upstream avant de forker udev en "eudev". C'est sûr que si on coopère pas, rien ne changera.
systemd, ses outils (dont udev) sont développés ensemble, et sont sur un VCS commun à la BSD. Mais ça ne plaît pas à BSDiste. Et ça ne plaît pas aux linuxiens. Faut croire que le problème, c'est peut-être pas systemd...
Pour l'etc, je ne vois pas... (je suis pas devin ;-) )
Dommage que ce soit toujours les même arguments répétés 1000 fois et réfutés 1000 fois. :/
Honnêtement, pour la plupart de tes griefs, je me suis renseigné 30 secondes pour savoir que c'était faux...
"Mon" /sbin/init (systemd) ne fait guère de plus que SysV, il me semble (non seulement d'après la page de man, mais en lançant /sbin/init --help on voit qu'on a pas grand chose de compliqué :
Ou du moins, il n'y a rien de surprenant.
D'ailleurs, quand j'interagis (rarement, d'ailleurs) avec systemd, j'utilise en fait /usr/bin/systemctl
Euh, ce n'est pas mon impression. Extrait du man :
Et puis tant qu'on parle de fiabilité : quand je m'étais planté dans mon inittab, SysV empêchait le système de démarrer. C'était tellement mieux, SysV à ce niveau ?
J'ai jamais eu cette impression.
Quant à la sécurité de SysV : euh, quelle sécurité ? La sécurité d'avoir des scripts shells exécutés par root, sans usage des control groups qui plus est ?
Et puis bon, face à la complexité du kernel, de Firefox, ou de Xorg, systemd (le PID 1 pas si compliqué que ça en fait...) c'est rien du tout du tout du tout. Mais le kernel et Xorg ne sont pas des cibles de choix : après tout, ce n'est pas systemd. ;-)
Euh... lesquelles ?
J'ai jamais été obligé de redémarrer. Et pour profiter de la nouvelle version les mises à jours du kernel ou de Xorg nécessitent elles aussi un redémarrage : rien d'anormal là dedans (oui pour Xorg on peut "juste" redémarrer Xorg : mais c'est plus rapide pour moi de redémarrer tout court...).
Bah d'un point de vue sécurité, c'est les logs textuels le plus "stupide" :
- N'importe qui ayant accès aux logs peut les modifier et effacer ses traces (ce qui n'est pas le cas avec journald)
- on ne peut pas mettre un core dump ou un dump de firmware avec les logs. Oh, on peut mettre ça à côté, mais ce n'est pas dans le journal binaire, le même journal qu'on veut pouvoir être lisible avec journalctl sur un autre système et authentifier facilement.
- on a pas un standard de notation des dates/heures, ce qui est particulièrement énèrvant quand on a des tonnes de logs
- Perso, je trouve bien plus vite les erreurs avec journald qu'avec des fichiers textes (pas besoin de me souvenir comment fonctionne awk, sed, & co.). Au bout d'un moment, avoir une abstraction qui m'évite cette peine a du sens.
Je veux les logs produits par Firefox ? Aucun problème :
Je veux les logs du boot précédent ? OK :
Les exemples du manuel sont pas mal aussi.
Aux pros de awk/sed & co. : Bravo, mais il y a des gens qui sont de simples mortels. Désolé de vous décevoir.
Euh, tu nous fais du FUD maintenant ?
Personne ne peut répondre à ce genre de questions, à part les auteurs de systemd ! D'ailleurs, tu leur a posé la question ?
Et à part ça, t'es au courant que c'est un logiciel libre, tout de même ?
Surtout qu'il te donne plus d'informations dans ton syslog que ne le fait SysV (parce que journald démarre plus tôt que ne peut le faire syslog, et que journald enregistre la sortie standard et la sortie d'erreurs de tout service système) : rien n'est caché à syslog. En rien, on ne te force d'utiliser journald.
C'est optionnel à la compilation, et d'ailleurs sur Archlinux ce n'est même pas compilé.
Le support de la génération de codes QR par journald (et non systemd) c'est environ 116 lignes.
Y'a pas de quoi fouetter un chat, surtout quand on sait à quoi ça sert.
(en gros, c'est une option pour ne pas avoir à copier des clés de vérification que l'utilisateur pourrait trouver trop longues).
Quant au serveur http (cela semble être systemd-journald-gatewayd) embarqué :
- il est embarqué (ou pas, si on le compile pas) pour éviter une dépendance
- sa compilation n'est pas activé par défaut
- son code est réduit au minimum
- il permet d'envoyer le journal de journald à travers le réseau. Rien de révoltant là non plus (on faisait pareil avec SysV)
- même s'il est compilé, il faut l'activer pour l'utiliser ou le désactiver si on en veut pas, comme n'importe quel autre service.
Euh ouais... Tout comme le kernel monolithique linux, Xorg le très mauvais middle-man (c'est les devs Xorg qui le disent eux-mêmes !), ou Firefox si on en croit certains (c'est vrai que je largement mets moins de temps à compiler linux qu'à compiler Firefox), si on va par là...
Et c'est vrai que quand j'ai découvert (par exemple) que systemd s'occupait de l'ACPI, je me suis dit qu'il faisait trop de choses. Mais ça a du sens sur un système embarqué (c'est un marché ou systemd semble être utilisé)
Ou si on veut pas utiliser de bureau : j'imaginerais bien un système utilisateur léger avec un WM de son choix, et systemd pour l'ACPI (pas xfce4-power-manager ni rien de tout ça !). :)
Ce qui compte, c'est pas la tellement taille du code, c'est sa qualité. Sinon, on utiliserait tous nginx au lieu d'Apache (ben oui moins de code = plus de sécurité. Autant éteindre l'ordi et le débrancher : il y aura zéro code, donc un maximum de sécurité ;-) ).
En parlant de qualité, avec des suites de tests et une convention de style de code assez détaillée, c'est bien plus que pas mal de projets...
Et j'ai du mal à imaginer qu'il n'y ait jamais eu de CVE avec SysV. Ou Xorg. Ou Linux. Ou Firefox. Ou Apache... Ou nginx.
Et je t'en remercie.
Pour en rire : voici les six étapes de systemd (linux conf.au 2014). ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)