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.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
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.
Personnellement je suis en faveur de init
Un truc de geek?
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.c'est un magnifique objet de troll comme seul les geeks savent les créer
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).
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.Envoyé par phil995511
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.
systemd a permis de séparer le bon grain de l'ivraie
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.
T'aurais pas le pseudo Nshag ailleurs par hasard ?
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.
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).
parallélisation et gestion de contraintes
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.
Il s'(agit là de manque de compétences en administration, pas d'un problème de systemd.
Ne racontez pas n'importe quoi. Pour administrer un système, encore faut-il qu'il démarre.
Je suis sur Linux, depuis les premières versions enfin utilisables Mandrake 6, je crois. Alors, Linux je connais ayant fait une formation certifiante. Donc, je sais ce qui est valable et ce qui est une c.......e de Geek !
Formation certifiante... ? Pas à jour alors, systemd étant maintenant présent dans toutes les distros (ou quasiment).
Mais c'est justement à l'administrateur de gérer ce type de problème.Pour administrer un système, encore faut-il qu'il démarre
J'arrive pas à faire marcher donc c'est de la merde, je trouve ça un peu léger. Après que tu n'aimes pas, c'est autre chose.
OpenSuse utilise systemd depuis la version 12.1, dispo depuis fin 2011.
Après, si systemd est une connerie de geek, j'aimerais en faire une avec autant de succès. Puis après tout, la première version de Linux était aussi une connerie de geek.
N'importe quoi, administrer un système c'est aussi comprendre pourquoi il ne démarre pas en sachant quoi faire dans ces cas-là pour débugger.Ne racontez pas n'importe quoi. Pour administrer un système, encore faut-il qu'il démarre.
Je suis sur Linux, depuis les premières versions enfin utilisables Mandrake 6, je crois. Alors, Linux je connais ayant fait une formation certifiante. Donc, je sais ce qui est valable et ce qui est une c.......e de Geek !
Ce genre de formation certifiante est manifestement une catastrophe, cela donne des gens qui croient qu'ils sont compétents alors que ce n'est clairement pas le cas.
Même la base n'est pas assimilée, c'est une catastrophe de lire cela. Le genre de faux admin qui aurait été bien incapable de faire quoi que ce soit avec les quantités de serveurs que j'ai dépanné avec cette abomination de sysvinit.
systemd a sauvé Linux de ce truc et il y a encore des anti Logiciel Libre ou pire, des incompétents complets, qui veulent revenir à sysvinit. Aucun admin compétent ne veut revenir à sysvinit, comme on l'a vu lors de la discussion que les mainteneurs Debian ont eu. Il faut vraiment être très nul en admin système pour vouloir utiliser sysvinit sur Linux. Les Unix s'en sont séparés, car ce n'était déjà pas adapté pour eux, alors imaginez sous Linux.
L'initd de System V a été construit pour un système avec des PID sur 32 bit (des milliards de process) et qui, une fois qu'il a épuisé tous ses PID, crashe. À l'époque cela n'arrivait jamais. Sauf que sysvinit a été porté tel quel sur Linux, qui lui, utilisait (et encore aujourd'hui par défaut) des PID sur 16 bit. Ce qui fait qu'on arrive très rapidement au bout. Donc Linux a implémenté le recyclage des PID, ce qui a entraîné tout un tas de bugs et de vulnérabilités insolubles, et rendus encore pire avec sysvinit qui ne sait pas du tout gérer le recyclage de PID, il n'a pas été fait pour ça. Certains malwares sont écrits pour profiter de cela par exemple, en remplaçant d'autres process. Ce fonctionnement entraînait tout un tas de bugs ou de crashs graves : impossibilité de se logger après avoir quitté sa session, daemon qui part en vrille et impossible à arrêter ou à redémarrer...
Grâce à systemd, de nombreuses améliorations dans le noyau ont été effectuées, comme pidfd, et on peut maintenant utiliser les 22 bit autorisés par le noyau Linux avec systemd (ce que je me suis dépêché de faire). C'est 1000 fois moins que sur les Unix mais avec les autres améliorations dans le noyau, Linux n'est plus le désastre en sursis qu'il a été autrefois. Et déloger cette abomination de sysvinit n'a pas été facile, il suffit de voir tous les ignorants complets venir cracher sur systemd encore aujourd'hui. Heureusement que le LL est une méritocratie qui ignore les neuneus, sinon on serait encore retenus par sysvinit et tous les incompétents qui veulent continuer à l'utiliser.
Je ne suis pas spécialiste Linux, mais passer de init à systemd n'est pas mission impossible. J'ai même créé des services systemd, ce qui ne m'a pas paru plus difficile qu'avec init. Et je n'ai pas lu la doc complète.
init n'était pas forcément top, mais il faisait globalement le job. Systemd est peut-être critiquable, mais il fait le job. Il s'est imposé, il faut s'adapter.
Et je ne pense pas qu'init datant un peu est été changé pour rien.
je sais pas si je sais
Ma crainte, n'étant pas assez informé du fond du fond, est - tel que j'ai compris SystemD - que dans une approche "kissnet" intégrée, si j'ai trois machines sous SystemD chacune ne puisse savoir exactement le statut des deux autres au moment de leur envoyer des commandes. Est-ce vrai ? Dans tous les cas cela m'incite à la réponse 4.
Les développeurs Debian ont manifesté leur intérêt pour systemd tout en soutenant l'exploration d'alternatives
Les développeurs Debian ont manifesté leur intérêt pour systemd, tout en soutenant l'exploration d'alternatives
à l'issue d'un vote
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 incluaient :
- 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é en début de mois sur la liste de diffusion et le vote s'est terminé le 27 décembre. Les résultats ont été publiés le lendemain.
La communauté s'est exprimé majoritairement en faveur de Choix 2: B: Systemd mais nous soutenons l'exploration d'alternatives.
Source : résultats du vote
Et vous ?
Que pensez-vous de ce choix ? Êtes-vous surpris ?
Voir aussi :
personnellement je suis pour une uniformisation des distribution linux au niveau de ces composants car c'est ce qui empêche souvent le portage de logiciels entre distrib.
systemd perso me conviens très bien et je suis content que toute les distrib populaire l'ai adopté.
Quand je fais un logiciel de type service/démon sous linux au moins mon code sera compatible avec toute les distrib ce qui est bien, je ne prend pas la peine de faire une version pour sys init.
Il y'a encore aujourd'hui le meme probleme dans linux avec X/Wayland et Python2/3, c'est assez pénible que ces migrations prennent autant de temps. Heureusement toute les distrib aujourd'hui ont wayland d'installer (pas forcément par défaut), pareil pour python3 mais c'est inacceptable qu'en 2020 des distribs embarque de base encore python2 et pire encore que se soit le python par défaut.
Le problème, c'est que Python3 casse la compatibilité Python2. Pour moi, ça justifie une transition lente, surtout que le langage est pas mal utilisé par des non développeurs à la base. quant à la version de Python par défaut, là je suis d'accord.c'est inacceptable qu'en 2020 des distribs embarque de base encore python2 et pire encore que se soit le python par défaut.
Il est à noter que Python fête actuellement ses 30 bougies :
En 1989, profitant d’une semaine de vacances durant les fêtes de Noël, il utilise son ordinateur personnelpour écrire la première version du langage.
sauf que cela fait plus de 10ans que la transition est en cours... 10ans c'est trop long.
Evidemment python2 dois pouvoir etre installé sur les distrib mais je veux dire les distributions linux devrait de base embarquer que python3 et tout leurs script auraient du etre migré depuis déja pas mal d'année.
Ils commencent enfin a supprimer python2 de l'installation de base car il y'a (enfin) l’arrêt du support de python2.7.
étant développeur python(3) sous linux j'ai pas mal souffert de ce probleme, souvent un client avait bien python...mais python2 alors soit il devait installer python3 quand c'étais possible soit je devais refaire le script en python2 car les machines ne pouvait pas installer python3 (pour des raison de sécurité/droit on pouvais pas installer de package supplémentaire)
Répondre avec citation
Partager