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

Posté par ploum (site web personnel, Mastodon) le 03 novembre 2022 à 14:24. Licence CC By‑SA.

Étiquettes :

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 Christie Poutrelle (site web personnel) le 03 novembre 2022 à 14:42. É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 ploum (site web personnel, Mastodon) le 03 novembre 2022 à 14:54. É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 Christophe le 03 novembre 2022 à 15:44. É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 devnewton 🍺 (site web personnel) le 03 novembre 2022 à 20:18. É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 FantastIX le 04 novembre 2022 à 10:12. É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 barmic 🦦 le 03 novembre 2022 à 16:04. É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 FantastIX le 04 novembre 2022 à 10:17. É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 barmic 🦦 le 04 novembre 2022 à 11:31. É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 barmic 🦦 le 04 novembre 2022 à 11:45. É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 FantastIX le 04 novembre 2022 à 15:04. É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 barmic 🦦 le 04 novembre 2022 à 15:58. É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érique¹.
        
        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 systemd². 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.
        
        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). ↩
        
        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 freem le 07 novembre 2022 à 23:57. É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 barmic 🦦 le 08 novembre 2022 à 00:31. É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érique¹.
        
        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.
        
        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 freem le 08 novembre 2022 à 00:40. É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 groumly le 04 novembre 2022 à 22:00. É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 GaMa (site web personnel) le 03 novembre 2022 à 16:05. É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 FantastIX le 04 novembre 2022 à 10:27. É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 Renault (site web personnel) le 04 novembre 2022 à 11:52. É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 Pierre-Alain TORET (Mastodon) le 03 novembre 2022 à 15:40. É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 ploum (site web personnel, Mastodon) le 03 novembre 2022 à 16:28. É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 Misc (site web personnel) le 03 novembre 2022 à 16:42. É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 Blackknight (site web personnel, Mastodon) le 03 novembre 2022 à 19:17. É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 Misc (site web personnel) le 03 novembre 2022 à 20:37. É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 Pierre-Alain TORET (Mastodon) le 04 novembre 2022 à 09:48. É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 Misc (site web personnel) le 04 novembre 2022 à 11:15. É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 Michaël (site web personnel) le 04 novembre 2022 à 10:27. É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 bbo le 03 novembre 2022 à 19:59. É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 Pierre-Alain TORET (Mastodon) le 04 novembre 2022 à 09:35. É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 bbo le 04 novembre 2022 à 12:22. É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 amonts¹.
        
        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 ?
        
        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 Pierre-Alain TORET (Mastodon) le 04 novembre 2022 à 09:58. É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 ZankFrappa le 04 novembre 2022 à 18:16. É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 karteum59 le 04 novembre 2022 à 11:46. É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 ZankFrappa le 04 novembre 2022 à 18:19. É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 bbo le 04 novembre 2022 à 12:23. É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 ZankFrappa le 04 novembre 2022 à 18:14. É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 ploum (site web personnel, Mastodon) le 05 novembre 2022 à 00:00. É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 ZankFrappa le 05 novembre 2022 à 08:29. É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 Psychofox (Mastodon) le 06 novembre 2022 à 01:51. É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 freem le 07 novembre 2022 à 23:45. É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 Renault (site web personnel) le 03 novembre 2022 à 14:55. É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 gUI (Mastodon) le 03 novembre 2022 à 17:41. É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 Misc (site web personnel) le 03 novembre 2022 à 20:46. É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 freem le 08 novembre 2022 à 00:13. É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 Mimoza le 03 novembre 2022 à 15:07. É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 WrathOfThePixel le 03 novembre 2022 à 16:01. É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 ploum (site web personnel, Mastodon) le 03 novembre 2022 à 16:30. É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 gUI (Mastodon) le 03 novembre 2022 à 17:50. É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 Misc (site web personnel) le 03 novembre 2022 à 20:50. É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 freem le 08 novembre 2022 à 00:30. É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 Psychofox (Mastodon) le 03 novembre 2022 à 15:54. É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 FantastIX le 04 novembre 2022 à 10:39. É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 freem le 08 novembre 2022 à 00:36. É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 tisaac (Mastodon) le 03 novembre 2022 à 15:55. É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 Milo le 03 novembre 2022 à 18:08. É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 Skilgannon le 03 novembre 2022 à 16:11. É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 Misc (site web personnel) le 03 novembre 2022 à 16:28. É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 eingousef le 03 novembre 2022 à 16:14. É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 Anonyme le 03 novembre 2022 à 17:31. É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 THE_ALF_ le 03 novembre 2022 à 17:32. É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"
- [^] # Re: Un autre avantage non cité: systemctl --user
  
  Posté par gUI (Mastodon) le 03 novembre 2022 à 17:54. Évalué à 10.
  
  C'est clairement le --user qui m'a mis à apprendre systemd. D'ailleurs je m'étais promis de rédiger un petit journal sur ça, avec les quelques recettes de base à avoir sous la main.
  
  En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
  - [^] # Re: Un autre avantage non cité: systemctl --user
    
    Posté par tisaac (Mastodon) le 03 novembre 2022 à 18:40. Évalué à 10.
    
    D'ailleurs je m'étais promis de rédiger un petit journal sur ça, avec les quelques recettes de base à avoir sous la main.
    
    Maintenant, c'est un peu comme si tu nous l'avais promis…, je me réjouis de lire ton journal sur le sujet ;-)
    
    Surtout, ne pas tout prendre au sérieux !
  - [^] # Re: Un autre avantage non cité: systemctl --user
    
    Posté par nud le 03 novembre 2022 à 23:37. Évalué à 5.
    
    J'avais bien ce petit journal qui touchait le sujet mais il n'est plus de prime jeunesse.
# GNU Guix / The Shepherd

Posté par Papey le 03 novembre 2022 à 17:44. É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 barmic 🦦 le 03 novembre 2022 à 17:57. É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 GaMa (site web personnel) le 03 novembre 2022 à 17:59. É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 Maclag le 03 novembre 2022 à 23:07. É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 Misc (site web personnel) le 04 novembre 2022 à 11:33. É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 claudex le 04 novembre 2022 à 15:40. É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 freem le 08 novembre 2022 à 00:47. É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 ben51 le 04 novembre 2022 à 11:07. Évalué à 9.

Ba faut pas utilisé Linux qui est un kernel monolithique.
- [^] # Re: Si le problème c'est le monolithique
  
  Posté par gst le 04 novembre 2022 à 12:52. É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 FantastIX le 04 novembre 2022 à 15:09. É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 gst le 04 novembre 2022 à 16:30. É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 PR le 04 novembre 2022 à 17:29. É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 slubman (site web personnel, Mastodon) le 04 novembre 2022 à 17:51. É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 unitEt une commande pour la défaire:
  systemctl unmask unit
- [^] # Re: Gentoo avec openrc (mais j’aimerai dév mon propre init)
  
  Posté par freem le 08 novembre 2022 à 00:51. É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 thierrybo le 05 novembre 2022 à 16:51. É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 Frank-N-Furter le 08 novembre 2022 à 08:07. É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.
- [^] # Re: Si tu n’arrives pas à utiliser systemd, c’est que tu n’en as tout simplement pas envie.
  
  Posté par freem le 10 novembre 2022 à 14:58. Évalué à 3.
  
  s/l'init/le framework/
  
  :p

Suivre le flux des commentaires

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