Discussion :

[Tryph]

Debian a de fortes chances d'être rempli de failles exprès via la NSA et autres. De nombreuses failles étaient présentes dans Debian (par exemple la faiblesse des clés générées) contrairement à d'autres distributions, permettant facilement à la NSA de rentrer dans tous les Debian installés.
[...]
La mise en place du réseau est encore un autre problème qui encore aujourd'hui dans Debian, est buggé au possible, et juste inutilisable.
[...]

he ben, faut aller prévenir toutes les entreprises qui ont des serveurs sous Debian des dangers qu'ils courent à utiliser une telle distribution.

les distributions maintenant, par défaut, vous mettent tout dans une partition racine plus un home : une hérésie totale de nos jours et une catastrophe attendant de se produire.

je ne suis pas un expert de ton niveau (en tout cas je ne me prétend pas détenteur de la vérité absolue comme toi) mais je n'ai encore jamais vu une distribution Gnu/Linux qui ne permette pas de faire le partitionnement exactement comme on le veut...
bon j'ai pas essayé des centaines de distribution, tout juste 5 ou 6, mais j'en pas vu une seule qui impose de faire seulement 2 partitions (un pouur le home et une pour le reste).
tu veux bien nous expliquer de quelles distributions tu parles?


sinon, c'est con t'as l'air d'avoir quelques connaissances, mais y a quelques aspect de ta diatribe qui ruinent complètement ta crédibilité:
- les jugements à l'emporte pièce sans la moindre justification
- le manichéisme (beaucoup en font preuve, c'est pas juste un de tes travers, mais ça fait un peu fan-boy de dire "systemd c'est le messi, tout ce qui a existé avant n'était que succession de merde)
- l'égo surdimensionné (les "moi je sais" toutes les 3 lignes, les "ceux qui ne pensent pas comme moi sont des ignorant" régulièrement. c'est peut être la vérité, mais le répeter comme un lietmotiv tout au long de ton texte, on dirait que tu essaies de te convaincre toi même)
- pas un mot sur les véritables problèmes de systemd qui ont été évoqué ici

[Ookaze]

he ben, faut aller prévenir toutes les entreprises qui ont des serveurs sous Debian des dangers qu'ils courent à utiliser une telle distribution.

Tu n'as absolument rien compris à ce que j'ai écrit, il est évident que tu n'es pas un administrateur. On parle de faire des choses comme reconfigurer le réseau d'une quelconque façon alors que l'on a qu'une session SSH pour administrer. Mais bon, tu ne comprendras pas plus et ce n'est pas grave, ceci ne t'était pas destiné mais tu t'es senti obligé de répondre sans être concerné et sans comprendre.

je ne suis pas un expert de ton niveau (en tout cas je ne me prétend pas détenteur de la vérité absolue comme toi) mais je n'ai encore jamais vu une distribution Gnu/Linux qui ne permette pas de faire le partitionnement exactement comme on le veut...
bon j'ai pas essayé des centaines de distribution, tout juste 5 ou 6, mais j'en pas vu une seule qui impose de faire seulement 2 partitions (un pouur le home et une pour le reste).
tu veux bien nous expliquer de quelles distributions tu parles?

Le problème est que tu n'as pas compris ou bien tu as zappé les deux petits mots "par défaut" qui se trouvaient dans la phrase.
Il est toujours possible de partitionner autrement, mais reste assuré que le niveau de compétence alors demandé va bien au-delà de ce que même un administrateur de base connaît. Et je parle des distributions Debian et Red Hat/Fedora.

- pas un mot sur les véritables problèmes de systemd qui ont été évoqué ici

