Ce qui fait beaucoup crier les gens autour de systemd c'est son côté hégémonique et prosélyte : les utilisateurs de Debian ou Redhat (et dérivées) se sont vus imposer de changer leur façon d'administrer leur machine, du jour au lendemain, sans avoir tellement le choix, parce qu'il est difficile de mettre ce truc là en option, ou de l'activer quand on veut, c'est tout ou rien, sans douceur.
La question est pourquoi ça a été fait comme ça : maintenir des outils en parallèle c'est possible mais pénible, ça demande des efforts d'intégration, de tests, etc. Et à l'ancienne tu avais des scripts init à leur sauce, des astuces qui divergent entre les distributions et logiciels, etc. Les mainteneurs ont globalement sauté sur un outil pratique pour simplifier leur travail.
Si les gens veulent maintenir la méthode à l'ancienne, comme c'est libre ils se mettent en commun pour le faire ou utiliser une autre distribution. ;) Debian et Red-Hat ne doivent pas se plier aux exigences de tout le monde. Les utilisateurs délèguent la gestion de la base du système à ces équipes qui font des choix en permanence, dont systemd.
Donc reprocher que ces équipes ont fait des choix pour les utilisateurs c'est fort le café : c'est le principe même d'une distribution, sinon tout le monde prend une LFS et se débrouille avec.
Je vais troller un peu (un peu, promis !), mais je pense que c'est parce que tu avais auparavant à administrer des Debian (ou Redhat ou dérivés), et qu'ils foutaient historiquement un bazar monstre et incompréhensible dans /etc pour permettre à des outils en clicodrôme d'administrer avec des gros boutons et des icônes colorées. Tu avais deux choses à apprendre : la façon de faire Debian et les spécificités de chaque logiciel.
Mouais pas vraiment.
Le soucis des scripts init à l'ancienne c'est qu'il n'y avait pas de standard.
Tu as certains mainteneurs qui vont gérer des cas courant différemment des autres, voire penser (ou pas) à l'existence de SELinux par exemple, et autres... Du coup tu as plein de manières de faire qui se mélangent, que ce soit au sein d'une distribution ou entre les logiciels eux mêmes quand ils fournissaient leur script init maison.
Du coup là encore, dire que tout est uniforme sans systemd c'est là aussi un peu aberrant, car c'est sans doute l'avantage numéro 1 de systemd.
Sous Slackware tu as les fichiers de conf des auteurs des logiciels, disponibles là où la doc officielle les place.
Et franchement, ça n'a rien ni de bordélique, ni de spécialement complexe.
Il faut juste éditer tes fichiers texte à la main, et lire la doc des auteurs des logiciels.
Le problème est justement le manque d’uniformité et la nécessité de se plonger dedans à chaque fois...
Systemd résout (aussi) des problèmes de Debian et de Redhat, un bon outil se contenterait de résoudre des problèmes de Linux.
En fait, je vois systemd comme une évolution de la philosophie d'administration système Linux développée ces (presque) trente dernières années par Debian et Redhat (qui se sont pas mal repompés leurs idées).
Je ne vois pas quels problèmes Debian et Red-Hat ont spécifiquement introduits mais bon. Ni en quoi les solutions retenues sont moins Linux que les autres.
Et comme la philosophie Slackware n'a jamais suivi cette voie là, systemd y a nettement moins d'intérêt.
L'intérêt de systemd ne dépend pas tellement de la distribution en dessous. Typiquement mon projet embarqué est techniquement une distribution sur mesure (on est loin de Red-Hat et Debian) et pourtant il y a systemd et ça a un avantage énorme par rapport à avant. :)
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par Renault (site web personnel) . En réponse à la dépêche Tout arrive, même Slackware 15.0. Évalué à 5.
La question est pourquoi ça a été fait comme ça : maintenir des outils en parallèle c'est possible mais pénible, ça demande des efforts d'intégration, de tests, etc. Et à l'ancienne tu avais des scripts init à leur sauce, des astuces qui divergent entre les distributions et logiciels, etc. Les mainteneurs ont globalement sauté sur un outil pratique pour simplifier leur travail.
Si les gens veulent maintenir la méthode à l'ancienne, comme c'est libre ils se mettent en commun pour le faire ou utiliser une autre distribution. ;) Debian et Red-Hat ne doivent pas se plier aux exigences de tout le monde. Les utilisateurs délèguent la gestion de la base du système à ces équipes qui font des choix en permanence, dont systemd.
Donc reprocher que ces équipes ont fait des choix pour les utilisateurs c'est fort le café : c'est le principe même d'une distribution, sinon tout le monde prend une LFS et se débrouille avec.
Mouais pas vraiment.
Le soucis des scripts init à l'ancienne c'est qu'il n'y avait pas de standard.
Tu as certains mainteneurs qui vont gérer des cas courant différemment des autres, voire penser (ou pas) à l'existence de SELinux par exemple, et autres... Du coup tu as plein de manières de faire qui se mélangent, que ce soit au sein d'une distribution ou entre les logiciels eux mêmes quand ils fournissaient leur script init maison.
Du coup là encore, dire que tout est uniforme sans systemd c'est là aussi un peu aberrant, car c'est sans doute l'avantage numéro 1 de systemd.
Le problème est justement le manque d’uniformité et la nécessité de se plonger dedans à chaque fois...
Je ne vois pas quels problèmes Debian et Red-Hat ont spécifiquement introduits mais bon. Ni en quoi les solutions retenues sont moins Linux que les autres.
L'intérêt de systemd ne dépend pas tellement de la distribution en dessous. Typiquement mon projet embarqué est techniquement une distribution sur mesure (on est loin de Red-Hat et Debian) et pourtant il y a systemd et ça a un avantage énorme par rapport à avant. :)