Bonjour,
Quand je lis ces discussions autour de systemd, je me revois quelques mois en arrière lorsque Python a pris la Branche 3.
Il y a presque autant de pour et de contre puis, au fil du temps … l’océan se calme peu à peu.
Personnellement, je suis enclin à faire un minimum de confiance aux développeurs et à tester, voir comment ça fonctionne et puis … on verra bien.
Mais chacun peut bien avoir son opinion personnelle. Et c’est tant mieux. C’est comme ça qu’on évolue 
A+
Pour ma part je pense que systemd est arrivé bien trop rapidement dans le monde linux. Par exemple, j’ai vu pas mal de messages sur différents chans IRC après le passage de jessie en stable et où la cause était clairement systemd.
Si j’étais sous debian, c’était aussi pour que les autres se ramassent sur les trucs nouveau et que moi je suive mon chemin tranquillement, quitte à avoir du retard.
De plus, j’ai vraiment vécu l’arrivée de systemd comme un contrainte et non comme un choix. J’ai donc préféré le refuser en bloc et rester avec mes habitudes de vieux con.
Par contre, il est clair que l’init sous linux avait (et a toujours) besoin d’un rafraîchissement. Ce que j’espère c’est que l’épisode systemd passera et que l’on aura de vraies alternatives qui feront avancer les choses. Mais bon, ça se saurait si les choses se passaient comme ça…
[quote=“Papy Octet”]Quand je lis ces discussions autour de systemd, je me revois quelques mois en arrière lorsque Python a pris la Branche 3.
Il y a presque autant de pour et de contre puis, au fil du temps … l’océan se calme peu à peu.[/quote]
Quelques mois ? Python 3 a plus de 6 ans… Et peine toujours à se faire adopter (même si effectivement ça se calme “un peu”).
[quote=“seb-ksl”][quote=“Papy Octet”]Quand je lis ces discussions autour de systemd, je me revois quelques mois en arrière lorsque Python a pris la Branche 3.
Il y a presque autant de pour et de contre puis, au fil du temps … l’océan se calme peu à peu.[/quote]
Quelques mois ? Python 3 a plus de 6 ans… Et peine toujours à se faire adopter (même si effectivement ça se calme “un peu”).[/quote]
Ok, python version 3 mais laquelle. Là on était 50 personnes à pythonner un petit pgm de 200 lignes. Bon, ben on a constaté que python 2.7, 3.2, 3.4 version pyzo 2014c et 3.4 version pyzo 2015a présentent des incompatibilités entre elles au point de rendre impossible la création d’un jeu de test commun. C’est franchement insupportable!! Tu m’étonnes que la version 3 ait du mal à s’imposer. Il s’agirait de préciser quelle version 3!
Mon but n’est certainement pas de relancer ces discussions interminables à propos de ces modifs de Python.
Je faisais allusion aux tsunamis de réactions qui sont apparu quand l’annonce de la sortie de Python 3 et des 'incompatibilités" qui allaient avoir lieu avec les versions précédentes (la branche 2.x).
À ce moment, ça tirait dans tous les sens. Certain critiquaient vertement, d’autres félicitaient cette arrivée.
Encore maintenant, bien des développeurs s’accrochent désespérément à des versions de la branche 2.x pour diverses raison qui leur sont propres et qui leur semble très justifiées. Et je respecte les chois de chacun.
Moi, dans pa toute petite sphère personnelle, je suis passé à la branche 3.x et je n’ai pas à m’en plaindre même si j’ai dû me mettre à corriger mes précédentes “créations”.
Mais je le répète, je suis dans une toute petite bulle bien personnelle.
systemd semble encore poser des problèmes et j’envisage très sérieusement d’installer Debian 8 en plus de 7 en multiboot sur une de mes machines pour voir.
Je suis aussi un “adepte” de Gnome ou plutôt je n’ai pas le courage, l’envie d’essayer autre chose.
Je lis mais respecte absolument les avis de chacun puis je me fais une opinion avant de tenter une action particulière. De toute façon, je n’ai ni les connaissances ni les compétences pour émettre un avis éclairé sur la chose. Mon niveau en programmation est à la limite des soubassements. Alors je m’instruis, j’essaie d’apprendre un peu plus sur la “chose” qui fâche 
Bonne journée à vous.
Ca éclairera sans doute sur les choix techniques de systemd, c’est tiré du blog de Lennart. Désolé, c’est en anglais:
0pointer.net/blog/revisiting-how … stems.html
Sauf erreur de ma part, l’objectif final est un contrôle qualité sur l’ensemble des distributions Linux, par un contrôle des versions des gros blocs logiciels. On est en droit de penser que c’est une erreur, la centralisation n’ayant pas été nécessaire à Linux pour être industrialisé (Cf Android par exemple), tandis que là, ce sont des modes de contrôle industriels qui tendent à être introduits dans le rassemblement des codes.
Trolls s’abstenir, je trouve que ce texte gagnait à être connu.
[quote=“dpascal”]J’ai lu quelque part que pour les bureaux que nous utilisons, on parlait d’un desktop-environment, et que pour systemd, on pouvait parler d’un system-environment.
Je suis assez d’accord avec ça. Bien sur que non, ce n’est pas qu’un système d’init.
Gnome3 + systemd + noyau Linux = ???-OS[/quote]
oui je tends à etre d’accord avec ca connaissant cent-os et fedo 21: je ne vois de vraies différences sauf yum. Et que debian est plus stable que fedo
Debian se windoïse en gros 
Ca fait maintenant quelques mois que j’utilise Arch et j’ai laissé “systemd” par défaut, justement pour tester, et parce qu’avec Arch je sais exactement ce que j’installe (l’installation n’est pas automatisé comme Debian, il faut créer le système de base à la main).
De mon expérience : “systemd” est une merde au quotidien pour le réseau.
Par défaut, “systemd” s’occupe d’attribuer des IP et des routes à ma carte Ethernet, alors que je n’ai jamais rien demandé. Ainsi, lorsque je commence à installer NetworkManager, les modules de “systemd” interfèrent avec NetworkManager et c’est le bordel, je ne sais plus ce que je fais. Du coup lorsque ça marche je remercie le Ciel et je ne touche plus à rien, de peur de perdre mon réseau et de devoir passer des nuits entières sur le manuel de “systemd”.
Alors vous allez me dire qu’il faut que je lise le manuel, toussa, mais c’est justement ce que je reproche à “systemd” : je ne suis pas censé lire le manuel du système d’init pour savoir comment déconfigurer mon réseau. Je ne veux pas que mon système d’init fasse autre chose que s’occuper de l’init, à moins que je ne lui demande explicitement (je vous rappelle que je suis sous Arch, normalement rien ne peut s’auto-configurer le temps qu’on ne le demande pas au système). Or, “systemd” prend l’initiative de toucher à des trucs qui ne le regarde pas. Demander au système d’init de prendre en charge (automatiquement !) le réseau, c’est comme demander à NetworkManager de s’occuper automatiquement de la gestion des services. C’est con, c’est stupide et c’est sale.
“systemd” rend la vie plus facile dans la gestion des services. On active/désactive un service en une ligne de commande, par exemple. Mais cette facilité se fait au coût de la propreté du système. Elle se fait également au prix d’un apprentissage de cet outil. Si on n’a pas lu le manuel, bon courage. Il y a des tutos entiers sur linuxfr.org pour expliquer comment faire plein de trucs qui étaient bien plus simples à faire avec un système compatible POSIX.
Bref, j’ai délaissé Debian pour Arch sur mon PC quotidien (mon serveur continuera à utiliser Debian pour la stabilité, mais Arch est finalement très stable aussi, je vais peut être quand même y passer sur mon serveur) car je n’étais plus en accord avec la philosophie de Debian. Debian aurait dû rester compatible POSIX par défaut (le plus possible), avec “systemd” en option pour ceux que ça intéressent. Donc quitte à devoir supporter “systemd”, je préfère une distribution qui l’assume et l’affiche clairement d’entrée de jeu, plutôt que de se fourvoyer. “systemd” est venu foutre la merde dans quelque chose qui fonctionnait bien et était simple à maintenir. Aujourd’hui j’ai l’impression de me retrouver face à une boîte noire que je ne comprendrai que lorsque j’aurai lu tout le manuel, tout ça pour désactiver proprement (et en comprenant pleinement ce que je fais) la configuration automatique de mon réseau.
En conclusion : “systemd” ça va me faire comme Internet Explorer, je ne vais l’utiliser que pour installer autre chose à la place. 
J’ai pas du tout la même conception de systemd.
J’ai écrit un script sysvinit et fait une “unit” systemd pour un truc qui doit marcher sur Wheezy ou Jessie.
Eh bien sysvinit c’est vraiment les années 90 : il se contente d’exécuter ton script sans intelligence ni suivi.
Il faut faire toutes les étapes : démarrage, arrêt, vérification du statut… du coup y’a bien une page entière juste pour ça.
Même sur Windows c’est mieux fait.
Tandis que systemd c’est simple, ton “unit” fait quelques lignes et il sait quand c’est censé être lancé ou non.
Je suis bien content qu’en 2015 on ait enfin un truc moderne.
En plus c’est unifié avec les distributions.
[quote=“Obidoub”]J’ai pas du tout la même conception de systemd.
J’ai écrit un script sysvinit et fait une “unit” systemd pour un truc qui doit marcher sur Wheezy ou Jessie.
Eh bien sysvinit c’est vraiment les années 90 : il se contente d’exécuter ton script sans intelligence ni suivi.
Il faut faire toutes les étapes : démarrage, arrêt, vérification du statut… du coup y’a bien une page entière juste pour ça.[/quote]C’est ce qui en fait l’intérêt.
[quote]
Même sur Windows c’est mieux fait.
[/quote]Non, ce qui tu considères comme un plus peut être vu comme un moins, ça n’est pas la même chose.[quote]
Tandis que systemd c’est simple, ton “unit” fait quelques lignes et il sait quand c’est censé être lancé ou non.
Je suis bien content qu’en 2015 on ait enfin un truc moderne.
En plus c’est unifié avec les distributions.[/quote]
Le mieux c’est donc un truc uniforme décidant complètement ce qui doit être fait sur ta machine. C’est le même bazar qui s’occupe de la gestion des mots de passe, de cron, du lancement des réseaux et de la gestion des imprimantes. Bientôt il fare le café!
Pour l’unification, le mieux est de se limiter à un traitement de texte, un bureau, un gestionnaire de réseau, un… bref une seul distribution avec une seule configuration. Ça existe, c’est Mac ou Windows par exemple.
Non. Ecrire 3 pages de scripts pour un truc basique devrait être géré directement par le système d’init. Aucun intérêt à faire ça à la main.
C’est indéniablement plus intelligent car le gestionnaire de services de Windows est au moins capable de savoir si son service est démarré ou pas. sysvinit s’en cogne il exécute le script même s’il est faux. Et si ton script de vérification (status) est faux, il te dira qu’il tourne alors que non, ou inversement. Cela n’arrive pas avec systemd.
[quote=“fran.b”]
Le mieux c’est donc un truc uniforme décidant complètement ce qui doit être fait sur ta machine. C’est le même bazar qui s’occupe de la gestion des mots de passe, de cron, du lancement des réseaux et de la gestion des imprimantes. Bientôt il fare le café!
Pour l’unification, le mieux est de se limiter à un traitement de texte, un bureau, un gestionnaire de réseau, un… bref une seul distribution avec une seule configuration. Ça existe, c’est Mac ou Windows par exemple.[/quote]
Là tu entre dans le FUD, mais depuis toutes ces années on est habitués. J’étais persuadé que Systemd était maléfique jusqu’au jour où j’ai du me plonger dedans, et surtout dans sysvinit.
Cela me saoule déjà de maintenir un paquet pour 2 versions d’une même distribution, alors si tout le monde pouvait s’unifier un minimum ce serait sympa. 2015 quoi… On est plus au temps d’UNIX.
Non. Ecrire 3 pages de scripts pour un truc basique devrait être géré directement par le système d’init. Aucun intérêt à faire ça à la main.[/quote]C’est là où tu te trompes. La mise au point de clefagreg a demandé une modification de beaucoup de script de démarrage, absolument impossible sous sytemd.[quote]
C’est indéniablement plus intelligent car le gestionnaire de services de Windows est au moins capable de savoir si son service est démarré ou pas. sysvinit s’en cogne il exécute le script même s’il est faux. Et si ton script de vérification (status) est faux, il te dira qu’il tourne alors que non, ou inversement. Cela n’arrive pas avec systemd.[/quote]Là encore c’est un point de vue. Tu as deux problèmes distincts, lancer les démons et vérifier qu’ils tournent selon les désirs du programmeur. Il est étonnant que tu envisages une erreur des scripts de sysinit sans envisager une de systemd (par exemple systemd ne prend pas en compte /etc/default, systemd ne semble pas avoir une politique claire dans le lancement d’openvpn, etc). Il n’est à l’heure actuelle pas envisageable de passer clefagreg sous systemd par exemple…
[quote]
[quote=“fran.b”]
Le mieux c’est donc un truc uniforme décidant complètement ce qui doit être fait sur ta machine. C’est le même bazar qui s’occupe de la gestion des mots de passe, de cron, du lancement des réseaux et de la gestion des imprimantes. Bientôt il fare le café!
Pour l’unification, le mieux est de se limiter à un traitement de texte, un bureau, un gestionnaire de réseau, un… bref une seul distribution avec une seule configuration. Ça existe, c’est Mac ou Windows par exemple.[/quote]
Là tu entre dans le FUD, mais depuis toutes ces années on est habitués. J’étais persuadé que Systemd était maléfique jusqu’au jour où j’ai du me plonger dedans, et surtout dans sysvinit.
Cela me saoule déjà de maintenir un paquet pour 2 versions d’une même distribution, alors si tout le monde pouvait s’unifier un minimum ce serait sympa. 2015 quoi… On est plus au temps d’UNIX.[/quote]
UNIX est un système dont les principes fondamentaux (dont le fameux KISS et le principe un programme une tache) ont assuré la fiabilité depuis 1980. Abandonner ces principes me parait dangereux. Mais le souci n’est pas là. À la question:
systemd est-il seulement un système d’init ?
la réponse est clairement non.
À la question
faut-il maintenir un système de démarrage simple type sysinit dans la liste des posssibilités?
la réponse est clairement oui, ne serait ce que par les nombreuses polémiques soulevées par systemd.
[quote=“Obidoub”]
Il faut faire toutes les étapes : démarrage, arrêt, vérification du statut… du coup y’a bien une page entière juste pour ça.[/quote]
Tu te fout pas un peu du monde toi ?
Pour le démarrage et l’arrêt, tu utilises start-stop-daemon (et c’est tout).
Pour la vérification du statut, tu utilises status_of_proc (et c’est tout).
Pour les messages avec couleur, tu utilises log_begin_msg et log_end_msg (et c’est tout).
Le fait que tu puisses tout écrire à la main ne signifie pas que tu dois tout écrire à la main.
[quote=“Obidoub”]
Cela me saoule déjà de maintenir un paquet pour 2 versions d’une même distribution, alors si tout le monde pouvait s’unifier un minimum ce serait sympa.[/quote]
Ha ?
Je maintiens des paquets pour 2 architectures et 3 versions de Debian.
1 paquet pour 6 distributions.
Je comprends ce point de vue et c’est d’ailleurs aussi (plus ou moins) le mien. Le problème de ‘systemd’ c’est qu’il ne se contente pas d’offrir une API pour simplifier tout ça, il embarque aussi des tas de trucs qu’un système d’init n’est pas censé faire.
Le fait que ça rende les choses a priori plus simples est aussi ce qui les rend bien plus compliquées dès qu’on souhaite aller plus loin. C’est le paradigme qu’a adopté Windows (tout intégrer) et ce n’est pas ce qui a fait la force des *NIX. Chaque élément est censé remplir un rôle bien définit et ne s’occuper que de ça.
Pour tenter de faire diversion, Pottering a placé chaque fonctionnalité de ‘systemd’ dans des binaires séparés. Comme ça à chaque fois qu’on lui dit que les *NIX reposent sur des binaires spécialisés, il répond “Ah vous aussi vous n’avez rien compris et vous n’avez pas regardé le code source. Vous auriez vu que les binaires sont séparés et remplissent une fonction bien définie.”. Ce qui est soit de la mauvaise foi incroyable, soit de la connerie brute de fonderie, puisque les binaires ne peuvent pas fonctionner indépendamment des uns des autres.
Avec ‘systemd’ c’est tout le paradigme UNIX qui est remis en cause. Pas seulement parce qu’il casse la compatibilité avec les normes POSIX (même si c’est déjà dur à avaler), mais également parce que l’approche adoptée va à l’encontre de ce qui a fait le succès des *NIX au fil des ans. Certains développeurs ont cette manie de vouloir sans cesse reprendre les vieux trucs qui marchent bien pour les refaire en moins bien, sous prétexte que c’est vieux et donc pas moderne, quand bien même ils ont faits leurs preuves.
C’est probablement le seul réel avantage de ‘systemd’.
[quote]Là tu entre dans le FUD, mais depuis toutes ces années on est habitués. J’étais persuadé que Systemd était maléfique jusqu’au jour où j’ai du me plonger dedans, et surtout dans sysvinit.
Cela me saoule déjà de maintenir un paquet pour 2 versions d’une même distribution, alors si tout le monde pouvait s’unifier un minimum ce serait sympa. 2015 quoi… On est plus au temps d’UNIX.[/quote]
Voilà pourquoi ‘systemd’ aurait dû se contenter de proposer une API pour unifier la gestion ses services, et rien d’autre. Ca aurait été bien plus intelligent, tout le monde aurait été content et on aurait pu conserver le système de démarrage propre à chaque distribution. C’est d’ailleurs un peu l’approche d’OpenRC (reste qu’OpenRC gagnerait à avoir une API plus simple car c’est encore loin d’être intuitif, faut reconnaître).
[quote]Tu te fout pas un peu du monde toi ?
Pour le démarrage et l’arrêt, tu utilises start-stop-daemon (et c’est tout).
Pour la vérification du statut, tu utilises status_of_proc (et c’est tout).
Pour les messages avec couleur, tu utilises log_begin_msg et log_end_msg (et c’est tout).
Le fait que tu puisses tout écrire à la main ne signifie pas que tu dois tout écrire à la main.[/quote]
Eh oui. RTFM, on le dira jamais assez ! 
EDIT : j’entends souvent “Si ça n’existe pas, code-le.” mais je pense que c’est une connerie. Dans 99 % des cas, on devrait dire “Si ça n’existe pas, c’est que tu as mal cherché.”…
Même système d’init il a un peu de mal à le faire.
Sous Stretch, [mono]shutdown -h +60[/mono] reboot… immédiatement !
En cause, un segfault dans systemd : github.com/systemd/systemd/issues/1120
Édit : heureusement, sous Sid c’est déjà réparé.
[quote=“haleth”][quote=“Obidoub”]
Il faut faire toutes les étapes : démarrage, arrêt, vérification du statut… du coup y’a bien une page entière juste pour ça.[/quote]
Tu te fout pas un peu du monde toi ?
Pour le démarrage et l’arrêt, tu utilises start-stop-daemon (et c’est tout).
Pour la vérification du statut, tu utilises status_of_proc (et c’est tout).
Pour les messages avec couleur, tu utilises log_begin_msg et log_end_msg (et c’est tout).
Le fait que tu puisses tout écrire à la main ne signifie pas que tu dois tout écrire à la main.
[/quote]
Je me suis basé sur les scripts de “gros” projets (nginx, ntpd) qui utilisent tout ce que tu dis. Et même avec ça, il y a plus d’une page.
[quote]
Vu que toutes les distributions passent à systemd j’imagine qu’une grosse majorité des mainteneurs sont pour.
[quote=“Obidoub”]
Vu que toutes les distributions passent à systemd j’imagine qu’une grosse majorité des mainteneurs sont pour.[/quote]
Oulala, rien n’est moins sur !
C’est de la politique : ne pense pas qu’à chaque décision politique, il y a “une grosse majorité des gens qui sont pour”
[quote=“haleth”][quote=“Obidoub”]
Vu que toutes les distributions passent à systemd j’imagine qu’une grosse majorité des mainteneurs sont pour.[/quote]
Oulala, rien n’est moins sur !
C’est de la politique : ne pense pas qu’à chaque décision politique, il y a “une grosse majorité des gens qui sont pour”[/quote]
Le choix de Debian de passer à systemd a été décidé suite à un vote, non ?
De plus comme les décideurs sont aussi ceux qui bossent pour de vrai dans la vie réelle (pas comme la politique), pourquoi choisiraient-il un truc mauvais ? Ils n’ont rien à y gagner.
Un vote représenté par Ubuntu et Red Hat.
Comme pour les politiques : du pouvoir et de l’argent. Les entreprises voient l’open source comme un bon moyen d’économiser des coûts et augmenter leurs marges, rien de plus. Rares sont les entreprises qui considèrent l’open source comme une philosophie à maintenir coûte que coûte (et le libre n’en parlons pas).
Partant de là, ce qui guide leurs choix n’est pas ce qui est le mieux techniquement, mais ce qui rapporte le plus à l’entreprise (ou lui coûte le moins cher). Avoir un système de démarrage qui inclut en fait tout le reste (réseau, chiffrement, etc.) permet d’intégrer plus facilement tout ce bazar dans une ROM, qu’on va ensuite signer numériquement et mettre dans une tablette ou un smartphone. Peu importe comment c’est fait, ça fonctionne en 3 coups de cuillère à pot, c’est tout ce qui compte. Et rien à foutre que ce soit taillé pour nos tablettes et que ça casse complètement les normes POSIX, nous on en a rien à foutre de POSIX, on est là pour se faire du fric. Voilà en gros.
Linus Torvald a déjà passé 3 jours pour gagner 400 cycles CPU. Des gars comme Pottering considèrent que ce genre de trucs n’est pas important. Or c’est ce qui a fait le succès technique d’UNIX/Linux, c’est la qualité du code, le souci du détail, et le respect des standards (séparation des logiciels pour chaque tâche donnée, respect des normes POSIX le plus possible, etc.). Torvald répète à l’envie que si Linux a connu un tel succès, c’est parce qu’il est bien fait, que tout est travaillé dans le détail. Et franchement je ne pourrais pas être plus d’accord avec lui.
Voilà pourquoi ‘systemd’ est une aberration pour moi.