Je passe les attaques ad hominem, je n'ai pas le temps pour ces gamineries, surtout que tu n'as aucune autorité pour me juger, et que tu es libre de rester dans ton incompréhension totale de ce qui se passe autour de systemd.
Aucun problème de systemd n'a été évoqué ici. Et c'est le cas la plupart du temps dans ces discussions.
Il y a bien eu des hypothèses avec des "si" et des trucs complètement farfelus, ou pire, des vrais problèmes mais dus en fait à la distribution et pas à systemd, montrant que leur auteur ne sait pas faire la différence et donc n'est pas qualifié pour critiquer systemd dans ce cas (faire des rapports de bug c'est difficile, d'autant plus quand on ne maîtrise pas le sujet).
J'aimerai bien voir des cas concrets de problèmes, mais les seuls que j'ai vu jusqu'ici, des vrais problèmes, c'est sur la ML des dev de systemd que je les ai vus. Et ils sont pris en compte lorsqu'ils sont pertinents. Un grand nombre de fonctionnalité ajoutées à systemd (que certains disent trop complexe) viennent de la nécessité de régler ces vrais problèmes pour des utilisateurs.

[vohufr]

J'aimerai bien voir des cas concrets de problèmes, mais les seuls que j'ai vu jusqu'ici, des vrais problèmes, c'est sur la ML des dev de systemd que je les ai vus. Et ils sont pris en compte lorsqu'ils sont pertinents. Un grand nombre de fonctionnalité ajoutées à systemd (que certains disent trop complexe) viennent de la nécessité de régler ces vrais problèmes pour des utilisateurs.

Du concret ? et bien, sur 7 PC, 4 ne s'éteignaient plus depuis le passage à systemd.
Un autre (sur lequel je gardais systemd pour surveiller) faisait une "analyse LSB" à chaque démarrage après une maj, sans aucune raison. Et ça durait 4 minutes !
Après une mise à jour sur le PC suivant, même chose. J'ai donc dégagé systemd de mes portables et PC de bureau. Depuis, plus de problème.
J'ai une machine virtuelle sur laquelle je testais le futur jessie pour mon serveur, Systemd est soit-disant compatible avec les vieux scripts sysV. J'ai un script qui lance des machines virtuelles selon les postes connectés ou non. J'étais obligé de le lancer à la main car si non, il se lançait 2 fois.

J'ai essayé systemd et pour toutes ces raisons + le fait de ne pas avoir le choix + que ça ne colle pas avec la philosophie DEBIAN, je ne veux pas/plus de systemd sur mon serveur ni ailleurs. Ca ne fonctionne pas encore correctement et il n'y a pas de recul pour une DEBIAN STABLE digne de ce nom !

Ce fork dont la plupart des adorateur systemd affichent une mort avant la naissance est une bonne chose. Je lis tous les jours leur mailing liste, et je trouve que ça avance, et que ça discute de choses importantes aussi ! Si ce fork devient un echec. Il reste slackware et les BSD !

Personne n'est contre une évolution des outils d'init, mais pas comme le propose systemd.

Tu peux dire ce que tu veux et insulter tout le monde de débile aussi. Ca changera rien.

[Tryph]

Tu n'as absolument rien compris à ce que j'ai écrit, il est évident que tu n'es pas un administrateur. On parle de faire des choses comme reconfigurer le réseau d'une quelconque façon alors que l'on a qu'une session SSH pour administrer. Mais bon, tu ne comprendras pas plus et ce n'est pas grave, ceci ne t'était pas destiné mais tu t'es senti obligé de répondre sans être concerné et sans comprendre.

effectivement je ne suis pas administrateur système (en même temps c'est écrit "Développeur informatique" juste son mon pseudo, c'était pas difficile à deviner), pas professionnellement en tout cas, je me contente d'administrer mon serveur perso sous... Debian (faut que je pense à changer un de ces jours pour éviter de me faire voler mes photos par la CIA )

Le problème est que tu n'as pas compris ou bien tu as zappé les deux petits mots "par défaut" qui se trouvaient dans la phrase.
Il est toujours possible de partitionner autrement, mais reste assuré que le niveau de compétence alors demandé va bien au-delà de ce que même un administrateur de base connaît. Et je parle des distributions Debian et Red Hat/Fedora.

