À vrai dire, sur un serveur à moitié embarqué j'aurais tendance à utiliser un système largement utilisé afin d'éviter au maximum des problèmes.
Ça tombe bien, j'utilise Debian.
Plus sérieusement, ça dépend de ce qu'on appelle "à moitié embarqué". Mais bien souvent, il y a au moins une des contraintes de l'embarqué à tenir compte. Moi dans mon cas, c'est un manque de RAM, mais j'ai quand même un disque dur pour swapper. Donc je vire tout ce qui prend de la RAM et qui ne swappe pas bien, du genre ifplugd qui passe son temps à poller alors qu'on peut faire sans si on daigne utiliser netlink, ou… D-Bus.
Si je résume, systemd c'est au final plus de fonctionnalités, moins de bugs, plus rapide. C'est quoi l'intérêt de garder un sysv à l'ancienne qui est lent et moins testé?
[Référence nécessaire]. Sérieux, d'ou tu sort que systemd est plus tésté que sysv ? Et je veux bien des tests sur la rapidité de systemd sur des petites machines. Quand aux nouvelles fonctionnalités, c'est bien pour celui qui les attend, mais c'est pas mon cas.
[^] # Re: la guerre de s unices
Posté par Batchyx . En réponse au journal udev forké. Évalué à 7.
Ça tombe bien, j'utilise Debian.
Plus sérieusement, ça dépend de ce qu'on appelle "à moitié embarqué". Mais bien souvent, il y a au moins une des contraintes de l'embarqué à tenir compte. Moi dans mon cas, c'est un manque de RAM, mais j'ai quand même un disque dur pour swapper. Donc je vire tout ce qui prend de la RAM et qui ne swappe pas bien, du genre ifplugd qui passe son temps à poller alors qu'on peut faire sans si on daigne utiliser netlink, ou… D-Bus.
[Référence nécessaire]. Sérieux, d'ou tu sort que systemd est plus tésté que sysv ? Et je veux bien des tests sur la rapidité de systemd sur des petites machines. Quand aux nouvelles fonctionnalités, c'est bien pour celui qui les attend, mais c'est pas mon cas.