Journal Les problèmes d’un desktop sans systemd ?

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
17
3
nov.
2022

Dans le monde Linux, le gros troll de la décade est, avec peu de contestation possible, le passage de sysVinit à systemd.

Beaucoup de choses ont été dites sur les problèmes de systemd (l’aspect monolithique, la complexité, les logs en binaire, le vendor-lock en forçant la dépendance à systemd de gros blocs logiciels comme GNOME, etc).

Force est de constater que recherchant pour le moment un certain minimalisme numérique, systemd ne me plait pas : plein de process qui tournent dès le démarrage, une logique que j’ai du mal à appréhender. Une chose est certaine : sur un serveur, je déteste systemd (je préfère une pile de bons vieux scripts shell).

Mais en voyant les distros systemd-free (devuan, void linux, alpine, artix, mxlinux, antix…) qui se vantent, entre autres, d’améliorer la vitesse de boot sans systemd, une question me taraude :

« Qu’est-ce qu’on perd en abandonnant systemd sur un laptop mono-utilisateur ? »

Les points vraiment difficiles dans ce cas d’usage traditionnel sont l’autonomie (optimisation de la consommation d’énergie), la détection de matériel hotplug comme le multiécran, le support wifi, le support bluetooth, des trucs genre les touches multimédias, etc…

Des trucs sur lesquels GNU/Linux a fait des bonds phénoménaux sur ces dix dernières années. Sur la plupart des distributions, ça "juste marche" et quand ça marche pas, faut juste installer le bon package.

Est-ce que ces améliorations sont liées, d’une manière ou d’une autre, à systemd? Que vais-je perdre si je décide de migrer demain mon laptop vers Devuan, par exemple ? Si c’est "rien du tout", alors pourquoi a-t-on besoin de systemd ? Si c’est "tout ce que t’as dit", alors pourquoi n’est-ce pas clairement expliqué par les afficionados de systemd ?

Avez-vous des expériences, des retours, des connaissances spécifiques à systemd et sur ce débat ? Utilisez-vous une distrib sans systemd ? (voidlinux me fait de l’œil, j’avoue).

