Il n'y a pas de couche réseau dans systemd. Ce n'est qu'une unité comme un autre.
Non, mais il y a trois couches communicantes en dépendance (2 IPC et les sockets). Ca laisse pas mal de place pour des failles réseau. Et puis les virtual sockets c'est pas techniquement dans systemd, mais c'est vraiment pas loin à coté.
En fait, systemd est très KISS : il ne fait qu'une chose, il gère des unités.
Pas vairment non, il fait appel à plusieurs dépendances pour gérer des unités (qui elle mêmes on des sous dépendances pour pouvoir fonctionner, la liste complète est là : http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart ) en comptant bien il y en a juste 40 dont deux IPC (DBus et treaty) plusieurs FS et les mounters qui vont avec etc. Donc dire que systemd est KISS c'est juste une blague.
Et tout ce qu'on lui reproche de faire en trop ne sont que des unités qu'il se contente de gérer
On lui reproche d'avoir d'ennormes dépendances pour au final en faire moins que SystemV init. On dira ce qu'on voudra mais systemd n'est pas turing complet, les shells si.
Comme SysV, sauf qu'il est plus modulaire
Non il est nettement moins modulaires que SystemV init. Il ne supporte pas les sous scripts d'init, pas les templates, il faut recompiler toute la chaine de boot à chaque modif etc. La ils sont en train de massacrer udev pour le rendre plus compatible avec systemd et ils demandent au kernel de faire des modifs aussi pour corriger les bugs qu'ils ont introduits dans udev.
Egalement l'init systemd ne fonctionne pas avec
- La plupart des systemes de fichiers chiffrés
- le /usr distant (au revoir les terminaux léger)
- le multiboot du même service (service qui se clone et qui se ferme mais ou il ne faut pas fermer les clones) - on peut mettre un mode dégradé en place pour dire à systemd de ne surtout toucher à rien, mais du coup on est moins bien qu'avec SystemV init. Bon c'est un peu con en période d'explosion du cloud, mais on peut pas penser à tout.
- le pxe "à rebond" (le initram charge deux environnement le premier pour authentifier l'utilisateur/la machine - le second qui est le "vrai" environement de travail) mais bon c'était déjà foutu pour les terminaux léger.
- la gestion des mots de passe au boot. Merci de donner les clefs de tout vos certificats à systemd ou de lancer vos services à la main si vous devez taper un mot de passe à un moment. le parallélisme ca ne va pas avec l'interactif.
- la gestion des templates. Vous devez démarrer 6 ou 7 VPN ? Ben ca fera 6 ou 7 services à configurer indépendamment les uns des autres mon bon monsieur.
On notera aussi pèle-mèle :
La complexité de la maintenance du truc : si un jour vous cassez votre boot process au niveau de systemd, vous avez interet à avoir une machine très similaire avec un environnement très très proche pour réparer systemd. Sur une machine un peu custom, réparer systemd depuis un LiveCD c'est juste un massacre.
Le coté (LSB/Fedora style)/Linux only. Systemd n'est pas compatible avec tous les systèmes même si ce sont des Linux récents. Encore faut-il avoir un processeur et un environnement qui peuvent s'y préter.
A part la vitesse de boot (dont personnellement je me fous royalement) Systemd est loin derrière SystemV init à tous les points de vues. Que se soit la compatibilité, la flexibilité, la maintenance (et même la capacité à fermer des processus et/ou à logguer leur comportement). Il ne faut pas oublier que l'on peut parfaitement utiliser cgroups avec SystemV init (95% des gens qui défendent systemd défendent en fait l'utilisation de cgroups dans les scripts d'init - ca marche très bien avec SystemV init, même mieux qu'avec systemd vu que la plupart des shells sont turing complets).
[^] # Re: Tu portes vraiment bien ton pseudonyme
Posté par Kaane . En réponse au journal Archlinux est morte.... Évalué à 10.
Il n'y a pas de couche réseau dans systemd. Ce n'est qu'une unité comme un autre.
Non, mais il y a trois couches communicantes en dépendance (2 IPC et les sockets). Ca laisse pas mal de place pour des failles réseau. Et puis les virtual sockets c'est pas techniquement dans systemd, mais c'est vraiment pas loin à coté.
En fait, systemd est très KISS : il ne fait qu'une chose, il gère des unités.
Pas vairment non, il fait appel à plusieurs dépendances pour gérer des unités (qui elle mêmes on des sous dépendances pour pouvoir fonctionner, la liste complète est là : http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart ) en comptant bien il y en a juste 40 dont deux IPC (DBus et treaty) plusieurs FS et les mounters qui vont avec etc. Donc dire que systemd est KISS c'est juste une blague.
Et tout ce qu'on lui reproche de faire en trop ne sont que des unités qu'il se contente de gérer
On lui reproche d'avoir d'ennormes dépendances pour au final en faire moins que SystemV init. On dira ce qu'on voudra mais systemd n'est pas turing complet, les shells si.
Comme SysV, sauf qu'il est plus modulaire
Non il est nettement moins modulaires que SystemV init. Il ne supporte pas les sous scripts d'init, pas les templates, il faut recompiler toute la chaine de boot à chaque modif etc. La ils sont en train de massacrer udev pour le rendre plus compatible avec systemd et ils demandent au kernel de faire des modifs aussi pour corriger les bugs qu'ils ont introduits dans udev.
Egalement l'init systemd ne fonctionne pas avec
- La plupart des systemes de fichiers chiffrés
- le /usr distant (au revoir les terminaux léger)
- le multiboot du même service (service qui se clone et qui se ferme mais ou il ne faut pas fermer les clones) - on peut mettre un mode dégradé en place pour dire à systemd de ne surtout toucher à rien, mais du coup on est moins bien qu'avec SystemV init. Bon c'est un peu con en période d'explosion du cloud, mais on peut pas penser à tout.
- le pxe "à rebond" (le initram charge deux environnement le premier pour authentifier l'utilisateur/la machine - le second qui est le "vrai" environement de travail) mais bon c'était déjà foutu pour les terminaux léger.
- la gestion des mots de passe au boot. Merci de donner les clefs de tout vos certificats à systemd ou de lancer vos services à la main si vous devez taper un mot de passe à un moment. le parallélisme ca ne va pas avec l'interactif.
- la gestion des templates. Vous devez démarrer 6 ou 7 VPN ? Ben ca fera 6 ou 7 services à configurer indépendamment les uns des autres mon bon monsieur.
On notera aussi pèle-mèle :
La complexité de la maintenance du truc : si un jour vous cassez votre boot process au niveau de systemd, vous avez interet à avoir une machine très similaire avec un environnement très très proche pour réparer systemd. Sur une machine un peu custom, réparer systemd depuis un LiveCD c'est juste un massacre.
Le coté (LSB/Fedora style)/Linux only. Systemd n'est pas compatible avec tous les systèmes même si ce sont des Linux récents. Encore faut-il avoir un processeur et un environnement qui peuvent s'y préter.
A part la vitesse de boot (dont personnellement je me fous royalement) Systemd est loin derrière SystemV init à tous les points de vues. Que se soit la compatibilité, la flexibilité, la maintenance (et même la capacité à fermer des processus et/ou à logguer leur comportement). Il ne faut pas oublier que l'on peut parfaitement utiliser cgroups avec SystemV init (95% des gens qui défendent systemd défendent en fait l'utilisation de cgroups dans les scripts d'init - ca marche très bien avec SystemV init, même mieux qu'avec systemd vu que la plupart des shells sont turing complets).