Clair que les scripts bash qui se baladent et non facilement maitrisable sur qui fait quoi, c'est très maintenable.
Je sais pas de quel système tu parle (Android ?), mais chez moi les scripts d'init sont tous dans /etc/init.d, avec de la conf dans /etc/default. Chaque script d'init s'occupe d'une seule chose et s'exécute dans un ordre bien précis.
À te lire on dirait que bash est un objet quantique et que c'est le script d'init de cron qui configure le réseau.
Et si tu trouve que le code de systemd est plus maintenable que des scripts shells, et bien je veux bien te regarder.
tu parles bien des systèmes d'init avant systemd, on est d'accord?
Non, je te parle des 30000 lignes de code de systemd, là ou tout mon init.d (avec une bonne tétrachiée de démons et de conf, plus que sur un desktop normal) n'en fait que 10000, /etc/init.d/rc compris. Et bash reste bien plus lisible et plus compact que du C.
Sauf que la, c'est plus que l'init.
Pourquoi le code de systemd est plus gros que ce qui sert à démarrer absolument tout les démons et les fonctionnalités noyaux qui me servent sur mon système, qui tiens plus d'un hybride serveur-desktop que d'un serveur ou un desktop habituel ?
Si seul l'init t'interresse, la doc est moins bordélique (c'est pas du bash qui plante car tu n'es pas sur la bonne distro et que tu as pas pensé à la petite subtilité de la distro) et petite.
Genre il y a des distros sur lequel le language bash n'est pas le même ? Tu crois vraiment à ce que tu dit ?
Et moi je préfère lire un script de 3 pages que de lire 30 pages de doc.
Tes exemples ensuite n'ont rien à voir : Mac OS X est simple pour l'utilisateur, ça ne dit pas que ce qu'il y a dessous est simple.
C'est toi qui n'a rien compris: on me dit que pour que Linux soit utilisable, il doit être complexe. La réponse est non. Merci.
Et tu donnes d'ailleurs un très bon exemple : pour le moment, la charge de travail est pour le mainteneur de distro et les utilisateurs
La charge de travail de quoi ? De l'écriture du script d'init ? Désolé mais elle reviens à l'auteur upstream du démon qui doit fournir un script LSB (sous Linux). Libre aux distributions de patcher ce script si elles veulent améliorer les choses.
Moi, j'en ai marre qu'on dise qu'avant c'était trop génial, que c'était simple et que ça faisait tout ce qu'on attend d'un OS moderne.
Peut-être parce que c'était le cas ? Après si tu préfère les systèmes centralisés interdépendants qui gèrent 90% des services de la machine "parce que c'est plus simple" qu'un système ou on sépare les choses bien comme il faut dans des couches et/ou des processus séparés, je ne vois pas ce que tu fout sur Internet ou sur un système Unix (malgré ses origines téléphonistes chez AT&T).
Et ce n'est pas parce que systemd est à la mode chez les mainteneurs que ça le sera pour l'éternité. Les mainteneurs ne font généralement que suivre les projets upstreams: si Gnome veux du policykit, du consolekit et du systemd, alors les mainteneurs vont avoir tendance à intégrer policykit, consolekit et systemd plutôt que réimplémenter Gnome.
[^] # Re: De plus en plus complexe, le système d'init...
Posté par Batchyx . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 3.
Je sais pas de quel système tu parle (Android ?), mais chez moi les scripts d'init sont tous dans /etc/init.d, avec de la conf dans /etc/default. Chaque script d'init s'occupe d'une seule chose et s'exécute dans un ordre bien précis.
À te lire on dirait que bash est un objet quantique et que c'est le script d'init de cron qui configure le réseau.
Et si tu trouve que le code de systemd est plus maintenable que des scripts shells, et bien je veux bien te regarder.
Non, je te parle des 30000 lignes de code de systemd, là ou tout mon init.d (avec une bonne tétrachiée de démons et de conf, plus que sur un desktop normal) n'en fait que 10000, /etc/init.d/rc compris. Et bash reste bien plus lisible et plus compact que du C.
Pourquoi le code de systemd est plus gros que ce qui sert à démarrer absolument tout les démons et les fonctionnalités noyaux qui me servent sur mon système, qui tiens plus d'un hybride serveur-desktop que d'un serveur ou un desktop habituel ?
Genre il y a des distros sur lequel le language bash n'est pas le même ? Tu crois vraiment à ce que tu dit ?
Et moi je préfère lire un script de 3 pages que de lire 30 pages de doc.
C'est toi qui n'a rien compris: on me dit que pour que Linux soit utilisable, il doit être complexe. La réponse est non. Merci.
La charge de travail de quoi ? De l'écriture du script d'init ? Désolé mais elle reviens à l'auteur upstream du démon qui doit fournir un script LSB (sous Linux). Libre aux distributions de patcher ce script si elles veulent améliorer les choses.
Peut-être parce que c'était le cas ? Après si tu préfère les systèmes centralisés interdépendants qui gèrent 90% des services de la machine "parce que c'est plus simple" qu'un système ou on sépare les choses bien comme il faut dans des couches et/ou des processus séparés, je ne vois pas ce que tu fout sur Internet ou sur un système Unix (malgré ses origines téléphonistes chez AT&T).
Et ce n'est pas parce que systemd est à la mode chez les mainteneurs que ça le sera pour l'éternité. Les mainteneurs ne font généralement que suivre les projets upstreams: si Gnome veux du policykit, du consolekit et du systemd, alors les mainteneurs vont avoir tendance à intégrer policykit, consolekit et systemd plutôt que réimplémenter Gnome.