Re: De plus en plus complexe, le système d'init...

C'est ce que je dis : ça répond a des problématiques plus orienté mainteneurs qu'utilisateur final.

Le mainteneur est confronté aux problèmes des sys admin. L'utilisateur final de systemd ce sont les mainteneurs et les sys admin, pas les autres qui effectivement ne verront pas une différence directe (mais indirectement, s'il y a moins de temps à passer pour gérer les services, la qualité globale du système augmente et cela permettrait de se concentrer sur d'autres tâches).

un pas de plus vers de la complexité non nécessaire dans le cas général.

Pourtant, les gens n'arrêtent pas de lister des cas où SysV a montré ses limites. Pour moi c'est la preuve que c'est nécessaire, pas pour tout le monde certes, et alors ? Gnome est une complexité non nécessaire pour certaines actions faisable plus efficacement en console, cela n'enlève pas son intérêt global d'exister.

En remplacement de System V, alors il y a peut-être un progrès, mais par rapport a un init sauce BSD, c'est juste de la complexité ajoutée pour couvrir des cas peu probables, particulièrement sur des serveurs basiques.

À lire les anti-systemd qui veulent un retour à SysV et non vers une autre solution, on voit qu'il y a un soucis de discours.
C'est de la résistance au changement.

Après c'est sur que pour un éditeur de distro, il y a clairement un gain, mais pour l'utilisateur final...

Qui est l'utilisateur final ? L'admin système et le créateur de la distribution ont un gain évident dans l'affaire. L'utilisateur moyen non, mais est-ce qu'on râle sur des nouveautés de gcc que l'utilisateur moyen ne verra pas non plus ?

Le changement c'est bien quand c'est nécessaire.

Il faudra combien de messages avec la liste des gains apportés pour que tu voies que c'est nécessaire ?
Et combien de distributions vont devoir migrer pour te montrer qu'ils le font car ils savent qu'ils ont à y gagner ?

Là, le changement va être induit par une nouvelle techno qui n'est pas développée pour répondre à mon besoin mais a celui de tiers (les mainteneurs).

Tout le monde s'en fout de ton besoin ou du mien. Dans le LL, le besoin qui est représenté est celui qui code. C'est comme ça. Ils dictent les changements car ils travaillent avant tout pour eux (ils veulent forcément que l'outil qu'ils développent répondent à leur besoin, à moins d'être maso et de programmer un utilitaire dont on ne souhaite pas l'utiliser).

Et si ton besoin n'a pas évolué, celui des autres oui, et systemd s'adapte à ce changement. D'autant qu'en étant compatible avec SysV, il peut satisfaire les "besoins" des "anciens".
Encore faut-il démontrer le besoin réel auquel répond SysV et pas systemd.

le problème est dans le fait qu'on bascule un truc expérimental dans un outil de production.

Ce n'est pas expérimental. Systemd est en développement très actif mais j'ai connu très peu de problèmes avec. J'en ai connu avec SysV aussi...
Ce n'est pas comme avec PA où en effet au début les problèmes étaient plus la norme que le bon fonctionnement. Systemd fonctionne très bien. Puis après on ne peut pas accuser le développeur d'un programme d'avoir son outil dans des distributions par défaut. Ce sont elles qui font le choix et en sont responsables.

En termes de technos oui c'est plus ou moins récent, mais les concepts sous jascents sont loin de l'être.

Oui, enfin osef. Une technologie qui n'existait que dans un garage ou de manière inaboutie ce n'est pas très intéressant. Cela reste des nouveautés qui impliquent de nouveaux usages et de nouveaux besoins.

Typiquement udev (et HAL) permettent de gérer l'histoire des périphériques à chaud qui existaient depuis un bail mais qui sont populaires depuis seulement une décennie pour l'ordinateur moyen. Et étant donné la fréquence d'utilisation de ces périphériques aujourd'hui, heureusement qu'il y a des mécanismes similaires.

Le concept est certes vieux, mais comme il était discret, le cas d'utilisation n'était pas gérée ou de manière trop légère.

Et avec systemd, pof, ça marche en un clic ?

Non, mais certains problèmes qu'il y avait avec SysV n'existe plus, ou sont plus simples à gérer.
C'est là l'intérêt...

Etape obligatoire quelque soit ton gestionnaire de service non ?

Je ne dis pas le contraire. Mais certains semblent oublier que SysV nécessite un apprentissage.
Et la courbe d'apprentissage de systemd semble intéressante vis à vis de SysV.

Donc lire la doc du service est plus long que lire la doc du service + la doc de systemd. CQFD

Où j'ai dis ça ? J'ai l'impression que tu négliges le temps de rédiger un démon sous SysV de manière propre. Car oui, gérer cela de manière propre est assez long et périlleux par rapport à une unité de systemd qui t'abstrait de l'implémentation de concepts délicats à gérer comme les dépendances de processus ou du chemin d'accès à certains fichiers.

A vous croire ça lave tellement plus blanc que toutes les distros seront identiques en termes de conf et que les migrations se feront en un clic. Rien que quand tu vois le support de la LSB par les distro, tu sais que ça relève du vœu pieux mais que c'est irréalisable justement parce que s'il existe différentes distros, c'est parce qu'il existes différents contextes.

C'est à se demander si tu as lu la doc de systemd et si tu t'en es réellement servi un jour.
Les unités de systemd peuvent différer entre distributions pour un service donné. Systemd ne change rien à ce fait et chaque distribution peut avoir sa petite touche personnelle.

Ce qui change c'est que si Debian fait une unité adaptée pour httpd, un utilisateur de Fedora intéressé pourra copier/coller ce fichier et l'utiliser et ça fonctionnera. C'est ça qui est intéressant.
Essaye de le faire avec SysV, tu vas prendre un certains temps à adapter le script...