L'idée que j'ai en tête, c'est l'utilisation d'une distribution "généraliste" dans une carte style raspberry pi, pour lequel par exemple les versions les plus récentes du noyau ne seraient pas supporté (car nécessité de le patcher mais patch pas dispo pour le noyau courant de la distribution), ou sur laquelle on voudrait faire tourner un linux allégé d'un tas de choses dont systemd aurait besoin, mais inutile dans le cas de figure ou on veut utiliser la carte. Le support à 2 ans, comme dit plus haut ne devrait pas poser problème, par contre je crains que systemd ne pousse à intégrer un noyau et des libs inutiles. Mais je me trompe peut-être, et dans ce cas, merci de me le préciser (comme dit plus haut, je ne trolle pas, il s'agit d'un cas d'utilisation plus ou moins courant pour des personnes qui font un peu plus qu'utiliser une distrib serveur ou desktop).
Je tourne avec systemd sur Raspberry Pi depuis des mois, aucun problème de ce côté-là.
systemd est parfait pour cela, les options inutiles peuvent être omises à la compilation sans le moindre souci. Les options non disponibles pour cause de bibliothèques manquantes sont automatiquement écartées donc aucun souci non plus.
En revanche, il faut utiliser la glibc, de nombreuses fonctionnalités extrêmement utiles manquent aux libc minimalistes.
Trop de fonctionnalités tue les fonctionnalités, il y a des cas ou ces fonctionnalités peuvent être inutiles. L'avantage de sysvinit était justement de pouvoir adapter une distrib généraliste à un niveau minimaliste. Personnellement une de mes craintes à propos de systemd, c'est une perte de possibilités de personalisation.
C'est faux, trop de fonctionnalités n'a jamais tué les fonctionnalités dans un cas de figure comme celui de systemd. Ces fonctionnalités sont de l'ordre de la commodité, comme des options sur une voiture. Au pire elles ne sont pas utilisées, mais en général, si on les achète, c'est pour les utiliser. systemd c'est pareil, si on ajoute des fonctionnalités, c'est pour les utiliser à priori vu que ça peut (pas toujours) affecter l'empreinte mémoire de certains daemons de systemd.
Les seules bibliothèques requises par systemd sont quasi obligatoires sur tout système GNU/Linux un minimum sécurisé : glibc >= 2.14 (bientôt 2.16), libcap, libmount d'util-linux.
Même dbus est optionnel mais alors systemd devient très compliqué à utiliser, donc je rajouterai quand même dbus en composant supplémentaire perçu comme inutile ailleurs.
Pour un système embarqué, systemd est clairement meilleur que sysvinit auquel s'ajoute au moins un daemon par fonctionnalité de systemd et des tonnes de scripts, l'empreinte mémoire de systemd et ses "aides" est clairement plus faible, principalement parce que beaucoup de fonctionnalités sont partagées et pas dupliquées. J'ai pu dégager des trucs devenus inutiles et clairement inférieurs (moins fiables) comme xinetd, autofs (sauf si la conf est dans LDAP), dhcpcd, mes scripts d'initialisation réseau, l'initialisation du stockage, ... Quand je vois le temps que j'ai passé à affiner dhcpcd avec mon firewall et bind afin qu'ils redémarrent correctement en cas de coupure réseau (ça m'a pris des jours avec des horreurs comme des timeout), et la simplicité avec laquelle j'ai fait la même chose avec systemd, c'est consternant.
[^] # Re: glibc non, systemd peut-être
Posté par ookaze . En réponse au message Kernel 4.0 et lfs. Évalué à 3.
Je tourne avec systemd sur Raspberry Pi depuis des mois, aucun problème de ce côté-là.
systemd est parfait pour cela, les options inutiles peuvent être omises à la compilation sans le moindre souci. Les options non disponibles pour cause de bibliothèques manquantes sont automatiquement écartées donc aucun souci non plus.
En revanche, il faut utiliser la glibc, de nombreuses fonctionnalités extrêmement utiles manquent aux libc minimalistes.
C'est faux, trop de fonctionnalités n'a jamais tué les fonctionnalités dans un cas de figure comme celui de systemd. Ces fonctionnalités sont de l'ordre de la commodité, comme des options sur une voiture. Au pire elles ne sont pas utilisées, mais en général, si on les achète, c'est pour les utiliser. systemd c'est pareil, si on ajoute des fonctionnalités, c'est pour les utiliser à priori vu que ça peut (pas toujours) affecter l'empreinte mémoire de certains daemons de systemd.
Les seules bibliothèques requises par systemd sont quasi obligatoires sur tout système GNU/Linux un minimum sécurisé : glibc >= 2.14 (bientôt 2.16), libcap, libmount d'util-linux.
Même dbus est optionnel mais alors systemd devient très compliqué à utiliser, donc je rajouterai quand même dbus en composant supplémentaire perçu comme inutile ailleurs.
Pour un système embarqué, systemd est clairement meilleur que sysvinit auquel s'ajoute au moins un daemon par fonctionnalité de systemd et des tonnes de scripts, l'empreinte mémoire de systemd et ses "aides" est clairement plus faible, principalement parce que beaucoup de fonctionnalités sont partagées et pas dupliquées. J'ai pu dégager des trucs devenus inutiles et clairement inférieurs (moins fiables) comme xinetd, autofs (sauf si la conf est dans LDAP), dhcpcd, mes scripts d'initialisation réseau, l'initialisation du stockage, ... Quand je vois le temps que j'ai passé à affiner dhcpcd avec mon firewall et bind afin qu'ils redémarrent correctement en cas de coupure réseau (ça m'a pris des jours avec des horreurs comme des timeout), et la simplicité avec laquelle j'ai fait la même chose avec systemd, c'est consternant.