le niveau de compétence pour faire un partitionnement custom va bien au delà des compétences d'un administrateur de base...? bah bordel...
c'est quoi un administrateur de base? un gars qui se contente de cliquer sur suivant à chaque étape d'une install sans rien customiser?
parce que bien que n'étant pas administrateur pro, je n'ai jamais connu d'échec en cherchant à me faire un partionnement custom.
juste pour que tu nous fasse profiter de tes grandes connaissances, tu mettrais quoi toi comme partionnement par défaut?

Je passe les attaques ad hominem, je n'ai pas le temps pour ces gamineries, surtout que tu n'as aucune autorité pour me juger, et que tu es libre de rester dans ton incompréhension totale de ce qui se passe autour de systemd.

les attaques ad hominem... comme tu y vas.
tu t'es senti offensé à la lecture de "égo surdimensionné" sans doute?
imagine ce que doivent ressentir les gens qui te lisent et qui sont qualifiés d'ignorants toutes les 3 ou 4 phrases. tu estimes donc que tu as autorité pour juger les autres toi.
pas le temps pour ces gamineries hein... pas le temps de prendre un peu de recul sur ce que tu écris non plus visiblement

Aucun problème de systemd n'a été évoqué ici. Et c'est le cas la plupart du temps dans ces discussions.
Il y a bien eu des hypothèses avec des "si" et des trucs complètement farfelus, ou pire, des vrais problèmes mais dus en fait à la distribution et pas à systemd, montrant que leur auteur ne sait pas faire la différence et donc n'est pas qualifié pour critiquer systemd dans ce cas (faire des rapports de bug c'est difficile, d'autant plus quand on ne maîtrise pas le sujet).
J'aimerai bien voir des cas concrets de problèmes, mais les seuls que j'ai vu jusqu'ici, des vrais problèmes, c'est sur la ML des dev de systemd que je les ai vus. Et ils sont pris en compte lorsqu'ils sont pertinents. Un grand nombre de fonctionnalité ajoutées à systemd (que certains disent trop complexe) viennent de la nécessité de régler ces vrais problèmes pour des utilisateurs.

