<div dir="ltr"><div>Je me suis trompé, les arguments A01 à A09 sont contre [systemd ou upstart]</div><div><br></div><br>En complément: ma traduction des arguments spécifiquement contre systemd:<div><br></div><div><br></div>

<div><div>A10. Pas portable, de par sa conception; utilise des fonctionnalités spécifiques à Linux ne sont pas disponibles sur d'autres plates-formes. </div><div>A11. Oblige Debian à être une distribution Linux; De plus, certains portages Linux peuvent être abandonnés si systemd ne les soutien plus. </div>

<div>A12. Viole les principes UNIX traditionnels de simplicité et de la séparation des fonctions kernel/initsystem/userland de façon à ce que les composants soient interchangeables. </div><div>A13. Constitue un précédent pour des changements perturbateurs, ce qui peut arriver à nouveau si systemd change ses API ou abandonne certaines interfaces (a été décrit comme ressemblant à 'verrouillage par un fournisseur'; ce qui implique en réalité que nous devons continuer à faire face aux changements imposés par l'amont. </div>

<div>A14. Logind ne peut plus être utilisé de manière autonome, pour la version V205 de systemd </div><div>A15. Prévoit de remplacer aussi les scripts ifupdown</div><div>A16. Entre en conflit avec busybox-syslogd </div><div>

A17. Fai s'interroger sur la stratégie/théorie de complot entourant GNOME, systemd, et Linux, en particulier l'intérêt de Red Hat pour chacun d'entre eux.</div><div>A18. Nous n'avons pas besoin du stress associé à la constante évolution vers le dernier cri et d'être mené dans un autre "trou de lapin". Debian devrait être un rocher dans la tempête, pas une poussière soufflée par le vent.</div>

<div>A19. Les opinions exprimées par ceux qui poussent systemd: </div><div>A20. désintérêt dans les ports de Debian, pour la possiblité d'avoir le choix et la capacité de «tout combiner avec tout le reste": </div>

<div>A21. incompréhension du concept «modulaire»; ayant "des plus de 80 ans binaires autour" est de l'obésité, ce n'est pas modulaire ils dépendent monolithiquement de systemd et ses interfaces  </div><div>

A22. <a href="http://bugs.debian.org/684396#10">http://bugs.debian.org/684396#10</a> </div><div>A23. <a href="http://bugs.debian.org/684396#30">http://bugs.debian.org/684396#30</a> </div><div>A24. <a href="https://plus.google.com/115547683951727699051/posts/8RmiAQsW9qf">https://plus.google.com/115547683951727699051/posts/8RmiAQsW9qf</a> </div>

<div>A25. Lennart Poettering (inventeur de systemd): "La seule chose que nous n'accepterons pas sont les modifications (patchs) pour porter systemd pour BSD ou Hurd." </div><div>A26. Jeter tout POSIX par la fenêtre: où ne s'arrête la reconception? </div>

<div>A27. Systemd procure un nombre croissant d'interfaces utiles, unifiées en ligne de commande pour les paramètres du système et le contrôle (timedatectl, bootctl, hostnamectl, loginctl, machinectl, kernel-installer, localectl)." "unifié" est un mauvais substitut à la conformité aux normes (comme POSIX) et aux conventions, et le pouvoir doit aller de pair avec la responsabilité </div>

<div>A28. Dépendances système minimale requise pour systemd: acl dbus glib2 hwids kmod libcap libgcrypt pam attr glibc expat libcap openssl pam perl cracklib db libtirpc libgssglue</div></div><div><br></div><div><br></div>

<div>--P</div><div><br></div></div>