Visiblement, systemd n’en finit pas de faire des remous:
debianfork.org/
et une traduction
bn.parinux.org/p/debianfork
Lire la DUF pour les commentaires.
Un article également
zdnet.fr/actualites/systemd- … 808179.htm
Article bien fait de linuxfr sur systemd:
linuxfr.org/news/%C3%A9volutions … de-systemd
Je pense que le design même du site parle pour les personnes qui sont derrière…
Ce n’est pas parce qu’on écrit en gros caractères que ça rend plus pertinent ce qu’on raconte.
Qu’ils lancent leur fork et je commencerai peut-être à les prendre au sérieux, mais pour l’instant je ne vois qu’une bande de trolls qui lancent un site pour cracher leur haine sans rien de concret à proposer.
Un fork juste pour le systeme d’init ? Si ce n’est pas un troll si ceci voit le jour ça devrait tout au plus devenir une variante pour les serveurs a mon avis !
C’est plus compliqué qu’un simple design du site et juger un livre sur une couverture est une mauvaise idée. Indépendamment de l’esthétisme du site, les personnes soulignent le pbm de fond qui consiste à installer un système multi services dont le plantage coincerait toute la machine. Cela semble gêner beaucoup de monde (se rappeler les plantages svchost sous windows) et constitue effectivement un abandon de la philosophie d’Unix (un service/un programme et «KISS» (soit keep it simple, stupid!»)). La liste DUF a vu se multiplier des demandes de machines avec un démarrage complet dans les choux ce qui était exceptionnel voire inexistant il y a un an. Le parallèle avec le svchost de windows fait petit à petit son chemin (même si leur fonction n’est pas la même, un svchost défaillant rend une machine inutilisable, un systemd défaillant semble faire de même)
J’ai suivi le précédent fil sur le sujet (*) mais tout ça dépasse à la fois ce que je connais de Debian et ce que je peux comprendre facilement.
J’ai quand même une question : si les problèmes de machines inutilisables se multiplient ou simplement persistent, est-il envisageable de faire machine arrière ou de passer carrément à autre chose ?
Je trouverais dommage que la philosophie « Ne faire qu’une seule chose, et la faire bien. » qui m’a aussi attirée vers GNU/Linux finisse par me manquer.
Il faut quand même faire confiance au principe. Ainsi debian a choisi gnome comme environnement par defaut, mais le choix d’un autre environnement ne pose strictement aucun problème (3 touches à l’installation). Si les prochaines installation se passent comme cela pour le choix systemd/systemv-init, tout va bien. Si par contre dès la prochaine mise à jour, c’est la bascule vers systemd ou si le choix consiste à désinstaller systemd pour réinstaller systemv-init, c’est un autre souci. Sur les ububntu, la mise à jour a conduit à installer systemd-services, systemd-shim, le tout venant semble-t-il de colord (dont l’utilité sur un serveur me parait discutable mais bon, ça marche)
Je ne suis pas certain de la pertinence du choix du système d’init à l’installation via les média traditionnel. Un “expert” utilisant debootstrap peut déjà choisir son système d’init s’il préfère utiliser sysvinit-core ou upstart (dommage d’ailleurs qu’openrc ne soit pas aussi dans les dépendances du paquet init). Mais sur le CD/DVD/USB je me demande si ce ne serait pas inutilement ajouter de la complexité.
Bien sûr, l’installation “en mode expert” se fait très bien même en ne sachant pas répondre à toutes les questions en gardant les choix par défaut, mais la prolifération de celles-ci est-elle vraiment une bonne idée ? Et surtout je crains que ça ne suffise pas à calmer les “anti-systemd” les plus virulents, qui même si le choix est proposé reprocheront que SysV ne soit pas le choix par défaut…
Pour la partie SPOF (un processus unique qui si HS met tout le système en vrac), il est évident que si je n’ai rien contre l’adoption de systemd comme système d’init par défaut de la Debian stable, c’est à la condition que celui-ci soit solide comme un roc ! Mais finalement la même chose s’applique à SysV : si celui-ci est planté, qui va démarrer la machine ?
Il est tout aussi important à mon avis de pouvoir utiliser un autre système d’init si le besoin (ou l’envie) s’en fait sentir. C’est pour ça que ma machine secondaire à son passage en Jessie continuera à utiliser SysV : pour m’assurer que contrairement à ce que je vois affirmé un peu partout autour de moi systemd n’est pas incontournable sous Debian.
Revenons quand même à ce “projet”… Comme dit plus haut, je suis tout-à-fait près à les prendre au sérieux, à condition qu’ils aient quelque chose à présenter. Avec une valeur ajoutée par rapport à Debian vanilla. La possibilité d’utiliser SysV comme système d’init n’est pas une valeur ajoutée : je peux déjà le faire avec ma Debian.
Sur une machine j’ai fait le test de migrer de SysV vers systemd, puis retour vers SysV. Ça fonctionne. D’où le fait que je trouve ces critiques au sujet de systemd qui serait imposé particulièrement malhonnêtes.
Vous remarquerez que je ne parle pas des qualités techniques comparées de SysV et systemd ici, que de toutes façons je ne suis pas qualifié pour discuter. Ce sont les choix du projet Debian qui m’intéressent, et pour le moment la situation actuelle me paraît satisfaisante. Un système d’init est installé par défaut (ce qui est bien normal), et la possibilité de le remplacer par un autre est présente. La plupart des critiques que je vois autour des choix du projet me semblent oublier un peu trop facilement cette possibilité de choix, pour des raisons que je ne parviens pas à dissocier de la malhonnêteté intellectuelle.
Un petit pavé, sur un sujet que je suis loin de maîtriser techniquement… N’hésitez pas à me reprendre si je me plante sur certains points. 
[quote=“vv222”]Je ne suis pas certain de la pertinence du choix du système d’init à l’installation via les média traditionnel. Un “expert” utilisant debootstrap peut déjà choisir son système d’init s’il préfère utiliser sysvinit-core ou upstart (dommage d’ailleurs qu’openrc ne soit pas aussi dans les dépendances du paquet init). Mais sur le CD/DVD/USB je me demande si ce ne serait pas inutilement ajouter de la complexité.
Bien sûr, l’installation “en mode expert” se fait très bien même en ne sachant pas répondre à toutes les questions en gardant les choix par défaut, mais la prolifération de celles-ci est-elle vraiment une bonne idée ? Et surtout je crains que ça ne suffise pas à calmer les “anti-systemd” les plus virulents, qui même si le choix est proposé reprocheront que SysV ne soit pas le choix par défaut…
[/quote]Il ne s’agit pas de calmer les virulents mais de ne pas énerver ceux qui se méfient de systemd. Si installer une debian avec sysvinit devient acrobatique, alors que Debian se flatte d’équiper tous les serveurs, ce serait un gros motif d’énervement.[quote]
Pour la partie SPOF (un processus unique qui si HS met tout le système en vrac), il est évident que si je n’ai rien contre l’adoption de systemd comme système d’init par défaut de la Debian stable, c’est à la condition que celui-ci soit solide comme un roc ! Mais finalement la même chose s’applique à SysV : si celui-ci est planté, qui va démarrer la machine ?[/quote]
Tu n’as pas un système de lancement mais une batterie de scripts qui se lance. Qu’il y en ait un qui plante c’est sur ça arrive, mais dans ce cas la machine est bancale certes mais elle démarre. Il m’est arrivé d’avoir des machines démarrant avec un disque en vrac, la moitié des services ne tournant pas mais restant accessible en ssh. Le systemd lui semble (d’après les messages relatant les soucis sur la DUF) tout planter d’un coup, un peu lorsque le svchost de windows explose. Tu ne peux rien faire à part pleurer. Pour systemd tu pourras toujours démarrer sur clef ou via init=/bin/bash mais 'est un peu rude.
[quote][…]
Sur une machine j’ai fait le test de migrer de SysV vers systemd, puis retour vers SysV. Ça fonctionne. D’où le fait que je trouve ces critiques au sujet de systemd qui serait imposé particulièrement malhonnêtes.
[/quote]La question consiste à savoir ce que fera un
apt-get dist-upgrade
Il semble que pour ne pas basculer sous systemd, il faudra faire des manoeuvres de «pinning» (en gros mettre les preferences à -1 sur les paquets systemd et/ou (?) installer systemd-shim. C’est ce qu’il se passe sous ubuntu trusty par exemple.
Par curiosité, on peut aller voir le code source de systemd. On y découvre des fichiers hwdb (hardware database, je suppose) qui pèsent assez lourds vu qu’ils contiennent “tous” les identifiants de matériels disponibles ! Au passage, certains identifiants sont enregistrés auprès de l’IEEE qui se dit à but non lucratif mais qui fait payer ces enregistrements. Un exemple typique : tous les modules wifi. Si j’ai bien compris, l’IEEE détient une sorte d’annuaire du matériel (chaque identifiant est unique) et les fabricants paient pour y être et/ou y rester. Avec le boom de l’internet des objets, je pense qu’il va y avoir un boom des transferts vers l’IEEE. Je me posais déjà des questions pour le web (les noms de domaines, tout ça) mais là, plus de doute possible. Quelque chose ne tourne pas rond… à mon humble avis.
Liens :
Code source : http://sources.debian.net/src/systemd/215-5/hwdb/
OUI http://standards.ieee.org/develop/regauth/oui/
systemd m’aura ouvert les yeux ! 
EDIT
Cette partie du code (hwdb) est hérité de udev qui a été englouti par systemd.
Dans ce cas rien de différent entre systemd et SysV : si un des scripts (ou “unit” pour systemd) se vautre, le démarrage se poursuit. Si le système d’init lui-même (PID 1) plante, le démarrage est dans les choux.
Rien de spécifique à systemd ici.
[quote=“fran.b”]La question consiste à savoir ce que fera un
apt-get dist-upgrade
Il semble que pour ne pas basculer sous systemd, il faudra faire des manoeuvres de «pinning» (en gros mettre les preferences à -1 sur les paquets systemd et/ou (?) installer systemd-shim. C’est ce qu’il se passe sous ubuntu trusty par exemple.[/quote]
C’est ce paquet qui s’en charge :
$ apt show init
Package: init
Source: init-system-helpers
Version: 1.21
Essential: yes
Installed-Size: 29,7 kB
Maintainer: pkg-systemd-maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>
Pre-Depends: systemd-sysv | sysvinit-core | upstart
Section: metapackages
Priority: required
Download-Size: 4 634 B
APT-Manual-Installed: yes
APT-Sources: http://ftp.fr.debian.org/debian/ testing/main amd64 Packages
Description: utilitaires init System-V-like - métapaquet
Ce méta-paquet essentiel permet de sélectionner un système d'init parmi
les trois disponibles dans Debian (systemd, sysvinit, upstart), tout en
assurant la disponibilité d'un de ces systèmes en continu.
À sa première installation (lors d’un dist-upgrade de Wheezy vers Jessie par exemple), il installera par le biais des dépendances systemd-sysv sauf si sysvinit-core ou upstart est installé.
Il suffira donc pour ne pas migrer vers systemd de précéder le dist-upgrade d’un [mono]apt-get install sysvinit-core[/mono].
Dans ce cas rien de différent entre systemd et SysV : si un des scripts (ou “unit” pour systemd) se vautre, le démarrage se poursuit. Si le système d’init lui-même (PID 1) plante, le démarrage est dans les choux.
Rien de spécifique à systemd ici.[/quote]
Si en fait, Sysv ne se constitue que d’un script simple faisant des appels des scripts, tu vois, tu ne penses qu’à plantage d’un script alors que je pense au plantage du système de lancement lui même. La simplicité de Sysv et surtout le fait qu’il ne fasse que ça minimise considérablement les risques, systemd lui même est un binaire assez complexe melant beaucoup de choses. S il plante, tout plante complètement. C’est ce que les expériences relatées sur la DUF semblent confirmer: Un truc qui se passe mal et le système lui même (et non un des scripts) explose.
Ok.
[quote]
Pour la partie SPOF (un processus unique qui si HS met tout le système en vrac), il est évident que si je n’ai rien contre l’adoption de systemd comme système d’init par défaut de la Debian stable, c’est à la condition que celui-ci soit solide comme un roc ! Mais finalement la même chose s’applique à SysV : si celui-ci est planté, qui va démarrer la machine ?
Il est tout aussi important à mon avis de pouvoir utiliser un autre système d’init si le besoin (ou l’envie) s’en fait sentir. C’est pour ça que ma machine secondaire à son passage en Jessie continuera à utiliser SysV : pour m’assurer que contrairement à ce que je vois affirmé un peu partout autour de moi systemd n’est pas incontournable sous Debian.[/quote]
Je n’ai jamais vu init planter! Il faut dire qu’init ne fait pas grand chose, c’est sa force
Pour le reste, je suis tout à fait d’accord avec toi: l’important est de pouvoir utiliser sysvinit.
Malgré tout, une peur défaitiste me fait craindre, comme beaucoup, que ce choix s’estompe dans le temps
À titre personnel, je rejoins plutôt les “anti-systemd”: systemd apporte beaucoup de risques (sur plein de niveaux), une courbe d’apprentissage non négligeable, des inconvénients clairement défini, et, sommes toute, peu d’avantages concrets
Autant je suis grandement intéressé par butterfs (qui lui aussi demande de l’apprentissage etc, mais qui donne de vrais et conséquents bénéfices), autant systemd me dégoute
Si seulement plus de personnes pouvait comprendre ça… Et surtout comprendre que c’est le cas !
(en tous cas sur Debian)
Si tu ne fais plus confiance aux développeurs de ta distribution, peut-être est-il temps d’en changer ?
C’est un fait, il gère bien plus de choses que l’init traditionnel, et a donc plus de raisons de planter et plus de surface d’attaque. Il est donc d’autant plus important que le code soit suivi et audité avec attention.
Pas un problème de mon point de vue. Ceux qui prétendent que l’apprentissage du fonctionnement de SysV est trivial sont de mauvaise foi.
Je pense que ce genre d’affirmation est biaisé quand avancé par une personne sachant déjà se servir de SysV : je n’ai jamais su écrire un script d’init SysV, mais il m’a fallu quelques minutes à peine pour écrire mes premières unit systemd.
Ben voyons, c’est sûrement pour cette raison qu’il est majoritairement adopté par les différentes distribution Linux…
[quote=“haleth”]
Autant je suis grandement intéressé par butterfs (qui lui aussi demande de l’apprentissage etc, mais qui donne de vrais et conséquents bénéfices), autant systemd me dégoute[/quote]
On n’est pourtant pas encore trolldi 
Utilisant au travail un très (trop d’ailleurs) grand nombre de distribution différente te de génération différente je n’ai jamais apprécié devoir apprendre un urgence un truc pour effectuer une réparation, modification ou correction.
Mais clairement le pseudo problème de systemd m’en touche une sans effleurer l’autre car je serais de toute façon obligé de le côtoyer régulièrement.
Pour ce qui est du BETTER FS, 
j’utilise régulièrement du ZFS donc … mais comme dit plus haut on n’est pas trolldi
C’est le cas, pour l’instant. Et j’ai confiance en Debian, c’est pour cela que je l’utilise, pour l’instant
Y’a quoi à savoir sur sysvinit ?
C’est tout.
Tu peux aussi comprendre les headers, mais ils ne sont pas obligatoire, ton truc va fonctionner.
[quote]
Ben voyons, c’est sûrement pour cette raison qu’il est majoritairement adopté par les différentes distribution Linux…[/quote]
Rhoo!
Si je prends la page wikipedia (fr.wikipedia.org/wiki/Systemd):
Bref, et c’est mon avis personnel, beaucoup de choses pour pas grand choses. Beaucoup de distributions sont passés à systemd (plus ou moins). M’enfin, ce n’est pas la première fois que système en remplace un autre dans Debian, par “erreur”. Pas vrai, avconv vs ffmpeg ?
[quote=“haleth”]Y’a quoi à savoir sur sysvinit ?
Il y a plus compliqué tout de même… Et surtout tu peux le tester avant de l’intégrer. Tu charges le squelette /etc/init.d/skeleton, tu remplis les variables du début et ça marche. Bien sur il se peut que ça ne soit pas un démon mais juste un script à lancer avant un instant précis, auquel cas tu modifies juste ce qu’il y a dans start et stop plus bas. C’est tout. Essaye tu verras je t’aiderai
Le seul avantage réel de systemd est le lancement à la demande (qui peut être utile sur une machine de bureau mais pas sur un serveur) et de rendre independant la création de la douille de communication du lancement du démon. Cela permet à un processus de ne pas attendre 1mn si syslogd n’est pas lancé. L’autre est de diminuer nettement le nombre de processus lancé: un système à base de sed, grep et autre awk lance un paquet de processus. Moi ça ne me gène pas mais les accros des concours de performance voudrait que le numéro du premier processus utilisateur soit inférieur à 1000 comme sur OS X par exemple. Est ce que ces avantages réels (outre l’aspect plus récent) justifient la concentration de plusieurs taches indépendantes en une seule, à mon avis non car ça fragilise le tout mais bon…
Je fais confiance à mon système, aussi. Il vaut mieux 
même si ça ne m’empêche pas de regarder ce qui se passe et de chercher à [strike]désobéir[/strike] comprendre.
Le choix entre systemd et systemv-init me semble être d’un autre niveau que celui entre KDE, Gnome, XFCE,… .
J’utilise toujours une Sid installée depuis belle lurette et sur laquelle je vois régulièrement passer des mises à jour de paquets systemd mais je n’ai constaté aucune différence (visuelle) au démarrage. P’t-être parce qu’il n’y a aucune raison que je voie quoique ce soit. 
Vous pouvez continuer la discussion comme si je n’étais pas là.
Le problème n’est pas quand tout va bien. Si UNIX a développé les deux principes «KISS» et «One task, one program» c’est pour simplifier la vie et limiter les dégats quand un programme a un bug (le problème n’est jamais de savoir si il y a un bug mais où est le bug). sysinit est donc juste constitué d’un script utilisant des programmes dits fondamentaux. Quand on compile grep par exemple, les fonctionnalités minimales attendues sont testéees, cela signifie que le remplacement de grep par une nouvelle version ne se fait que si les tests passent donc que le démarrage fonctionnent. systemd intègre tout en un y compris udev. Un bug de systemd (un seul programme compliqué donc au lieu de plusieurs dizaines simples) multiplie les conséquences, par contre il y a beaucoup moins de processus crées donc une plus grande rapidité.
Avec openwrt ui utilise aussi sysv le premier processus après les rcS est dans les numéro 1000 et ça monte très vite.
Lis cet article: linuxfr.org/news/%C3%A9volutions … de-systemd c’est un bon résumé des avantages de systemd même si c’est systemd au royaume de ToutVaBien où le dogme «efficacité=rapidité» est ce que le dogme «loi du marché=efficacité» dans le monde actuel. À mon avis les deux mènent dans le mur.