puisque tu as l'air de bien connaitre systemd, dis moi si les assertions suivantes sont des fantasmes (c'est possible mais tu n'en as pas parlé pour le moment et, pour moi, ce sont des gros problème de systemd):
- avec systemd, on perd en modularité: on ne peut pas remplacer un certain nombre de composants lancés au boot (comme c'était le cas avec sysv) car systemd est un gros paquet qui intègre plein de fonctionalité prévues pour fonctionner ensemble et pas avec autre chose
- systemd étant un gros ensemble de fonctionalité, il est de facto plus sujet à disfonctionnement qu'un simple programme qui fait une seule chose. toutes les fonctionalités de systemd étant liées, le disfonctionnement d'une de ces fonctionnalité peut impacter les autres fonctionalités (ce qui n'est pas le cas avec sysv qui se contente de lancer des taches automones). et donc on peut éventuellement perde en stabilité.

dis moi si je me trompe, je suis un peu ignorant... mais je comprends vite... mais faut m'expliquer longtemps

[quicky2000]

Regardez logind (fait partie des outils fournis par systemd) : cela fait plus de 10 ans qu'on demande de partout des API pour implémenter le multiseat. Logind est la seule implémentation qui le permette, grâce aux fonctions de systemd. Les DE n'ont d'autre choix que d'utiliser celui-ci puisque c'est la seule implémentation viable aujourd'hui.

Salut,

Comme je n y connais pas grand chose dans tout ca et que le mot multiseat ne me parlait pas j ai fait une petite recherche et je suis tombe sur cette page wikipedia :
https://en.wikipedia.org/wiki/Multiseat_configuration
Il n y a pas un mot sur systemd et il semble que des solutions existent.
Est ce que la page n est pas a jour ?
est ce que les solutions existantes sont comparables a ce que propose systemd ?
quelle est ton opinion la dessus ?

[Ookaze]

Salut,

Comme je n y connais pas grand chose dans tout ca et que le mot multiseat ne me parlait pas j ai fait une petite recherche et je suis tombe sur cette page wikipedia :
https://en.wikipedia.org/wiki/Multiseat_configuration
Il n y a pas un mot sur systemd et il semble que des solutions existent.
Est ce que la page n est pas a jour ?
est ce que les solutions existantes sont comparables a ce que propose systemd ?
quelle est ton opinion la dessus ?

Question tout à fait pertinente. Si tu as lu le passage concernant GNU/Linux, tu auras vu que ce sont de vieilles méthodes, qui imposent d'utiliser de vieilles versions buggées de XOrg, qui imposent d'utiliser des outils dont certains n'existent même plus (en tout cas via les liens fournis dans l'article, certains sont morts, et pas des moindres comme MDM), mais surtout tu verras la galère que c'était pour mettre tout ça en place. Il suffit de regarder les howtos et les conditions à la mise en oeuvre, ainsi que les limitations.
En bref, cet article n'est tout simplement pas à jour sur ce qui se fait de mieux en la matière sous Linux (mais ce n'est pas une nouveauté sur Wikipedia). Parce que bon, l'amélioration du multiseat avec systemd ça date quand même de 2012. Cet article de Phoronix de l'époque résume bien la situation : http://www.phoronix.com/scan.php?pag...multiseat_kick .
Tu noteras qu'une des principales raisons de l'ajout des drivers DisplayPort récemment dans le noyau, c'est pour supporter les configurations multiseat, KMS règle aussi ces problèmes, et avec une console en userspace (seuls les devs de kmscons et de systemd se sont attelés à la tâche) on finira de régler les derniers problèmes. Depuis cet article Wikipedia, même XOrg a implémenté des fonctions pour améliorer le support du multiseat. Wayland le supporte d'office.
Avec systemd (et pulseaudio, etv un XOrg assez récent ou un Wayland, et les dernières fonctions du noyau Linux), tu plugges et ça marche tout seul. C'est tout l'intérêt d'un init comme systemd qui prend en compte que de nos jours, tout est géré dynamiquement sur Linux, en particulier au niveau du noyau. Donc quand le userspace ne sait pas gérer, c'est une galère.

[quicky2000]

Question tout à fait pertinente. Si tu as lu le passage concernant GNU/Linux, tu auras vu que ce sont de vieilles méthodes, qui imposent d'utiliser de vieilles versions buggées de XOrg, qui imposent d'utiliser des outils dont certains n'existent même plus (en tout cas via les liens fournis dans l'article, certains sont morts, et pas des moindres comme MDM), mais surtout tu verras la galère que c'était pour mettre tout ça en place. Il suffit de regarder les howtos et les conditions à la mise en oeuvre, ainsi que les limitations.

Oui c est ce qu il me semblait avoir compris

En bref, cet article n'est tout simplement pas à jour sur ce qui se fait de mieux en la matière sous Linux (mais ce n'est pas une nouveauté sur Wikipedia). Parce que bon, l'amélioration du multiseat avec systemd ça date quand même de 2012.

Ca vaudrait peut etre le coup de mettre un ou deux mots sur systemd avec les references qui vont bien pour ceux qui souhaiteraient approfondir non ?

Cet article de Phoronix de l'époque résume bien la situation : http://www.phoronix.com/scan.php?pag...multiseat_kick .
Tu noteras qu'une des principales raisons de l'ajout des drivers DisplayPort récemment dans le noyau, c'est pour supporter les configurations multiseat, KMS règle aussi ces problèmes, et avec une console en userspace (seuls les devs de kmscons et de systemd se sont attelés à la tâche) on finira de régler les derniers problèmes. Depuis cet article Wikipedia, même XOrg a implémenté des fonctions pour améliorer le support du multiseat. Wayland le supporte d'office.
Avec systemd (et pulseaudio, etv un XOrg assez récent ou un Wayland, et les dernières fonctions du noyau Linux), tu plugges et ça marche tout seul. C'est tout l'intérêt d'un init comme systemd qui prend en compte que de nos jours, tout est géré dynamiquement sur Linux, en particulier au niveau du noyau. Donc quand le userspace ne sait pas gérer, c'est une galère.

