Pourquoi ? Est-ce parce que le système d'init t'a empêché de le faire ? Ca m'est déjà arrivé de devoir forcer un reboot sous d'autres systemes, mais jamais parce que le système d'init en lui-même était tellement pourri qu'ill ne voulait pas le faire.
En fait comme SysV ne fait pas grand chose en tant que tel et que cela repose sur des scripts qui peuvent faire n'importe quoi, ton système peut être bloqué par un script d'init mal fait.
Donc oui, ce n'est pas init qui bloque, mais le design d'init SysV reposant sur la multitudes de scripts environnants pour faire son job (démarrer ou couper la machine), il faut en tenir compte dans l'évaluation.
Sinon faut être juste et ne pas compter les soucis avec dbus comme des problèmes liés à systemd...
BIIIP Contradiction détectée. Faut savoir : j'utilise ou j'utilise pas ? Si j'utilise pas, je ne rencontre pas de problème, non ?
Je n'ai pas dit que tu n'as pas utilisé systemd. Relis bien. J'ai dit que tu avais un avis négatif sur systemd avant même de t'en servir. Comme souvent dans cet état d'esprit, on monte en épingle le premier soucis rencontré sans relativiser son expérience par rapport à son propre passé avec une solution concurrente.
Le problème de systemd pour moi est qu'il multiplie les surcouches sur lesquelles il s'appuie pour pouvoir fonctionner.
Mais c'est bien d'avoir des couches. Le but de ces couches est de mutualiser le travail, ne pas réinventer la roue, avoir des composants plus solides.
systemd mutualise des tas de comportements. Et c'est très bien. L'init à la SysV c'est historique, c'est initialiser une machine à l'ancienne. C'était bien à l'époque mais le monde a évolué.
Bientôt tu vas rejeter les bibliothèques comme Qt, GTK+, Boost, glibc ou même le noyau car cela mutualise et ajoute des couches ? Réutiliser c'est l'essence même d'une bonne conception.
Et dès qu'il y a un grain de sable dans ces surcouches, on se tretrouve à ne pas pouvoir redémarrer sa machine
Oui un système plus complexe peut avoir plus de problèmes. Mais cela apporte plus de choses. cela n'a rien de spécifique à systemd et je ne vois pas en quoi cela est un soucis. Systemd a par design des tas d'avantages. Certes il y a des inconvénient, comme tout logiciel il y a des compromis de conception. C'est dommage mais un choix doit être fait.
Et bizarrement, il n'y a pas grand monde pour se bouger à maintenir les scripts init à l'ancienne, preuve que pas grande monde trouvait SysV si bien que cela à maintenir et à l'usage...
C'est un gros SPOF sur le système. Après on peut me dire que le noyau est aussi un SPOF, sauf que le noyau ne fait pas tout : il se contente de gérer les ressources hardware et délègue pas mal de choses aux couches supérieures.
Lol, systemd c'est pareil alors.
Le noyau Linux par sa conception fait beaucoup de choses. Suivant certaines conceptions comme micro-noyau, Linux fait vraiment trop de choses par lui même. Son cœur est trop gros. C'est un choix assumé par conception et l'histoire a montré que ce n'était pas absurde.
systemd, c'est exactement pareil, on peut faire autrement mais l'histoire montre que les choix opérés ont un sens et que le gain l'emporte sur les inconvénients.
[^] # Re: systemd32.exe
Posté par Renault (site web personnel) . En réponse au journal [HS] Microsoft ♥ Linux - Episode IV L'attaque des clones. Évalué à 5.
En fait comme SysV ne fait pas grand chose en tant que tel et que cela repose sur des scripts qui peuvent faire n'importe quoi, ton système peut être bloqué par un script d'init mal fait.
Donc oui, ce n'est pas init qui bloque, mais le design d'init SysV reposant sur la multitudes de scripts environnants pour faire son job (démarrer ou couper la machine), il faut en tenir compte dans l'évaluation.
Sinon faut être juste et ne pas compter les soucis avec dbus comme des problèmes liés à systemd...
Je n'ai pas dit que tu n'as pas utilisé systemd. Relis bien. J'ai dit que tu avais un avis négatif sur systemd avant même de t'en servir. Comme souvent dans cet état d'esprit, on monte en épingle le premier soucis rencontré sans relativiser son expérience par rapport à son propre passé avec une solution concurrente.
Mais c'est bien d'avoir des couches. Le but de ces couches est de mutualiser le travail, ne pas réinventer la roue, avoir des composants plus solides.
systemd mutualise des tas de comportements. Et c'est très bien. L'init à la SysV c'est historique, c'est initialiser une machine à l'ancienne. C'était bien à l'époque mais le monde a évolué.
Bientôt tu vas rejeter les bibliothèques comme Qt, GTK+, Boost, glibc ou même le noyau car cela mutualise et ajoute des couches ? Réutiliser c'est l'essence même d'une bonne conception.
Oui un système plus complexe peut avoir plus de problèmes. Mais cela apporte plus de choses. cela n'a rien de spécifique à systemd et je ne vois pas en quoi cela est un soucis. Systemd a par design des tas d'avantages. Certes il y a des inconvénient, comme tout logiciel il y a des compromis de conception. C'est dommage mais un choix doit être fait.
Et bizarrement, il n'y a pas grand monde pour se bouger à maintenir les scripts init à l'ancienne, preuve que pas grande monde trouvait SysV si bien que cela à maintenir et à l'usage...
Lol, systemd c'est pareil alors.
Le noyau Linux par sa conception fait beaucoup de choses. Suivant certaines conceptions comme micro-noyau, Linux fait vraiment trop de choses par lui même. Son cœur est trop gros. C'est un choix assumé par conception et l'histoire a montré que ce n'était pas absurde.
systemd, c'est exactement pareil, on peut faire autrement mais l'histoire montre que les choix opérés ont un sens et que le gain l'emporte sur les inconvénients.