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 :
Ne racontez pas n'importe quoi. Pour administrer un système, encore faut-il qu'il démarre.Envoyé par chrtophe
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.
Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
Mon article sur le P2V, mon article sur le cloud
Consultez nos FAQ : Windows, Linux, Virtualisation
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.
Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
Mon article sur le P2V, mon article sur le cloud
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 ?
Voir aussi :
Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités
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.
Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
Mon article sur le P2V, mon article sur le cloud
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