Ok merci pour les infos

[Stéphane le calme]

Les développeurs Debian appelés à voter pour juger de leur intérêt pour « la diversité du système init »,
cinq ans après le vote qui a conduit à l'adoption de systemd

En 2014 a eu lieu un vote à l'issue duquel systemd, le démon init qui a été l'objet de débats houleux, a été adopté par Debian. En effet, en février 2014, le comité technique en charge de Debian avait décidé que pour la prochaine version majeure de l’OS, systemd serait utilisé comme système d’initialisation par défaut. Cependant, systemd était rejeté par certains membres de la communauté open source, qui estimaient que le projet allait à l’encontre de la philosophie Unix et que ses développeurs ont un comportement anti-Unix, du fait que systemd est incompatible avec tous les systèmes non Linux.

Des administrateurs utilisant Debian ont menacé en octobre 2014 de forker Debian Jessie si systemd venait à être utilisé par défaut. Quelques semaines après, quatre membres éminents de la communauté Debian ont démissionné de leur fonction ou ont réduit leur participation. Colin Watson et Russ Allberry, deux membres du comité technique du projet Debian, ont annoncé respectivement leur démission le 8 et le 16 novembre 2014.

Suite à toutes ces pressions, un autre vote avait été initié par le comité technique en ce qui concerne systemd avant que les fonctionnalités qui seront proposées dans « Jessie » ne soient gelées. Plusieurs options (au total cinq) ont été proposées pour la résolution du conflit. Ian Jackson, un membre du comité technique avait proposé l’adoption d’un couplage des systèmes d’initialisation, arguant que les paquets Debian n’ont pas, en général, besoin d’un système d’initialisation spécifique, et qu’il fallait adopter une directive technique pour obliger cela, sauf dans des cas individuels justifiés. Un autre développeur a proposé que la prise en charge d’autres systèmes d’initialisation soit recommandée, mais pas obligatoire.

Finalement, l’utilisation de systemd comme prévu initialement a été maintenue. Les résultats du vote ont été publiés en novembre 2014.

Cinq ans plus tard, Debian a lancé un nouveau vote pour juger de l'intérêt pour « la diversité du système init » et à quel point les développeurs Debian se soucient (ou non) de soutenir des alternatives à systemd.

En raison des opinions divergentes des développeurs Debian sur la gestion des bogues non-systemd en 2019 et de l'intérêt / de l'engagement à soutenir les alternatives systemd dans le cadre du packaging Debian et de divers points de friction connexes, ils cherchent à adopter une nouvelle résolution générale sur la pondération de la diversité du système init.

Après les commentaires du public, les huit options de vote par les développeurs Debian incluent :

• Choix 1: F: Focus sur systemd.
• Choix 2: B: Systemd mais nous soutenons l'exploration d'alternatives.
• Choix 3: A: La prise en charge plusieurs systèmes d'initialisation est importante.
• Choix 4: D: Prise en charge des systèmes non-systemd, sans bloquer la progression.
• Choix 5: H: Prise en charge de la portabilité, sans bloquer la progression.
• Choix 6: E: La prise en charge de plusieurs systèmes d'initialisation est requise.
• Choix 7: G: La prise en charge de la portabilité et de plusieurs implémentations.
• Choix 8: Poursuite de la discussion.

L'appel au vote a été annoncé il y a peu sur la liste de diffusion et le vote se termine le 27 décembre. Peu de temps après, nous devrions apprendre ce que la communauté de développement Debian a décidé pour le futur rôle du support non-systemd par la distribution.

Source : liste diffusion Debian

Et vous ?

Que pensez-vous de systemd ?
Si vous deviez faire un choix parmi les 8 qui ont été proposés aux développeurs Debian, lequel feriez-vous ?

