• [^] # Re: Bug ferme chez tmux

    Posté par . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 8.

    Je ne prétends pas répondre à la place de Grégoire G, ce serait malvenu, mais tu exagères son propos et tu lui fais dire ce qu'il n'a pas dit.

    Mais ce n'est pas parce que Redhat n'est pas adapté à TON usage que c'est de la merde.

    Il ne prétend pas que « c'est de la merde », il préfère Debian à RedHat, sans pour autant qualifier RedHat de « merde ».

    Ben pour des serveurs, je trouve ça cool. Ca t'évite d'avoir des services non configuré qui vont être lancé automatiquement.

    Il n'a pas dit le contraire. Il mentionne juste un cas précis, et tu en a fait une généralité.

    Systemd, la source de tous les mots.

    De même, il précise qu'il trouve systemd « pénible », et tu généralises sans fondement.


    Systemd a apporté de nombreuses réponses à bon nombre de problème (il n'y a qu'à voir son adoption rapide par les distributions. Si c'était si inutile que ça, il n'y aurait pas eu tant d’engouement).

    L'adoption de systemd n'est pas le résultat d'un consensus de la communauté des utilisateurs de Linux. Les paragraphes qui suivent devrait te convaincre.

    Premièrement, il faut reconnaître que systemd est plus facile à utiliser que SysVInit pour les mainteneurs d'une distribution. Et c'est pourquoi il a été adopté, car ces sont précisément les mainteneurs qui ont le dernier mot sur les programmes par défaut d'une distribution.

    Ce ne sont pas les utilisateurs (autant sysadmin, développeurs ou personne lambda) qui ont choisi systemd. Et il ce trouve que systemd est moins bon que SysVInit du point de vue utilisateur, comme le montre ce journal et de nombreux autres avant, ici ou ailleurs sur Internet.

    Il faut aussi reconnaître que systemd à été poussé de force dans RedHat et Fedora, tout simplement car RedHat contrôle ces deux distributions. Cette migration a forcé certain programmes à être fortement dépendant de systemd, notamment car systemd est conçut comme un monolithe. Si tu dépends d'une fonctionnalités quelconque de systemd, alors tu dépends la totalité de systemd.

    Rappelons aussi que systemd contient en autres udev, un système de logs, un gestionnaire de session, et gère une partie de dbus. Ainsi les programmes qui ont besoins de telles fonctionnalités doivent inclure du code pour pouvoir fonctionner sur un nombre croissant de distributions. Et comme maintenir plusieurs version d'un même code est difficile, certain programmes sont devenu simplement dépendant de systemd.

    Un peu à la manière de pulseaudio qui ce place entre tout autre serveur son et le noyau, systemd ce place entre tout programmes utilisateurs et le noyau. C'est la raison majeure de l'adoption massive de systemd. Et c'est pourquoi le terme « forcé » est tout à fait approprié.

    C'est encore une fois un cas typique qui montre qu'une adoption massive n'est en générale pas corrélé à la qualité technique.


    Tiens, on va prendre un exemple : systemd et wayland. Systemd est sorti en 2010 et à déjà été adopté par la grande majorité des distributions. Wayland existe depuis 2008 et à encore pas mal de chemin à faire.

    Wayland n'est pas aussi mature que systemd. Le contexte n'est pas le même, les programmes ont des finalités bien différentes. Bref, c'est comparer l'incomparable, cet exemple n'est pas convaincant.