Tout comme systemd n'a pas grand chose à voir avec une des règles de base d'UNIX malheureusement, à savoir la séparation de tâches simples en briques logicielles indépendantes.
La stagnation, c'est l'avenir !
J'ai dit "Il y a des fois où il faut savoir faire marche arrière et se dire que les vieilles recettes sont parfois les meilleures". Pas "Maintenons le statu quo". Parfois, oui, il vaut mieux refuser certaines évolutions qui en réalité amènent autant de problèmes qu'elles n'en résolvent. Ce qui ne veut pas dire qu'il ne faille rien faire pour améliorer par exemple OpenRC.
Change vite d'OS, ça fait plus de vingt ans que Linux (le *NIX majoritaire depuis 15 ans au moins) utilise un gros noyau monolithique.
C'était même tellement bien qu'on a été obligé de créer une v2 de Linux pour y ajouter des modules.
Pas vraiment. D'abord, pour avoir systemd il faut linux. Aussi, systemd aurait été plus difficile avec 16 Kio de mémoire (la taille de la mémoire vive du premier IBM PC), AMHA.
C'est bien tout le coeur du problème : pour avoir systemd, il ne faut que Linux.
Lesquelles ?
Ca fait 3 fois que je l'écris dans ce fil mais je vais le redire : séparer des tâches en briques logicielles indépendantes. C'est un des concepts de base de la programmation système sous les *NIX, j'en veux pour référence cet excellent ouvrage : http://www.oreilly.com/openbook/linuxdrive3/book/
Les vielles recettes puent. Quand on copie/colle du code shell mal fichue pendant 40 ans plutôt que d'arrêter de re-faire le même boulot des milliers de fois :
1) soit on a la foi
2) soit on est stupide
Je te rejoins totalement sur ce point. Mais si c'est remplacer un truc qui pue par un truc moisi, non merci, je préfère encore conserver l'ancien truc en bossant sur un système correct qui viendra le remplacer plus tard (je pense à OpenRC).
Et c'est parce qu'on sait quand savoir évoluer, qu'on a eu bien d'autres systemd-like avant systemd (qui ne fait que réunir le meilleur des systemd-like qui sont apparus avant lui).
Par évolution, j'entendrais quelque chose comme "contribuer à l'existant pour le rendre vraiment meilleur", plutôt que de prendre plein de fonctionnalités et de les agréger en un ensemble de briques pas indépendantes qu'on aura entièrement recodées. Plutôt que de faire un peu de vérification de système de fichiers + un peu de parefeu + un peu de ceci et un peu de cela, systemd ferait bien de ne faire que l'initialisation. Ou s'il veut tout faire, qu'il ait au moins la gentillesse de séparer les briques logicielles de façon indépendantes, qu'on puisse remplacer chaque élément par un autre si l'on préfère. Mais ce n'est pas du tout la logique adoptée ici, et c'est je crois ce qui pose problème à tant de personnes.
[^] # Re: Journal approximatif
Posté par cluxter . En réponse au journal Systemd contrôlera bientôt tout votre réseau. Évalué à 2.
Tout comme systemd n'a pas grand chose à voir avec une des règles de base d'UNIX malheureusement, à savoir la séparation de tâches simples en briques logicielles indépendantes.
J'ai dit "Il y a des fois où il faut savoir faire marche arrière et se dire que les vieilles recettes sont parfois les meilleures". Pas "Maintenons le statu quo". Parfois, oui, il vaut mieux refuser certaines évolutions qui en réalité amènent autant de problèmes qu'elles n'en résolvent. Ce qui ne veut pas dire qu'il ne faille rien faire pour améliorer par exemple OpenRC.
C'était même tellement bien qu'on a été obligé de créer une v2 de Linux pour y ajouter des modules.
C'est bien tout le coeur du problème : pour avoir systemd, il ne faut que Linux.
Ca fait 3 fois que je l'écris dans ce fil mais je vais le redire : séparer des tâches en briques logicielles indépendantes. C'est un des concepts de base de la programmation système sous les *NIX, j'en veux pour référence cet excellent ouvrage : http://www.oreilly.com/openbook/linuxdrive3/book/
Je te rejoins totalement sur ce point. Mais si c'est remplacer un truc qui pue par un truc moisi, non merci, je préfère encore conserver l'ancien truc en bossant sur un système correct qui viendra le remplacer plus tard (je pense à OpenRC).
Par évolution, j'entendrais quelque chose comme "contribuer à l'existant pour le rendre vraiment meilleur", plutôt que de prendre plein de fonctionnalités et de les agréger en un ensemble de briques pas indépendantes qu'on aura entièrement recodées. Plutôt que de faire un peu de vérification de système de fichiers + un peu de parefeu + un peu de ceci et un peu de cela, systemd ferait bien de ne faire que l'initialisation. Ou s'il veut tout faire, qu'il ait au moins la gentillesse de séparer les briques logicielles de façon indépendantes, qu'on puisse remplacer chaque élément par un autre si l'on préfère. Mais ce n'est pas du tout la logique adoptée ici, et c'est je crois ce qui pose problème à tant de personnes.