Voir aussi :

La version 8.6 de Knoppix devient la première de la distribution Linux basée sur Debian à abandonner systemd, son créateur en explique les raisons
Buster, la version 10 de Debian Linux est disponible avec le support du Secure Boot et plus de paquets que Stretch
Le système d'exploitation Debian 10 « Buster » de GNU/Linux sortira le 6 juillet 2019, avec de nombreuses fonctionnalités et améliorations
Une faille grave du noyau Linux a été découverte dans RDS, Red Hat, Ubuntu, Debian et SUSE affectées
Le projet Debian pourrait se retrouver sans chef à sa tête, car personne ne semble vouloir le diriger

[Invité]

Que pensez-vous de systemd ?

Que c'est un magnifique objet de troll comme seul les geeks savent les créer 😍

BSD vs Linux
Linux vs Hurd
Gnome vs KDE
Beurre vs Confiture

Si vous deviez faire un choix parmi les 8 qui ont été proposé aux développeurs Debian, lequel feriez-vous ?

Celui du KISS 😁

[Steinvikel]

Que c'est un magnifique objet de troll comme seul les geeks savent les créer 😍

BSD vs Linux
Linux vs Hurd
Gnome vs KDE
Beurre vs Confiture


Celui du KISS 😁

Perso, j'ai galéré pour trouver une solution qui me permettait de faire du multi-seat sans s'appuyer sur 1 GPU par utilisateur...
Je suis finalement tombé sur une correcte qui s'appuie sur systemd et loginctl (Debian).
Donc au final, j'ai beau être utilisateur final, mon usage atypique de Debian me rend directement lié a cette actualité. Parce que le jour où je ferais une clean install sur une nouvelle monture de Debian, je saurais qu'en premier lieu, je dois activer systemd (s'il est au final toujours retenu pour être utilisé par défaut).

[Mimoza]

Tu as oublié :

Chocolatine VS Pain au chocolat

[Christophe]

Maintenant que la plupart des distros est passé sur systemd, c'est peut-être un peu tard pour se poser la question d'un retour vers init.

[phil995511]

Personnellement je suis en faveur de init

[abriotde]

Personnellement je suis en faveur de init

Init a ses avantage pour son côté fiabilité/simplicité mais il a des limites quand on veux pousser les performances dans ses derniers retranchement (je pense notamment à la parallélisation et a la gestion de contraintes). Il faut conserver Init pour des systèmes simple, je pense notamment a l'embarqué, les système très cusomisé et simplifié, mais pour l'OS de tout un chacun, SystemD est a même d'évoluer pour une intégration simple avec plein de logiciels.

Je pense que le problème fondamental de SystemD est qu'il est arrivé pas assez mature et surtout pas assez bien pensé KISS. Il faut que le moins possible d'outils dépendent de SystemD mais plutôt que les outils intégrent des fonctionnalités pour comuniquer avec un système comme systemD (style D-Bus complété s'il le faut par d'autres protocoles standards). Ainsi ce n'est pas mount, cron et autre qui sont intégré dans SystemD mais systemD qui fait appels de fonctionnalitées.

[Ookaze]

Ce que je pense de systemd ?
Cela fait plus de 20 ans que j'ai créé mon propre OS et plus de 10 ans que j'utilise systemd, donc je n'en pense que du bien comme au premier jour où je l'ai découvert, alors que je cherchais activement un init maintenu et fonctionnel, contrairement à simpleinit-msb que je maintenais tout seul.
systemd a permis de faire ressortir tous les faux soi-disant administrateurs vétérans, qui ne sont en fait que des charlatans. On savait depuis bien avant les années 2000 que sysvinit (que les béotiens confondent et appellent init) est nul et inadapté aux systèmes, mais on n'avait rien trouvé de mieux sous Linux, et surtout, personne ne voulait faire le boulot. Parce que les Unix propriétaires basés sur System V, eux, avaient fait le boulot pour se débarasser de sysvinit, notamment Solaris avec DMF je crois. Donc ce n'est pas du tout anti-Unix de se débarasser de sysvinit, sauf pour les charlatans qui n'y connaissent rien.
Beaucoup de personnes se sont attelés à la tâche, il existe plus d'une dizaine d'init autre que sysvinit rien que sur Linux, mais aucun n'a jamais pu sortir du lot, ils ont tous trop de défauts rédhibitoires. Et finalement, dès que j'ai vu arriver systemd, ça a été la révélation. J'avais juste peur que les auteurs n'aillent pas au bout, donc je me suis inscrit à la ML dès le début du projet et ait participé autant que je pouvais au projet.
Je revois mes discussions sur ce forum, et je vois qu'au final tout s'est déroulé comme je le pensais, et tout ce que j'ai dit est toujours valable aujourd'hui. Et chaque jour qui passe montre à quel point mes détracteurs étaient complètement à côté de la plaque, mais bon, ils avaient zéro connaissance technique. Il y a 5 ans, j'avais déjà 15 ans d'expertise sur ce domaine, et dans le milieu professionnel, je n'ai jamais rencontré qu'une unique personne qui maîtrisait les scripts d'init, et encore, loin de mon niveau. Pour les connaisseurs, je corrigeais les scripts HACMP d'AIX les doigts dans le nez, alors que des administrateurs AIX aguerris (des vétérans Unix donc) n'osaient même pas regarder ce code, encore moins le toucher. C'est un autre niveau de complexité par rapport à des scripts d'init. sysvinit, c'est le premier truc que j'ai dégagé de mes OS il y a 20 ans après avoir installé avec succès ma première LFS.
systemd est maintenant le top au niveau init, et durant toutes ces années, personne n'a réussi à produire le moindre concurrent sérieux. Je ne retiens pas mon souffle pour en voir arriver un, quand on voit le temps qu'a tenu sysvinit alors que cela faisait plus de 10 ans que l'on savait qu'il fallait s'en débarrasser.
systemd a surtout permis de faire un boulot fantastique pour améliorer Linux : étant donné qu'il a standardisé le système d'init, le noyau Linux a pu être amélioré à un tas de niveaux fondamentaux puisque l'on a pu affirmer que les problèmes venaient du noyau et non pas des scripts shell de sysvinit. Je ne compte plus le nombre d'améliorations qui ont eu lieu grâce à systemd. Mes systèmes tournent maintenant avec les PID en 32 bits et une des dernières avancées en date sont l'introduction des pidfs. Dès le départ, systemd avait changé la donne avec la conservation des logs de boot dans les logs système, ordonnées correctement dans le temps. Auparavant, on perdait des tonnes de logs et sur une machine même d'il y a 15 ans, on ne pouvait pas récupérer les logs du démarrage du noyau, il fallait avoir une console série. Sur Debian, une des reliques les plus catastrophiques de sysvinit était que l'on ne pouvait pas changer la configuration IP sans rebooter sa machine ou dans le meilleur des cas, perdre sa connexion distante.

Si je devais faire un choix, ce serait le 4 D.
Il faut laisser une alternative viable émerger (mais je ne me fait pas d'illusions), mais ne pas retarder l'avancée de l'OS à cause du système d'init.
Aucun mainteneur ne veut continuer à supporter les scripts de sysvinit de toutes façons, ils sont encore aujourd'hui bourrés de bugs impossibles à corriger.

[Invité]

Cela fait plus de 20 ans que j'ai créé mon propre OS

T'aurais pas le pseudo Nshag ailleurs par hasard ?

[Ookaze]

Init a ses avantage pour son côté fiabilité/simplicité mais il a des limites quand on veux pousser les performances dans ses derniers retranchement (je pense notamment à la parallélisation et a la gestion de contraintes). Il faut conserver Init pour des systèmes simple, je pense notamment a l'embarqué, les système très cusomisé et simplifié, mais pour l'OS de tout un chacun, SystemD est a même d'évoluer pour une intégration simple avec plein de logiciels.

Je pense que le problème fondamental de SystemD est qu'il est arrivé pas assez mature et surtout pas assez bien pensé KISS. Il faut que le moins possible d'outils dépendent de SystemD mais plutôt que les outils intégrent des fonctionnalités pour comuniquer avec un système comme systemD (style D-Bus complété s'il le faut par d'autres protocoles standards). Ainsi ce n'est pas mount, cron et autre qui sont intégré dans SystemD mais systemD qui fait appels de fonctionnalitées.

sysvinit (je suppose qu'init faisait référence à sysvinit) n'a aucun avantage, il n'est pas fiable et est très simple, à tel point que ses fonctionnalités ne sont même pas utilisées. Tout passe par des scripts shell et le monitoring de daemon n'est même plus utilisé dans les distributions qui l'utilisent encore. Déjà il y a 20 ans, j'étais un des seuls à avoir essayé d'utiliser la gestion de daemon sur mon OS, les distributions géraient un ou deux daemons, tout le reste était fait par scripts. La plupart des admins ne savent même pas qu'il y a un moniteur dans sysvinit. Sur les systèmes embarqué, on utilise plutôt des systèmes tout en un plus léger et leur init, comme busybox ou (ironie du sort) systemd.
systemd n'a pas de problème, c'est juste une inversion accusatoire, ce sont certaines personnes qui ont un problème avec systemd, toujours idéologique.
Cela n'a aucun sens de dire qu'un Logiciel Libre est arrivé pas assez mâture, le logiciel ce n'est pas un truc qui apparaît d'un coup comme par magie, le code est construit au fur et à mesure en partant de rien.
Et comme dans le Libre on a accès au code dès le début... Au contraire, c'est sysvinit et ses scripts qui ne sont toujours pas mâtures des décennies après, à cause de problèmes fondamentaux.
systemd est complètement KISS justement, et tous les "il faut que" demandés sont déjà intégrés dans systemd depuis le début. mount, cron et cie ne sont pas du tout intégrés dans systemd d'ailleurs.
Ce sont les bibliothèques système ou les API du noyau Linux qui sont utilisées pour fournir des fonctionnalités similaires, mais en réalité souvent plus avancées, parfois différentes.
Mais le plus important est quand même tous les bugs rédhibitoires qui se trouvaient à tous les niveaux de l'OS et du noyau Linux, que systemd a permis de résoudre, sans compter la sécurité renforcée des systèmes.

[abriotde]

c'est un magnifique objet de troll comme seul les geeks savent les créer

Il est normal que seul les personnes qui s'y connaissent prennent part aux sujets aussi techniques. Cela ne changera rien pour l'utilisateur lambda, cela touche les administrateurs système, les concepteurs de logiciels et surtout les mainteneurs de l'OS et les performances global.
De même seul les motoristes et les connaisseurs discutent de savoir de quel technologie de turbo il faut mettre sur un moteur diesel.
Si tu regarde autour de toi, des débats techniques existent partout (en économie, en sciences, en électronique, en cuisine, en service à la personne et sans parler de la politique).

[edrobal]

Systemd est de la daube et parallélisation et gestion de contraintes sont une idiotie. Je viens de migrer un serveur sur la dernière version d'openSuse. Résultat de systemd :
1) le système n'a jamais démarré aussi lentement à cause de boucles d'attente introduites pour la gestion de contraintes dues à la parallélisation.
2) J'ai une erreur aléatoire qui met parfois le système en mode debug probablement à cause d'un montage du raid avant que le driver ne soit actif. Donc reboot nécessaire.
Ces problèmes n'existaient pas avec init. Enfin, accélérer le démarrage du noyau qui était une histoire de 10 à 15s au max, c'est une couillonnade de geeks. Et ce manque de sérieux est une des causes de l'échec de Linux.

[Christophe]

Il s'(agit là de manque de compétences en administration, pas d'un problème de systemd.