• [^] # Re: De plus en plus complexe, le système d'init...

    Posté par . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 10.

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

    Personnellement, je suis bien content que les mainteneurs travaillent avec un outil qui leur permet de consolider beaucoup de code et d'être globalement plus efficaces. Je préfère ça plutôt que ramasser un bug dans un script shell dont le code est "presque pareil mais en fait non" que d'autres services/sur d'autres distros.

    Sinon moi je ne fais pas de développement, alors ce serait bien qu'on arrête de passer du temps sur ces absurdités de IDE et autre RAD et qu'on revienne à des choses simples et prouvées telles que Emacs/Vim, un Makefile fait à la main, et la compilation en ligne de commande dans un autre terminal. Ça a marché pendant des années, c'est le summum de la souplesse parce qu'il n'y a aucun cas de figure qui ne soit pas faisable, alors qu'un outil d'aide au développement peut mettre des restrictions à cause de conventions ou de la logique interne.
    Faut pas oublier que le résultat tourne sur ma bécane à la fin, et si je sais ouvrir et lire un Makefile, je ne comprends pas l'arborescence des trucs générés par des outils inutilement complexes.

    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.

    Ce qu'il y a de bien avec les cas "peu probables", c'est que ce sont forcément les cas des autres. Faudrait aussi faire le ménage dans le noyau Linux qui devient de plus en plus gros à force de supporter du matériel "peu probable", enfin tant que c'est pas le mien hein!

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

    Ben ça dépend s'il est concerné par le cas "peu probable", ou s'il se soucie d'avoir une montagne de scripts shell tous plus "presque pareils" les-uns que les-autres mais maintenus complètement indépendamment les-uns des-autres.
    En ce qui me concerne, ça me ferait un peu chier qu'on me dise que "non, avec Linux, tu ne pourras jamais couvrir ton cas, tu comprends beaucoup d'admin pense que ton cas est «peu probable» alors tant pis, tu dois en chier". Mais c'est assurément une opinion très personnelle.

    Un peu comme quand on décide de changer l'orga des menus de Gnome parce que "c'est mieux". Sauf que 2 ans plus tard, on fait machine arrière parce que ça pue. Le problème n'est pas d'avoir essayé (bien au contraire), le problème est dans le fait qu'on bascule un truc expérimental dans un outil de production.

    Comment on passe de "expérimental" à "prêt production"? Si aucune distro n'intègre le truc "trop expérimental", il va rester expérimental un paquet d'années. Si tu as besoin d'un truc testé pendant plusieurs années (par "les autres") avant de le voir sur ta distro, vois avec les mainteneurs de ta distro!

    Le changement c'est bien quand c'est nécessaire. 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). Mon besoin n'a pas changé et pourtant je vais être amené a changer : est-ce une bonne chose ?

    Pas plus que les outils de dévs qui ne me servent personnellement à rien mais qu'on a mis dans la chaîne de développement alors qu'ils automatisent tout un tas de trucs dans mon dos. Un Makefile écrit avec amour complètement à la main, c'était tellement plus simple à appréhender que tout ce fatras d'outils qui génèrent des trucs et des machins et à la fin on ne sait pas comment ton Makefile a été pondu sans lire de la doc supplémentaire.

    X.org n'est qu'une implémentation de X, un protocole qui a ... 30 ans.

    Ouai, il fait un peu plus que juste supporter le protocole X. Ah, et j'ai une mauvaise nouvelle pour toi au sujet du futur de l'affichage graphique, mais je ne sais pas si tu es prêt à l'entendre...

    Actuellement, vu le nombre de distro qui utilisent systemd, je ne comprend pas comment du peux parler de généralités dans les config. Sans compter que systemd ou pas, je ne connais auncune distro qui n'a pas de spécificité dans sa config. Et puis, le problème se posera toujours si tu dois naviguer entre linux et un autre Unix.

    Un des intérêts de systemd, c'est que justement tu vas adoucir les changements d'une distro à l'autre. Après si tu râles parce que tu as trouvé une ch'toute petite différence entre 2 distros, je me demande comment tu peux supporter le méga-bordel qu'on a aujourd'hui.

    Et si tu dois naviguer entre Linux et d'autres Unix... ben ça ne changera rien, effectivement, ce sera autant le bordel qu'aujourd'hui. D'un autre côté, si tu veux que tout soit pareil, c'est simple: il faut installer un seul et unique OS partout!

    Donc lire la doc du service est plus long que lire la doc du service + la doc de systemd. CQFD
    A moins que systemd soit tellement bien foutu qu'il te gère tout seul tes vhosts apache et tes instances PostgreSQL ?

    Je ne pense pas que lire juste la doc du service permette de comprendre quand et dans quelles conditions/environnement son script init va être appelé. Pour ton cas, tu connais déjà l'existant, donc encore une fois: ça ne te concerne pas et par conséquent, tu t'en fous. Pour ceux qui découvrent leur premier système d'init, je ne crois pas qu'ils auront plus de mal à décortiquer systemd que sysV.

    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.
    Comprend que ce type d'arguments relève plus du décideur pressé que de la réalité quotidienne.

    À te lire, il faut croire que si c'est pas "parfait", il vaut mieux laisser le super-méga-bordel qu'on traîne depuis des années tel quel parce que toi tu le connais bien et tu en as l'habitude.
    Franchement j'aimerais que les admins et autres qui râlent contre systemd se lancent ensembles dans un fork d'une distrib juste pour enlever systemd. Quand ils reviendront en disant qu'ils n'ont pas que ça à foutre de maintenir la chiadée de scripts init, on pourra leur expliquer que les mainteneurs des autres distros ont aussi d'autres choses qu'ils aimeraient bien faire avec leur temps.