Est-ce que le principe de (relative) simplicité qui prévalait auparavant est devenu obsolète? Ou alors c'est ma réticence au "changement" qui m'aveugle?
Le principe de simplicité qui prévalait auparavant non seulement prévaut toujours mais s'accompagne d'autres avantages, je crains donc que ce ne soit la seconde proposition qui soit la bonne.
Bon,ceci étant dit, s'il faut en passer par là pour simplifier la tâche des développeurs du noyau, pour avoir un système plus universel, prenant en charge une plus grande diversité d'architectures, un meilleur support matériel, un système plus optimisé et économe en ressources, c'est un sacrifice auquel je consentirais de bonne grâce.
Mais est-ce bien le but poursuivi?
C'est une partie du but poursuivi, bien qu'en réalité il y en a d'autres bien plus importants et essentiels. Par exemple :
- systemd n'a pas servi à simplifier la tâche des développeurs du noyau, si ce n'est pour trouver des dysfonctionnements dans celui-ci. Ce n'était pas possible auparavant, car on attribuait le problème aux différents systèmes utilisés, systemd a permis de révéler ces problèmes dans le noyau qui s'en trouve meilleur aujourd'hui ;
- les systèmes peuvent désormais démarrer dans le même état à coup sûr (hors problème matériel) s'ils sont bien configurés, contrairement à auparavant où un système, sans rien changer, pouvait voir sa configuration de carte réseau changer au redémarrage, ou encore sa disposition des disques si le BIOS avait subi la moindre modification, ou simplement en insérant une clé USB. Pour l'utilisateur lambda, c'est beaucoup mieux. La plupart des utilisateurs/administrateurs avaient des problèmes dont ils n'ont jamais cherché ou trouvé la cause, parce que beaucoup trop compliqué à investiguer. Les administrateurs des distributions ont forcément eu le cas avec la quantité d'utilisateurs qui remontent des problèmes. Même moi qui crée mes OS entièrement, je savais que même avec tous mes scripts personnalisés, les serveurs avaient toujours une chance de ne pas redémarrer correctement avant systemd ;
- les problèmes pouvaient survenir rien que par le fait que les anciens systèmes d'init ne géraient pas les événements, or le noyau Linux s'était adapté depuis bien longtemps avec udev et encore avant avec son prédécesseur (dont j'ai oublié le nom), il envoie des événements que les systèmes d'init ignoraient joyeusement, et c'était une misère pour gérer le démarrage et des choses simples comme connecter une clé USB et la voir prise en compte. Un exemple du KISS respecté, il est plus simple de simplement brancher sa clé USB que d'encore aller exécuter des commandes ensuite pour y avoir accès ;
- les systèmes sont beaucoup plus sécurisés qu'auparavant. Il est maintenant possible de vraiment cloisonner simplement ses démons, son poste de travail pour l'utilisateur, et même en multiseat ou en multi-sessions. Une de mes hantises sur les serveurs était qu'il était très facile de placer des malwares dans les scripts d'init sans que cela ne soit détecté (hors utilisation d'IDS) ;
- les fonctionnalités de qualité de vie, d'optimisation, de sécurité, de performance, etc. du noyau Linux sont enfin utilisées et améliorées puisque vraiment utilisées, grâce à systemd. Les détracteurs se contentent de dire "mais si on peut faire" mais ne font jamais en réalité, d'où le fait que seul systemd a permis de remonter des dysfonctionnements sur ces options du noyau ;
- rien que monter un VPN (avec wireguard récemment) est devenu d'une simplicité sans comparaison avec ce qui se faisait ;
Lorsqu'on a eu les mains dans le cambouis comme moi (je fais mes propres OS, le même travail que font les distributions) depuis plus de 20 ans, il est évident du pourquoi de l'adoption de systemd par quasiment toutes les distributions, qui souvent utilisaient des binaires pour tenter de faire démarrer de manière cohérente leurs OS. Lorsque systemd est arrivé il y a plus de 10 ans, je l'ai accueilli sans hésiter, j'ai sauté sur les toutes premières versions de développement. Il faut dire que je maintenais tout seul simpleinit-msb jusque-là (j'avais abandonné l'abomination qu'est sysvinit en quelques mois d'utilisation), en espérant trouver mieux. Je n'y croyais pas trop au départ mais j'espérais fortement que systemd tienne ses promesses, et non seulement il les a tenues mais il a pu s'insérer comme une référence.
[^] # Re: le principe "KISS" est-il devenu obsolète?
Posté par ookaze . En réponse au lien Grandeur et décadence de Linux (et j'ajoute: sic transit Linux regnum). Évalué à 0.
Le principe de simplicité qui prévalait auparavant non seulement prévaut toujours mais s'accompagne d'autres avantages, je crains donc que ce ne soit la seconde proposition qui soit la bonne.
C'est une partie du but poursuivi, bien qu'en réalité il y en a d'autres bien plus importants et essentiels. Par exemple :
- systemd n'a pas servi à simplifier la tâche des développeurs du noyau, si ce n'est pour trouver des dysfonctionnements dans celui-ci. Ce n'était pas possible auparavant, car on attribuait le problème aux différents systèmes utilisés, systemd a permis de révéler ces problèmes dans le noyau qui s'en trouve meilleur aujourd'hui ;
- les systèmes peuvent désormais démarrer dans le même état à coup sûr (hors problème matériel) s'ils sont bien configurés, contrairement à auparavant où un système, sans rien changer, pouvait voir sa configuration de carte réseau changer au redémarrage, ou encore sa disposition des disques si le BIOS avait subi la moindre modification, ou simplement en insérant une clé USB. Pour l'utilisateur lambda, c'est beaucoup mieux. La plupart des utilisateurs/administrateurs avaient des problèmes dont ils n'ont jamais cherché ou trouvé la cause, parce que beaucoup trop compliqué à investiguer. Les administrateurs des distributions ont forcément eu le cas avec la quantité d'utilisateurs qui remontent des problèmes. Même moi qui crée mes OS entièrement, je savais que même avec tous mes scripts personnalisés, les serveurs avaient toujours une chance de ne pas redémarrer correctement avant systemd ;
- les problèmes pouvaient survenir rien que par le fait que les anciens systèmes d'init ne géraient pas les événements, or le noyau Linux s'était adapté depuis bien longtemps avec udev et encore avant avec son prédécesseur (dont j'ai oublié le nom), il envoie des événements que les systèmes d'init ignoraient joyeusement, et c'était une misère pour gérer le démarrage et des choses simples comme connecter une clé USB et la voir prise en compte. Un exemple du KISS respecté, il est plus simple de simplement brancher sa clé USB que d'encore aller exécuter des commandes ensuite pour y avoir accès ;
- les systèmes sont beaucoup plus sécurisés qu'auparavant. Il est maintenant possible de vraiment cloisonner simplement ses démons, son poste de travail pour l'utilisateur, et même en multiseat ou en multi-sessions. Une de mes hantises sur les serveurs était qu'il était très facile de placer des malwares dans les scripts d'init sans que cela ne soit détecté (hors utilisation d'IDS) ;
- les fonctionnalités de qualité de vie, d'optimisation, de sécurité, de performance, etc. du noyau Linux sont enfin utilisées et améliorées puisque vraiment utilisées, grâce à systemd. Les détracteurs se contentent de dire "mais si on peut faire" mais ne font jamais en réalité, d'où le fait que seul systemd a permis de remonter des dysfonctionnements sur ces options du noyau ;
- rien que monter un VPN (avec wireguard récemment) est devenu d'une simplicité sans comparaison avec ce qui se faisait ;
Lorsqu'on a eu les mains dans le cambouis comme moi (je fais mes propres OS, le même travail que font les distributions) depuis plus de 20 ans, il est évident du pourquoi de l'adoption de systemd par quasiment toutes les distributions, qui souvent utilisaient des binaires pour tenter de faire démarrer de manière cohérente leurs OS. Lorsque systemd est arrivé il y a plus de 10 ans, je l'ai accueilli sans hésiter, j'ai sauté sur les toutes premières versions de développement. Il faut dire que je maintenais tout seul simpleinit-msb jusque-là (j'avais abandonné l'abomination qu'est sysvinit en quelques mois d'utilisation), en espérant trouver mieux. Je n'y croyais pas trop au départ mais j'espérais fortement que systemd tienne ses promesses, et non seulement il les a tenues mais il a pu s'insérer comme une référence.