Merci pour vos retours

  • # Je pose la question dans l'autre sens

    Posté par  (site web personnel) . Évalué à 10. Dernière modification le 03 novembre 2022 à 14:44.

    Perso je me poserais la question dans l'autre sens: qu'est-ce que tu gagnes à enlever systemd ?

    Si j'ai bien compris, dans les faits, systemd c'est pas que un outil, mais c'est aussi une spec, et chacun de ses binaires dont ton applicatif est censé être dépendant, sont remplaçable par n'importe quoi d'autre qui en respecte la spec.

    Perso je laisse systemd là où il est, c'est facile et pratique, pour ce que j'en fait, deux trois unit de temps en temps, un peu de conf, voilà. Et surtout pour le reste ça ne me cause aucun soucis 99% du temps (c'est à dire quand je ne m'en soucie pas).

    Attention, du troll se cache ensuite, si vous ne voulez pas lancer de flame wars, ne lisez pas la suite.

    Peut-être que justement, ce qu'il manque sous linux et ce qui en cause toute la complexité, c'est le fait qu'au dessus du kernel y'a plus rien, les distro n'ont pas de spec sur ces aspects gestion de l'OS bas niveau, gestion des services, etc… les RC scripts sont des scripts, et ça me donne la chair de poule, de laisser des aspects aussi critiques du système à un interpréteur de ligne de commande (en toute honnêteté, je suis développeur, je touche à plusieurs langage, mais le BASH/SH/*SH c'est juste une syntaxe horrible, avec aucune robustesse, et quand quelqu'un le maîtrise bien, le relire c'est juste mission impossible).

    • [^] # Re: Je pose la question dans l'autre sens

      Posté par  (site web personnel, Mastodon) . Évalué à 9.

      C’est une excellente question. Pour bien des cas, je pense qu’enlever systemd n’a aucun sens.

      Mais je suis dans une démarche plutôt minimaliste/comprendre ce que fait mon ordinateur et lui laisser le moins possible de trucs "que je n’utilise pas/comprends pas". Historiquement, je faisais cela en désactivement le lancement de process dans /etc/init.d/, en rebootant et en voyant ce qui avait changé. Aussi simple qu’un mv de fichier vers un backup.

      Le problème de systemd, c’est que c’est justement ça : ça fait plein de trucs que je ne comprends pas. Il y’a d’une part ma faute (je n’arrive pas/n’ai pas envie de me plonger dans systemd/je lis les scripts bash assez intuitivement) et d’une part systemd (je peux pas juste lancer un grep dans le répertoire init pour voir ce qui est censé tourner, je peux pas simplement limiter la horde de process qui tournent sur mon ordi dès le démarrage).

      L’une des critiques récurrentes est que la pseudo-modularité de systemd est essentiellement illusoire, que tout dépend de tout et bonne chance pour modulariser (après, je ne l’ai pas testé moi-même, je ne fais que rapporté l’expérience de ceux qui ont tenté).

      Donc je comprends la position "ça fonctionne donc je touche pas" mais j’explore justement le contraire "qu’est-ce qui casse si je touche à le truc".

      Mes livres CC By-SA : https://ploum.net/livres.html

      • [^] # Re: Je pose la question dans l'autre sens

        Posté par  . Évalué à 8. Dernière modification le 03 novembre 2022 à 15:44.

        Oui, systemd débarque avec énormément de petits outils qui remplacent d'autres outils plus traditionnels (hostname, cron, automount, syslog, etc etc).

        Mon opinion à moi (que je partage) est que cet aspect monolithique vient principalement d'un problème de packaging: systemd c'est tout ou rien, il est rarement possible de faire ses emplettes dans les fonctionnalités offertes par systemd.
        Je pense que ça explique cette perception de pseudo-modularité de systemd […] essentiellement illusoire .
        Ça décourage aussi les alternatives: systemd installe toujours ses implémentations d'interfaces sur le système, proposer une implémentation alternative est compliqué…

        Passé ce cap, systemd fonctionne globalement très bien. Et en tant qu'utilisateur desktop, je suis content de pouvoir écrire facilement de petits services (automount, timers, services utilisateurs…) qui seront associés à ma session.

        • [^] # Re: Je pose la question dans l'autre sens

          Posté par  (site web personnel) . Évalué à 10.

          Est-il vraiment sain de faire trop modulaire ?

          Sous Linux, on a un système de son (pulseaudio) qui est indépendant du système vidéo (wayland). Résultat : lorsque je branche un câble hdmi qui transporte à la fois l'audio et la vidéo, il faut que je fasse deux réglages.

          On me dit que Pipewire réglera le problème, mais des cas d'usage comme"je veux faire une visioconf" ou "je veux voir un flim" qui demandent une coordination audio/vidéo auraient du être pris en compte dès le début.

          Il manque peut être un chef d'orchestre et systemd essaye de jouer ce rôle sans plaire à tout le monde.

          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: Je pose la question dans l'autre sens

          Posté par  . Évalué à 1.

          systemd c'est tout ou rien […]

          C'était précisément l'argumentation du contraire qui était avancée pour la promotion du bouzin.

      • [^] # Re: Je pose la question dans l'autre sens

        Posté par  . Évalué à 10.

        je peux pas juste lancer un grep dans le répertoire init pour voir ce qui est censé tourner, je peux pas simplement limiter la horde de process qui tournent sur mon ordi dès le démarrage

        Tu peux parfaitement avoir toutes ses infos.

        Pour le premier systemctl list-units --type service, oui tu connais déjà les binutils et pas la commande systemctl, mais savoir qu'il faut aller /etc/init.d par exemple ne s'invente pas non plus.

        Pour le second systemctl disable ton_service et il ne sera plus lancé.

        Quelqu'un qui n'a pas pris peur en lançant man grep et doit pouvoir survivre à un man systemctl.

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

        • [^] # Re: Je pose la question dans l'autre sens

          Posté par  . Évalué à 1.

          Tu peux parfaitement avoir toutes ses infos.

          Je pense que tu n'as pas saisi le point de vue.

          Ça n'est pas une question d'avoir les infos ou pas. C'est à propos de la manière d'y arriver. Là où grep était utile, en farfouillant dans un répertoire connu, il faut à présent lancer une commande, qui ne dit pas grand chose sur le ou les endroit(s) où elle va chercher ses infos.

          • [^] # Re: Je pose la question dans l'autre sens

            Posté par  . Évalué à 10. Dernière modification le 04 novembre 2022 à 11:31.

            J'ai évité de l'écrire dans mon premier commentaire parce que ça allait être pris comme une attaque, mais ce que j'avance c'est que c'est de la résistance aux changements.

            Tu peut avoir toutes ces informations avec systemd sans problème et ce sera plus simple qu'avec sysvinit :

            • tu n'a pas à comprendre des choses parfois subtiles en shell
            • tu va bien moins reposer sur grep/sed/awk/… qui peuvent ne pas donner ce que tu attends si par exemple ton expression n'est pas assez précise ou trop au contraire

            D'un point de vu utilisateur systemd n'est complexe que quand tu choisi d'ignorer que t'a passer des années/décénies à apprendre le précédent, mais ça c'est de la résistance aux changements.

            Vraiment il suffit de voir le man de systemctl, c'est un point d'entrée tout à fait convenable pour commencer à utiliser systemd. Pour sysvinit tu as quoi ?

            Pour les gros barbus virils pour qui tout est fichier, tu as une introduction à quels fichiers sont manipulé dans le man de systemctl et tu aura une explication complète dans le man de systemd.unit (il est pointé par le man de systemctl).

            Qui veut savoir n'a qu'à se baisser pour avoir toutes les informations dont il a besoin.

            Le problème de ploum c'est de ne pas vouloir s'y intéresser tout en ayant une conviction : systemd irais à l'encontre d'un « minimalisme numérique ».

            https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

            • [^] # Re: Je pose la question dans l'autre sens

              Posté par  . Évalué à 10.

              Sincèrement si au lieu de freiner des 4 fers, on prends quelques dizaines de minutes pour lister les usages qu'on a avec l'un et chercher comment les reproduire avec systemd au lieu de s'inventer des raisons de ne pas y passer, on s'achète de la tranquillité à pas chère.

              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

              • [^] # Re: Je pose la question dans l'autre sens

                Posté par  . Évalué à -5. Dernière modification le 04 novembre 2022 à 15:06.

                Sincèrement, peut-être que d'arrêter de voir des biais en tout genre dans les contre-argumentations serait une manière d'encourager des discussions constructives, tu ne crois pas¹? C'est facile de taxer les autres de succomber à la résistance au changement, vraiment très facile… Les erreurs de conception et les usines à gaz, ça existe aussi. Encore faut-il en reconnaître une quand on la voit.

                ¹ T'inquiète, je crois que je connais ta réponse…

                • [^] # Re: Je pose la question dans l'autre sens

                  Posté par  . Évalué à 9.

                  Comme dis plus haut, je savais que parler de résistance aux changements aller être mal pris et je m'en suis gardé dans un premier temps. Mais j'ai du mal à voir autrement un comportement qui consiste à refuser un nouvellement mis en place par la plupart des distributions dont de ce que je comprends celle de l'ami ploum tout en :

                  • affirmant detester systemd
                  • affirmant ne pas connaître systemd
                  • associant des concepts qui semblent flous « minimalisme numérique »

                  Je veux bien entendre des arguments qui expliquent que systemd pose des problèmes, qu'il fait trop de choses ou pas assez, qu'il a était intégré au chausse pied ou tout autre argument. Mais là je n'en vois pas. Détester ce n'est pas un argument, mais un avis et je veux bien avoir une explication d'en quoi systemd empêche le minimalisme numérique1.

                  Les erreurs de conception et les usines à gaz, ça existe aussi. Encore faut-il en reconnaître une quand on la voit.

                  J'en serais probablement incapable. Je suis loin d'être connaisseur et j'ai des besoins très simples voir simplistes. Mais une usine à gaz ce n'est pas une sensation, ce n'est pas lié à l'intime et au ressenti ça s'appuie sur des arguments. J'ai pas de problème à ce qu'il y ai des soucis dans systemd2. Lors des grands débats autour de systemd, il n'était pas mon approche préféré. Je lui préférais upstart (et je pense qu'upstart pouvait devenir une brique simple et très utile).

                  Rester dans un état d'esprit où l'on déteste ce vers quoi la majeure parti des communautés semblent aller ça me paraît être surtout un moyen de se donner des aigreurs d'estomac. Prendre le temps de prendre un peu de recul et de se mettre dans un état d'esprit neutre pour essayer. Ça ne prend pas forcément beaucoup de temps et si vraiment on voit des problèmes ça enrichi.

                  Dommage si tu y vois de la fermeture d'esprit.


                  1. si je cherche un peu ce que c'est ça ne semble avoir aucun rapport avec un aspect technique, mais de comment on aborde le numérique. Installer une distribution et vouloir en triturer les couches basses semble être l'inverse du minimalisme numérique alors qu'installer un ordinateur et s'en servir uniquement pour des besoins qui ne sont pas numériquement centrés (donc pas améliorer le fonctionnement de la machine pour la satisfaction) est du minimalisme numérique (quelque soit l'OS ou la distribution qui fonctionne dessus). 

                  2. mais après une adoption massive, je n'ai pas l'impression de voir une arrivé massive de problèmes. C'est que ça doit pas être si désastreux que ça. 

                  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

            • [^] # Re: Je pose la question dans l'autre sens

              Posté par  . Évalué à 2.

              systemd irais à l'encontre d'un « minimalisme numérique ».

              En fait, il suffit de peser les processus pour savoir si tu peux garder les guillemets.
              Mesure de la RSS de systemd, puis mesure de la RSS utilisée par un concurrent valable (non, pas sysVinit). Selon mes mesures, qui sont assez vieilles, systemd est clairement plus lourd, d'un ordre de grandeur.
              Alors, certes, on parle ici de concurrents dont l'ordre de grandeur est de quelques megs de RSS (si lié dynamiquement à glibc, sinon ce sont quelques centaines de kilos) à systemd qui étais, de mémoire, dans les 30 ou 40 megs.
              Je parle ici de "juste systemd-init" comparé à "runit + runsvdir + tous les runsv + tous les svlogd", pour être fair play.
              Systemd ayant une augmentation de RSS par nouveau daemon quasi nulle, alors que runit nécessite 2 process par daemon journalisé, chacun pesant 4Kio avec linkage statique ou vers muslc, ou ~650Kio en linkage dynamique glibc.
              Systemd dépend, de mémoire, explicitement de glibc, je ne sais pas s'il est possible de lier statiquement.

              Évidemment, ces valeurs sont absolument négligeables de nos jours, je ne remets pas ça en cause, mais systemd est clairement plus lourd que sa concurrence.
              Il a aussi plus de fonctionnalités, certaines des plus utiles, telles que l'activation par sockets et les dépendances.

              Il est donc indéniable que systemd n'est pas minimaliste. Tout comme il est a mon avis indéniable que systemd est meilleur sur tous les points que sysvinit+rc.d (et ce point la pourrais me mener au bûcher, je sais).

              • [^] # Re: Je pose la question dans l'autre sens

                Posté par  . Évalué à 1.

                Le minimalisme numérique n'a rien à voir avec ça. Passer du temps à observer si ton processus d'init prend plus ou moins de RSS c'est l'opposée du minimalisme numérique. Utiliser ton ordinateur pour améliorer celui-ci plutôt que de le garder éteins c'est exactement ce que combat le minimalisme numérique.

                Il est donc indéniable que systemd n'est pas minimaliste.

                Tout ce temps que tu aura passé à mesurer les kio utilisés par systemd, pour ensuite les comparer à sysvinit, openrc et ruinit, puis à configurer finement toute ta distribution pour choisir dans le détail ce qui est lancé, puis à désinstaller tous ces Mio que tu n'utilise pas. Tout ça pour la satisfaction de "j'ai un système minimaliste" c'est l'inverse du minimalisme numérique1.

                Le minimalisme numérique consiste à utiliser le numérique de manière frugal, il interroge les pratiques des utilisateurs face au numérique et pas la technique.

                Ce dont tu parle est plus de l'éco-conception ou conception responsable.


                1. et la différence est énorme entre : manquer de ressources et chercher à garder son matériel et passer des heures à réduire la consommation de ma machine pour le plaisir d'avoir un système qui ne consomme pas les ressources dont il a disposition 

                https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                • [^] # Re: Je pose la question dans l'autre sens

                  Posté par  . Évalué à 3. Dernière modification le 08 novembre 2022 à 00:42.

                  Tout ce temps que tu aura passé à mesurer les kio utilisés par systemd, pour ensuite les comparer à sysvinit, openrc et ruinit

                  A peu près 5 minutes par système (et encore. De toute façon j'avais déjà un dual-boot entre ma debian custom et une debian normalle, pour cause qu'il faut tout une stack logicielle pour faire tourner un vulgaire soft de video-conf sur firefox… et je crois que ça merdait sur chromium aussi? Je sais plus), un jour que j'étais curieux de vraiment savoir.

                  Tout ça pour la satisfaction de "j'ai un système minimaliste" c'est l'inverse du minimalisme numérique1

                  J'ai un PC qui a moins de 200 megs de ram. Il tourne très bien merci. Mais pas si je gâche 30 megs pour l'init.
                  Honnêtement, je conserve cette machine juste parce que. A l'origine, parce qu'elle dispose encore de connecteurs P-ATA, et y'a même du SCSI et un lecteur de bande. Je me disais "on sait jamais, une connaissance pourrait me demander de récup des données…".
                  Cet argument est maintenant caduc, mais je garde la machine pour le fun :)
                  Chose que j'assume d'ailleurs. Je pense avoir bien indiqué que l'impact de RSS était négligeable sur les machines modernes.

                  Ce dont tu parle est plus de l'éco-conception ou conception responsable

                  Je vois ton point. Je suppose que ça marche aussi.

          • [^] # Re: Je pose la question dans l'autre sens

            Posté par  . Évalué à 8.

            en farfouillant dans un répertoire connu, il faut à présent lancer une commande, qui ne dit pas grand chose sur le ou les endroit(s) où elle va chercher ses infos.

            C’est un peu faux problème. Le mot clé ici est “connu”. Il est connu juste parce que t’as passé 10 minutes à te demander comment ça marche, et tu sais que ça commence dans /etc/init.d. En tout cas pour sysv init sous Linux. Et puis c’est pas que un répertoire, tu vas aussi te taper du /etc/rc*, et d’autres exceptions.

            Bref, ce répertoire n’est pas particulièrement connu, t’as juste l’habitude de faire comme ça. macOS utilise launchd, grosse inspiration pour systemd, et tout le monde sait que ça se passe dans /Library/LaunchAgents ou LaunchDaemons. T’aurais exactement la même remarque si Apple décidait à passer à sysv.

            La question c’est surtout “quel est l’info minimale à connaître pour commencer a groker systemd à la rache”, et j’ai pas l’impression que ça soit tant que ça. Systemctl et journalctl font une énorme partie du travail, les units vont dans /etc/systemd, et ça te permet de lancer la machine

            Linuxfr, le portail francais du logiciel libre et du neo nazisme.

      • [^] # Re: Je pose la question dans l'autre sens

        Posté par  (site web personnel) . Évalué à 10.

        Il y’a d’une part ma faute (je n’arrive pas/n’ai pas envie de me plonger dans systemd/je lis les scripts bash assez intuitivement) et d’une part systemd (je peux pas juste lancer un grep dans le répertoire init pour voir ce qui est censé tourner, je peux pas simplement limiter la horde de process qui tournent sur mon ordi dès le démarrage).

        Je pense que c'est surtout le premier point le problème. Si on veut, on peut très facilement comprendre comment fonctionne systemd. (Par exemple avec ça https://wiki.archlinux.org/title/Systemd)

        je peux pas juste lancer un grep dans le répertoire init pour voir ce qui est censé tourner

        Tout est dans /etc/systemd/system/ (configuration "admin", des liens symboliques) et /usr/lib/systemd/system/ (configuration "développeur", des fichiers)

        ls -l /etc/systemd/system/default.target me dit que par défaut on lance /usr/lib/systemd/system/graphical.target (chez moi, Fedora 36)

        Un cat /usr/lib/systemd/system/graphical.target (ou directement grep -E "(Wants|Requires)" /etc/systemd/system/default.target te dit qu'on a besoin de multi-user.target et display-manager.service (si possible).

        Un ls /etc/systemd/system/graphical.target.wants me dit que mon admin a aussi rajouté 6 autres services voulu par graphical.target. (Je te laisse voir lesquels)

        Et tu peux continuer comme ça a descendre l'arbre de dépendances. Alors oui, c'est un peu plus compliqué qu'un dossier avec des scripts 10_foo.sh, 50_bar.sh… où tu peux voir rapidement ce qui sera lancé et dans quel ordre. Alors oui, c'est plus facile de configurer son système. Il suffit de rajouter un lien symbolique dans /etc/systemd/system/foo.target.wants vers un service pour que le service soit lancé. T'as pas besoins de gérer les dépendances et de renommer tes fichiers avec des nombres pour garder un système globalement cohérent pour être sur que tout se lance dans l'ordre.

        Toute les commandes à base de systemctl, c'est des outils "user-friendly" pour faire les liens et parcourir l'arbre des dépendances à ta place. Mais t'en a pas besoin.

        Si tu veux l'arbre de dépendances : systemctl list-dependencies
        Rajouter un lien symbolique pour mettre un service en dépendance d'une target : systemctl add-requires TARGET UNIT

        je peux pas simplement limiter la horde de process qui tournent sur mon ordi dès le démarrage).

        Tu vires des liens symboliques et c'est bon.
        C'est pas vraiment plus compliquer que virer tout les scripts dans un dossier pour sysVinit. C'est juste que sysVinit tu connais et que systemd non.

        mais j’explore justement le contraire "qu’est-ce qui casse si je touche à le truc".

        Tu te crées une nouvelle target à toi, sans dépendance et tu fais pointer /etc/systemd/system/default.target dessus. Tu devrais vite voir ce qui casse :)

        Matthieu Gautier|irc:starmad

      • [^] # Re: Je pose la question dans l'autre sens

        Posté par  . Évalué à 1. Dernière modification le 04 novembre 2022 à 10:28.

        Il y’a d’une part ma faute (je n’arrive pas/n’ai pas envie de me plonger dans systemd/je lis les scripts bash assez intuitivement)

        Je pense qu'on ne peut pas vraiment t'en vouloir (à commencer par toi) de n'avoir pas pris/eu le temps d'explorer. Après tout, c'est un système complet, qui n'a rien à voir avec l'ancien, ni dans sa philosophie, ni dans son approche, ni dans sa manière de coder, ni dans sa structure, ni dans sa terminologie, ni dans sa nomenclature, ni dans sa syntaxe… Tu as probablement passé un temps considérable à comprendre ce qui se faisait avant, du coup recommencer le même taf et devoir oublier¹ ce que tu avais appris peut paraître décourageant.


        ¹ En gros, hein, je parle de ressenti, ici, inutile de jouer sur les mots…

        • [^] # Re: Je pose la question dans l'autre sens

          Posté par  (site web personnel) . Évalué à 10.

          Je pense qu'on ne peut pas vraiment t'en vouloir (à commencer par toi) de n'avoir pas pris/eu le temps d'explorer.

          C'est un peu du foutage de gueule quand même.
          Ploum veut supprimer les composants qui tournent inutilement sur son système, quitte à faire des tests finalement assez avancés et bas niveaux et de comprendre ce qu'il se passe. Pour atteindre une sobriété numérique qui me semble basée sur de mauvaises métriques.

          La moindre des choses dans cette démarche c'est d'essayer de comprendre justement comment fonctionne systemd, pour évaluer réellement si c'est un atout ou un obstacle dans sa démarche. Dire juste je n'en veux pas en ayant un apriori basé sur une vision hors sol me semble contraire à ses propres objectifs.

          Tu as probablement passé un temps considérable à comprendre ce qui se faisait avant, du coup recommencer le même taf et devoir oublier¹ ce que tu avais appris peut paraître décourageant.

          Cela s'appelle de la résistance au changement, ce qui ne me semble pas compatible avec sa démarche.

    • [^] # Re: Je pose la question dans l'autre sens

      Posté par  (Mastodon) . Évalué à 9.

      Peut-être que justement, ce qu'il manque sous linux et ce qui en cause toute la complexité, c'est le fait qu'au dessus du kernel y'a plus rien

      C'est justement le côté intéressant des *BSD ou d'autres systèmes d'exploitation où on n'a pas cet assemblage hétérogène et différents selon les distributions d'un noyau et d'outils pour l'utilisateur, mais une vraie intégration et des outils et le noyau qui évoluent en même temps.

      • [^] # Re: Je pose la question dans l'autre sens

        Posté par  (site web personnel, Mastodon) . Évalué à 4.

        en effet, c’est ce qui m’intéresse très fort dans BSD. Mais la moindre popularité de BSD implique souvent certaines difficultés avec le hardware (moins bonne autonomie de la batterie, pas de bluetooth sous openbsd, moindre performance en utilisation desktop, etc…)

        D’où le fait que je louche vers Void qui semble tenter de réconcilier le meilleur de deux mondes.

        Mes livres CC By-SA : https://ploum.net/livres.html

        • [^] # Re: Je pose la question dans l'autre sens

          Posté par  (site web personnel) . Évalué à 9.

          Si c'était que le hardware, ça passerait encore. Mais même sur le serveur, les BSDs sont un peu à la ramasse.

          Par exemple, j'ai du corriger quelques bugs pour Ansible sur NetBSD et FreeBSD (la détection du système de paquet, ce genre de chose) parce que je devais être le premier à m'en servir.

          Automatiser l'installation d'un OpenBSD ou de NEtBSD m'a toujours donné l'impression d'être un bricolage (e.g., pas de preseed/kickstart à l'époque).

          Et l'intégration, c'est un peu de la propagande, n'importe qui ayant utilisé de façon un peu poussé voit bien que ça ne corresponds pas vraiment à la réalité.

          Par exemple, il y a 3 firewalls sur NetBSD (PF, NPF, IP Filter) et FreeBSD (PF, IPFW et IPFILTER). Ce n'est pas un souci, mais c'est pas ce que j'appelle de l'intégration.

          Et de même, l'idée que "les BSDs sont mieux écrit", ça me parait être surtout le signe qu'il y a moins de monde, cf une présentation de 2017 toujours valable.

          C'est assez triste, car je pense qu'il est important que des alternatives à Linux existent, mais pour avoir tenter l'aventure, c'est quand même aller contre le courant.

          • [^] # Re: Je pose la question dans l'autre sens

            Posté par  (site web personnel, Mastodon) . Évalué à 4.

            Par exemple, j'ai du corriger quelques bugs pour Ansible sur NetBSD et FreeBSD (la détection du système de paquet, ce genre de chose) parce que je devais être le premier à m'en servir.

            En quoi est-ce la faute des BSD ? Ansible fait partie de l'installation de base ? Non, donc là, c'est plutôt du côté d'Ansible qu'il faut regarder.
            D'ailleurs, ils le disent eux-mêmes:

            BSD support is important to us at Ansible. Even though the majority of our contributors use and target Linux we have an active BSD community and strive to be as BSD-friendly as possible. Please feel free to report any issues or incompatibilities you discover with BSD; pull requests with an included fix are also welcome!

            Ça ne dépend donc que de la communauté.

            Par exemple, il y a 3 firewalls sur NetBSD (PF, NPF, IP Filter) et FreeBSD (PF, IPFW et IPFILTER). Ce n'est pas un souci, mais c'est pas ce que j'appelle de l'intégration.

            Pourquoi ? Les trois fonctionnent très bien ? Perso, il y a 15 ans environ, j'étais passé d'IPFilter à PF sans aucun souci et sans rien installer de supplémentaire, juste une config noyau parce qu'à l'époque, je construisais mes noyaux.

            • [^] # Re: Je pose la question dans l'autre sens

              Posté par  (site web personnel) . Évalué à 8.

              En quoi est-ce la faute des BSD ? Ansible fait partie de
              l'installation de base ? Non, donc là, c'est plutôt du côté
              d'Ansible qu'il faut regarder.

              Mon point n'est pas qu'il y a un bug (ça arrive), mais que la communauté autour des BSD me semble trop petite car sinon, les bugs auraient été trouvé plus tôt. Et de ce point découle le fait que l'affirmation "c'est mieux" ne me parait pas se vérifier dans les chiffres.

              L'écosystème compte aussi un peu.

              Pourquoi ? Les trois fonctionnent très bien ? Perso, il y a 15
              ans environ, j'étais passé d'IPFilter à PF sans aucun souci et
              sans rien installer de supplémentaire, juste une config noyau
              parce qu'à l'époque, je construisais mes noyaux.

              Mais le point n'est pas de savoir si ça marche ou pas. Le point est que si il y a 3 firewalls, c'est parce que le ménage n'a pas été fait. Il y a sans doute des bonnes raisons (compat, manque de ressources, etc), mais ça veut dire aussi que tout comme Linux, les noyaux de NetBSD et FreeBSD ont des vieux trucs qui traînent, et que ce n'est pas comme j'ai entendu plusieurs fois "sur FreeBSD, on pense d'abord et ensuite on ajoute quand c'est bon". Le fait d'avoir la même fonction 3 fois me laisse à croire que les 2 premières n'étaient pas assez bonnes, un point normal surtout pour des bénévoles mais omis dans le discours.

              Et mon point n'est pas que les BSD sont mauvais, ou que ça soit un souci d'avoir 3 firewalls. Ça tourne correctement, la communauté fait avec ce qu'elle a comme ressources, et clairement, il y a moins de monde payé pour coder que sur les distros Linux, donc c'est assez impressionnant de réussir à maintenir l'OS.

              Mais j'ai trop souvent l'impression qu'on invente des qualités la ou il n'y a rien.

              C'est un peu ce que je retient de la présentation de 2017 que j'ai collé explique. C'est pas que les BSD sont mieux écrit que Linux qui fait qu'il y a moins de CVE. C'est qu'il y a moins de monde qui trouve car il y a moins de monde qui cherche.

              Et hélas, c'est sans doute pareil pour les soucis autre que les failles de sécurités, ce qui me fait relativiser beaucoup les affirmations sur le fait que ça soit mieux.

              • [^] # Re: Je pose la question dans l'autre sens

                Posté par  (Mastodon) . Évalué à 3.

                En quoi est-ce la faute des BSD ? Ansible fait partie de
                l'installation de base ? Non, donc là, c'est plutôt du côté
                d'Ansible qu'il faut regarder.

                Mon point n'est pas qu'il y a un bug (ça arrive), mais que la communauté autour des BSD me >semble trop petite car sinon, les bugs auraient été trouvé plus tôt. Et de ce point découle >le fait que l'affirmation "c'est mieux" ne me parait pas se vérifier dans les chiffres.

                Encore une fois, c'est le soucis avec les écosystèmes Linux, ce qu'a mis en avant Blacknight, on ne fait plus de distinctions entre le système et les "ports", c'est à dire les logiciels qui sont additionnels et ne sont pas fournis par défaut.

                Ansible fait partie de la seconde catégorie pour moi, et n'est peut-être pas vraiment utilisé par les communautés BSD. Mais le support en question dépend plus d'Ansible que des BSD.

                • [^] # Re: Je pose la question dans l'autre sens

                  Posté par  (site web personnel) . Évalué à 4.

                  Ansible fait partie de la seconde catégorie pour moi, et n'est
                  peut-être pas vraiment utilisé par les communautés BSD. Mais le
                  support en question dépend plus d'Ansible que des BSD.

                  Visiblement oui, il n'y a pas eu beaucoup d'usage d'Ansible.

                  Ensuite, c'est mon point. L'adéquation d'un OS pour le serveur, c'est aussi lié à la qualité de son écosystème, et pour le logiciel libre, c'est directement lié au fait qu'assez de personnes l'utilisent pour ça.

                  Et ce que j'ai vu, c'est que des choses que j'avais supposé comme de base sur un système Linux (avoir un moyen d'installer un serveur automatiquement, avoir des images cloud officiels, avoir un support basique pour des outils populaires) ne le sont pas forcément.

                  Et pour en revenir au point de base, si ça n'était qu'une question de hardware, ça irait, parce qu'on peut s'en sortir avant des achats judicieux ou de l'occase. Ça coûte un peu d'argent si tu dois changer ton matos, mais on s'en sort.

                  Sortir 50€ pour une carte wifi qui marche, c'est chiant, mais ça va.

                  Par contre, quand c'est du logiciel, l'investissement pour faire marcher est différent, et plus coûteux.

              • [^] # Re: Je pose la question dans l'autre sens

                Posté par  (site web personnel) . Évalué à 3.

                Mon point n'est pas qu'il y a un bug (ça arrive), mais que la communauté autour des BSD me semble trop petite car sinon, les bugs auraient été trouvé plus tôt.

                C'est la communauté des utilisateurs d'Ansible et BSD qui est trop petite… perso ça fait depuis longtemps que j'ai arrêté d'utiliser Ansible et je ne m'en porte que mieux… (terraform, shell scripts).

        • [^] # Re: Je pose la question dans l'autre sens

          Posté par  . Évalué à 10. Dernière modification le 03 novembre 2022 à 19:59.

          Je trouve que, justement, systemd apporte une certaine homogénéité dans les couches basses d'un GNU/Linux. Je ne comprends pas pourquoi l'homogénéité c'est bien quand on parle des BSD et c'est mal quand on parle de systemd ?

          Et pour les polémiques autour du risque de "mono-culture systemd" chez GNU/Linux, je me demande si le risque de "mono-culture rc.d" est aussi discutée chez FreeBSD ?

          • [^] # Re: Je pose la question dans l'autre sens

            Posté par  (Mastodon) . Évalué à 2.

            En fait le soucis vient surtout qu'il faut voir chaque distribution Linux comme une sorte de BSD, c'est à dire qu'elle réalise l'intégration à sa façon. Donc là si systemd est un projet externe qui veut apporter de l'homogénéité, il faut comprendre que ça "force" en quelque sorte toutes les distributions à s'adapter. C'est un peu comme si les choix d'un des BSD impactaient les autres, et si tu veux mon avis, ça gueulerait aussi si c'était le cas :) Mais là en l'état chacun est maître chez soi, donc ça reste plus calme.

            • [^] # Re: Je pose la question dans l'autre sens

              Posté par  . Évalué à 3.

              Là encore, je ne comprends pas l'argument. N'y vois pas de la mauvaise volonté de ma part mais dire que l'équipe de systemd force les distributions, ça me parait sur-estimer le pouvoir qu'ils ont vraiment. Certes, une fois que des mainteneurs décident de l'intégrer dans leur distribution, ils deviennent dépendants des choix du projet amont. Mais c'est le cas avec tous leurs amonts1.

              La comparaison est probablement maladroite de ma part mais :

              • Pourquoi ça gueule moins sur la GNU libc qui pose aussi des soucis ? C'est la faute des développeurs GNU si des logiciels utilisent des fonctionnalités spécifiques à la glibc ?
              • Ce sont les développeurs Bash qui ont forcé les distributions a massivement utiliser Bash, ce qui a pour conséquence de facilement faire des scripts non portables ?

              Cependant, je reconnais que systemd avance vite. Et j'ai plus l'impression que c'est ça qui pose soucis dans la communauté. Ça va vite parce que des gens sont payés pour travailler dessus à temps plein. Je ne vois pas comment les alternatives non financées peuvent suivre le rythme. C'est le même type de problème qu'on peut rencontrer dans certaines associations ayant des salariés (bénévolat de quelques heures par mois ou par semaine vs 35h/semaine…).

              Et donc, je me demande souvent : si une (ou plusieurs) boites finançai(en)t 3, 4 ou 5 développeurs à plein temps pour bosser sur s6, OpenRC, eudev, elogind et/ou la définition de nouvelles API Free Desktop, est-ce que les "débats" seraient moins dans la confrontation ?


              1. Mais il me parait clair que la relation avec les amonts est vraiment différente chez GNU/Linux par rapport aux BSD. Vu que chaque BSD est l'amont ou embarque directement les sources dans leur dépôt pour les outils ayant un amont. 

        • [^] # Re: Je pose la question dans l'autre sens

          Posté par  (Mastodon) . Évalué à 2.

          Void permettrait potentiellement d'avoir le meilleur des deux mondes, par contre je vois qu'ils utilisent musl et glibc, est-ce que c'est un choix à faire à l'installation ?

          Parce qu'avec musl ça peut empêcher de faire tourner certains trucs que tu pourrais trouver précompilé en ligne par exemple et pas fourni par la distribution.

          • [^] # Re: Je pose la question dans l'autre sens

            Posté par  . Évalué à 2.

            Void permettrait potentiellement d'avoir le meilleur des deux mondes, par contre je vois qu'ils utilisent musl et glibc, est-ce que c'est un choix à faire à l'installation ?

            Exactement oui.

        • [^] # Re: Je pose la question dans l'autre sens

          Posté par  . Évalué à 5. Dernière modification le 04 novembre 2022 à 11:51.

          en effet, c’est ce qui m’intéresse très fort dans BSD. Mais la moindre popularité de BSD implique souvent certaines difficultés avec le hardware (moins bonne autonomie de la batterie, pas de bluetooth sous openbsd, moindre performance en utilisation desktop, etc…). D’où le fait que je louche vers Void qui semble tenter de réconcilier le meilleur de deux mondes.

          Une chose à garder à l'esprit : void linux utilise musl libc. Cette dernière, bien qu'étant excellente (et utilisée notamment dans la toute aussi excellente Alpine ainsi que dans l'embarqué e.g. avec openwrt/buildroot) peut potentiellement entrainer des petites difficultés avec certains softs (e.g. Gnome ?). Il vaut mieux le savoir et faire le choix en connaissance de cause. Comme void utilise musl, l'absence de systemd est une conséquence logique : en retrouvant mes vieux posts, je disais ici, ici et ici la chose suivante : systemd ne marche qu'avec la glibc et Lennard a clairement dit qu'il refusait de résoudre le problème ("we will rely on good APIs exposed in the generally accepted Linux API which is the one glibc exposes".

          Concernant des expérimentations antérieures à systemd et moins connues que upstart/openrc/s6, j'avais autrefois bien aimé les approches décrites dans ces deux vieux posts (merci archive.org) concernant Pardus/Pisi (entièrement fait en Python) et IBM Developerworks (à base de Makefile :). J'avais aussi bien aimé Debian file-rc (qui n'est évidemment plus maintenu). J'ai aussi l'impression que uselessd est abandonné…

          Note que Artix propose différentes variantes et qu'en dehors de openrc tu as aussi dinit, s6, system66, runit

          • [^] # Re: Je pose la question dans l'autre sens

            Posté par  . Évalué à 2.

            Void te laisse le choix entre musl et glibc mais supporte les deux, et propose des binaires pour les deux. Si tu veux installer ton système en glibc tu peux. Idem pour x86 et ARM.

        • [^] # Re: Je pose la question dans l'autre sens

          Posté par  . Évalué à 6.

          en effet, c’est ce qui m’intéresse très fort dans BSD

          N'oublie pas la Slackware !

        • [^] # Re: Je pose la question dans l'autre sens

          Posté par  . Évalué à 2.

          Ça fait un an que je suis sous VoidLinux sur un petit Thinkpad et j'en suis très content. Avant ça j'étais sous Ubuntu, et à vrai dire je n'ai aucune idée de ce que je rate à ne pas avoir systemd. Peut-être journalctl, dont je n'ai pas trouvé d'équivalent (mais pas trop cherché non plus) ?

          • [^] # Re: Je pose la question dans l'autre sens

            Posté par  (site web personnel, Mastodon) . Évalué à 2.

            Est-ce que tout fonctionne out-of-the-box pour le suspend, le hotplug d’écran, le bluetooth, etc ? Est-ce que tu vois une différence d’autonomie ?

            Mes livres CC By-SA : https://ploum.net/livres.html

            • [^] # Re: Je pose la question dans l'autre sens

              Posté par  . Évalué à 3.

              Est-ce que tout fonctionne out-of-the-box pour le suspend, le hotplug d’écran, le bluetooth, etc ?

              Suspend oui. Pour les deux autres, pas du tout, mais dans mes souvenirs ça n'était pas le cas sous Ubuntu non plus. Après je n'utilise pas de vrai DE. J'ai des scripts pour ça, mais quand j'aurai le temps j'essaierai d'en faire des services, pour l'exercice.

            • [^] # Re: Je pose la question dans l'autre sens

              Posté par  (Mastodon) . Évalué à 4.

              Est-ce que tout fonctionne out-of-the-box pour […l, le hotplug d’écran, le bluetooth, etc ?

              Quel est le rapport avec systemd?

              Systemd ne gère à ma connaissance pas ce genre de choses.

    • [^] # Re: Je pose la question dans l'autre sens

      Posté par  . Évalué à 2.

      le BASH/SH/*SH c'est juste une syntaxe horrible, avec aucune robustesse, et quand quelqu'un le maîtrise bien, le relire c'est juste mission impossible

      C'est l'un des rares arguments valables pour systemd, sauf que… ben, les unit systemd ne semblent pas si simples que ça non plus.
      Peu importe que ça soit vrai ou pas, peut-être sera-tu intrigué par ces alternatives comme je l'ai été (mais jamais assez pour tester le code sur mes machines perso!):

      • dinit, le dernier que j'ai "trouvé" en faisant le zombi sur IRC. Il me semble qu'il utilise une syntaxe déclarative, comme systemd.
      • s6 qui utilise son propre DSL, justement parce que comme tu l'as pointé, bourne shell est loin d'être sympa.

      Bon, après, mon script runit le plus compliqué, et de très, très loin, c'est celui qui démarre udevd-systemd, programme qui existait bien avant systemd (donc, ses défauts ne proviennent pas de systemd), que voici:

      #!/bin/sh
      . /etc/runit/common
      
      need()
      {
          i=0
          while ! test -e "$1"
          do
              sleep "0.$i"
              test "$i" = 9 || i=$((i+1))
          done
      }
      
      mkdir -p /run/udev
      rm -f /run/udev/control #just in case
      rm -f /run/udevd_ready #just in case
      (
          need /run/udev/control # not sure we really need to wait for it
          echo "Trigger+settle:"
          udevadm --debug trigger --type=subsystems --action=add
          udevadm --debug trigger --type=devices --action=add
          udevadm --debug settle
          >/run/udevd_ready
          echo "Done: trigger+settle"
      ) &
      
      echo "Starting $SVNAME"
      exec env - PATH="$PATH" /lib/systemd/systemd-udevd -N late
      

      Quant à sa dépendance, qui est un truc que je source de partout:

      #!/bin/sh
      
      #this file provides some automatic features for runit daemons
      #notably it:
      #* provides the variable SVNAME, which is the name of the daemon dir
      #* provides the die() function
      #* sources an existing ./conf file
      #* automatically rotates logs on startup if there are logs and AUTO_ROTATE=yes
      #* redirects stderr to stdout
      #* enables some shell verbosity and safeties (-xe)
      
      die()
      {
          printf "%s\n" "$@" | tee ./down
          exit 1
      }
      
      SVNAME="$(basename $(pwd))"
      HAS_LOG="$(test -d "$(pwd)/log" && printf "yes")"
      exec 0<&-
      exec 2>&1
      set -xe
      test -f conf && . ./conf
      
      if test "$0" = "run"
      then
          if test "$SVNAME" = "log"
          then
              SVLOG="$(basename $(dirname $(pwd)))"
              SVNAME="${SVLOG}/${SVNAME}"
              AUTO_ROTATE="${AUTO_ROTATE:="no"}"
          fi
          test "yes" = "${AUTO_ROTATE}" -a "yes" = "$HAS_LOG" && \
              sv alarm "$(pwd)/log"
      fi
      

      On est très loin, je pense, des horribles scripts que l'on vois pour rc.d dans debian, notamment, pas vrai?
      D'ailleurs sur ce système j'ai un peu fait les trucs en mode organique, du coup s'pas super clean…

      La quasi totalité des autres daemons sont lancés ainsi:

      #!/bin/sh
      
      . /etc/runit/common
      
      test -e /run/sshd || mkdir /run/sshd
      
      echo "Starting $SVNAME"
      exec /usr/sbin/sshd -D -e
      

      Comme tu le vois, c'est très simple, et ça ne gère pas l'un des autres avantages de systemd: la gestion des dépendances. D'un autre côté, en pratique ce n'est pas gênant, surtout sur un desktop. Je fais aussi tourner mon Xorg de cette façon, mais i3 n'aime pas trop mon humour, il faut que je trouve la motivation pour utiliser un truc un peu moins monolithique pour avoir vraiment ce que je veux. Notamment, avoir les entrées contrôlées par leur propre daemon, au lieu d'avoir le WM qui fait tout: son job, c'est les fenêtres, par les raccourcis clavier, après tout.
      Mais bon, je comprend que des gens qui ont autre chose a faire ne s'amusent pas avec ça :) (sur un bureau, du moins)

  • # Il dit qu'il ne voit pas le rapport

    Posté par  (site web personnel) . Évalué à 9.

    Force est de constater que recherchant pour le moment un certain minimalisme numérique, systemd ne me plait pas : plein de process qui tournent dès le démarrage

    Je ne vois pas le rapport entre les deux.
    Avoir plein de petits processus pas trop gourmands en RAM et CPU n'ont rien de choquant et de problématique.

    • [^] # Re: Il dit qu'il ne voit pas le rapport

      Posté par  (Mastodon) . Évalué à 6.

      Oui, de toutes façons la première étape de la frugalité est de toutes façons de virer ce dont on ne se sert pas, et ça quel que soit le système utilisé.

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Il dit qu'il ne voit pas le rapport

      Posté par  (site web personnel) . Évalué à 10.

      J'ai 7 process avec systemd comme prefixe sur mon portable dans ps fax.

      J'ai 114 threads dans le kernel qui apparaissent dans ps fax

      Il est intéressant de voir qu'on suppose que les devs du kernel savent ce qu'ils font, mais pas les devs des distros ou les devs systemd vu que 7, c'est trop, mais 114, ç'est pas du tout un signe de complexité croissante dans le kernel.

      Par comparaison, la machine FreeBSD dans ma chambre a 27 threads kernel, et 33 sur le même hardware dans le salon sous OpenWRT.

      Alors bien sur, d'un coté, c'est un portable, et de l'autre, 2 Rpi 1, donc il y a moins de hardware. Mais logiquement, si on veux réduire la complexité, c'est pas forcément au niveau de l'OS qu'il faut commencer.

      • [^] # Re: Il dit qu'il ne voit pas le rapport

        Posté par  . Évalué à 2.

        J'ai 7 process avec systemd comme prefixe sur mon portable dans ps fax.
        J'ai 114 threads dans le kernel qui apparaissent dans ps fax

        Et combien de thread les process systemd ont-ils chacun?
        De mémoire quand je m'étais amusé à vérifier ce genre de trucs, ils n'en avaient pas des masses, mais n'ayant pas de systemd sous le coude, je me permets de poser la question.
        Il est aussi possible que init ne soit pas préfixé de systemd-, et vu que dans systemd c'est un seul process qui fait, euh… pas mal de choses, ça pourrais biaiser?

        Mais logiquement, si on veux réduire la complexité, c'est pas forcément au niveau de l'OS qu'il faut commencer.

        Très clairement: c'est au niveau du bureau.
        Ensuite viens le système de gestion des daemon (systemd, daemon-tools, runit… peu importe), puis le navigateur web, puis le noyau.
        Dans cet ordre, parce qu'il est plus simple de bricoler un bureau qu'un watchdog, ou un watchdog qu'un navigateur, ou un navigateur qu'un kernel.
        Le plus bloaté de la liste étant, de loin, le navigateur web.

        De toute façon le nombre de processus ou de thread n'indique pas vraiment le taux de bloat d'un système je pense. Ou alors, runit est vraiment très, très, très bloaté:

        % pstree -paT | grep -e runsv -e svlogd -e runit | wc -l
        50
        

        Il faut savoir que pour chaque daemon qui tourne, j'ai en pratique 3 processus minimum: son gestionnaire, son logger, et le daemon lui-même (plus ses enfants s'il en a).

  • # Une mode ?

    Posté par  . Évalué à 6.

    J’annonce la couleur tout de suite, j’ai toujours été très critique sur l’aspect gloutonnerie de systemd. Je suis plus fan d’un system KISS et dont chaque composant est indépendant.

    Maintenant ce que je voie comme avantage de systemd qui a jouer en sa faveur et qui a sûrement séduit pas mal de monde, c’est justement ce coté unification.
    * Tu as 1 seul endroit/logiciel pour tout gérer, donc plus besoins de connaître 36 logiciel différents, avec des syntaxe diamétralement opposé qui te donne a arrière goût du monde des framwork JS ou tout est réinventé tous les 4 matin. Je trouve ça dommage car c’est dans la prolifération de solution diverses et varié que l’on y trouve la créativité. Se cantonner a une solution unique rigidifie le mode de pensé.
    * Suppression de pas mal de code/configuration propre a chaque distro. Créer et maintenir une distro est un travail colossal avec souvent des ressources très variable. Donc si on te présente un produit sur étagère qui te divise par 2 ton travail, ça a un aspect tout de même très attrayant. Et là dessus je ne peux pas jeter la pierre sur qui que se soit vu que je profite très largement du travail des mainteneurs.

    Pour tes questions je ne sais absolument pas ce que tu vas perdre en te passant de systemd. Je n’ai jamais vraiment entendu de personne se plaindre que quelque chose ne fonctionnait pas correctement sans systemd (sauf Gnome bien sûr).

    Pour ce qui est de mon titre, je me dit que systemd n’est pas éternel et qu’il sera remplacé par autre chose a un moment donné et que peut être on assistera au mouvement inverse. J’ai en tête l’exemple de pulseaudio qui avait fait aussi quelque vagues a l’époque, remplaçant le vieillissant Alsa. Dernièrement c’est pipewire qui a la cote.

    • [^] # Re: Une mode ?

      Posté par  . Évalué à 10.

      Pulsaudio ne remplace pas Alsa. C'est une interface entre Alsa et les applications. Alsa est toujours nécessaire pour assurer le pilotage bas niveau du matériel.

      • [^] # Re: Une mode ?

        Posté par  (site web personnel, Mastodon) . Évalué à 6.

        Pulseaudio remplaçait ESD et je me souviens très bien que c’était un bonheur de pouvoir se passer de ESD (qui plantait beaucoup, ne fonctionnait avec avec plusieurs user, bouffait du CPU, introduisait de la latence, etc…)

        Mes livres CC By-SA : https://ploum.net/livres.html

    • [^] # Re: Une mode ?

      Posté par  (Mastodon) . Évalué à 10. Dernière modification le 03 novembre 2022 à 17:59.

      C'est un bon exemple l'audio. Pourquoi Alsa a suffit pendant un moment et maintenant on veut des PulseAudio/Pipewire ? Parce que les usages ont changé. Et se dire "ouais mais Alsa c'était cool", c'est oublier qu'on pouvait pas (ou très difficilement) assigner différentes application à différentes sorties par exemple.

      Si tu as un RPi et que tu te contentes de jouer des MP3 sur ta stéréo du salon, alors même aujourd'hui Alsa suffit amplement. Mais si tu as un ordinateur portable que tu trimballes entre docking station, que tu as un casque/micro pour tes visioconf que tu branches/débranches à volonté, c'est quand même plus pratique un vrai framework qui route les flux facilement, appli par appli.

      Même si je connais peu, je suppose que avec systemd c'est un peu pareil. Les besoin en init ont eux aussi évolués, les raisons de démarrer un daemon sont devenues multiples, on est devenus plus méticuleux sur les droits… Je ne sais pas si systemd répond à un besoin utilisateur, mais à un besoin des distributions, je n'en doute pas.

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: Une mode ?

        Posté par  (site web personnel) . Évalué à 8.

        Je ne dirait pas qu'Alsa a suffit pendant un moment. On avait aRts et ESD il y a 20 à 25 ans parce que justement Alsa et OSS n'étaient pas suffisant.

      • [^] # Re: Une mode ?

        Posté par  . Évalué à 3.

        Je ne sais pas si systemd répond à un besoin utilisateur

        Je dirais que si. Le système d'unit de systemd est plus simple a hacker que l'horreur sans nom qu'il y a encore dans debian pour les rc.d.
        Petit example avec mpd en fin de message (parce que c'est LONG rc.d!).
        C'est juste indiscutablement plus simple, le jour ou l'on a besoin de bricoler un daemon pour soi. Et je n'aime pas systemd, hein!
        En gros:

        • systemd: 49 lignes
        • init.d: 108 lignes, et je n'ai pas eu le courage d'aller compter les trucs sourcés
        • runit, pour l'instance de runsvdir qui démarre quand je me log en tant que user et pas quand je boote le système, pour le fun: 35 (c'est moi qui ai plus petite, nanananèèreeeee)

        Il est possible de lancer des daemon sans être root! Sans DE! Et un watchdog, comme ça quand ça plante ou qu'on ferme par erreur, ça redémarre. Typiquement: le client lourd pour les mails que les gens qui bossent continuent de préférer globalement aux interfaces web.

        Dernier: avantage théorique, avec systemd on devrais pouvoir démarrer plus vite parce que tout simplement si le PC est hors réseau, certains services qui requièrent le réseau ne chercherons pas à démarrer. Je sais pas, moi, le logiciel de backup par exemple, ou syncthing, ou le client mail… Reste à voir si c'est mesurable.

        Ensuite la question est: quelle est la limite entre un utilisateur et un mainteneur sur un système GNU/Linux? Vu que je maintiens mes scripts d'init DIY, que suis-je?

        Systemd:

        [Unit]
        Description=Music Player Daemon
        Documentation=man:mpd(1) man:mpd.conf(5)
        Documentation=file:///usr/share/doc/mpd/html/user.html
        After=network.target sound.target
        
        [Service]
        Type=notify
        EnvironmentFile=/etc/default/mpd
        ExecStart=/usr/bin/mpd --no-daemon $MPDCONF
        
        # Enable this setting to ask systemd to watch over MPD, see
        # systemd.service(5).  This is disabled by default because it causes
        # periodic wakeups which are unnecessary if MPD is not playing.
        #WatchdogSec=120
        
        # allow MPD to use real-time priority 40
        LimitRTPRIO=40
        LimitRTTIME=infinity
        
        # for io_uring
        LimitMEMLOCK=64M
        
        # disallow writing to /usr, /bin, /sbin, ...
        ProtectSystem=yes
        
        # more paranoid security settings
        NoNewPrivileges=yes
        ProtectKernelTunables=yes
        ProtectControlGroups=yes
        ProtectKernelModules=yes
        # AF_NETLINK is required by libsmbclient, or it will exit() .. *sigh*
        RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX AF_NETLINK
        RestrictNamespaces=yes
        
        [Install]
        WantedBy=multi-user.target
        Also=mpd.socket
        
        [Socket]
        ListenStream=%t/mpd/socket
        ListenStream=6600
        Backlog=5
        KeepAlive=true
        PassCredentials=true
        
        [Install]
        WantedBy=sockets.target
        

        sysvinit+rc.d sous debian:

        #!/bin/sh
        
        ### BEGIN INIT INFO
        # Provides:          mpd
        # Required-Start:    $local_fs $remote_fs
        # Required-Stop:     $local_fs $remote_fs
        # Should-Start:      autofs $network $named alsa-utils pulseaudio avahi-daemon
        # Should-Stop:       autofs $network $named alsa-utils pulseaudio avahi-daemon
        # Default-Start:     2 3 4 5
        # Default-Stop:      0 1 6
        # Short-Description: Music Player Daemon
        # Description:       Start the Music Player Daemon (MPD) service
        #                    for network access to the local audio queue.
        ### END INIT INFO
        
        . /lib/lsb/init-functions
        
        PATH=/sbin:/bin:/usr/sbin:/usr/bin
        NAME=mpd
        DESC="Music Player Daemon"
        DAEMON=/usr/bin/mpd
        MPDCONF=/etc/mpd.conf
        
        # Exit if the package is not installed
        [ -x "$DAEMON" ] || exit 0
        
        # Read configuration variable file if it is present
        [ -r /etc/default/$NAME ] && . /etc/default/$NAME
        
        if [ -n "$MPD_DEBUG" ]; then
            set -x
            MPD_OPTS=--verbose
        fi
        
        PIDFILE=$(sed -n 's/^[[:space:]]*pid_file[[:space:]]*"\?\([^"]*\)\"\?/\1/p' $MPDCONF)
        
        mpd_start () {
            log_daemon_msg "Starting $DESC" "$NAME"
        
            if [ -z "$PIDFILE" ]; then
                log_failure_msg \
                    "$MPDCONF must have pid_file set; cannot start daemon."
                exit 1
            fi
        
            PIDDIR=$(dirname "$PIDFILE")
            if [ ! -d "$PIDDIR" ]; then
                mkdir -m 0755 $PIDDIR
                if dpkg-statoverride --list --quiet /run/mpd > /dev/null; then
                    # if dpkg-statoverride is used update it with permissions there
                    dpkg-statoverride --force --quiet --update --add $( dpkg-statoverride --list --quiet /run/mpd ) 2> /dev/null
                else
                    # use defaults
                    chown mpd:audio $PIDDIR
                fi
            fi
        
            start-stop-daemon --start --quiet --oknodo --pidfile "$PIDFILE" \
                --exec "$DAEMON" -- $MPD_OPTS "$MPDCONF"
            log_end_msg $?
        }
        
        mpd_stop () {
            if [ -z "$PIDFILE" ]; then
                log_failure_msg \
                    "$MPDCONF must have pid_file set; cannot stop daemon."
                exit 1
            fi
        
            log_daemon_msg "Stopping $DESC" "$NAME"
            start-stop-daemon --stop --quiet --oknodo --retry 5 --pidfile "$PIDFILE" \
                --exec $DAEMON
            log_end_msg $?
        }
        
        # note to self: don't call the non-standard args for this in
        # {post,pre}{inst,rm} scripts since users are not forced to upgrade
        # /etc/init.d/mpd when mpd is updated
        case "$1" in
            start)
                mpd_start
                ;;
            stop)
                mpd_stop
                ;;
            status)
                status_of_proc -p $PIDFILE $DAEMON $NAME
            ;;
            restart|force-reload)
                mpd_stop
                mpd_start
                ;;
            force-start)
                mpd_start
                ;;
            force-restart)
                mpd_stop
                mpd_start
                ;;
            force-reload)
            mpd_stop
            mpd_start
            ;;
            *)
                echo "Usage: $0 {start|stop|restart|force-reload}"
                exit 2
                ;;
        esac
        

        Mon runit à moi, pour le fun, qui est contrôlé par une instance utilisateur de runsvdir (je sais, systemd aussi le peut):

        #!/bin/sh
        
        die()
        {
            printf "%s\n" "$@" | tee ./down
            exit 1
        }
        
        SVNAME="$(basename $(pwd))"
        HAS_LOG="$(test -d "$(pwd)/log" && printf "yes")"
        exec 0<&-
        exec 2>&1
        set -xe
        test -f conf && . ./conf
        
        if test "$0" = "run"
        then
            if test "$SVNAME" = "log"
            then
                SVLOG="$(basename $(dirname $(pwd)))"
                SVNAME="${SVLOG}/${SVNAME}"
                AUTO_ROTATE="${AUTO_ROTATE:="no"}"
            fi
            test "yes" = "${AUTO_ROTATE}" -a "yes" = "$HAS_LOG" && \
                sv alarm "$(pwd)/log"
        fi
        
        export DATADIR="/dev/shm/$(id -u)/"
        
        #!/bin/sh
        
        . ../../common
        
        echo "Starting $SVNAME"
        
        exec mpd --no-daemon ~/.config/mpd/mpd.conf --stderr 2>&1
        
  • # sans systemd

    Posté par  (Mastodon) . Évalué à 10.

    J'ai une machine sous artix, une raspberry pi sous alpine et une sous netbsd. Dans le cas des raspberry pi, c'est plus en quête d'économiser de la mémoire car ce sont des pi3b avec 1GB de ram. Pour l'artix c'était plus par curiosité des systèmes basés sur runit que parce que je n'aime pas systemd.

    Pour revenir à la question, la plupart des gens se focalisent beaucoup sur la question de l'init et les distros qui ne veulent pas de systemd se positionnent sur un choix d'init alternatif. Mais systemd c'est plus que ça

    • les timers, une alternative à cron beaucoup plus flexible.

    • des logs binaires qui sont indexés, supportent des logs structurés et dont la rotation ne nécessite pas forcément des hacks façon logrotate. Les recherches sont aussi plus rapides et on n'a pas à se poser la question de droits sur les fichiers. Les logs d'un service qui tourne sur le user foo sera visible par le user foo et pas bar.

    • puisqu'on parle des users différents, systemd permet la gestion des services, mais aussi des timers au niveau de l'utilisateur.

    • resolved. Je comprends qu'on puisse ne pas l'aimer, mais il permet une plus grande flexibilité des config dns, par exemple quand on se connecte à des VPN ou autre. Dans le temps ça y allait à la gruik avec des clients VPNs qui t'éditaient le resolv.conf à la connection mais sans gérer les états et te remettre ton resolv.conf comme il était avant lorsqu'il se déconnecte. Dégueulasse doc.

    J'oublie surement d'autres trucs. Systemd n'est pas strictement nécessaire mais il facilite pas mal la vie aussi.

    • [^] # Re: sans systemd

      Posté par  . Évalué à 1.

      des logs binaires qui sont indexés, supportent des logs structurés et dont la rotation ne nécessite pas forcément des hacks façon logrotate. Les recherches sont aussi plus rapides et on n'a pas à se poser la question de droits sur les fichiers.

      C'est la même question que se demander s'il vaut mieux une base de données ou des fichiers texte pour un journal. Il y en aura toujours pour trouver ça pratique et utile. La vraie question est: est-ce que c'est vraiment pertinent?

      • [^] # Re: sans systemd

        Posté par  . Évalué à 2.

        Pas pour l'immense quantité de gens qui ne vont jamais les lire de toute façon :D

        Pour les autres, je sais pas, je trouve que les deux ont leurs côtés sympa. Je ne crois d'ailleurs pas que les deux soient en conflit.

        Pour moi, garder les logs bruts de chaque daemon pendant un certain temps, isolés les uns des autres (important ça), puis uploader sur une machine centrale juste les infos qui sont réellement utiles pour avoir des métriques, c'est pas déconnant.

        De cette façon, la BDD ne grossit pas pour rien (pas de données inutiles) et est plus simple a explorer ou manipuler, mais quand ça part vraiment en sucette, les logs bruts sont toujours accessibles sur les machines émettrices (exemple de cas d'usage vécu: 250+ systèmes dont la connexion se fait via 2G/3G/4G en forfaits limités et avec une qualité réseau aléatoire dans l'espace et dans le temps).

  • # Tester avec un live CD ?

    Posté par  (Mastodon) . Évalué à 5.

    Est-ce que ces améliorations sont liées, d’une manière ou d’une autre, à systemd? Que vais-je perdre si je décide de migrer demain mon laptop vers Devuan, par exemple ? Si c’est "rien du tout", alors pourquoi a-t-on besoin de systemd ? Si c’est "tout ce que t’as dit", alors pourquoi n’est-ce pas clairement expliqué par les afficionados de systemd ?

    N'est-ce pas possible de tester Devuan ou un autre OS sans systemd en live CD ? Tu observerais rapidement de quelle côté la réponse penche, non ?

    Surtout, ne pas tout prendre au sérieux !

    • [^] # Re: Tester avec un live CD ?

      Posté par  . Évalué à 2. Dernière modification le 03 novembre 2022 à 18:08.

      Dans un VM ça devrait pouvoir se faire aisément

  • # Même réflexion ... parfois

    Posté par  . Évalué à 3.

    Systemd, comme d’autre dans 99 % du temps je m’en préoccupe pas vraiment ;
    systemd, systemd status,start,stop,enable,disable , systemctl list-units –failed et c’est à peu près tout.

    Mais il est vrai que je trouve que ce système d’initialisation gère un peu trop de chose sans qu’on le sache. Dernier exemple en date : (m)locate. J’ai découvert par hasard il y a peu que le rafraîchissement de la base de données était gérée via un timer systemd. (J’avoue que je m’étais jamais posé la question).

    Ensuite, ok on fait le choix de vouloir changer de système d’initialisation mais vers lequel se tourner ? OpenRC ?

    • [^] # Re: Même réflexion ... parfois

      Posté par  (site web personnel) . Évalué à 10.

      Mais il est vrai que je trouve que ce système d’initialisation
      gère un peu trop de chose sans qu’on le sache. Dernier exemple
      en date : (m)locate. J’ai découvert par hasard il y a peu que
      le rafraîchissement de la base de données était gérée via un
      timer systemd. (J’avoue que je m’étais jamais posé la
      question).

      C'était sans doute un cron avant, ou anacron (vu que le cron qui rafraichi à 3h du mat, quand tu éteint la machine, c'est pas terrible).

      Mais du coup, je pige pas le souci, ta distro a choisi d'utiliser systemd pour lancer une tache périodique (sans doute parce qu'un timer permet aussi de limiter les I/O), mais comme tu le dis, tu ne t'es jamais posé la question, c'est peut être parce que ça n'a pas une grande importance ?

      Surtout que vixie-cron, le programme que la plupart des distros utilisent, a été écrit en 1987, avec sa dernière release en 2004:

      https://github.com/vixie/cron/blob/master/Documentation/Changelog.md

      Maintenant, il y a un dépôt de code publique, mais ça n'a pas été le cas pendant très longtemps.

  • # Sans systemd

    Posté par  . Évalué à 6.

    la détection de matériel hotplug comme le multiécran, le support wifi, le support bluetooth, des trucs genre les touches multimédias

    J'arrive à faire tout ça sur une debian sans systemd (avec openrc).

    Le multiécran je le gère avec xrandr, le wifi avec iwconfig + wpa_supplicant, le bluetooth je ne l'utilise pas mais je crois qu'il y a un bluetoothctl qui fonctionne bien sans systemd, quant aux touches multimedia elles sont configurées dans mon ~/.config/openbox/rc.xml.

    Après je fais tout manuellement ou via des scripts maison donc si tu parles de "Plug-and-Play" (passage auto en double écran quand un écran est branché, détection auto des touches multimedia quand un nouveau clavier est branché, etc.) effectivement j'ai pas ça. Mais c'est parce que ce n'est pas mon usage, j'aime bien tout faire à la main, si ça se trouve ça peut aussi marcher sans systemd.

    *splash!*

    • [^] # Re: Sans systemd

      Posté par  . Évalué à 4.

      tout pareil, que ce soit sur serveur ou desktop, j'utilise une debian sans systemd avec sysvinit-core.
      J'ai juste ajouté ceci à /etc/apt/preferences/systemd:

      Package: systemd-sysv
      Pin: origin *
      Pin-Priority: -100
      
      Package: systemd
      Pin: origin *
      Pin-Priority:-100
      
      

      pour éviter une réinstallation de systemd lorsque, par hasard et très rarement, certains paquets l'ont en dépendance obligatoire. Dans ce cas, je me débrouille pour faire trouver une alternative à ces paquets.

  • # Un autre avantage non cité: systemctl --user

    Posté par  . Évalué à 8.

    Un point agréable pour systemctl en mode desktop est l'utilisation en mode user. Cela permet simplement de gérer les démons "user". D'autant que l'on a des scripts tout faits dans /usr/lib/systemd/user sans avoir a inventer grand chose. On active ce que l'on veut avec 'systemctl --user enable trucmuche', on le lance la première fois avec 'systemctl --user start trucmuche'. Et puis c'est tout, on a activé nos démons pour utilisateurs.

    Typiquement, je l'utilise pour deux choses: emacs (qui permet d'avoir le emacs tournant en mode démon à tout moment (auquel on se connecte instantanément par emacsclient) et jupyter-notebook (pour lancer automatiquement les notebooks accessibles via browser en localhost)

    Simple, et homogène avec la gestion des démons "system"

  • # GNU Guix / The Shepherd

    Posté par  . Évalué à 6.

    Je ne pratique pas, mais j'aime bien le concept de GNU Guix et son système d'init, The Shepherd (héritier de GNU dmd).

    Les services et leurs dépendances sont décrits en Scheme. Tout est de ce fait décrit en texte et est donc "grepable", et comme ce sont aussi des objets Scheme, l'arbre des dépendances est également requêtable.

    https://guix.gnu.org/manual/en/html_node/Shepherd-Services.html#Shepherd-Services

    Il me semble qu'on a donc à la fois la flexibilité de systemd et la lisibilité des scripts des init plus classiques.

    • [^] # Re: GNU Guix / The Shepherd

      Posté par  . Évalué à 8.

      Il me semble qu'on a donc à la fois la flexibilité de systemd et la lisibilité des scripts des init plus classiques.

      Je suis pas certains que plus de monde sache manipuler du scheme que systemctl/systemd-analyze.

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: GNU Guix / The Shepherd

      Posté par  (site web personnel) . Évalué à 7.

      Les services et leurs dépendances sont décrits en Scheme. Tout est de ce fait décrit en texte et est donc "grepable", et comme ce sont aussi des objets Scheme, l'arbre des dépendances est également requêtable.

      Les services de systemd et leurs dépendances sont aussi décrits avec du texte, c'est donc "grepable". C'est aussi requêtable (et modifiable), il y a même un outil pour ça : systemctl

      Matthieu Gautier|irc:starmad

  • # Si on repart aux sources...

    Posté par  . Évalué à 10.

    De mémoire, l'(un des) avantage de systemd n'était pas d'améliorer directement l'expérience utilisateur, mais plutôt la vie des admins et des mainteneurs.
    Il y avait aussi la prise en compte de cas non-triviaux mais il faudrait retourner voir les présentations originales.

    Je ne pense pas qu'un utilisateur du quotidien soit censé voir la différence (d'ailleurs l'utilisateur, par définition, se fout de ce qu'il y dans le cambouis tant que ça juste marche).
    Par contre, systemd a éliminé la chiadée de scripts d'init qu'il fallait constamment maintenir, par exemple.
    Et le fait que toutes les "grosses" distros l'aient adopté est sans doute un gage de l'intérêt pour les mainteneurs de distros!

    • [^] # Re: Si on repart aux sources...

      Posté par  (site web personnel) . Évalué à 7.

      Par contre, systemd a éliminé la chiadée de scripts d'init
      qu'il fallait constamment maintenir, par exemple.

      Ou les bugs impossible à corriger sans réimplementer systemd.

      Je n'ai plus le lien, mais il y avait une race condition (je crois) dans le script bind de Debian du au fonctionnement de named (qui utilise les signaux pour s'eteindre), race condition impossible à éviter sans l'usage des cgroups.

      Mais on a largement commentés systemd y a 7 ans, il faut vraiment lire les archives.

      • [^] # Re: Si on repart aux sources...

        Posté par  . Évalué à 9.

        Les sockets ont aussi permit d'avoir un démarrage plus maîtrisé de mysql (par exemple), qui reposait sur un for i in $( seq 30 ) ; do if test ; then break ; else sleep 1 ; done. Ce qui ne marchait pas si ça prenait plus de 30 secondes, qui attendait au pire des cas une seconde de trop, et qui réveille un script potentiellement 30 fois pour rien (ce qui n'est pas terrible quand on veut du minimalisme).

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Si on repart aux sources...

          Posté par  . Évalué à 3.

          Et ce n'était pas faisable avec, disons, tcpd, ça? Je crois qu'il y a un autre daemon qui fait le même type de trucs, mais impossible de me rappeler le nom… Pure curiosité, hein. Je troue personnellement logique que ce type de fonctionnalités aille dans le gestionnaire de daemon (pas dans l'init, cependant, mais c'est une autre histoire).

  • # Si le problème c'est le monolithique

    Posté par  . Évalué à 9.

    Ba faut pas utilisé Linux qui est un kernel monolithique.

    • [^] # Re: Si le problème c'est le monolithique

      Posté par  . Évalué à 3.

      Si le problème c'est le monolithique

      systemd ne me plait pas : plein de process qui tournent dès le démarrage, … je déteste systemd (je préfère une pile de bons vieux scripts shell).

      ;)

      • [^] # Re: Si le problème c'est le monolithique

        Posté par  . Évalué à -6.

        Reductio ad absurdum.

        Après 10 ans, c'est toujours les mêmes rengaines, dans les deux camps. Et toujours autant de fermeture d'esprit et d'hypocrisie. C'est beau l'informatique, pas vrai?

        --> []

        • [^] # Re: Si le problème c'est le monolithique

          Posté par  . Évalué à 2.

          je ne faisais que mettre en évidence le fait que l'auteur stipule:

          .. sur les problèmes de systemd (l’aspect monolithique,

          et que la phrase d'après il dit:

          systemd ne me plait pas : plein de process qui tournent dès le démarrage,

          en quoi cela est-il absurde ?

  • # Gentoo avec openrc (mais j’aimerai dév mon propre init)

    Posté par  . Évalué à 7.

    Si ton but c’est le minimalisme, tu peux déjà commencer avec systemd, car il est possible de désactiver les services mis en place par défaut (à la main faut créer un lien symbolique vers /dev/null, mais il doit y’avoir une commande qui fait ça). De plus toutes les distros, avec leur propre système d’init, viennent avec une configuration par défaut qui active/lance un certain nombre de service sans rien demander à personne.

    C’est pas systemd contre les autres. C’est une philosophie de distro.

    Techniquement udevd peut te lancer n’importe quel script/programme en fonction des événements matériel. Historiquement un inetd écoute les ports et démarre les serveurs à la demande (y’a plus récent et plus safe). Un cron ou atd vont gérer les tâches périodiques. Pour le bluetooth y’a un daemon pour ça, idem probablement pour gérer le wifi (quoiqu’une petite collection de scripts bien sentie devrait faire le job…).

    Mais tu perds beaucoup d’automatisme et de trucs qui marchent out-of-the-box. En vrai des gens très sympas qui ont écrit les scripts et les programmes pour que toi tu n’ais rien à faire. Autant je fais dans le minimalisme pour mon fixe, autant sur un portable qui bouge pas mal, j’éviterai et à la lecture de ton journal je vois que tu as bien cerné le problème qui risque de se poser.

    Donc il faut avoir du temps, mais c’est gratifiant d’acquérir les compétences. Grosso modo tu fais une part du boulot qui revient habituellement aux mainteneurs de la distro. L’avantage c’est que tu connais ton matériel et ton usage, du coup t’es pas obligé de monter une usine à gaz pour prévoir tous les cas imaginables. L’inconvénient c’est qu’il faudra mettre la main à la patte. C’est du boulot qu’il n’est envisageable de faire que sur un système très minimaliste, sinon ce serait chronophage.

    Petit exemple (mon dernier en date).

    Pour la gestion de l’horloge un linux traditionnel fonctionne ainsi :
    1. au démarrage je récupère l’heure système depuis le quartz sur la machine ;
    2. durant le fonctionnement je suppose qu’un client ntp va tourner pour mettre à jour l’heure système ;
    3. à l’arrêt je mets à jour le petit quartz de la machine grâce à l’heure système.

    J’avais désactivé le script à l’arrêt. Au bout de quelques mois j’arrivais à quelques 10min de décalage.
    Au final ma solution minimaliste : toutes les semaines environ j’ai programmé une tâche qui fait la synchro ntp puis met à jour dans la foulée le quartz. Car synchroniser un quartz une fois par semaine, c’est amplement suffisant, et je n’ai pas un programme qui tourne pour rien à chaque séquence démarrage/arrêt.

    Note que cet exemple montre la futilité de la démarche. C’est juste le plaisir de maîtriser sa machine, de la configurer selon son goût et de mieux comprendre comment elle fonctionne.

    Le débat n’est pas technique (systemd ou pas systemd), il est politique : à la base une distro distribue des programmes (merci Mr Obvious), mais avec le temps les tâches admin ont été de plus en plus prises en charge par la distribution (rigoureusement une distribution ne devrait même pas toucher à /etc). Ceci en faveur d’une réorientation plus destinée à l’utilisateur-final où l’intermédiaire qu’est l’admin-sys a sauté.

    Je n’utilise pas non plus de bureau user-friendly (dwm). Faudra rester cohérent je pense sur tout le système, parce que je suppose que des gnome ou kde doivent bien plus s’attendre à avoir systemd.

    Mort aux cons !

    • [^] # Re: Gentoo avec openrc (mais j’aimerai dév mon propre init)

      Posté par  (site web personnel, Mastodon) . Évalué à 6.

      Si ton but c’est le minimalisme, tu peux déjà commencer avec systemd, car il est possible de désactiver les services mis en place par défaut (à la main faut créer un lien symbolique vers /dev/null, mais il doit y’avoir une commande qui fait ça)

      Oui il existe une commande:

      systemctl mask unit
      Et une commande pour la défaire:

      systemctl unmask unit

    • [^] # Re: Gentoo avec openrc (mais j’aimerai dév mon propre init)

      Posté par  . Évalué à 2.

      Si ton but c’est le minimalisme, tu peux déjà commencer avec systemd, car il est possible de désactiver les services mis en place par défaut

      En plus je crois que systemd intègre bootchartd, ou un truc du genre, pour avoir des graph de quoikibouf du temps de boot? Je me base sur de vieux souvenirs de lecture… p'tet utilisable avec d'autres outils?

  • # Journal Les problèmes d’un desktop sans systemd ?

    Posté par  . Évalué à -4.

    Je n'utilise qu'un desktop donc pas à résoudre les problèmes de mobilité. Je suis passé d'Ubuntu il y a 4 ans à Devuan stable, puis Testing il y a deux avec juste dwm puis maintenant Openbox. Et pour ma part je n'ai rien perdu.
    Mes motivations à ne pas utiliser systemd:
    - je veux conserver le principe de séparation "un outil pour chaque tâche"
    - je l'avoue la flemmme d'apprendre un nouveau truc (je suis trop vieux pour ça :-) )
    - le fait que systemd s’infiltre partout au point de ne plus pouvoir installer certains programmes)
    - troll: je n'aime pas Lennart Poettering

  • # Si tu n’arrives pas à utiliser systemd, c’est que tu n’en as tout simplement pas envie.

    Posté par  . Évalué à 4.

    Si tu n’as pas l’envie d’apprendre à utiliser systemd, c’est compréhensible. Personne ne te force. Mais n’accuse pas l'init.

    Depending on the time of day, the French go either way.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.