C'était une bonne présentation. C'était aussi cool de voir Lennart en vrai, ça met un visage et un aperçu sur un des personnages dont on entend régulièrement parler.
L'article sur LWN est un bon résumé, reprenant tous les points clés. Il y a aussi eu un passage intéressant sur « Est-ce que systemd respecte la philosophie Unix », qui n'est pas cité dans l'article mais qui vaut le coup. C'est un peu résumé sur le site de systemd (point 10: « Myth: systemd is not UNIX. »). (D'ailleurs, cette page montre à quel point les détracteurs de systemd sont souvent à côté de la plaque dans leurs arguments, il y a une réponse claire à la plupart des critiques qu'on peut lire).
L'impression que ça m'a donné, c'est que l'équipe qui maintient systemd a une vision forte sur comment faire les choses, et que des efforts sont faits pour garder un ensemble propre, cohérent et un bon équilibre entre légèreté, sécurité et fonctionnalités. Par exemple, ils réduisent au maximum le nombre de leur dépendances fortes, et utilisent dlopen pour les fonctionnalités plus optionnelles. C'est plutôt rafraîchissant de voir ce genre de démarche dans un monde où on s'en fout de rajouter 2000 dépendances transitive et où on bundle le tout pour le balancer au navigateur sans se préoccuper de la situation matérielle des destinataires.
J'aime bien aussi leur ambition de standardiser les manières de faire / un certain nombre de choses sur les systèmes GNU/Linux (l'article en parle).
Bref : systemd, j'aime la démarche, et le résultat.
Franchement voilà, s'il en était besoin, un signe de plus de l'incompétence de Lennart Potering. Il n'est peut-être pas nul mais pas au niveau techniquement.
SystemD coche toute les alertes… eg pourtant ça reste hélas le meilleur choix sous Linux. Je regarde les autres mais aucun n'est aussi abouti (faute de moyens).
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Posté par raphj .
Évalué à 10 (+14/-0).
Dernière modification le 19 février 2025 à 07:12.
Très bizarres tes commentaires ici. Tu affirmes partout que systemd est mal conçu, que c'est indébogable… Sans jamais rentrer dans les détails.
Moi je dis : il va falloir étayer tout ça, parce qu'il ne suffit pas de l'affirmer pour que ce soit vrai, et je suis loin d'être convaincu. En particulier quand justement aucune alternative crédible n'a réussi à percer malgré les efforts.
Ici tu affirmes que Lennart n'est pas au niveau. Bon déjà il ne travaille pas seul sur systemd, donc tu vises une équipe entière. Et… ça parait grotesque. On peut ne pas aimer son travail, mais son niveau… On parle quand même d'une personne qui a transformé le desktop linux dans plein d'aspects souvent fondamentaux. On n'y arrive pas si on est incompétent. Va falloir étayer aussi, et bon courage.
Concernant Rust, il a argumenté et c'était très raisonnable. Rust actuellement n'est pas adapté au cas d'usage de systemd et ses remarques étaient une invitation à améliorer Rust pour qu'il soit adapté à son cas d'usage. La démarche me parait bonne, mais bon, oui, tu peux continuer à te boucher les oreilles quand des experts mondiaux travaillant sur des parties critiques de ton OS font des retours constructifs sur pourquoi ils ne peuvent pas utiliser telle ou telle techno en l'état et décréter que c'est parce qu'ils sont nuls.
Ça doit demander un sacré égo, ça me laisse admiratif…
C'était une bonne présentation. C'était aussi cool de voir Lennart en vrai, ça met un visage et un aperçu sur un des personnages dont on entend régulièrement parler.
Son visage apparaissait souvent (et même sur des coussins, mais je trouve plus la photo) et d'ailleurs je sais pas si le travail le stress mais pour son âge je trouve qu'il a pris une claque par rapport aux débuts de systemd. Ça fait presque de la peine, qu'on aime ou pas systemd, il s'est pris une sacré shitstorm dont il en avait fait un message sur google+ à l'époque.
git is great because linus did it, mercurial is better because he didn't
L'article sur les mythes autour de Systemd n'est pas maintenu :
- le mythe 27 parle de leur communauté active sur Google+
- l'article LWN parle de 150 binaires, le mythe 1 indique 69 binaires
ça reste probablement une bonne introduction pour comprendre la vision des deux parties.
J'ai fait partie de ceusses qui maudissaient Lennart et systemd au début.
Un comble car étant minot j'étais fan de la célèbre revue "Système D" dont j'avais récupéré une collection bien odorante de vieux papier moisi des années 45-50… :-)
Mais ici, point question de bricolage de postes radio à galène, ni de fabriquer une arbalète à grenouilles avec un parapluie (oui cet article a vraiment existé, dans la France d'après guerre, la faim justifiait encore les moyens parfois), ou de faire de la colle à bois avec des tendons et os de lapin…
En 2011 je voyais pas vraiment en quoi il était nécessaire de remplacer le "bon vieil init SystemV".
Bon an mal an je m'y suis fait, par contrainte plus que par plaisir.
Certains détails m'échappent encore mais c'est plus de la réticence au changement et de la paresse intellectuelle que des raisons objectives de détester le machin.
Et maintenant je râle encore tout autant contre nftables… Suis-je le seul?
Ils ont aussi changé netstat, ifconfig, rajouté un 8e bit, viré lilo voire grub, lxc est ostracisé, alpha et sparc sont reléguées, maintenant tout est flatpak/AppImage/docker/k8s. Ils nous en veulent. Ils nous obligent à changer nos habitudes.
Tu oublies un peu vite que les gens du kernel, ils ont déprécié OSS pour le remplacer par Alsa, puis ils nous ont imposé PulseAudio et maintenant PipeWire.
Il y a des utilisateurs qui tenaient à se la péter devant d'autres utilisateurs: "Wouaaah! Tu as réussi à avoir le son qui fonctionne?!?" et maintenant, c'est plus possible :-/
Ah non mais ils ont changé plein de trucs en passant du noyau 1.2.x au 2.x, en abandonnant la libc5, en abandonnant les sites web en WML générés en 9 passes, en remplaçant daCode et Templeet, en allant de GCC 2 à 3, en retirant Clippy, en arrêtant le chiffrement DES des mots de passe, en virant rlogin, le NIS, ils ont quasi doublé la longueur des numéros de téléphone, allongé les adresses IP comme des oufs et je ne parle même pas des mots de passe. Ils sont partout à ne faire qu'à tout changer. Cool bits don't change
SystemD coche toute les alertes… et pourtant ça reste hélas le meilleur choix sous Linux. Je regarde les autres mais aucun n'est aussi abouti (faute de moyens). Je pense à Dinit…
La plus grosse faute de SystemD c'est de rendre les soft dépendant de SystemD et même de rendre SystemD dépendant de Linux.
Pire il intègre carrément les softs pour devenir un méga soft…ingerable.
Reste qu'un process qui initialise (en //), gère les dépendances et monitor et relance les services planté c'est utile.
Le problème vient qu'il n'a pas été recherché une solution technique satisfaisante. Ce n'est pas facile mais possible.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Posté par AncalagonTotof .
Évalué à 0 (+7/-9).
Dernière modification le 18 février 2025 à 14:16.
Disclaimer : on peut trouver plein de défauts et de qualités à systemd. Moi, je lui trouve plus de défauts que de qualités.
Pourquoi ? Parce que j'ai débuté sous UNIX en 1988 par la connexion à un système dont j'ignorais tout, d'abord pour les sauvegardes de nos projets, puis pour les cours de … UNIX !
Ensuite, c'était un peu de Minix sur Atari ST, et beaucoup de Sun OS dans les salles de TP du LIFL.
En enfin, en 1995, le pote qui débarque chez moi avec une disquette en criant "ils ont sorti le driver 2940 Linux, on peut tester sur ta bécane ?". Donc, même si l'admin sys est pas mon métier, j'en fais de façon poussée depuis longtemps, depuis 30 ans, depuis 25 ans et l'arrivée d'ADSL et le début de l'auto-hébergement.
Tout ça pour dire que ça forge des habitudes difficiles à changer, et des réflexes KISS malmenés par systemd.
Disclaimer 2 : non, j'ai pas RTFM. Enfin, pas toutes. Mon premier contact avec systemd, c'était pendant une mise à jour de mon FW, et un plantage du système. systemd s'est imposé pendant la mise à jour, y'a des trucs qui ne lui plaisaient pas, et impossible de rebooter correctement. Impossible de faire des recherches pour piger, vue que c'était le FW, plus d'internet. Cool, une réinstallation imprévue, en soirée/nuit, principalement pour assurer le fonctionnement du mail auto-hébergé. J'ai gardé une dent contre depuis.
Mes dernières mésaventures avec cette "chose", sur une Debian 12 :
1) avant : bécane principale, zindoz/Linux. Utilisation des cartes réseau intégrées à la carte mère, tout va bien.
Après : ajout d'une carte 10 GBps. Hum, ça marche, c'est presque 10 x plus rapide.
Mais y'a un truc bizarre : mes partages NFS ne sont plus montés au démarrage, je dois le faire à la main.
Pourtant, rien n'a changé, à commencer (si je puis dire vu le début de la phrase) par mon bon vieux /etc/fstab.
Après avoir étudié le phénomène, j'arrive à la conclusion que le réseau n'est pas prêt au moment de monter les partages.
Ah ? Pourquoi ? Je sais pas, j'ai pas trouvé. Un truc plus lent à cause de la carte elle-même ou de son driver Atlantic peut-être.
Tentative d'IP fixe : pas mieux.
Mais bon, Debian 12, systemd, ok, je vais essayer de faire ça dans les règles.
Pas simple, mais je trouve systemd-networkd-wait-online.service, que j'active, et qui me cause un timeout "de malade" au démarrage. Et là, c'est le drââââme, toujours pas de partages montés après ça.
OK, donc, des partages qui, manifestement, ne devaient être montés que quand le réseau passait UP, ne sont toujours pas montés quand j'active systemd-networkd-wait-online.service, après une attente phénoménale. Super. C'est moi qui ne sait plus parler anglais, ou bien y'a un défaut dans l'énoncé systemd-networkd-wait-online.service ou les autres "machins" censés s'assurer que le réseau est UP ?
Heureusement, j'ai des potes … Qui s'y connaissent mieux que moi et qui me signalent l'existence de automount, et sa config par systemd.
Ça marche. Après un peu de galères, et sans être certain d'avoir placé les fichiers .mount et .automount à l'emplacement canon. Mais ça marche.
Galères parce que l'un des partages se trouve sur une machine qui n'est pas souvent allumée. Et que selon l'emplacement du point de montage, ça crée encore du timeout, le temps que ça se dise "ah bah nan, pas dispo".
Mais surtout, parce que automount traite /media d'une façon particulière, contrairement à /etc/fstab : marche pas. Et pas expliqué dans les docs que j'ai pu lire. Faut deviner. Faut placer les points de montage ailleurs.
Bien bien bien, cool cette histoire, j'aime bien perdre mon temps sur ce genre de choses.
2) concernant la tentative d'IP fixe : j'aime bien /etc/network/interfaces. Mais on m'a dit, c'est mal, faut passer par NetworkManager. OK, allons-y : nmtui. Ça marche, mais ça fait un moment que je suis au courant de "ze next thing" : y'a une autre façon de faire, "encore plus systemd". Nan, me demandez pas comment ça s'appelle, où ça se trouve, j'ai toujours eu la flemme d'essayer.
3) logs
Utiles pour essayer de comprendre pourquoi ça monte pas les partages.
Sur mon FW, ça va, c'est une Debian 12 qui était 11, et peut-être même 10 avant. Donc, j'ai encore les logs au format texte, c'était le standard à l'époque, et les upgrade n'ont pas modifié ça.
Mais sur la bécane principale, c'est une Debian 12 "assez fraiche". Donc, plus de fichiers texte, que du journalctl. Et journalctl, faut apprendre à s'en servir (un fichier texte, non. Juste less, grep et tail généralement). Et journalctl, c'est obligatoire, parce que les logs sont au format binaire, impossible de le contourner.
4) conclusion (?)
Est-ce que ça valait vraiment le coup ?
OK, je suis mal placé, je sais faire un paquet de trucs en amateur, mais je suis pas pro, j'ai pas passé des heures à lire les généralités, ni les man pages sur systemd. Donc, c'est ma faute, j'ai qu'à RTFM.
Flemme. Y'a des principes KISS qui ont été mis à la poubelle.
Je veux bien croire qu'on y a gagné, en temps de boot (encore que, pas toujours), et sur d'autres sujets que je ne maîtrise pas.
Ça m'inquiète de perdre la main, et sur le plan pro, à l'occasion, ça m'inquiète de voir des systèmes embarqués bâtis avec systemd.
Aller, encore un effet de ma viellitude ?…
Celle qui va probablement me pousser à retenter l'expérience Devuan quand j'aurai fini de pourrir ma Debian ?…
Tout ça pour dire que ça forge des habitudes difficiles à changer, et des réflexes KISS malmenés par systemd.
Franchement, qu’est ce qu’il faut penser d’un projet qui dit « on garde en l’état parce qu’on a l’habitude » ? Il est en maintenance et ne cherche plus à évoluer.
Ton laïus donne plus l’impression que le UNIX que tu as connu est une madeleine de Proust. Ce n’est pas grave, mais est-ce que c’est sur ce genre d’arguments que les choix decs distributions devraient être prises ?
Flemme.
Tu as passé 70 ans 0 lire de la doc et ça a l’air de t’avoir traumatisé. Personne ne t’oblige à l’utiliser, mais tu peux pas non plus forcer Debian dans ces choix.
Tu as eu 2 problèmes avec systemd et ça te plaît pas d’avoir à lire. Tu explique toi-même que tu en as eu des mille fois pire avant et que tu en a un souvenir heureux. Je suis désolé mais qu’est-ce qu’on peut faire ? Prend une Debian 11 et arrête de la mettre à jour. Si tu ne veux pas que ça change.
Y'a des principes KISS qui ont été mis à la poubelle. […] Aller, encore un effet de ma viellitude ?…
Non il y a une lecture différente des principes et tu choisi de les considérer comme mauvais car différents de ce que tu connais plutôt de t’y intéresser. Ce n’est pas une question d’age, c’est un choix.
L’age n’a rien à voir là dedans. C’est ton droit le plus strict, mais la position « c’est pas de ma faute, je suis comme ça » est une position confortable pour se dédouaner et ronchonner sans trop se mouiller.
Tu as eu 2 problèmes avec systemd et ça te plaît pas d’avoir à lire. Tu explique toi-même que tu en as eu des mille fois pire avant et que tu en a un souvenir heureux.
Plus que 2 problèmes, sensiblement. J'ai pas fait de liste pour la ressortir en entier ici.
"eu des mille fois pire avant et que tu en a un souvenir heureux" ??? Où est-ce que j'ai écrit ça ??? Si je l'ai fait, c'est par erreur, typo ou je ne sais quoi.
Pour le reste, ça n'étais pas assez clair peut-être, mais je n'ai pas écris non plus que le problème, ça n'était pas moi.
Oh, et si j'osais le formuler ainsi : donc, depuis systemd, c'est KISS my ass ?
Qu'est-ce qu'il y avait de mal à avoir un soft qui règle un et un seul problème, par rapport à un systemd tentaculaire qui va finir par devenir un OS à lui tout seul ?
Où est-ce que j'ai écrit ça ??? Si je l'ai fait, c'est par erreur, typo ou je ne sais quoi.
Avoir un matériel qui ne fonctionne pas est de plusieurs magnitude plus problématique qu’avoir à faire des montages à la main.
En enfin, en 1995, le pote qui débarque chez moi avec une disquette en criant "ils ont sorti le driver 2940 Linux, on peut tester sur ta bécane ?".
.
Plus que 2 problèmes, sensiblement.
Tu n’en liste qu’un.
Oh, et si j'osais le formuler ainsi : donc, depuis systemd, c'est KISS my ass ?
Pourquoi tu pose des questions dont tu ne t’intéresse pas à la réponse ? C’est du troll ?
Qu'est-ce qu'il y avait de mal à avoir un soft qui règle un et un seul problème, par rapport à un systemd tentaculaire qui va finir par devenir un OS à lui tout seul ?
Moi aussi je suis un debianeux depuis suffisamment longtemps et j’ai vraiment souffert à utilise sysvinit avec en plus le framework que debian utilisait et dont j’ai jamais trouvé une doc correct. Et j’étais super content de me retrouver au boulot à devoir utiliser RedHat et à ne pouvoir rien réutiliser de ce que j’avais laborieusement appris.
J’ai aussi passé du temps à faire des grep de fichier en faisant des regex approximatives pour tenter de m’y retrouver en jonglant entre différent format de date et d’heure, à créer des fichiers temporaires,… J’ai même longtemps gardé urxvt pour sa vitesse (largement au dessus de tous les autres terminaux mis à part ghostty).
Je n’ai pas eu besoin de beaucoup pour apprendre :
à créer des services simplement quelque soit la distribution qui utilise systemd
à pouvoir manipuler plus efficacement les logs
à gérer des cron et à pouvoir facilement configurer leur fréquence
à gérer des cron et à pouvoir facilement quand elles se lancent et vont se lancer
Bon j’arrête de nourrir le troll, on est pas vendredi
Posté par gUI (Mastodon) .
Évalué à 8 (+5/-0).
Dernière modification le 18 février 2025 à 17:12.
à créer des services simplement quelque soit la distribution qui utilise systemd
Moi perso ce qui m'a fait définitivement passer à systemd c'est les services utilisateurs (et pas root). Simplicité et robustesse, tous mes petits scripts à la con tournent sur mon compte, dans mon /home. Le tout dans un script qui doit faire 4 lignes.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Où est-ce que j'ai écrit ça ??? Si je l'ai fait, c'est par erreur, typo ou je ne sais quoi.
Avoir un matériel qui ne fonctionne pas est de plusieurs magnitude plus problématique qu’avoir à faire des montages à la main.
Mais c'est pas possible, j'ai jamais dis que j'avais un problème matériel, elle marche bien cette carte réseau. C'est probablement le driver qui pose problème.
Et qui est à l'origine de la galère pour trouver une solution.
En enfin, en 1995, le pote qui débarque chez moi avec une disquette en criant "ils ont sorti le driver 2940 Linux, on peut tester sur ta bécane ?".
Pardon ? Qu'est-ce que ça vient faire là ? C'est quoi l'idée ? C'est un bout de mon histoire. Et ce driver 2940 a bien fonctionné il me semble. En 1995 !!!
Pourquoi avoir cité ce passage ?
Plus que 2 problèmes, sensiblement.
Tu n’en liste qu’un.
Ouais, et alors ?
C'est marrant la mauvaise foi, et la suppression de ce qui suit. Phrases complètes :
Plus que 2 problèmes, sensiblement. J'ai pas fait de liste pour la ressortir en entier ici.
Parce que ça allait avec le passage d'avant
À la belle époque de 1995 tu devais courir derrière les drivers, les compiler toi-même, avec une compilation du noyau avec en appliquant le patch correctement.
Aujourd'hui dans ce monde où tout fou le camp tu doit te renseigner pour avoir des montages réseaux qui se montent automatiquement.
C'est marrant la mauvaise foi, et la suppression de ce qui suit. Phrases complètes :
Plus que 2 problèmes, sensiblement. J'ai pas fait de liste pour la ressortir en entier ici.
Si ça, ça ne nourrit pas le troll …
Comprends que je ne peux pas parler de ce dont tu ne parle pas. Ce que tu as choisi pour illustrer ton propos c'est des montages réseaux qui ne sont plus automatiques et la flemme de te renseigner.
J'ai répondu pour dissiper l'incompréhension suite à mon commentaire précédent mais ça s'arrêtera là
Parce que ça allait avec le passage d'avant
À la belle époque de 1995 tu devais courir derrière les drivers, les compiler toi-même, avec une compilation du noyau avec en appliquant le patch correctement.
Aujourd'hui dans ce monde où tout fou le camp tu doit te renseigner pour avoir des montages réseaux qui se montent automatiquement.
Désolé, mais j'ai toujours du mal à faire le rapprochement.
Ce que tu as choisi pour illustrer ton propos c'est des montages réseaux qui ne sont plus automatiques et la flemme de te renseigner.
Et, à me relire, je précise, à nouveau, que non, je n'ai pas rien lu, rien recherché.
Que non, il ne s'agit pas d'un problème matériel.
Qu'on m'explique : par défaut, systemd et sa config sont bien supposés attendre que le réseau soit UP pour tenter des montages ? (J'attends plus que "ça dépend", merci)
Alors pourquoi ne le fait-il pas avec cette carte ? Ma supposition : le driver. La conséquence : un client DHCP plus lent ? Et alors ? Pourquoi "ça" n'attend pas que le réseau soit UP ?
Pourquoi, alors que pour un paquet de trucs, on a droit à un message d'erreur et un compteur de temps, pour de longues secondes ou minutes, avant timeout et poursuite du boot, au contraire, quand il s'agit de monter un partage réseau, je n'ai que quelques messages "en rouge" que je dois filmer pour pouvoir les lire, parce que, bien que l'option --no-clear soit présente dans tous les fichiers de systemd relatif à getty que j'ai pu trouver à grands coups de find/grep, les messages kernel et services sont effacés par le prompt de login ? (vous pouvez reprendre votre souffle. Non, je ne reformulerai pas cette phrase trop longue)
Non, je n'ai pas rien cherché.
Oui, j'ai fini par mettre en place automount.
Non, ça ne s'est pas passé tout seul, et je n'aurais pas trouvé seul, ou pas avant longtemps.
Oui, j'ai cherché mais je n'ai trouvé aucune explication du : pourquoi automount ne fait pas son boulot si le point de montage est dans /media ? À part un pote qui disait "ah, peut-être parce que /media est réservé au supports amovibles ?", ce qui est une supposition non étayée. Et j'ajoute que sans ce problème de carte/driver/DHCP, un montage par /etc/fstab fonctionnait très bien.
Je veux bien admettre que j'ai beaucoup de défauts, dont certains dus à l'âge, mais y'a pas que moi qui présente des défauts.
Qu'on m'explique : par défaut, systemd et sa config sont bien supposés attendre que le réseau soit UP pour tenter des montages ? (J'attends plus que "ça dépend", merci)
Alors pourquoi ne le fait-il pas avec cette carte ? Ma supposition : le driver. La conséquence : un client DHCP plus lent ? Et alors ? Pourquoi "ça" n'attend pas que le réseau soit UP ?
Sur Debian et ses dérivés, quand une interface réseau est déclarée avec allow-hotplug dans /etc/network/interfaces, cette interface n'est pas prise en compte par la chaîne de dépendances genre "wait-network-online", car l'interface peut apparaître bien plus tard, ou jamais (c'est le sens de "hotplug" dans ce contexte, une interface USB ou que sais-je), et ce serait absurde de l'attendre.
C'est peut-être (désolé) ce qu'il se passe dans ton cas ?
Merci de répondre à cette question après tout ce déchaînement de violence !
Après vérification, cette interface n'est définie ni dans /etc/network/interfaces, ni dans /etc/network/interfaces.d/. Comme quoi, je ne fais pas tout "à l'ancienne" ;-)
Elle était en DHCP.
Et j'ai oublié de repréciser dans la dite bataille, elle est depuis configuré en IP fixe via nmtui. C'est d'ailleurs la première chose que j'ai faite, avant tout le reste (systemd-networkd-wait-online.service puis automount).
Je n'ai pas vu d'équivalent à allow-hotplug dans nmtui. Je serais passé à côté ?
J'ai un doute sur la signification l'option (non cochée) Require IPv4 addressing for this connection. Automatically connect et Available to all users sont cochées.
Posté par raphj .
Évalué à 10 (+8/-0).
Dernière modification le 18 février 2025 à 17:39.
Qu'est-ce qu'il y avait de mal à avoir un soft qui règle un et un seul problème, par rapport à un systemd tentaculaire qui va finir par devenir un OS à lui tout seul ?
Lennart le redit dans sa présentation : leur objectif est de fournir une solution pour démarrer un OS. Et pour faire ça bien, en fait on touche plein de choses.
Mais en réalité systemd c'est très modulaire. On pourrait se dire qu'on n'a pas besoin de networkd, nspawn, resolved… et c'est vrai, et ça tombe bien, ces composants sont optionnels.
Par exemple pour ton histoire de configuration réseau : aucune obligation d'utiliser NetworkManager si tu n'en veux pas, c'est normalement possible de faire comme avant.
Mais systemd, c'est aussi une standardisation, un ensemble plus cohérent et unifié. Ça change forcément l'existant, mais ça simplifie grandement la vie des gens flemmards comme moi. Tu installes un nouveau service, tu sais direct comment t'en servir, et notamment que tu peux avoir ses logs en lançant journalctl -fu service par exemple. grep, tail, tout ça, tu peux continuer à les utiliser en apprenant une commande : journalctl -u service; c'est pas la mort. En général il y a un flag pour faire ça mieux direct dans l'outil, mais c'est toujours possible.
Cette standardisation, ça demande effectivement un apprentissage initial, mais sur le long terme, c'est moins la pagaille, l'ensemble est plus facile à comprendre et au final c'est moins d'effort.
Après, c'est clair que si tu n'aimes pas la vision, ça va mal se passer pour toi. Je ne crois pas qu'il faut rester sur l'impression laissée par une mauvaise expérience de migration au début, et plutôt analyser ce qu'on a aujourd'hui, sinon c'est sûr que tu resteras bloqué sur ça mais ça ne parait pas méga constructif.
Je suis d'accord, des outils existent, mais ils sont nombreux, il est long de tout (re)découvrir, et si j'admets le terme "flemmards", il ne faut pas oublier non plus qu'il recouvre "je ne suis pas admin sys pro, loin de là, et j'aurais aimé qu'on me laisse le choix Debian avec ou sans systemd, parce que j'ai pas que ça à faire de tout ré-apprendre après qu'on me l'ait imposé, j'ai d'autres trucs à faire".
Hum, et si on se donnait rendez-vous dans 5 ou 10 ans ? Pour voir les discussions entre les gens qui n'ont pas de problème avec systemd (et je n'ai pas de problème avec les gens qui n'ont pas de problème avec systemd, sauf barmic peut-être. Je comprends et j'admets qu'il y en ait et qu'il y ait des avantages selon le contexte), et les gens qui seront passés au successeur de systemd ? Ça pourrait être drôle …
Je ne suis pas admin sys pro. Je ne bosse même pas en IT.
J'ai installé Linux pour la première fois avec une boite RedHat 4.0 sans même trop savoir exactement ce qu'était un OS ou Linux. J'ai appris, essayé moultes distros, jonglé avec les fichiers de config, etc.
Je suis passé à systemd parce que Debian est passé à systemd.
J'ai dû ré-apprendre certaine commandes parce que systemd les fait différentes, mais j'ai toujours un gros différentiel entre ce que je savais faire avant systemd et ce que je sais faire avec systemd.
Parce que ça juste marche bien plus souvent, et donc je n'ai pas besoin de savoir tout ce dont j'avais besoin avant.
Là j'ai appris à me servir de tout un tas de services que j'héberge sur un serveur perso. J'ai dû apprendre des commandes Yunohost, etc. Et dans quelques années, tout ce que j'aurai appris là-dessus sera sans doute inutile et/ou obsolète.
L'informatique, ça évolue tout le temps. Ça fait que certaines connaissances deviennent obsolètes, et les gens "qui touchent bien" mais qui n'apprennent plus deviennent les vieux aigris qui ne savent plus non plus comment marchent les trucs et passent leur temps à dire que c'était mieux avant.
Mais moi je ne regrette pas l'époque où lancer X11 était un petit exploit, ou les réglages divers et la recherche du bon pilote, et les bidouilles dans les modules noyau, etc. étaient des étapes normales post-installation.
Et donc là je ne regrette pas l'époque où je maîtrisais à peu près ifconfig alors que je ne me souviens jamais comment utiliser la commande ip, parce que ça veut surtout dire que je n'ai plus besoin de savoir, et ça, c'est une bonne chose!
Et oui, ça arrive et ça arrivera encore que je tombe sur un os, et que je doive lire une doc sur comment faire truc ou machin en 2025, alors que je savais faire en 2005. Et ben je ré-apprendrai, parce que je n'oublie pas la quantité d'efforts que je devais fournir en 2005 pour un truc qui marche même après les mises-à-jour.
Je me suis posé un petit défi curieux pour voir si l'herbe était plus verte sans systemd. J'ai donc testé beaucoup de distros intégrant des inits différents (Antix, Devuan, Artix, Void, Guix et j'en oublie) avec à chaque fois plusieurs mois d'utilisation. Ma conclusion est sans appel: Ce n'est pas grâce à systemd que tout se passe mieux. Il y a peut être des éléments qui se sont améliorés mais ça ne concerne pas mon utilisation. Je joue à des jeux vidéos,dev et de la bureautique classique. Rien de bien folichon tout est similaire.
Concernant l'argument que j'ai vu passé au début des messages sur le temps de boot amélioré avec systemd. C'est assez faux systemd est plus rapide que SysVinit mais il est beaucoup plus lent que s6, dinit, openRC ou runit.
Systemd, je n'y vois aucun avantage et je ne suis pas assez technique pour y voir des inconvénients. A sa sortie j'en ai effectivement vu beaucoup car il était très instable et m'a forcé à refaire plusieurs machines, il faut bien que jeunesse se fasse, maintenant RAS.
J'utilise une distribution avec systemd au quotidien la seule chose qui me dérangerai à la limite c'est la complexité et l'opacité (du coup liée) qu'il propose. A mon sens, et parce que je ne suis pas un vrai admin sys, un système simple et rustique c'est un système ou les briques logicielles n'éloignent pas l'humain ou ne lui enlève pas de pouvoir. Personnellement je me sens à milles lieux de cette brique logicielle je ne la comprends tout simplement pas alors que runit est compréhensible par n'importe qui par exemple. Ca me fait penser aux logiciels open source installables par tous ou la complexité de déploiement te fais passer à la caisse. C'est une petite perte de pouvoir, faut l'accepter si on l'utilise voila tout.
Sinon, les seuls vrais déboires que j'ai eu c'etait lors de l'utilisation de distros basées sur musl là c'etait vraiment la mouise. le son, l'horodatage, les applis qui plantent ouch. Je ne sais pas si c'était la faute de la distribution ou de musl mais j'ai vite rebroussé chemin.
Ce n'est pas grâce à systemd que tout se passe mieux. Il y a peut être des éléments qui se sont améliorés mais ça ne concerne pas mon utilisation. Je joue à des jeux vidéos,dev et de la bureautique classique. Rien de bien folichon tout est similaire.
Tant mieux pour toi si tout se passe bien pour ton cas de figure.
Moi je me demande pourquoi toutes les distros auraient sauté sur systemd si c'est tellement pourri.
J'ai lu maintes fois que c'est parce que "RedHat l'a forcé et tout le monde a été obligé de suivre", mais l'existence même de distros ayant très peu de moyens qui n'y ont pas recours prouve que cet argument ne tient pas: aucune distro n'était obligée de l'adopter.
Et je pense que c'est parce que ça facilite la tâche des mainteneurs. Et donc ils passent moins de temps sur les scripts init, et plus à peaufiner d'autres trucs. Et conclusion: les utilisateurs y gagnent aussi, indirectement.
Moi je me demande pourquoi toutes les distros auraient sauté sur systemd si c'est tellement pourri.
Étrange comme réponse, personne a affirmé que c'était pourri dans nos échanges.
J'ai lu maintes fois que c'est parce que "RedHat l'a forcé et tout le monde a été obligé de suivre", mais l'existence même de distros ayant très peu de moyens qui n'y ont pas recours prouve que cet argument ne tient pas: aucune distro n'était obligée de l'adopter.
Forcé je sais pas, ce que je vois c'est que Redhat est une entreprise avec de nombreux utilisateurs, du flouz, un ecosystème complet, des contributeurs kernel, un pied dans la Linux foundation, une image qui était très correcte à lépoque. Pour Suse par exemple ça passe bien et ça standardise dans un monde économique qui veut conquérir un marché, tout bénéf. Pour Jean-Michel qui fait sa petite Debian perso c'est vécu autrement et par question d'énergie à poser dans la projet il se conforme, c'est logique et humain.
Les petites distributions dont tu parles ont systemd sous une autre forme. Vous voulez d-bus, lightdm, un DE nouvelle génération ? Vous êtes obligé de passer par elogind et là, la salle se vide. Même les distros qui se réclament anti-systemd possèdent majoritairement elogind. On peut donc dire qu'elles sont très raisonnables dans leur approche de systemd. Pour aller dans ces contrées obscures on se retrouve avec du KISS, Hyperbola, Obarun. C'est tout de même pas fait pour n'importe qui. C'est un choix, c'est bien qu'il existe. Ce qui est dramatique c'est d'enlever ou de complexifier la possibilité de faire ce choix. De nombreux mainteneurs de distributions sans systemd reproche cet état de fait.
Posté par sebas .
Évalué à 7 (+5/-0).
Dernière modification le 18 février 2025 à 21:18.
j'aurais aimé qu'on me laisse le choix Debian avec ou sans systemd, parce que j'ai pas que ça à faire de tout ré-apprendre après qu'on me l'ait imposé, j'ai d'autres trucs à faire
Sans même parler de devuan, il y a MX-linux qui est une debian pure avec une config de base très légèrement différente, un dépôt MX additionnel et quelques outils en plus (qu'on peut virer sans problème, si on n'en veut pas), et qui laisse le choix sysVinit ou systemd à chaque boot.
The systemd argument is largely an argument about the Unix philosophy:
Write programs that do one thing and do it well.
Write programs to work together.
Write programs to handle text streams, because that is a universal interface.
Some people feel that Systemd doesn’t follow that philosophy very well.
C'est précisément ça que je repproche à systemd (non, je n'ai pas oublié le commentaire précisant que systemd est modulaire et qu'on est pas obligé de tout prendre. Ceci dit, quelqu'un a déjà essayé de ne pas tout prendre ?)
L'approche de MX Linux est intéressante et semble se couper de la Debian moins que la Devuan :
Because the use of systemd as a system and service manager has been controversial, we want to be clear about its function in MX Linux. Systemd is included by default but not enabled. You can scan your MX system and discover files bearing systemd* names, but those simply provide a compatibility hook/entrypoint when needed.
MX Linux uses systemd-shim, which emulates the systemd functions that are required to run the helpers without actually using the init service. This means that SvsVinit remains the default init yet MX Linux can use crucial Debian packages that have systemd dependencies such as CUPS and Network Manager. This approach also allows the user to retain the ability to choose his/her preferred init on the boot screen (GRUB).
Si je trouve le temps, peut-être un test en VM d'abord.
Posté par raphj .
Évalué à 3 (+1/-0).
Dernière modification le 18 février 2025 à 23:42.
C'est précisément ça que je repproche à systemd
Mais systemd n'est pas un bloc monolithique, c'est un ensemble de petits outils qui se concentrent sur une chose et qui fonctionnent bien ensemble. Du coup, de ce point de vue, ça respecte la philosophie unix. Je ne commente pas l'aspect "bien" de "faire une seule chose bien", on peut subjectivement trouver qu'ils ne font pas bien le taf.
Le pid 1 de systemd est peut-être plus complexe que le reste, peut-être qu'on peut discuter cet aspect, en vérifiant que les alternatives ne sont pas aussi complexes de toute façon, à fonctionnalités comparables.
On peut regretter que journald ne soit pas optionnel (pid 1 l'est probablement, je suppose qu'on peut utiliser la plupart des outils systemd sans, à vérifier), donc la modularité a ses limites, mais pareil, est-ce plus modulaire ailleurs ? Vrai question, je ne suis pas trop familier avec les alternatives.
Enfin, on peut regretter que journald stocke les journaux en binaire. Question de goût, je suppose que c'est pour des questions de robustesse et d'efficacité. Je comprends qu'on n'aime pas trop, en même temps ça ne m'est jamais arrivé de m'en rendre compte parce que je trouve journalctl très agréable à utiliser pour manipuler les logs.
En résumé, qu'est-ce qui n'est pas unix pour toi dans systemd, et quels inconvénients cela apporte en ptatique ? (Après avoir lu les contre-arguments aux critiques usuelles là : http://0pointer.de/blog/projects/the-biggest-myths.html_ en particulier les points 1 et 10)
Je note l'inaccessibilité des logs sans utiliser un binaire systemd, j'entends, avec les réserves que j'ai émises dans l'autre commentaire.
Sinon j'entends aussi l'argument de n'être pas familier avec la solution, en vrai c'est une vraie bonne raison.
Concernant ta question sur la modularité et si quelqu'un a essayé en pratique, je n'ai pas trop essayé à part utiliser ou non systemd-networkd, nspawn et leur solution pour remplacer cron (?). Je dirais que c'est à la critique de montrer que ce n'est pas modulaire.
Mais en vrai, la philosophie unix, je m'en fiche un peu, ce qui m'importe c'est que ce soit efficace, clair et si possible élégant. Un argument plus fort pour moi serait la présentation d'une alternative dont la fonctionnalité principale n'est pas "n'est pas systemd", mais des arguments convaincants sur pourquoi c'est mieux. Sachant que pour moi, l'arrivée de systemd a été une grosse amélioration. Écrire un service par exemple, largement plus simple et plus compréhensible qu'un script shell parce que c'est en mode déclaratif et c'est très conscis. C'était déjà le cas avec upstart, qui était pas mal, mais pour moi systemd est juste un meilleur upstart, avec si j'ai bien compris un peu d'inspiration du côté de launchd avec l'activation par socket (qui semble être une excellente idée, pour avoir accès à des fonctionnalité sans tout devoir lancer en avance).
Si SystemD est un bloc monolithique ou tout les soft doivent être redéveloppé quasiment pour SystemD. Comprends bien l'énormité de cette affirmation. C'est plus simple d'adapter un soft Linux à BSD et peut-être même à Windows (non Unix) qu'à SystemD…
Je suis pour autant d'accord pour dire que systemd apporte un plus à SysVinit. Cependant il se développe d'autres alternatives, toutefois pas encore aussi mâture (fautes de moyens). Je pense à Dinit. Le problème n'est pas simple à résoudre mais SystemD est une mauvaise solution (mais la meilleure pour l'instant).
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
A peu près aucun sont n'est lié au bout de l'OS. Je veux dire ma DB peut démarrer 2h après l'OS et inversement l'OS boot très bien sans ma DB. Pareil pour l'environnement de bureau. Avec SystemD je dois répondre mon soft pour qu'il utilise SystemD dans sa pile réseau et tout un tas de trucs… des trucs tout aussi indépendant du bout…
Bien sûr tous veulent démarrer au boot (un script à lancer) et être relancer en cas de plantage (test + lancement).
Qu'il y ait un ou 2 détails à adapter OK. Mais là c'est trop.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Avec SystemD je dois répondre mon soft pour qu'il utilise SystemD dans sa pile réseau et tout un tas de trucs… des trucs tout aussi indépendant du bout…
Es-tu bien conscient que cette phrase est absolument incompréhensible ?
Concernant la gestion des services par systemd, je pense que les administrateurs système et les mainteneurs de paquets des distributions sont quasi unanimes pour dire que cela rend la tâche plus facile, plus simple et plus efficace.
Avec SystemD je dois répondre mon soft pour qu'il utilise SystemD dans sa pile réseau et tout un tas de trucs…
Je ne comprend vraiment pas ce que tu veux dire. À quel moment ton serveur est dépendant d'une pile réseau de systemd ? Quand je développe un soft réseau, je le fais exactement comme avant, avec une socket. Et quand j'ai fini, écrire l'unit systemd qui la lance au démarrage me prend environ 5 minutes…
Write programs to handle text streams, because that is a universal interface
Ca aussi l'ami Lennart a une idée pour faire mieux dans sa présentation :
Idea: someone should build a shell, that deals in JSON objects (hey jq), works
natively with Varlink IPC (and the various flavours of JSON over HTTP), as well as
programs that take JSON as input and/or output, but retains UNIX concepts such
as shell pipelines (JSON-SEQ?) and so on.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
À propos de ton dernier paragraphe : j'ai espoir que je ferai partie de la seconde catégorie de gens mais je comprends parfaitement les difficultés liées à réapprendre des choses qu'on sait déjà faire efficacement avec un système qui est remplacé. C'est assez frustrant.
Je ne l'ai pas trop vécu avec la transition vers systemd (et la transition vers upstart avant ça), mais on ne peut pas dire que j'avais une utilisation avancée. Je redémarrais les services (d'ailleurs la commande pour ça, service xxx restart, fonctionne toujours, même si elle est découragée et qu'elle va certainement disparaître et qu'elle n'est même pas partout) et consultais les logs, sans plus.
Tu installes un nouveau service, tu sais direct comment t'en servir, et notamment que tu peux avoir ses logs en lançant journalctl -fu service par exemple. grep, tail, tout ça, tu peux continuer à les utiliser en apprenant une commande : journalctl -u service; c'est pas la mort. En général il y a un flag pour faire ça mieux direct dans l'outil, mais c'est toujours possible.
Ou pas. Genre tiens mon service "zefklop" a pas démarré (ou si?). Faisons juste un ps ax | grep zefklop. oula non. systemctl status zefklop parcequ'on est moderne:
octane@patate:~ $ systemctl status zefklop
● zefklop.service - On-premise tartiflette AI powered (multi-instance-master)
Loaded: loaded (/lib/systemd/system/zefklop.service; enabled; preset: enabled)
Active: active (exited) since Tue 2025-02-18 17:20:32 GMT; 14h ago
Process: 302473 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
Main PID: 302473 (code=exited, status=0/SUCCESS)
CPU: 6ms
Feb 18 17:20:32 patate systemd[1]: Starting zefklop.service - tartiflette On-premise
Feb 18 17:20:32 patate systemd[1]: Finished zefklop.service - tartiflette On-premise
Bien bien bien. Du coup on a "active (exited)" Ca veut dire quoi? code=exited status=SUCCESS? Donc il a démarré, mais il est arrêté?
Bah non, tout faut, zefklop.service c'est un lien sur /bin/true (pourquoi? parceque fuck you, that's why!!) et qu'il fallait utiliser systemctl start zefklop@default t'avais qu'a lire la doc! (wut?). Et t'as de la couleur dans le terminal! Et va pas faire un tail /var/log/messages parcequ'il est vide, lol! systemd c'est modulaire, mais faut prendre tout le package complet sinon ça marche moins bien.
Cette standardisation, ça demande effectivement un apprentissage initial, mais sur le long terme, c'est moins la pagaille, l'ensemble est plus facile à comprendre et au final c'est moins d'effort.
Ouais. Comme tail, grep, cat, et quelques autres outils utilisés universellement ailleurs. C'est effectivement un apprentissage initial (c'est quoi déjà le -x de journalctl? ou c'est -u, ou attends je suis au travers d'un xterm dans un VNC et journalctl a gentiment mis de la couleur et du scroll à droite/gauche sauf que du coup j'ai pas la fin de la ligne).
C'est toujours un plaisir de passer 2h à chercher de la doc pour apprendre l'existence d'une option assez obscure et mystérieuse qui fait exactement ce que tu veux faire dans un cas précis d'usage (car systemd sait ce qui est bon pour toi). Tu mets l'option, ça marche de manière assez mystérieuse, et tu t'empresses de l'oublier. Learn once, use once, forget immediately. Ca me rappelle l'époque héroïque de windows quand on te disait d'aller manipuler des clés dans la base de registre avec des valeurs opaques. Des fois ça marchait bien. J'ai du utiliser l'autre jour "ConditionPathExists=!/etc/ssh/sshd_not_to_be_run
" Je suis heureux de savoir que ce genre de directive existe. C'est très utile.
Je vais me faire moinsser encore une fois, mais vous connaisser le sketch du tailleur de Fernand Reynaud? https://www.youtube.com/watch?v=TtADuXkM560 bah je crois que c'est un peu ça le principe. Tu fais tout comme systemd veut que tu fasses, t'es content. Tu veux faire légèrement différent, il ne reste qu'à te tordre en deux pour faire à la manière de systemd et tu seras content. Ca va toujours pas? Bah t'as toujours rien compris, tu te tiens mal et tu fais mal, fais comme systemd veut et tords toi encore un peu et ça sera bien.
La mauvaise foi…
Tu vois bien que la commande systemctl donne beaucoup plus d'information que ta commande ps
active (exited) se comprend aisément : le service est active mais ce n'est pas un démon. un démon afficherait active (runing)
Pour les logs, à ma connaissance, toutes les distributions continuent à fournir rsyslog même si ce n'est pas installé par défaut. Donc tu as le choix et cela te laisse le temlps de te familiariser avec journald pur en voir les avantages et les incovénients.
Je ne vois pas comment on peut prétendre administrer un système (en pro ou en amateur), pou faire du développement, sans faire de la veille technologique et lire de la doc. Et pour ne pas oublier, on prend des notes surtout quand ce sont des choses inhabituelles et nouvelles.
La mauvaise foi…
Tu vois bien que la commande systemctl donne beaucoup plus d'information que ta commande ps
J'ai pas dit que ça en donnait plus ou moins.
active (exited) se comprend aisément : le service est active mais ce n'est pas un démon. un démon afficherait active (runing)
Ah bah ui, c'est évident. Bien sûr. C'est clairement indiqué. Parfaitement lumineux. Running pour un daemon, exited pour pas un daemon. Mais mon service zefklop est un daemon. Sauf qu'il n'en est pas un, c'est clair comme du cristal avec "active (exited)".
Pour les logs, à ma connaissance, toutes les distributions continuent à fournir rsyslog même si ce n'est pas installé par défaut. Donc tu as le choix et cela te laisse le temps de te familiariser avec journald pur en voir les avantages et les incovénients.
attends je retrouve mes notes ou j'avais noté les options utiles de journalctl.
Je ne vois pas comment on peut prétendre administrer un système (en pro ou en amateur), pou faire du développement, sans faire de la veille technologique et lire de la doc. Et pour ne pas oublier, on prend des notes surtout quand ce sont des choses inhabituelles et nouvelles.
Donc exactement ce que j'ai fait?
(oulala mon karma en prend un coup sévère)
(vite, vite :
Oh, systemd, tu es si grand, si beau 🎶😅
Un seul process pour tout, quel cadeau ! 🎵🤨
Tes logs en binaire, quel doux parfum 🤩🎶
Et tes dépendances, un vrai festin ! 🎵🙃
Qui voudrait d'un Unix léger et charmant ? 🤔🎶
Vive systemd… (et pour longtemps?) 😵🎵
siouplaît, pourrissez pas trop mon karma coeur avec les doigts)
Posté par raphj .
Évalué à 5 (+3/-0).
Dernière modification le 19 février 2025 à 11:50.
Ah bah ui, c'est évident. Bien sûr. C'est clairement indiqué. Parfaitement lumineux
Ça m'a clairement surpris les premières fois. active (exited) est surprenant. Ça, je suis d'accord.
Bon, la sortie est certainement perfectible, mais une fois qu'on a compris la logique, ça va, non ?
Le système permet de gérer des units qui exécutent un programme qui retourne immédiatement pour mettre en place un truc, et c'est pas mal d'avoir un statut qui indique que ça a bien été lancé et que ça s'est bien passé.
Bah non, tout faut, zefklop.service c'est un lien sur /bin/true (pourquoi? parceque fuck you, that's why!!) et qu'il fallait utiliser systemctl start zefklop@default t'avais qu'a lire la doc! (wut?)
Je n'ai jamais observé ça. C'est quoi zefklop ? Un exemple concret, pas inventé, permettrait d'évaluer la situation correctement et objectivement.
parceque fuck you, that's why!!
Bon, rarement quand-même, il y a souvent une bonne explication à un truc qui nous parait initialement incompréhensible. C'est sûr que si tu prends les dev pour des adversaires, la vie va être triste.
Faisons juste un ps ax | grep zefklop. oula non
Bah pourquoi pas ? Ça fonctionne toujours et je ne m'en prive pas.
On critique justement systemd parce que ça fonctionne plus pareil et que ça veut remplacer les outils unix de base, mais quand ça marche, un grand plat de pâte géant nous interdit de les utiliser ? C'est un pattern que je vois pas mal dans les commentaires ici. "On nous dit de". On nous dit rien du tout, juste appelle ton grep et ton tail sur journalctl et appelle ps aux | grep pour trouver ton service, je ne vois pas où est le problème, personne ne va te manger si tu fais ça.
c'est quoi déjà le -x de journalctl? ou c'est -u, ou
Que suggères-tu comme solution ? Parce que tes outils unix historiques, ils sont tous comme ça. Il n'y a pas plus unix que des paramètres au nom plus ou moins arbitraire et plus ou moins logique à apprendre à utiliser. Regarde justement ps ax. C'est cryptique au possible. Perso j'écris ps aux, ou ps -ef si le précédent ne marche pas avec la version de ps que j'ai en main, sans savoir ce que ça veut dire parce que je sais que ça fait le taf, mais c'est pas très intelligent. Mais bon c'est pas grave, si un jour je suis curieux, il y a la doc. Pour ps comme pour journalctl, également de la même manière avec man ou -h.
Bref, critiquons systemd pour ses particularités, par pour les caractéristiques qu'il partage avec son écosystème, surtout quand on voudrait qu'il soit un peu plus dans la philosophie de cet écosystème.
Tu n'as même pas besoin de savoir beaucoup de choses pour utiliser systemd. Voilà tout ce que j'utilise de lui, et je n'en sais pas plus (notamment, l'option -x, je ne sais pas ce qu'elle fait et je n'en ai pas encore eu besoin - ou peut-être je passe à côté de quelque chose mais je suis encore vivant) :
l'option -u (pour unit, unité) pour cibler le service dont tu veux les logs. À omettre si tu veux tous les logs.
l'option -r (pour reverse, inverser) pour lire les logs du plus récent en bas. Franchement, ça aurait pu être par défaut, mais bon, les outils historiques ont le même sens de lecture que le sens par défaut
l'option -f (pour follow, suivre) pour suivre les logs en temps réel.
Propose aussi simple avec les outils Unix traditionnels.
Maintenant qu'on vient d'établir que journalctl est aussi simple d'utilisation que possible, et suite aux échanges dans ces commentaires, je vais avoir besoin d'être convaincu que l'affirmation suivante est fausse : les attentes sur systemd de la part de ses détracteurs sont irréalistes, et ce qu'ils proposent est moins utilisable, moins fonctionnel, ou n'existe pas. Bon, pour être tout à fait honnête, c'était déjà mon avis avant ces échanges.
Autre affirmations à casser :
Les systèmes d'init alternatifs obligent à écrire des scripts shell pour définir des services et/ou de hardcoder le processus entier de boot (ce qui est à la fois un calvaire pour la distribution et pour l'utilisateur ou l'utilisatrice), au lieu d'utiliser un format déclaratif dans lequel on peut lister les dépendances et d'avoir un moteur d'exécution qui résout ses dépendances proprement.
Ils ne proposent pas non plus un système d'activation lazy par l'accès à un socket, ce qui fait que tout ce dont on pourrait potentiellement avoir besoin doit être démarré en avance, et tout doit tourner sur la machine en permanence.
La seule chose qui m'a convaincue pour le moment, c'est le retour d’AncalagonTotof sur le fait que c'est difficile de retrouver ses petits après un changement, mais ce n'est pas vraiment spécifique à systemd, c'est commun à toute évolution.
Je n'ai jamais observé ça. C'est quoi zefklop ? Un exemple concret, pas inventé, permettrait d'évaluer la situation correctement et objectivement.
tor
Y'a un tor.service et un tor@default.service. Encore une syntaxe à apprendre (mais pourquoi le arobase?? quel est le sens de tout ceci?), il y a surement une bonne explication à ce truc qui me paraît initialement incompréhensible.
Bon, rarement quand-même, il y a souvent une bonne explication à un truc qui nous parait initialement incompréhensible.
Oui, mais on est pas forcément d'accord avec ces justifications.
C'est sûr que si tu prends les dev pour des adversaires, la vie va être triste.
I'm my worst enemy, muhahahaha!!!
Propose aussi simple avec les outils Unix traditionnels.
tail -f /var/log/messages | grep zefklop
En fait, je pense qu'il y a pas vraiment de solution. Je vais continuer de rager dans mon coin tel un vieux boomer qui râle en disant que de son temps les trains arrivaient à l'heure et les prix ne dépendaient que de la distance, et je suis entouré de gens qui vont me dire que non non vieux boomer c'est mieux avec la nouvelle tarification et que j'ai le choix entre uber et blablacar. systemd fait plein de trucs géniaux, j'ai toujours pas compris (enfin si j'ai très bien compris, mais ce ne sont pas des problèmes pour moi) quels problèmes ça résoud et quel génie Lennart est.
Je vais m'en retourner à mon service de tartiflette on premise, parceque l'heure tourne (déjà midi passé! :o )et que j'ai faim.
Posté par raphj .
Évalué à 3 (+1/-0).
Dernière modification le 19 février 2025 à 12:39.
Y'a un tor.service et un tor@default.service. Encore une syntaxe à apprendre (mais pourquoi le arobase?? quel est le sens de tout ceci?), il y a surement une bonne explication à ce truc qui me paraît initialement incompréhensible.
Merci pour l'exemple concret :-)
Okay, j'ai été voir par curiosité. Je n'ai jamais mis tor en place. Ça a l'air d'être un choix de conception de Tor expliqué ici : Tor a décidé que ça devait être un système multi-instance, dont une par défaut (le default), et que lancer Tor sans préciser d'instance n'a pas de sens.
Ils auraient pu décider de ne pas fournir de tor.service, ou de le faire échouer avec un message d'erreur spécifique, en tout cas systemd ne les empêchaient pas de le faire. Pourquoi ils ne l'ont pas fait, je ne sais pas, en tout cas ça n'a pas l'air d'être la faute de systemd.
Quant au @, c'est une convention que d'autres services utilisent. Par exemple systemd-nspawn. Si tu veux gérer un conteneur tartampion avec un service, tu vas avoir un service nommé systemd-nspawn@tartampion.service. Tor a réutilisé cette convention pour son système multi-instance. Je note qu'il n'y a d'ailleurs pas de systemd-nspawn.service, Tor pourrait certainement calquer ça pour éviter les surprises. Moi, je trouve ce @ élégant, mais question de goût. Ça aurait pu être un autre caractère. C'est bien que ça ne soit pas alphanumérique, ni un tiret, ni un point, bref, pas un caractère que tu peux utiliser dans une le nom d'une variable C. Ça aurait pu être dans un sous-dossier mais je suppose que ne pas gérer une arborescence simplifie les choses.
Donc quand tu utilises tor@default.service, tu gères l'instance default de tor. Il semble important de comprendre cet élément central de l'architecture de tor.
Pour moi on est effectivement dans une situation où il y a une bonne explication à un truc initialement incompréhensible, et ça montre aussi que c'est facile de rejeter la faute sur le mauvais acteur si on ne s'est pas assez renseigné, entrainant potentiellement des échanges un peu stériles parce que les critiques sont incompréhensibles ou tombent à côté de la réalité, et du coup c'est impossible d'échanger sur une base commune compréhensible.
Oui, mais on est pas forcément d'accord avec ces justifications.
Oui, évidemment, mais du coup ce n'est plus juste "fuck you" :-)
quel génie Lennart est
il ne s'agit pas de ça, et par ailleurs, j'aimerais aussi avoir des trains à l'heure avec une tarification qui a du sens, le train étant un de mes modes de transports principaux.
Quant au @, c'est une convention que d'autres services utilisent
Non, c'est une fonctionnalité bien précise de systemd, et qui permet de passer un argument à un service. Il est ainsi possible de récupérer cet "argument" dans le fichier de service, et l'utiliser pour lancer le service correctement.
AMHA, la présence de ce tor.service ressemble fortement à une erreur.
Non c'est exprès :
$ systemctl cat tor.service
# /usr/lib/systemd/system/tor.service
# This service is actually a systemd target,
# but we are using a service since targets cannot be reloaded.
Ah oui, en effet, mes confuses, une petite lecture de /lib/systemd/system/systemd-nspawn@.service m'aurait permis d'éviter de dire des âneries. Comme quoi on en apprend tous les jours, y compris au plus profond d'un troll systemd xD
Non c'est une expérience tout à fait valide qui essaye d'excuser SystemD.
La vérité c'est qu'un serveur Web performant comme NginX, c'est simple a configurer/debugger, une base de donnée comme MySql aussi, un OS comme Linux idem. Par contre systemd, dès que tu veux un truc tordu c'est compliquer car c'est très mal conçu. Ce n'est pas KISS. Le problème c'est que c'est au soft et à l'OS de s'adapter à SystemD. Alors que c'est le serveur HTTP qui s'adapte au langage (PHP, Html ou Java).
Rien à été conçu dans SystemD pour decoupler les choses.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Posté par raphj .
Évalué à 4 (+2/-0).
Dernière modification le 19 février 2025 à 07:26.
Rien à été conçu dans SystemD pour decoupler les choses.
Au contraire, je crois que c'est l'inverse. Tu as un exemple de deux choses qui pourraient et devraient être découplées (parce que ce serait utile, avec un exemple de pourquoi ce serait utile) mais qui ne le sont pas ? Et qui le sont dans un projet équivalent ?
Je crois qu'il y a confusion entre la modularité du logiciel et celle de sa distribution.
systemd est modulaire en tant que logiciel, avec des interfaces DBus définies. En tout cas dans la théorie, car dans la pratique quasiment aucun de ces modules n'a jamais eu d'alternative.
Par contre, j'ai l'impression que les distributions ne veulent pas tenter l'aventure de la modularité: systemd c'est souvent un seul paquet, avec tous les modules dedans. Une belle surface d'attaque, et un frein à l'apparition d'alternatives. Personnellement c'est ce que je reproche à systemd depuis ses débuts; car à part ça, la base (services, timers, paths, etc) marche très bien pour moi, et je n'imagine pas revenir à cron et son horrible syntaxe.
Posté par raphj .
Évalué à 3 (+1/-0).
Dernière modification le 19 février 2025 à 08:59.
Ah oui, en effet. Dans ce cas, j'imagine que la faute est partagée :
les distributions devraient modulariser la distribution de systemd
il n'y a pas, de la part du projet systemd, une volonté de pousser les distributions à modulariser, notamment en donnant des guidelines pour l'empaquetage
Peut-être que ça viendra si une alternative un minimum suivie réutilise certaines briques de systemd et pas d'autres.
A tout hasard, prenons le DNS. Partout il est indépendant. Dans SystemD c'est hyper imbriqué. Au point que toute la pile réseau est obliger de s'adapter à SystemD. C'est hyper handicapant.
Aucun autre système d'Init n'a quelque chose de pareil.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Posté par Voltairine .
Évalué à 4 (+3/-0).
Dernière modification le 19 février 2025 à 09:47.
A tout hasard, prenons le DNS. Partout il est indépendant. Dans SystemD c'est hyper imbriqué.
De quel sorte de « DNS » veux-tu parler ? D'un résolveur cache local comme le fait systemd-resolved ?
C'est imbriqué dans quoi ? systemd-resolved peut être utilisé ou pas c'est au choix et il ne fait pas partie du système d'init !
J'ai l'impression que tu es très critique sur une technologie que tu ne comprends pas vraiment.
Et aussi qu'il reproche à systemd les choix fait par les mainteneurs de la distribution. Ma distro démarre bien avec systemd mais je n'utilise pas systemd-resolved à moins de l'activer.
Voila c'est juste ça. Les artisans sont mis dehors, et on uniformise le tout, pour scaler sans problème et avoir une qualité gérable dans le temps.
Alors oui un expert/artisan ne sera pas content et voudra continuer à faire comme avant, à maitriser chaque brique (et donc y passer sa vie à ne faire que ça, car le sujet est massif). Là où l'industrie a juste besoin d'une brique que tout le monde peut utiliser de la même manière, qu'une modification se fasse partout pareil, et surtout qu'elle puisse se concentrer sur les applications, et non pas sur l'init d'un foutu serveur. Car l'init ne rapporte rien, les applications si.
Et on a la même avec les systèmes de packages et de distribution d'application: pris seul oui techniquement rpm ou deb est mieux, mais ça ne scale pas à une industrie entière, d'où l'arrivée des flatpack et autre système uniforme. Au moins avec systemd on a eu un vainqueur rapidement. Avec les distributions d'applications on en a malheureusement plusieurs. Et je dis bien malheureusement car au moins avoir un champion par défaut, et des alternatives à côté permettrait de continuer d'innover sans bloquer l'industrie qui elle a besoin d'uniformisation.
Ce n'est juste plus un métier pour les artisans, au mieux un hobby et c'est déjà très bien. Mais ce temps est passé, l'argent est arrivé en masse, avec une masse de salariés, et donc un besoin d'uniformisation.
C'est un peu triste car il y a beaucoup moins de projets foufous, mais une industrie n'a pas besoin d'eux.
J'attaque SystemD dans mes messages pour la philosophie et les choix non UNIX pris. Mais concrètement je n'ai pas toujours la solution technique. Mais je sais, que même si elle n'est pas simple, elle existe certainement.
Fondamentalement on voit une différence profonde de compréhension technique et de la philosophie KISS (maintenable) entre L'encart Potering et Linus Torwald. Linux à une capacité à taper du point sur la table et à dire non à l'ajout de fonctionnalités utiles car le choix technique ne convient pas. C'est frustrant mais on finit par trouver ue solution technique. C'est grâce à ça que son nées les fonctionnalités avancées de sécurité qui ont permis de créer Docker. Et vous remarquerez que Docker (et ses concurrents) sont des projets indépendant du noyau Linux.
Lennart n'a pas cette force de caractère et en plus il est affaibli par son historique. C'est un mauvais leader technique.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Je m'attendais pas en postant ce lien de créer une telle flamewar. Je pensais que systemd avait tellement bien fait ses preuves que ses débats étaient d'une autre époque.
Par contre, je note bien qu'après que tout tes arguments techniques ont été contré, tu passe aux attaques personnelles à l'encontre de Lennart.
Non les arguments technique restent, il n'y a rien de personnel contre Lennart. C'est contre les choix techniques qu'il a fait. (Après il n'est sans doute pas seul).
SystemD est parfait pour le néophyte. La documentation est plutôt bien faite et ce n'est pas difficile de s'y mettre… le problème c'est de le debugger en cas de problème. Que l'on soit expert ou pas. Mais le problème n'est même pas vraiment là. Le problème c'est que l'on sait qu'une partie de ces problèmes sont du aux choix de SystemD. La pluspart sont résolu en contournant SystemD… voir pour certain en le subtilisant.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Lennart n'a pas cette force de caractère […]
il n'y a rien de personnel contre Lennart
Est-ce que tu vois la contradiction ? Tant qu'on est dans le personnel, tu parles de "force de caractère" mais j'ai régulièrement l'impression que tes messages (à propos de systemd, Rust, ou même musk & l'IA) sont un genre de patchwork de morceaux trouvés sur le net. Tu balances des pseudo-facts sans jamais argumenter.
le problème c'est de le debugger en cas de problème.
C'est à dire ? Pourquoi un service systemd serait plus compliqué à débugguer qu'un script SysVinit ?
La pluspart sont résolu en contournant SystemD… voir pour certain en le subtilisant.
Subtiliser systemd ? Il est libre, tu peux le prendre pas besoin de le voler (oui je fais l'idiot, je suppose que tu voulais dire "substituer")
Je m'attendais pas en postant ce lien de créer une telle flamewar. Je pensais que systemd avait tellement bien fait ses preuves que ses débats étaient d'une autre époque.
Pas vraiment non. Et le prosélytisme ainsi que l'agressivité du projet pour intégrer des besoins indépendants devrait interroger sur sa finalité (ne pas oublier que Microsoft est à la manœuvre). C'est très politique tout ça.
Techniquement j'ai fais le chemin inverse Systemd -> SysV (nu). Les prisons dorées, ça attire toujours, jusqu'à…
Posté par raphj .
Évalué à 4 (+4/-2).
Dernière modification le 19 février 2025 à 11:17.
ne pas oublier que Microsoft est à la manœuvre
Le fait que Lennart bosse pour Microsoft est assez récent dans l'histoire de systemd.
devrait interroger sur sa finalité
Tu as des hypothèses ? J'en vois deux :
L'équipe derrière systemd est honnête sur son objectif de proposer une solution pour le démarrage des systèmes Linux
RedHat précédemment, et maintenant Microsoft, ont malicieusement poussé systemd partout (contre le gré des distributions qui n'ont pas du tout adopté systemd volontairement parce qu'en vrai, ce n'est pas une bonne solution technique qui résout des vrais problèmes que les distributions avaient sans systemd - surtout Debian qui n'a absolument pas un fonctionnement bénévole et démocratique et qui s'y est mis immédiatement et sans délai) pour conquérir le monde libre. Microsoft n'a en fait pas embauché Lennart pour son expertise en OS Linux au moment où ils ont un énorme cloud qui repose sur cette techno, et au moment où il veulent proposer du WSL pour récupérer des dev.
La deuxième hypothèse, en plus de sentir un peu la théorie du complot (qu'il faut donc bien étayer), n'explique pas l'absence totale de changement de situation entre le passage de Lennart de Red Hat à Microsoft, qui pourtant ne sont pas trop partenaires (Red Hat n'est d'ailleurs pas dans le store de Microsoft comme distribution installable pour WSL). Il faut aussi bien voir que l'hypothèse 2 ne serait pas une bonne nouvelle sur la gestion d'aucune distribution majeur, et en particulier Debian. En vrai, c'est même une accusation assez grave sur leur fonctionnement, donc ce n'est pas léger.
Alors, il me reste l'hypothèse 1, qui correspond également à mon ressenti personnel (je trouve les système linux incroyablement plus simple à utiliser et à administrer depuis systemd.
Je suis ouvert à d'autres hypothèses ou à des preuves pour étayer l'hypothèse 2 bien sûr.
On peut sortir de cette vision binaire et manichéenne ?
Toutefois, étant donné le nombre de contre-vérités sur sysV on est tout de même en droit de se poser des questions. La très grande majorité des reproches qui lui sont adressés étaient le fait d'un certain historique mais pas d'un problème intrinsèque. On en reparle dans 10 ans, quand j'ai switché c'était déjà une belle usine à gaz.
Ces logiciels répondent à des besoins différents. Par contre il y'a très clairement une volonté, satisfaite, d'hégémonie.
Les scripts shells illisible, inmaintenable, qui changent d'une distro a l'autre car ils ont implémenté un framework shell différent comme base (avec comme mention honorable, debian qui requiert des commentaires avec une syntaxe spécifique)
^
C'est pas un problème intrinsèque à SysV qui a été reproché maintes et maintes fois ?
Et que upstart/systemd ont remplacé par un fichier de conf simple, unifié entre distro, et surtout bien documenté ?
Où est la vision manichéenne ? J'ai demandé d'étayer des accusations sous-entendues dont *je ne suis pas l'origine. J'ai développé cette demande pour montrer les contradictions sur lesquelles on tombe rapidement avec ces accusations.
Accusations que systemd poursuit une finalité questionable, juste après un rappel sur le fait que systemd a un lien avec Microsoft, sans d'ailleurs expliquer lequel. En partant de la supposition que Microsoft c'est le mal, j'imagine.
C'est moi qui suis manichéen ? Si mon raisonnement parait grotesque, il fallait être plus explicite en premier lieu.
Je suis sûr que systemd a des défauts, mais malheureusement, les critiques constructives, factuelles et informées se font rares dans les commentaires de cette page, à la place on a le droit à des tartines de frustrations profondes essentiellement causées par une méconnaissance du sujet, et maintenant, du fud. Super. En vrai, les gens semblent détester systemd de manière complètement irrationnelle. Rien de nouveau depuis 15 ans finalement.
Tant pis, j'irai lire des comparatifs informés avec les alternatives ailleurs à l'occasion pour satisfaire ma curiosité.
Tu en es totalement à l’origine. Tu as juste projeté sur moi une pensée sociale et politique très pauvre. Parce que tu n’es pas capable de mieux.
En partant de la supposition que Microsoft c'est le mal, j'imagine.
C’est pas moi qui le dit. C’est toi. CQFD.
les critiques constructives, factuelles et informées se font rares dans les commentaires de cette page
Elles sont là. Faut juste arrêter d’être sectaire. Pareil, avant de critiquer SysV il faut connaître un minimum. J’ai utilisé les deux, à un niveau plutôt avancé. J’en connais les limites et choisirai en fonction de mon besoin. Quiconque en fait de même reconnaît les idiosynchrasies un peu pénibles, la documentation abyssale à s’avaler, pour trouver exactement le paramètre sur lequel jouer pour remplir son besoin. D’un autre côté ne pas avoir compris que SysV, tout comme Systemd, sont totalement agnostiques de l’exécutable lancé (les deux lancent du shell, du binaire, etc.), ben ça invite pas à la discussion… je suis pas là pour vous tenir la main.
Après on peut se demander pourquoi les projets de Lennart suscitent autant de «passions» (on va dire ça comme ça hein). Du peu que j’en ai lu, lui-même a une manière bien toxique de défendre le bien fondé de ses projets et à les imposer par la force (cf. udev). Insidueusement il fait passer le message de l’homme providentiel qui a sauvé l’écosystème Linux courant à la catastrophe. On aime ça en France les hommes providentiels. Et en Allemagne.
Posté par raphj .
Évalué à 3 (+1/-0).
Dernière modification le 20 février 2025 à 14:32.
Tu en es totalement à l’origine.
Non
Tu as juste projeté sur moi une pensée sociale et politique très pauvre.
Bah oui, à défaut d'avoir une explication demandée à répétition de ce que tu sous-entendais par :
Et le prosélytisme ainsi que l'agressivité du projet pour intégrer des besoins indépendants devrait interroger sur sa finalité (ne pas oublier que Microsoft est à la manœuvre). C'est très politique tout ça.
Insidueusement il fait passer le message de l’homme providentiel qui a sauvé l’écosystème Linux courant à la catastrophe. On aime ça en France les hommes providentiels.
Okay, ça ça pue vraiment du cul comme remarque.
Perso, je n'ai pas de passion pour systemd, si c'était une autre accusation que tu souhaitais exprimer. Mais j'avoue, j'ai du mal avec les argumentations pétées.
En fait, je me demande qui est le plus passionné ici.
Cela ne fait pas Lennart un mauvais développeur ou leader…
C'est un peu la théorie qui dit que le capitalisme tends à mener à son incompétence (on progresse dans la hiérarchie quand on est bon et on stagne quand on est mauvais…)
Plus largement la communauté open-source à plus souvent raison que le leader… c'est un des super pouvoir de l'open-source… il permet un fork par un autre pour mettre en compétition des choix techniques.
Null doute que SystemD tombera un jour. Mais cela peut prendre du temps. En attendant c'est vrai qu'il est intéressant… à défaut de mieux
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Posté par raphj .
Évalué à 3 (+1/-0).
Dernière modification le 19 février 2025 à 11:23.
Et vous remarquerez que Docker (et ses concurrents) sont des projets indépendant du noyau Linux.
Je ne vois pas trop le rapport avec Docker, mais la majorité de ce qui fait fonctionner Docker et ses copains aujourd'hui, c'est des fonctionnalités du noyau Linux et c'est dans le noyau Linux que les développements se sont passés. Notamment tout ce qui concerne l'isolation des différents namespaces. Ces systèmes sont des couches très légères sur des fonctionnalités puissantes du noyau (plus, éventuellement, tout un système de format et de distribution de conteneurs, et un système de virtualization sur les systèmes qui ne sont pas basés sur Linux, peut-être en faisant appel à des briques de toute façon existantes comme Qemu ou Hyper-V, à vérifier).
Fondamentalement on voit une différence profonde de compréhension technique et de la philosophie KISS (maintenable) entre L'encart Potering et Linus Torwald
Mouais, il m'a fallu 30s de recherche pour trouver ce commentaire de Linus :
I believe that many of the "original ideas" of UNIX are more a matter of mindset than a reflection of reality. There is still value in understanding the traditional "do one thing and do it well" model, but that is not how complex systems work, and it is not how large applications were designed for a long time. This is a useful simplification that is true on a "certain" level, but clearly does not describe most of reality. And systemd is by no means the piece that breaks the old legacy UNIX. Graphical applications rarely work like this, and then there is obviously the traditional GNU Emacs counterexample, which was never just a simple UNIX model, but a big new infrastructure, like systemd. Of course, I am old enough to like logs in text and not in binary. Sometimes I think systemd doesn't necessarily have the best taste, but they are details.
Ouais après considérer le monstrueux kernel Linux comme un truc KISS relève un peu de la mauvaise foi. Entre les millions de lignes de code et les méga-octets de binaire final, on est loin de l'architecture d'un micro-kernel par exemple.
J'ai pas dit que ce serait moins bien ou mieux (le débat existe depuis la publication du premier code source par Linus), je dis juste que le kernel Linux n'a rien de KISS contrairement à ce que tu sous-entends.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
La première chose que tu devrais faire avant de râler sur le boulot d'autres personnes, c'est d'apprendre à orthographier correctement leur nom, ce qui serait un poil plus respectueux donc : Lennart Poettering et Linus Torvalds.
1) Je commence par le troll : c'était pas le but. Si, si, je n'en rajoute pas là.
Mais je trouve quand même positif d'avoir mis en lumière la division qui existe toujours entre les pros et les contres systemd. Je ne sais pas si on peut tracer une frontière claire pour délimiter les camps. D'ailleurs, il y a certainement plus d'une seule frontière, et plus que deux camps.
Il y en a une, de frontière, que je situerais entre :
les professionnels qui trouvent beaucoup d'avantages, genre standardisation de la config, et ce, sur de nombreuses distrib (corollaire, ils deviennent plus facilement remplaçables ?)
les amateurs, surtout ceux de longue date, qui ont investi du temps et appris quelques principes, alors que ça n'est ni leur métier, ni leur objectif final. Se prendre dans la face un systemd du jour au lendemain (dans mon cas, passage de la Debian X à la Y, j'ai plus les n° de version en tête), en n'en ayant entendu parler que vaguement, ça fout une baffe qui fait mal et ça fait perdre du temps, faut apprendre une tonne de nouveaux trucs dans un laps de temps très court (et sans connexion internet le jour où ça m'est arrivé. Autrement dit : impossible, réinstallation imprévue, from scratch).
Vous n'êtes pas obligés de relancer la guerre là-dessus.
Non, franchement, y'a des arguments dans tous les camps. Et si je ne me trompe pas, personne ne trouvera l'argument ultime pour mettre tous le monde d'accord.
2) la soluce. À quel problème ? La console effacée à la fin du boot. Quand j'ai eu ce problème de réseau pas totalement/du tout UP alors que systemd tentait quand même de monter les partages réseau, je me suis battu pour essayer d'éviter que la console ne soit effacée à la fin du boot, pas le prompt de login (stop, je sais maintenant, cf plus bas).
"Dans le temps", c'était facile, il suffisait d'ajouter --noclear aux lignes *tty du fichier /etc/inittab.
Donc, dans un premier temps, j'ai cherché à faire de même, mais à la sauce systemd.
Et j'ai trouvé un paradoxe : l'option est présente dans tous les fichiers de service agetty, trouvé à grands coups de find par-ci par-là -type f -exec grep -Hn noclear "{}" \; par exemple, mais la console est effacée quand même.
Buh ?
DuckDuckGo ? Bof, rien d'utile.
Au final, je n'ai réussi qu'à foirer la console : plus du tout de login sur tty1.
C'était il y a plusieurs semaines.
Hier, nouvelle recherche.
Là, j'ai trouvé. Pourquoi seulement hier, et pas la première fois ? Je ne sais pas formuler une recherche ? Qu'est-ce que ça va être quand les prompts/IA seront incontournables … N'en rajoutons pas, c'est de la matière à un autre troll …
Alors ? Cette soluce, c'est quoi ?
déjà, j'ai trouvé plus d'infos pertinentes sur qui fait quoi. Pas trop tôt. Ce qui, au final, m'a permis de faire un systemctl status pertinent cette fois, sur le bon service. Ce qui m'a permis de découvrir que mes tentatives, mes bricolages, m'ont fait faire une connerie conduisant à deux ExecStart par le biais de /etc/systemd/system/getty@tty1.service.d/override.conf. OK, problème de démarrage résolu. Mais quid du --noclear ?
--noclear fait son office. Tout simplement parce que ça n'est pas lui qui efface la console. Devinez … Oui, c'est systemd ! Stop, halte, zut à la fin. Oui, je comprends la logique, y'a pas forcément de rapport entre "il faut effacer la console pour des raisons de sécurité" et "prompt de login" parce que ce dernier n'est pas forcément utile/recommandable sur tous les systèmes, ou dans tous les cas de figure; mais il faut absolument effacer la console quand même, même sans agetty.
Par contre, j'espère que vous allez admettre que l'option à la sauce systemd qui permet de ne plus effacer cette console est bel et bien obscure : TTYVTDisallocate=yes (à changer en =no donc). Source ici. Bon, honnêtement, je n'ai pas encore testé jusqu'au bout : système mis en veille, et non pas rebooté. Mais ça sent bon la soluce quand même.
On est d'accord, y'a pas que moi qui soit le problème dans cette histoire ? Il faut du bol pour tomber là-dessus ? Ou être un pro dont c'est le métier d'apprendre, de se former, si possible en avance et de façon méthodique, en lisant la doc, toute la doc. Pas un amateur qui subit le changement imposé ?
Posté par orfenor .
Évalué à 5 (+3/-0).
Dernière modification le 20 février 2025 à 14:13.
La console effacée (ou qui semble telle) c'est vieux comme une distro Linux. Je cherchais déjà les messages de boot en 1994.
Par contre, merci systemd, je les retrouve facilement sur Debian. J'ai oublié comment (ça sert pas souvent), va falloir chercher un peu (j'ai vraiment oublié).
En lisant tes messages, je me suis plusieurs fois dit que tu cherchais des solutions aux problèmes de ta bécane, plutôt que participer au débat. Franchement, penses-y, parce qu'une discussion technique aurait été plus enrichissante (même si tu as suscité des belles réponses).
Par contre, merci systemd, je les retrouve facilement sur Debian. J'ai oublié comment (ça sert pas souvent), va falloir chercher un peu (j'ai vraiment oublié)
En lisant tes messages, je me suis plusieurs fois dit que tu cherchais des solutions aux problèmes de ta bécane,
Oui, et je ne pense pas l'avoir présenté autrement que : j'ai eu ces soucis, et sans m'être fait imposer systemd, je les aurais résolus plus vite.
plutôt que participer au débat. Franchement, penses-y, parce qu'une discussion technique aurait été plus enrichissante (même si tu as suscité des belles réponses).
On est d'accord que la question n'est pas tranchée, rapport à mon histoire de camps et de frontières ?
On est d'accord que ce qui se justifie parfaitement dans un contexte peut devenir une énorme charge pour ceux dont ce n'est pas le métier ?
Est-ce qu'il faut limiter l'accès, ou le droit de publier ou répondre sur ce site à une ou certaines catégories d'utilisateurs ?
Accessoirement, on s'écarte aussi de la technique en poursuivant le troll, et en négligeant la soluce que j'ai fini par trouver.
Je voulais dire que ce n'était peut-être pas le bon endroit pour poser ta question: le forum avec une question directe sans y annexer de troll ;-) aurait amené plus vite la réponse
J’ai laissé passé du temps. Je suis sincèrement désolé que les esprits se soient si vite échauffés. Je vais tenter de donner mon point de vu en espérant que cela se passe mieux. Et je commence pas te présenter mes excuses.
D'ailleurs, il y a certainement plus d'une seule frontière, et plus que deux camps.
Je me permet[1]. Pour moi il n’y a pas de camps. Je me fou de systemd et il n’est d’ailleurs pas présent sur la machine que j’utilise le plus.
Pour moi c’est fondamentalement une question d’état d’esprit et de réaction à l’évolution. De manière caricaturale est-ce que la réaction primaire a une évolution est la curiosité ou la réactance ? C’est de cette réaction primaire que découle les procès d’intention qu’on peut lire plus haut ou la position qui consiste à se dire que chacun fait de son mieux et que oui systemd peut faire des erreurs, debian aussi et que l’on peut payer les pots casser.
Je n’ai pas encore utilisé wayland par exemple pas parce que je ne l’aime pas je suis sûre que c’est bien debian ne m’a juste pas encore fais switcher.
Il ne faut pas voir ces points de vus comme des camps au quel on appartient (quelque soit le sens qu’on y met) et qu’il faudrait défendre. Il y a tout un gradient entre ces points de vu et les gens peuvent être en réactance sur des sujets et curieux sur d’autres.
Hors d’une question de vérité absolue qui ne me parait pas pertinent, il me semble qu’il est plus agréable d’arriver à adopter une position curieuse que de réactance1. J’ai par exemple plus de mal avec les LLM, mais je test, je me renseigne pour tenter de trouver aussi sincèrement que je peux à quoi ça pourrait servir.
Du coup
On est d'accord, y'a pas que moi qui soit le problème dans cette histoire ?
La question n’est pas de savoir qui est le problème. De mon point de vu je suis convaincu que les mainteneurs de Debian, les développeurs de systemd et toutes les personnes impliquées font de leur mieux. Des fois ça marche mieux et des fois cette chaîne humaine connaît des couacs. Pour moi quand je choisi d’utiliser un système communautaire je reconnais que ce sont des personnes et que je ne suis pas un simple client/consommateur.
Tu parle de moteur de recherche et tu te lamente sur l’IA, mais la force des projet communautaires c’est l’humain justement. Tu as des forums et autres communauté d’utilisateurs qui se feront une mission de trouver des solutions. Si tu ne sais pas où commencer les issues du projet upstream peuvent être un point de démarrage pour demander de l’aide (en respectant la netiquette en vérifiant que la question n’a pas était posée). Cela permet en plus d’aider à la compréhension dev/utilisateur et ce n’est que de l’humain.
ne me faites pas dire ce que je n’ai pas, ne sortait pas ça de son contexte. ↩
# Présentation à FOSDEM
Posté par raphj . Évalué à 10 (+22/-0).
C'était une bonne présentation. C'était aussi cool de voir Lennart en vrai, ça met un visage et un aperçu sur un des personnages dont on entend régulièrement parler.
L'article sur LWN est un bon résumé, reprenant tous les points clés. Il y a aussi eu un passage intéressant sur « Est-ce que systemd respecte la philosophie Unix », qui n'est pas cité dans l'article mais qui vaut le coup. C'est un peu résumé sur le site de systemd (point 10: « Myth: systemd is not UNIX. »). (D'ailleurs, cette page montre à quel point les détracteurs de systemd sont souvent à côté de la plaque dans leurs arguments, il y a une réponse claire à la plupart des critiques qu'on peut lire).
L'impression que ça m'a donné, c'est que l'équipe qui maintient systemd a une vision forte sur comment faire les choses, et que des efforts sont faits pour garder un ensemble propre, cohérent et un bon équilibre entre légèreté, sécurité et fonctionnalités. Par exemple, ils réduisent au maximum le nombre de leur dépendances fortes, et utilisent
dlopenpour les fonctionnalités plus optionnelles. C'est plutôt rafraîchissant de voir ce genre de démarche dans un monde où on s'en fout de rajouter 2000 dépendances transitive et où on bundle le tout pour le balancer au navigateur sans se préoccuper de la situation matérielle des destinataires.J'aime bien aussi leur ambition de standardiser les manières de faire / un certain nombre de choses sur les systèmes GNU/Linux (l'article en parle).
Bref : systemd, j'aime la démarche, et le résultat.
[^] # Re: Présentation à FOSDEM
Posté par devnewton 🍺 (site web personnel) . Évalué à 9 (+6/-0).
J'ai retenu de cette présentation que Rust n'est pas au niveau pour Lennart !
L'idée est de lancer un concours entre Zig/Rust/Go/… pour devenir le premier langage à mériter systemd !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Présentation à FOSDEM
Posté par Donk . Évalué à 6 (+4/-0).
À quand la création de Rustd?
[^] # Re: Présentation à FOSDEM
Posté par bistouille . Évalué à 5 (+3/-0).
Faut le dire aux gens de Redox OS :-)
[^] # Re: Présentation à FOSDEM
Posté par abriotde (site web personnel, Mastodon) . Évalué à -10 (+2/-14).
Franchement voilà, s'il en était besoin, un signe de plus de l'incompétence de Lennart Potering. Il n'est peut-être pas nul mais pas au niveau techniquement.
SystemD coche toute les alertes… eg pourtant ça reste hélas le meilleur choix sous Linux. Je regarde les autres mais aucun n'est aussi abouti (faute de moyens).
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Présentation à FOSDEM
Posté par raphj . Évalué à 10 (+14/-0). Dernière modification le 19 février 2025 à 07:12.
Très bizarres tes commentaires ici. Tu affirmes partout que systemd est mal conçu, que c'est indébogable… Sans jamais rentrer dans les détails.
Moi je dis : il va falloir étayer tout ça, parce qu'il ne suffit pas de l'affirmer pour que ce soit vrai, et je suis loin d'être convaincu. En particulier quand justement aucune alternative crédible n'a réussi à percer malgré les efforts.
Ici tu affirmes que Lennart n'est pas au niveau. Bon déjà il ne travaille pas seul sur systemd, donc tu vises une équipe entière. Et… ça parait grotesque. On peut ne pas aimer son travail, mais son niveau… On parle quand même d'une personne qui a transformé le desktop linux dans plein d'aspects souvent fondamentaux. On n'y arrive pas si on est incompétent. Va falloir étayer aussi, et bon courage.
Concernant Rust, il a argumenté et c'était très raisonnable. Rust actuellement n'est pas adapté au cas d'usage de systemd et ses remarques étaient une invitation à améliorer Rust pour qu'il soit adapté à son cas d'usage. La démarche me parait bonne, mais bon, oui, tu peux continuer à te boucher les oreilles quand des experts mondiaux travaillant sur des parties critiques de ton OS font des retours constructifs sur pourquoi ils ne peuvent pas utiliser telle ou telle techno en l'état et décréter que c'est parce qu'ils sont nuls.
Ça doit demander un sacré égo, ça me laisse admiratif…
[^] # Re: Présentation à FOSDEM
Posté par Pol' uX (site web personnel) . Évalué à 9 (+7/-0).
Ou juste de l'inconscience de son incompétence.
Adhérer à l'April, ça vous tente ?
[^] # Re: Présentation à FOSDEM
Posté par dj_ (site web personnel) . Évalué à 6 (+4/-0). Dernière modification le 18 février 2025 à 17:02.
Le lien direct vers la présentation.
14 Years of systemd
[^] # Re: Présentation à FOSDEM
Posté par David Demelier (site web personnel) . Évalué à 3 (+1/-0).
Son visage apparaissait souvent (et même sur des coussins, mais je trouve plus la photo) et d'ailleurs je sais pas si le travail le stress mais pour son âge je trouve qu'il a pris une claque par rapport aux débuts de systemd. Ça fait presque de la peine, qu'on aime ou pas systemd, il s'est pris une sacré shitstorm dont il en avait fait un message sur google+ à l'époque.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Présentation à FOSDEM
Posté par srb (site web personnel) . Évalué à 1 (+0/-0).
L'article sur les mythes autour de Systemd n'est pas maintenu :
- le mythe 27 parle de leur communauté active sur Google+
- l'article LWN parle de 150 binaires, le mythe 1 indique 69 binaires
ça reste probablement une bonne introduction pour comprendre la vision des deux parties.
# retour sur râleries diverses
Posté par bistouille . Évalué à 9 (+7/-0).
J'ai fait partie de ceusses qui maudissaient Lennart et systemd au début.
Un comble car étant minot j'étais fan de la célèbre revue "Système D" dont j'avais récupéré une collection bien odorante de vieux papier moisi des années 45-50… :-)
Mais ici, point question de bricolage de postes radio à galène, ni de fabriquer une arbalète à grenouilles avec un parapluie (oui cet article a vraiment existé, dans la France d'après guerre, la faim justifiait encore les moyens parfois), ou de faire de la colle à bois avec des tendons et os de lapin…
En 2011 je voyais pas vraiment en quoi il était nécessaire de remplacer le "bon vieil init SystemV".
Bon an mal an je m'y suis fait, par contrainte plus que par plaisir.
Certains détails m'échappent encore mais c'est plus de la réticence au changement et de la paresse intellectuelle que des raisons objectives de détester le machin.
Et maintenant je râle encore tout autant contre nftables… Suis-je le seul?
[^] # Re: retour sur râleries diverses
Posté par Benoît Sibaud (site web personnel) . Évalué à 10 (+14/-0).
Ils ont aussi changé netstat, ifconfig, rajouté un 8e bit, viré lilo voire grub, lxc est ostracisé, alpha et sparc sont reléguées, maintenant tout est flatpak/AppImage/docker/k8s. Ils nous en veulent. Ils nous obligent à changer nos habitudes.
[^] # Re: retour sur râleries diverses
Posté par Maclag . Évalué à 10 (+8/-0).
Tu oublies un peu vite que les gens du kernel, ils ont déprécié OSS pour le remplacer par Alsa, puis ils nous ont imposé PulseAudio et maintenant PipeWire.
Il y a des utilisateurs qui tenaient à se la péter devant d'autres utilisateurs: "Wouaaah! Tu as réussi à avoir le son qui fonctionne?!?" et maintenant, c'est plus possible :-/
[^] # Re: retour sur râleries diverses
Posté par Benoît Sibaud (site web personnel) . Évalué à 10 (+9/-0).
Ah non mais ils ont changé plein de trucs en passant du noyau 1.2.x au 2.x, en abandonnant la libc5, en abandonnant les sites web en WML générés en 9 passes, en remplaçant daCode et Templeet, en allant de GCC 2 à 3, en retirant Clippy, en arrêtant le chiffrement DES des mots de passe, en virant rlogin, le NIS, ils ont quasi doublé la longueur des numéros de téléphone, allongé les adresses IP comme des oufs et je ne parle même pas des mots de passe. Ils sont partout à ne faire qu'à tout changer. Cool bits don't change
[^] # Re: retour sur râleries diverses
Posté par devnewton 🍺 (site web personnel) . Évalué à 10 (+12/-0).
Mais ils n'ont pas encore réussi à gérer l'upload d'images sur linuxfr :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: retour sur râleries diverses
Posté par Nicolas . Évalué à 4 (+3/-0).
Vous faites peur…
[^] # Re: retour sur râleries diverses
Posté par jigso . Évalué à 7 (+5/-0).
le pire, c'est quand on réalise qu'on a toutes les refs.
P…. je suis vieux…
[^] # Re: retour sur râleries diverses
Posté par Benoît Sibaud (site web personnel) . Évalué à 5 (+2/-0).
Dans le style https://bsky.app/profile/lateralux.bsky.social/post/3lgl3qvuua22c (via Nils)
[^] # Re: retour sur râleries diverses
Posté par abriotde (site web personnel, Mastodon) . Évalué à -6 (+2/-9).
SystemD coche toute les alertes… et pourtant ça reste hélas le meilleur choix sous Linux. Je regarde les autres mais aucun n'est aussi abouti (faute de moyens). Je pense à Dinit…
La plus grosse faute de SystemD c'est de rendre les soft dépendant de SystemD et même de rendre SystemD dépendant de Linux.
Pire il intègre carrément les softs pour devenir un méga soft…ingerable.
Reste qu'un process qui initialise (en //), gère les dépendances et monitor et relance les services planté c'est utile.
Le problème vient qu'il n'a pas été recherché une solution technique satisfaisante. Ce n'est pas facile mais possible.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: retour sur râleries diverses
Posté par thoasm . Évalué à 5 (+2/-0).
Satisfaisant c'est quoi, "qui aurait tout changé sans rien changer" genre tu n'as rien à changer de tes habitudes toi ?
# C'est pas que je veuille cramer systemd, mais ...
Posté par AncalagonTotof . Évalué à 0 (+7/-9). Dernière modification le 18 février 2025 à 14:16.
Disclaimer : on peut trouver plein de défauts et de qualités à systemd. Moi, je lui trouve plus de défauts que de qualités.
Pourquoi ? Parce que j'ai débuté sous UNIX en 1988 par la connexion à un système dont j'ignorais tout, d'abord pour les sauvegardes de nos projets, puis pour les cours de … UNIX !
Ensuite, c'était un peu de Minix sur Atari ST, et beaucoup de Sun OS dans les salles de TP du LIFL.
En enfin, en 1995, le pote qui débarque chez moi avec une disquette en criant "ils ont sorti le driver 2940 Linux, on peut tester sur ta bécane ?". Donc, même si l'admin sys est pas mon métier, j'en fais de façon poussée depuis longtemps, depuis 30 ans, depuis 25 ans et l'arrivée d'ADSL et le début de l'auto-hébergement.
Tout ça pour dire que ça forge des habitudes difficiles à changer, et des réflexes KISS malmenés par systemd.
Disclaimer 2 : non, j'ai pas RTFM. Enfin, pas toutes. Mon premier contact avec
systemd, c'était pendant une mise à jour de mon FW, et un plantage du système.systemds'est imposé pendant la mise à jour, y'a des trucs qui ne lui plaisaient pas, et impossible de rebooter correctement. Impossible de faire des recherches pour piger, vue que c'était le FW, plus d'internet. Cool, une réinstallation imprévue, en soirée/nuit, principalement pour assurer le fonctionnement du mail auto-hébergé. J'ai gardé une dent contre depuis.Mes dernières mésaventures avec cette "chose", sur une Debian 12 :
1) avant : bécane principale, zindoz/Linux. Utilisation des cartes réseau intégrées à la carte mère, tout va bien.
Après : ajout d'une carte 10 GBps. Hum, ça marche, c'est presque 10 x plus rapide.
Mais y'a un truc bizarre : mes partages NFS ne sont plus montés au démarrage, je dois le faire à la main.
Pourtant, rien n'a changé, à commencer (si je puis dire vu le début de la phrase) par mon bon vieux
/etc/fstab.Après avoir étudié le phénomène, j'arrive à la conclusion que le réseau n'est pas prêt au moment de monter les partages.
Ah ? Pourquoi ? Je sais pas, j'ai pas trouvé. Un truc plus lent à cause de la carte elle-même ou de son driver Atlantic peut-être.
Tentative d'IP fixe : pas mieux.
Mais bon, Debian 12,
systemd, ok, je vais essayer de faire ça dans les règles.Pas simple, mais je trouve
systemd-networkd-wait-online.service, que j'active, et qui me cause un timeout "de malade" au démarrage. Et là, c'est le drââââme, toujours pas de partages montés après ça.OK, donc, des partages qui, manifestement, ne devaient être montés que quand le réseau passait UP, ne sont toujours pas montés quand j'active
systemd-networkd-wait-online.service, après une attente phénoménale. Super. C'est moi qui ne sait plus parler anglais, ou bien y'a un défaut dans l'énoncésystemd-networkd-wait-online.serviceou les autres "machins" censés s'assurer que le réseau est UP ?Heureusement, j'ai des potes … Qui s'y connaissent mieux que moi et qui me signalent l'existence de
automount, et sa config parsystemd.Ça marche. Après un peu de galères, et sans être certain d'avoir placé les fichiers
.mountet.automountà l'emplacement canon. Mais ça marche.Galères parce que l'un des partages se trouve sur une machine qui n'est pas souvent allumée. Et que selon l'emplacement du point de montage, ça crée encore du timeout, le temps que ça se dise "ah bah nan, pas dispo".
Mais surtout, parce que
automounttraite/mediad'une façon particulière, contrairement à/etc/fstab: marche pas. Et pas expliqué dans les docs que j'ai pu lire. Faut deviner. Faut placer les points de montage ailleurs.Bien bien bien, cool cette histoire, j'aime bien perdre mon temps sur ce genre de choses.
2) concernant la tentative d'IP fixe : j'aime bien
/etc/network/interfaces. Mais on m'a dit, c'est mal, faut passer parNetworkManager. OK, allons-y :nmtui. Ça marche, mais ça fait un moment que je suis au courant de "ze next thing" : y'a une autre façon de faire, "encore plus systemd". Nan, me demandez pas comment ça s'appelle, où ça se trouve, j'ai toujours eu la flemme d'essayer.3) logs
Utiles pour essayer de comprendre pourquoi ça monte pas les partages.
Sur mon FW, ça va, c'est une Debian 12 qui était 11, et peut-être même 10 avant. Donc, j'ai encore les logs au format texte, c'était le standard à l'époque, et les upgrade n'ont pas modifié ça.
Mais sur la bécane principale, c'est une Debian 12 "assez fraiche". Donc, plus de fichiers texte, que du
journalctl. Etjournalctl, faut apprendre à s'en servir (un fichier texte, non. Justeless,grepettailgénéralement). Etjournalctl, c'est obligatoire, parce que les logs sont au format binaire, impossible de le contourner.4) conclusion (?)
Est-ce que ça valait vraiment le coup ?
OK, je suis mal placé, je sais faire un paquet de trucs en amateur, mais je suis pas pro, j'ai pas passé des heures à lire les généralités, ni les
man pagessursystemd. Donc, c'est ma faute, j'ai qu'à RTFM.Flemme. Y'a des principes KISS qui ont été mis à la poubelle.
Je veux bien croire qu'on y a gagné, en temps de boot (encore que, pas toujours), et sur d'autres sujets que je ne maîtrise pas.
Ça m'inquiète de perdre la main, et sur le plan pro, à l'occasion, ça m'inquiète de voir des systèmes embarqués bâtis avec
systemd.Aller, encore un effet de ma viellitude ?…
Celle qui va probablement me pousser à retenter l'expérience Devuan quand j'aurai fini de pourrir ma Debian ?…
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par barmic 🦦 . Évalué à 9 (+9/-2).
Franchement, qu’est ce qu’il faut penser d’un projet qui dit « on garde en l’état parce qu’on a l’habitude » ? Il est en maintenance et ne cherche plus à évoluer.
Ton laïus donne plus l’impression que le UNIX que tu as connu est une madeleine de Proust. Ce n’est pas grave, mais est-ce que c’est sur ce genre d’arguments que les choix decs distributions devraient être prises ?
Tu as passé 70 ans 0 lire de la doc et ça a l’air de t’avoir traumatisé. Personne ne t’oblige à l’utiliser, mais tu peux pas non plus forcer Debian dans ces choix.
Tu as eu 2 problèmes avec systemd et ça te plaît pas d’avoir à lire. Tu explique toi-même que tu en as eu des mille fois pire avant et que tu en a un souvenir heureux. Je suis désolé mais qu’est-ce qu’on peut faire ? Prend une Debian 11 et arrête de la mettre à jour. Si tu ne veux pas que ça change.
Non il y a une lecture différente des principes et tu choisi de les considérer comme mauvais car différents de ce que tu connais plutôt de t’y intéresser. Ce n’est pas une question d’age, c’est un choix.
L’age n’a rien à voir là dedans. C’est ton droit le plus strict, mais la position « c’est pas de ma faute, je suis comme ça » est une position confortable pour se dédouaner et ronchonner sans trop se mouiller.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par AncalagonTotof . Évalué à 0 (+2/-4).
Plus que 2 problèmes, sensiblement. J'ai pas fait de liste pour la ressortir en entier ici.
"eu des mille fois pire avant et que tu en a un souvenir heureux" ??? Où est-ce que j'ai écrit ça ??? Si je l'ai fait, c'est par erreur, typo ou je ne sais quoi.
Pour le reste, ça n'étais pas assez clair peut-être, mais je n'ai pas écris non plus que le problème, ça n'était pas moi.
Oh, et si j'osais le formuler ainsi : donc, depuis systemd, c'est KISS my ass ?
Qu'est-ce qu'il y avait de mal à avoir un soft qui règle un et un seul problème, par rapport à un systemd tentaculaire qui va finir par devenir un OS à lui tout seul ?
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par barmic 🦦 . Évalué à 3 (+3/-2).
Avoir un matériel qui ne fonctionne pas est de plusieurs magnitude plus problématique qu’avoir à faire des montages à la main.
.
Tu n’en liste qu’un.
Pourquoi tu pose des questions dont tu ne t’intéresse pas à la réponse ? C’est du troll ?
Moi aussi je suis un debianeux depuis suffisamment longtemps et j’ai vraiment souffert à utilise sysvinit avec en plus le framework que debian utilisait et dont j’ai jamais trouvé une doc correct. Et j’étais super content de me retrouver au boulot à devoir utiliser RedHat et à ne pouvoir rien réutiliser de ce que j’avais laborieusement appris.
J’ai aussi passé du temps à faire des grep de fichier en faisant des regex approximatives pour tenter de m’y retrouver en jonglant entre différent format de date et d’heure, à créer des fichiers temporaires,… J’ai même longtemps gardé urxvt pour sa vitesse (largement au dessus de tous les autres terminaux mis à part ghostty).
Je n’ai pas eu besoin de beaucoup pour apprendre :
Bon j’arrête de nourrir le troll, on est pas vendredi
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par gUI (Mastodon) . Évalué à 8 (+5/-0). Dernière modification le 18 février 2025 à 17:12.
Moi perso ce qui m'a fait définitivement passer à
systemdc'est les services utilisateurs (et pas root). Simplicité et robustesse, tous mes petits scripts à la con tournent sur mon compte, dans mon/home. Le tout dans un script qui doit faire 4 lignes.En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par AncalagonTotof . Évalué à 1 (+1/-2).
Mais c'est pas possible, j'ai jamais dis que j'avais un problème matériel, elle marche bien cette carte réseau. C'est probablement le driver qui pose problème.
Et qui est à l'origine de la galère pour trouver une solution.
Pardon ? Qu'est-ce que ça vient faire là ? C'est quoi l'idée ? C'est un bout de mon histoire. Et ce driver 2940 a bien fonctionné il me semble. En 1995 !!!
Pourquoi avoir cité ce passage ?
Ouais, et alors ?
C'est marrant la mauvaise foi, et la suppression de ce qui suit. Phrases complètes :
Si ça, ça ne nourrit pas le troll …
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par barmic 🦦 . Évalué à 3 (+2/-1).
Parce que ça allait avec le passage d'avant
À la belle époque de 1995 tu devais courir derrière les drivers, les compiler toi-même, avec une compilation du noyau avec en appliquant le patch correctement.
Aujourd'hui dans ce monde où tout fou le camp tu doit te renseigner pour avoir des montages réseaux qui se montent automatiquement.
Comprends que je ne peux pas parler de ce dont tu ne parle pas. Ce que tu as choisi pour illustrer ton propos c'est des montages réseaux qui ne sont plus automatiques et la flemme de te renseigner.
J'ai répondu pour dissiper l'incompréhension suite à mon commentaire précédent mais ça s'arrêtera là
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par AncalagonTotof . Évalué à 0 (+0/-2).
Désolé, mais j'ai toujours du mal à faire le rapprochement.
Et, à me relire, je précise, à nouveau, que non, je n'ai pas rien lu, rien recherché.
Que non, il ne s'agit pas d'un problème matériel.
Qu'on m'explique : par défaut, systemd et sa config sont bien supposés attendre que le réseau soit UP pour tenter des montages ? (J'attends plus que "ça dépend", merci)
Alors pourquoi ne le fait-il pas avec cette carte ? Ma supposition : le driver. La conséquence : un client DHCP plus lent ? Et alors ? Pourquoi "ça" n'attend pas que le réseau soit UP ?
Pourquoi, alors que pour un paquet de trucs, on a droit à un message d'erreur et un compteur de temps, pour de longues secondes ou minutes, avant timeout et poursuite du boot, au contraire, quand il s'agit de monter un partage réseau, je n'ai que quelques messages "en rouge" que je dois filmer pour pouvoir les lire, parce que, bien que l'option
--no-clearsoit présente dans tous les fichiers de systemd relatif àgettyque j'ai pu trouver à grands coups defind/grep, les messages kernel et services sont effacés par le prompt de login ? (vous pouvez reprendre votre souffle. Non, je ne reformulerai pas cette phrase trop longue)Non, je n'ai pas rien cherché.
Oui, j'ai fini par mettre en place automount.
Non, ça ne s'est pas passé tout seul, et je n'aurais pas trouvé seul, ou pas avant longtemps.
Oui, j'ai cherché mais je n'ai trouvé aucune explication du : pourquoi automount ne fait pas son boulot si le point de montage est dans /media ? À part un pote qui disait "ah, peut-être parce que /media est réservé au supports amovibles ?", ce qui est une supposition non étayée. Et j'ajoute que sans ce problème de carte/driver/DHCP, un montage par
/etc/fstabfonctionnait très bien.Je veux bien admettre que j'ai beaucoup de défauts, dont certains dus à l'âge, mais y'a pas que moi qui présente des défauts.
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par cg . Évalué à 6 (+4/-0).
Sur Debian et ses dérivés, quand une interface réseau est déclarée avec
allow-hotplugdans/etc/network/interfaces, cette interface n'est pas prise en compte par la chaîne de dépendances genre "wait-network-online", car l'interface peut apparaître bien plus tard, ou jamais (c'est le sens de "hotplug" dans ce contexte, une interface USB ou que sais-je), et ce serait absurde de l'attendre.C'est peut-être (désolé) ce qu'il se passe dans ton cas ?
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par AncalagonTotof . Évalué à 1 (+1/-2).
Merci de répondre à cette question après tout ce déchaînement de violence !
Après vérification, cette interface n'est définie ni dans
/etc/network/interfaces, ni dans/etc/network/interfaces.d/. Comme quoi, je ne fais pas tout "à l'ancienne" ;-)Elle était en DHCP.
Et j'ai oublié de repréciser dans la dite bataille, elle est depuis configuré en IP fixe via
nmtui. C'est d'ailleurs la première chose que j'ai faite, avant tout le reste (systemd-networkd-wait-online.servicepuisautomount).Je n'ai pas vu d'équivalent à
allow-hotplugdansnmtui. Je serais passé à côté ?J'ai un doute sur la signification l'option (non cochée) Require IPv4 addressing for this connection.
Automatically connect et Available to all users sont cochées.
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par raphj . Évalué à 10 (+8/-0). Dernière modification le 18 février 2025 à 17:39.
Lennart le redit dans sa présentation : leur objectif est de fournir une solution pour démarrer un OS. Et pour faire ça bien, en fait on touche plein de choses.
Mais en réalité systemd c'est très modulaire. On pourrait se dire qu'on n'a pas besoin de networkd, nspawn, resolved… et c'est vrai, et ça tombe bien, ces composants sont optionnels.
Par exemple pour ton histoire de configuration réseau : aucune obligation d'utiliser NetworkManager si tu n'en veux pas, c'est normalement possible de faire comme avant.
Mais systemd, c'est aussi une standardisation, un ensemble plus cohérent et unifié. Ça change forcément l'existant, mais ça simplifie grandement la vie des gens flemmards comme moi. Tu installes un nouveau service, tu sais direct comment t'en servir, et notamment que tu peux avoir ses logs en lançant
journalctl -fu servicepar exemple. grep, tail, tout ça, tu peux continuer à les utiliser en apprenant une commande :journalctl -u service; c'est pas la mort. En général il y a un flag pour faire ça mieux direct dans l'outil, mais c'est toujours possible.Cette standardisation, ça demande effectivement un apprentissage initial, mais sur le long terme, c'est moins la pagaille, l'ensemble est plus facile à comprendre et au final c'est moins d'effort.
Après, c'est clair que si tu n'aimes pas la vision, ça va mal se passer pour toi. Je ne crois pas qu'il faut rester sur l'impression laissée par une mauvaise expérience de migration au début, et plutôt analyser ce qu'on a aujourd'hui, sinon c'est sûr que tu resteras bloqué sur ça mais ça ne parait pas méga constructif.
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par AncalagonTotof . Évalué à 0 (+1/-3).
Je suis d'accord, des outils existent, mais ils sont nombreux, il est long de tout (re)découvrir, et si j'admets le terme "flemmards", il ne faut pas oublier non plus qu'il recouvre "je ne suis pas admin sys pro, loin de là, et j'aurais aimé qu'on me laisse le choix Debian avec ou sans systemd, parce que j'ai pas que ça à faire de tout ré-apprendre après qu'on me l'ait imposé, j'ai d'autres trucs à faire".
Hum, et si on se donnait rendez-vous dans 5 ou 10 ans ? Pour voir les discussions entre les gens qui n'ont pas de problème avec systemd (et je n'ai pas de problème avec les gens qui n'ont pas de problème avec systemd, sauf barmic peut-être. Je comprends et j'admets qu'il y en ait et qu'il y ait des avantages selon le contexte), et les gens qui seront passés au successeur de systemd ? Ça pourrait être drôle …
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par Maclag . Évalué à 10 (+9/-0).
Je ne suis pas admin sys pro. Je ne bosse même pas en IT.
J'ai installé Linux pour la première fois avec une boite RedHat 4.0 sans même trop savoir exactement ce qu'était un OS ou Linux. J'ai appris, essayé moultes distros, jonglé avec les fichiers de config, etc.
Je suis passé à systemd parce que Debian est passé à systemd.
J'ai dû ré-apprendre certaine commandes parce que systemd les fait différentes, mais j'ai toujours un gros différentiel entre ce que je savais faire avant systemd et ce que je sais faire avec systemd.
Parce que ça juste marche bien plus souvent, et donc je n'ai pas besoin de savoir tout ce dont j'avais besoin avant.
Là j'ai appris à me servir de tout un tas de services que j'héberge sur un serveur perso. J'ai dû apprendre des commandes Yunohost, etc. Et dans quelques années, tout ce que j'aurai appris là-dessus sera sans doute inutile et/ou obsolète.
L'informatique, ça évolue tout le temps. Ça fait que certaines connaissances deviennent obsolètes, et les gens "qui touchent bien" mais qui n'apprennent plus deviennent les vieux aigris qui ne savent plus non plus comment marchent les trucs et passent leur temps à dire que c'était mieux avant.
Mais moi je ne regrette pas l'époque où lancer X11 était un petit exploit, ou les réglages divers et la recherche du bon pilote, et les bidouilles dans les modules noyau, etc. étaient des étapes normales post-installation.
Et donc là je ne regrette pas l'époque où je maîtrisais à peu près ifconfig alors que je ne me souviens jamais comment utiliser la commande ip, parce que ça veut surtout dire que je n'ai plus besoin de savoir, et ça, c'est une bonne chose!
Et oui, ça arrive et ça arrivera encore que je tombe sur un os, et que je doive lire une doc sur comment faire truc ou machin en 2025, alors que je savais faire en 2005. Et ben je ré-apprendrai, parce que je n'oublie pas la quantité d'efforts que je devais fournir en 2005 pour un truc qui marche même après les mises-à-jour.
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par AncalagonTotof . Évalué à 2 (+2/-2).
OK, merci pour la leçon.
Pas de méprise, ça n'est pas ironique ou sarcastique, c'est du 1er degré.
J'en déduis que j'ai fait mon temps.
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par da_kal . Évalué à 0 (+1/-2).
Je me suis posé un petit défi curieux pour voir si l'herbe était plus verte sans systemd. J'ai donc testé beaucoup de distros intégrant des inits différents (Antix, Devuan, Artix, Void, Guix et j'en oublie) avec à chaque fois plusieurs mois d'utilisation. Ma conclusion est sans appel: Ce n'est pas grâce à systemd que tout se passe mieux. Il y a peut être des éléments qui se sont améliorés mais ça ne concerne pas mon utilisation. Je joue à des jeux vidéos,dev et de la bureautique classique. Rien de bien folichon tout est similaire.
Concernant l'argument que j'ai vu passé au début des messages sur le temps de boot amélioré avec systemd. C'est assez faux systemd est plus rapide que SysVinit mais il est beaucoup plus lent que s6, dinit, openRC ou runit.
Systemd, je n'y vois aucun avantage et je ne suis pas assez technique pour y voir des inconvénients. A sa sortie j'en ai effectivement vu beaucoup car il était très instable et m'a forcé à refaire plusieurs machines, il faut bien que jeunesse se fasse, maintenant RAS.
J'utilise une distribution avec systemd au quotidien la seule chose qui me dérangerai à la limite c'est la complexité et l'opacité (du coup liée) qu'il propose. A mon sens, et parce que je ne suis pas un vrai admin sys, un système simple et rustique c'est un système ou les briques logicielles n'éloignent pas l'humain ou ne lui enlève pas de pouvoir. Personnellement je me sens à milles lieux de cette brique logicielle je ne la comprends tout simplement pas alors que runit est compréhensible par n'importe qui par exemple. Ca me fait penser aux logiciels open source installables par tous ou la complexité de déploiement te fais passer à la caisse. C'est une petite perte de pouvoir, faut l'accepter si on l'utilise voila tout.
Sinon, les seuls vrais déboires que j'ai eu c'etait lors de l'utilisation de distros basées sur musl là c'etait vraiment la mouise. le son, l'horodatage, les applis qui plantent ouch. Je ne sais pas si c'était la faute de la distribution ou de musl mais j'ai vite rebroussé chemin.
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par Maclag . Évalué à 5 (+2/-0).
Tant mieux pour toi si tout se passe bien pour ton cas de figure.
Moi je me demande pourquoi toutes les distros auraient sauté sur systemd si c'est tellement pourri.
J'ai lu maintes fois que c'est parce que "RedHat l'a forcé et tout le monde a été obligé de suivre", mais l'existence même de distros ayant très peu de moyens qui n'y ont pas recours prouve que cet argument ne tient pas: aucune distro n'était obligée de l'adopter.
Et je pense que c'est parce que ça facilite la tâche des mainteneurs. Et donc ils passent moins de temps sur les scripts init, et plus à peaufiner d'autres trucs. Et conclusion: les utilisateurs y gagnent aussi, indirectement.
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par da_kal . Évalué à 2 (+1/-0).
Étrange comme réponse, personne a affirmé que c'était pourri dans nos échanges.
Forcé je sais pas, ce que je vois c'est que Redhat est une entreprise avec de nombreux utilisateurs, du flouz, un ecosystème complet, des contributeurs kernel, un pied dans la Linux foundation, une image qui était très correcte à lépoque. Pour Suse par exemple ça passe bien et ça standardise dans un monde économique qui veut conquérir un marché, tout bénéf. Pour Jean-Michel qui fait sa petite Debian perso c'est vécu autrement et par question d'énergie à poser dans la projet il se conforme, c'est logique et humain.
Les petites distributions dont tu parles ont systemd sous une autre forme. Vous voulez d-bus, lightdm, un DE nouvelle génération ? Vous êtes obligé de passer par elogind et là, la salle se vide. Même les distros qui se réclament anti-systemd possèdent majoritairement elogind. On peut donc dire qu'elles sont très raisonnables dans leur approche de systemd. Pour aller dans ces contrées obscures on se retrouve avec du KISS, Hyperbola, Obarun. C'est tout de même pas fait pour n'importe qui. C'est un choix, c'est bien qu'il existe. Ce qui est dramatique c'est d'enlever ou de complexifier la possibilité de faire ce choix. De nombreux mainteneurs de distributions sans systemd reproche cet état de fait.
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par David Delassus (site web personnel) . Évalué à 5 (+3/-0).
Argument fallacieux, il y a plusieurs milliards de mouche sur terre qui bouffent des excréments, on devrait les imiter ?
:)
PS: Je suis d'avis que systemd c'est très bien, pas parfait, et qu'il aura sûrement un successeur qui sera pas parfait non plus.
Il n'y a que 2 types de logiciels : les logiciels que tout le monde déteste, et les logiciels que personne n'utilise.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par sebas . Évalué à 7 (+5/-0). Dernière modification le 18 février 2025 à 21:18.
Sans même parler de devuan, il y a MX-linux qui est une debian pure avec une config de base très légèrement différente, un dépôt MX additionnel et quelques outils en plus (qu'on peut virer sans problème, si on n'en veut pas), et qui laisse le choix sysVinit ou systemd à chaque boot.
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par AncalagonTotof . Évalué à 0 (+1/-3).
Merci pour le lien.
Je cite le site :
C'est précisément ça que je repproche à systemd (non, je n'ai pas oublié le commentaire précisant que systemd est modulaire et qu'on est pas obligé de tout prendre. Ceci dit, quelqu'un a déjà essayé de ne pas tout prendre ?)
L'approche de MX Linux est intéressante et semble se couper de la Debian moins que la Devuan :
Si je trouve le temps, peut-être un test en VM d'abord.
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par raphj . Évalué à 3 (+1/-0). Dernière modification le 18 février 2025 à 23:42.
Mais systemd n'est pas un bloc monolithique, c'est un ensemble de petits outils qui se concentrent sur une chose et qui fonctionnent bien ensemble. Du coup, de ce point de vue, ça respecte la philosophie unix. Je ne commente pas l'aspect "bien" de "faire une seule chose bien", on peut subjectivement trouver qu'ils ne font pas bien le taf.
Le pid 1 de systemd est peut-être plus complexe que le reste, peut-être qu'on peut discuter cet aspect, en vérifiant que les alternatives ne sont pas aussi complexes de toute façon, à fonctionnalités comparables.
On peut regretter que journald ne soit pas optionnel (pid 1 l'est probablement, je suppose qu'on peut utiliser la plupart des outils systemd sans, à vérifier), donc la modularité a ses limites, mais pareil, est-ce plus modulaire ailleurs ? Vrai question, je ne suis pas trop familier avec les alternatives.
Enfin, on peut regretter que journald stocke les journaux en binaire. Question de goût, je suppose que c'est pour des questions de robustesse et d'efficacité. Je comprends qu'on n'aime pas trop, en même temps ça ne m'est jamais arrivé de m'en rendre compte parce que je trouve journalctl très agréable à utiliser pour manipuler les logs.
En résumé, qu'est-ce qui n'est pas unix pour toi dans systemd, et quels inconvénients cela apporte en ptatique ? (Après avoir lu les contre-arguments aux critiques usuelles là : http://0pointer.de/blog/projects/the-biggest-myths.html_ en particulier les points 1 et 10)
Je note l'inaccessibilité des logs sans utiliser un binaire systemd, j'entends, avec les réserves que j'ai émises dans l'autre commentaire.
Sinon j'entends aussi l'argument de n'être pas familier avec la solution, en vrai c'est une vraie bonne raison.
Concernant ta question sur la modularité et si quelqu'un a essayé en pratique, je n'ai pas trop essayé à part utiliser ou non systemd-networkd, nspawn et leur solution pour remplacer cron (?). Je dirais que c'est à la critique de montrer que ce n'est pas modulaire.
Mais en vrai, la philosophie unix, je m'en fiche un peu, ce qui m'importe c'est que ce soit efficace, clair et si possible élégant. Un argument plus fort pour moi serait la présentation d'une alternative dont la fonctionnalité principale n'est pas "n'est pas systemd", mais des arguments convaincants sur pourquoi c'est mieux. Sachant que pour moi, l'arrivée de systemd a été une grosse amélioration. Écrire un service par exemple, largement plus simple et plus compréhensible qu'un script shell parce que c'est en mode déclaratif et c'est très conscis. C'était déjà le cas avec upstart, qui était pas mal, mais pour moi systemd est juste un meilleur upstart, avec si j'ai bien compris un peu d'inspiration du côté de launchd avec l'activation par socket (qui semble être une excellente idée, pour avoir accès à des fonctionnalité sans tout devoir lancer en avance).
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par abriotde (site web personnel, Mastodon) . Évalué à -3 (+3/-7).
Si SystemD est un bloc monolithique ou tout les soft doivent être redéveloppé quasiment pour SystemD. Comprends bien l'énormité de cette affirmation. C'est plus simple d'adapter un soft Linux à BSD et peut-être même à Windows (non Unix) qu'à SystemD…
Je suis pour autant d'accord pour dire que systemd apporte un plus à SysVinit. Cependant il se développe d'autres alternatives, toutefois pas encore aussi mâture (fautes de moyens). Je pense à Dinit. Le problème n'est pas simple à résoudre mais SystemD est une mauvaise solution (mais la meilleure pour l'instant).
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par raphj . Évalué à 5 (+3/-0).
Tu peux en dire plus ? Si ton soft est intimement lié au boot, ça paraît normal, mais sinon, que faut-il adapter ?
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par abriotde (site web personnel, Mastodon) . Évalué à -2 (+1/-4).
A peu près aucun sont n'est lié au bout de l'OS. Je veux dire ma DB peut démarrer 2h après l'OS et inversement l'OS boot très bien sans ma DB. Pareil pour l'environnement de bureau. Avec SystemD je dois répondre mon soft pour qu'il utilise SystemD dans sa pile réseau et tout un tas de trucs… des trucs tout aussi indépendant du bout…
Bien sûr tous veulent démarrer au boot (un script à lancer) et être relancer en cas de plantage (test + lancement).
Qu'il y ait un ou 2 détails à adapter OK. Mais là c'est trop.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par Voltairine . Évalué à 10 (+9/-0).
Es-tu bien conscient que cette phrase est absolument incompréhensible ?
Concernant la gestion des services par systemd, je pense que les administrateurs système et les mainteneurs de paquets des distributions sont quasi unanimes pour dire que cela rend la tâche plus facile, plus simple et plus efficace.
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par aiolos . Évalué à 9 (+7/-0).
Je ne comprend vraiment pas ce que tu veux dire. À quel moment ton serveur est dépendant d'une pile réseau de systemd ? Quand je développe un soft réseau, je le fais exactement comme avant, avec une socket. Et quand j'ai fini, écrire l'unit systemd qui la lance au démarrage me prend environ 5 minutes…
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par devnewton 🍺 (site web personnel) . Évalué à 6 (+3/-0).
Ca aussi l'ami Lennart a une idée pour faire mieux dans sa présentation :
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par raphj . Évalué à 2 (+0/-0).
À propos de ton dernier paragraphe : j'ai espoir que je ferai partie de la seconde catégorie de gens mais je comprends parfaitement les difficultés liées à réapprendre des choses qu'on sait déjà faire efficacement avec un système qui est remplacé. C'est assez frustrant.
Je ne l'ai pas trop vécu avec la transition vers systemd (et la transition vers upstart avant ça), mais on ne peut pas dire que j'avais une utilisation avancée. Je redémarrais les services (d'ailleurs la commande pour ça,
service xxx restart, fonctionne toujours, même si elle est découragée et qu'elle va certainement disparaître et qu'elle n'est même pas partout) et consultais les logs, sans plus.[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par octane . Évalué à -3 (+4/-9).
Ou pas. Genre tiens mon service "zefklop" a pas démarré (ou si?). Faisons juste un ps ax | grep zefklop. oula non. systemctl status zefklop parcequ'on est moderne:
Bien bien bien. Du coup on a "active (exited)" Ca veut dire quoi? code=exited status=SUCCESS? Donc il a démarré, mais il est arrêté?
Bah non, tout faut, zefklop.service c'est un lien sur /bin/true (pourquoi? parceque fuck you, that's why!!) et qu'il fallait utiliser systemctl start zefklop@default t'avais qu'a lire la doc! (wut?). Et t'as de la couleur dans le terminal! Et va pas faire un tail /var/log/messages parcequ'il est vide, lol! systemd c'est modulaire, mais faut prendre tout le package complet sinon ça marche moins bien.
Ouais. Comme tail, grep, cat, et quelques autres outils utilisés universellement ailleurs. C'est effectivement un apprentissage initial (c'est quoi déjà le -x de journalctl? ou c'est -u, ou attends je suis au travers d'un xterm dans un VNC et journalctl a gentiment mis de la couleur et du scroll à droite/gauche sauf que du coup j'ai pas la fin de la ligne).
C'est toujours un plaisir de passer 2h à chercher de la doc pour apprendre l'existence d'une option assez obscure et mystérieuse qui fait exactement ce que tu veux faire dans un cas précis d'usage (car systemd sait ce qui est bon pour toi). Tu mets l'option, ça marche de manière assez mystérieuse, et tu t'empresses de l'oublier. Learn once, use once, forget immediately. Ca me rappelle l'époque héroïque de windows quand on te disait d'aller manipuler des clés dans la base de registre avec des valeurs opaques. Des fois ça marchait bien. J'ai du utiliser l'autre jour "ConditionPathExists=!/etc/ssh/sshd_not_to_be_run
" Je suis heureux de savoir que ce genre de directive existe. C'est très utile.
Je vais me faire moinsser encore une fois, mais vous connaisser le sketch du tailleur de Fernand Reynaud? https://www.youtube.com/watch?v=TtADuXkM560 bah je crois que c'est un peu ça le principe. Tu fais tout comme systemd veut que tu fasses, t'es content. Tu veux faire légèrement différent, il ne reste qu'à te tordre en deux pour faire à la manière de systemd et tu seras content. Ca va toujours pas? Bah t'as toujours rien compris, tu te tiens mal et tu fais mal, fais comme systemd veut et tords toi encore un peu et ça sera bien.
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par Voltairine . Évalué à 6 (+6/-1).
La mauvaise foi…
Tu vois bien que la commande systemctl donne beaucoup plus d'information que ta commande
psactive (exited) se comprend aisément : le service est active mais ce n'est pas un démon. un démon afficherait active (runing)
Pour les logs, à ma connaissance, toutes les distributions continuent à fournir rsyslog même si ce n'est pas installé par défaut. Donc tu as le choix et cela te laisse le temlps de te familiariser avec journald pur en voir les avantages et les incovénients.
Je ne vois pas comment on peut prétendre administrer un système (en pro ou en amateur), pou faire du développement, sans faire de la veille technologique et lire de la doc. Et pour ne pas oublier, on prend des notes surtout quand ce sont des choses inhabituelles et nouvelles.
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par octane . Évalué à -4 (+4/-10).
J'ai pas dit que ça en donnait plus ou moins.
Ah bah ui, c'est évident. Bien sûr. C'est clairement indiqué. Parfaitement lumineux. Running pour un daemon, exited pour pas un daemon. Mais mon service zefklop est un daemon. Sauf qu'il n'en est pas un, c'est clair comme du cristal avec "active (exited)".
attends je retrouve mes notes ou j'avais noté les options utiles de journalctl.
Donc exactement ce que j'ai fait?
(oulala mon karma en prend un coup sévère)
(vite, vite :
Oh, systemd, tu es si grand, si beau 🎶😅
Un seul process pour tout, quel cadeau ! 🎵🤨
Tes logs en binaire, quel doux parfum 🤩🎶
Et tes dépendances, un vrai festin ! 🎵🙃
Qui voudrait d'un Unix léger et charmant ? 🤔🎶
Vive systemd… (et pour longtemps?) 😵🎵
siouplaît, pourrissez pas trop mon karma coeur avec les doigts)
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par raphj . Évalué à 5 (+3/-0). Dernière modification le 19 février 2025 à 11:50.
Ça m'a clairement surpris les premières fois.
active (exited)est surprenant. Ça, je suis d'accord.Bon, la sortie est certainement perfectible, mais une fois qu'on a compris la logique, ça va, non ?
Le système permet de gérer des units qui exécutent un programme qui retourne immédiatement pour mettre en place un truc, et c'est pas mal d'avoir un statut qui indique que ça a bien été lancé et que ça s'est bien passé.
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par Voltairine . Évalué à 5 (+4/-0).
Je reconnais aussi que
active (exited)est perturbant au premier abord mais moins que de penser que /usr/bin/true puisse être un démon :P[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par raphj . Évalué à 6 (+4/-0).
Je n'ai jamais observé ça. C'est quoi zefklop ? Un exemple concret, pas inventé, permettrait d'évaluer la situation correctement et objectivement.
Bon, rarement quand-même, il y a souvent une bonne explication à un truc qui nous parait initialement incompréhensible. C'est sûr que si tu prends les dev pour des adversaires, la vie va être triste.
Bah pourquoi pas ? Ça fonctionne toujours et je ne m'en prive pas.
On critique justement systemd parce que ça fonctionne plus pareil et que ça veut remplacer les outils unix de base, mais quand ça marche, un grand plat de pâte géant nous interdit de les utiliser ? C'est un pattern que je vois pas mal dans les commentaires ici. "On nous dit de". On nous dit rien du tout, juste appelle ton
grepet tontailsurjournalctlet appelleps aux | greppour trouver ton service, je ne vois pas où est le problème, personne ne va te manger si tu fais ça.Que suggères-tu comme solution ? Parce que tes outils unix historiques, ils sont tous comme ça. Il n'y a pas plus unix que des paramètres au nom plus ou moins arbitraire et plus ou moins logique à apprendre à utiliser. Regarde justement
ps ax. C'est cryptique au possible. Perso j'écrisps aux, oups -efsi le précédent ne marche pas avec la version depsque j'ai en main, sans savoir ce que ça veut dire parce que je sais que ça fait le taf, mais c'est pas très intelligent. Mais bon c'est pas grave, si un jour je suis curieux, il y a la doc. Pourpscomme pourjournalctl, également de la même manière avecmanou-h.Bref, critiquons systemd pour ses particularités, par pour les caractéristiques qu'il partage avec son écosystème, surtout quand on voudrait qu'il soit un peu plus dans la philosophie de cet écosystème.
Tu n'as même pas besoin de savoir beaucoup de choses pour utiliser systemd. Voilà tout ce que j'utilise de lui, et je n'en sais pas plus (notamment, l'option
-x, je ne sais pas ce qu'elle fait et je n'en ai pas encore eu besoin - ou peut-être je passe à côté de quelque chose mais je suis encore vivant) :-u(pour unit, unité) pour cibler le service dont tu veux les logs. À omettre si tu veux tous les logs.-r(pour reverse, inverser) pour lire les logs du plus récent en bas. Franchement, ça aurait pu être par défaut, mais bon, les outils historiques ont le même sens de lecture que le sens par défaut-f(pour follow, suivre) pour suivre les logs en temps réel.Propose aussi simple avec les outils Unix traditionnels.
Maintenant qu'on vient d'établir que
journalctlest aussi simple d'utilisation que possible, et suite aux échanges dans ces commentaires, je vais avoir besoin d'être convaincu que l'affirmation suivante est fausse : les attentes sur systemd de la part de ses détracteurs sont irréalistes, et ce qu'ils proposent est moins utilisable, moins fonctionnel, ou n'existe pas. Bon, pour être tout à fait honnête, c'était déjà mon avis avant ces échanges.Autre affirmations à casser :
La seule chose qui m'a convaincue pour le moment, c'est le retour d’AncalagonTotof sur le fait que c'est difficile de retrouver ses petits après un changement, mais ce n'est pas vraiment spécifique à systemd, c'est commun à toute évolution.
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par raphj . Évalué à 2 (+0/-0).
je voulais dire
journalctlici.[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par octane . Évalué à 1 (+1/-2).
tor
Y'a un tor.service et un tor@default.service. Encore une syntaxe à apprendre (mais pourquoi le arobase?? quel est le sens de tout ceci?), il y a surement une bonne explication à ce truc qui me paraît initialement incompréhensible.
Oui, mais on est pas forcément d'accord avec ces justifications.
I'm my worst enemy, muhahahaha!!!
tail -f /var/log/messages | grep zefklop
En fait, je pense qu'il y a pas vraiment de solution. Je vais continuer de rager dans mon coin tel un vieux boomer qui râle en disant que de son temps les trains arrivaient à l'heure et les prix ne dépendaient que de la distance, et je suis entouré de gens qui vont me dire que non non vieux boomer c'est mieux avec la nouvelle tarification et que j'ai le choix entre uber et blablacar. systemd fait plein de trucs géniaux, j'ai toujours pas compris (enfin si j'ai très bien compris, mais ce ne sont pas des problèmes pour moi) quels problèmes ça résoud et quel génie Lennart est.
Je vais m'en retourner à mon service de tartiflette on premise, parceque l'heure tourne (déjà midi passé! :o )et que j'ai faim.
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par raphj . Évalué à 3 (+1/-0). Dernière modification le 19 février 2025 à 12:39.
Merci pour l'exemple concret :-)
Okay, j'ai été voir par curiosité. Je n'ai jamais mis tor en place. Ça a l'air d'être un choix de conception de Tor expliqué ici : Tor a décidé que ça devait être un système multi-instance, dont une par défaut (le
default), et que lancer Tor sans préciser d'instance n'a pas de sens.Ils auraient pu décider de ne pas fournir de
tor.service, ou de le faire échouer avec un message d'erreur spécifique, en tout cas systemd ne les empêchaient pas de le faire. Pourquoi ils ne l'ont pas fait, je ne sais pas, en tout cas ça n'a pas l'air d'être la faute de systemd.Quant au
@, c'est une convention que d'autres services utilisent. Par exemple systemd-nspawn. Si tu veux gérer un conteneurtartampionavec un service, tu vas avoir un service nommésystemd-nspawn@tartampion.service. Tor a réutilisé cette convention pour son système multi-instance. Je note qu'il n'y a d'ailleurs pas desystemd-nspawn.service, Tor pourrait certainement calquer ça pour éviter les surprises. Moi, je trouve ce@élégant, mais question de goût. Ça aurait pu être un autre caractère. C'est bien que ça ne soit pas alphanumérique, ni un tiret, ni un point, bref, pas un caractère que tu peux utiliser dans une le nom d'une variable C. Ça aurait pu être dans un sous-dossier mais je suppose que ne pas gérer une arborescence simplifie les choses.Donc quand tu utilises
tor@default.service, tu gères l'instancedefaultde tor. Il semble important de comprendre cet élément central de l'architecture de tor.Pour moi on est effectivement dans une situation où il y a une bonne explication à un truc initialement incompréhensible, et ça montre aussi que c'est facile de rejeter la faute sur le mauvais acteur si on ne s'est pas assez renseigné, entrainant potentiellement des échanges un peu stériles parce que les critiques sont incompréhensibles ou tombent à côté de la réalité, et du coup c'est impossible d'échanger sur une base commune compréhensible.
Oui, évidemment, mais du coup ce n'est plus juste "fuck you" :-)
il ne s'agit pas de ça, et par ailleurs, j'aimerais aussi avoir des trains à l'heure avec une tarification qui a du sens, le train étant un de mes modes de transports principaux.
bon app'
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par Christophe . Évalué à 4 (+2/-0).
Non, c'est une fonctionnalité bien précise de systemd, et qui permet de passer un argument à un service. Il est ainsi possible de récupérer cet "argument" dans le fichier de service, et l'utiliser pour lancer le service correctement.
Exemples (fictifs ou non):
* getty@[tty].service
* tor@[instance name].service
* trollbot@[tribune].service
C'est une fonctionnalité très pratique, qui permet de lancer le même service plusieurs fois avec des contextes différents.
AMHA, la présence de ce tor.service ressemble fortement à une erreur.
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par Voltairine . Évalué à 3 (+2/-0).
Non c'est exprès :
On est sur un cas très particulier.
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par raphj . Évalué à 4 (+2/-0).
Ah oui, en effet, mes confuses, une petite lecture de
/lib/systemd/system/systemd-nspawn@.servicem'aurait permis d'éviter de dire des âneries. Comme quoi on en apprend tous les jours, y compris au plus profond d'un troll systemd xD[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par Lutin . Évalué à 4 (+2/-0).
J'ai aussi ce problème avec journalctl, mais c'est parce que je suis vieux. Pour pallier ce problème j'ai fait plein d'alias.
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par abriotde (site web personnel, Mastodon) . Évalué à -1 (+3/-5).
Non c'est une expérience tout à fait valide qui essaye d'excuser SystemD.
La vérité c'est qu'un serveur Web performant comme NginX, c'est simple a configurer/debugger, une base de donnée comme MySql aussi, un OS comme Linux idem. Par contre systemd, dès que tu veux un truc tordu c'est compliquer car c'est très mal conçu. Ce n'est pas KISS. Le problème c'est que c'est au soft et à l'OS de s'adapter à SystemD. Alors que c'est le serveur HTTP qui s'adapte au langage (PHP, Html ou Java).
Rien à été conçu dans SystemD pour decoupler les choses.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par raphj . Évalué à 4 (+2/-0). Dernière modification le 19 février 2025 à 07:26.
Au contraire, je crois que c'est l'inverse. Tu as un exemple de deux choses qui pourraient et devraient être découplées (parce que ce serait utile, avec un exemple de pourquoi ce serait utile) mais qui ne le sont pas ? Et qui le sont dans un projet équivalent ?
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par Christophe . Évalué à 6 (+4/-0).
Je crois qu'il y a confusion entre la modularité du logiciel et celle de sa distribution.
systemd est modulaire en tant que logiciel, avec des interfaces DBus définies. En tout cas dans la théorie, car dans la pratique quasiment aucun de ces modules n'a jamais eu d'alternative.
Par contre, j'ai l'impression que les distributions ne veulent pas tenter l'aventure de la modularité: systemd c'est souvent un seul paquet, avec tous les modules dedans. Une belle surface d'attaque, et un frein à l'apparition d'alternatives. Personnellement c'est ce que je reproche à systemd depuis ses débuts; car à part ça, la base (services, timers, paths, etc) marche très bien pour moi, et je n'imagine pas revenir à cron et son horrible syntaxe.
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par raphj . Évalué à 3 (+1/-0). Dernière modification le 19 février 2025 à 08:59.
Ah oui, en effet. Dans ce cas, j'imagine que la faute est partagée :
Peut-être que ça viendra si une alternative un minimum suivie réutilise certaines briques de systemd et pas d'autres.
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1 (+2/-2).
A tout hasard, prenons le DNS. Partout il est indépendant. Dans SystemD c'est hyper imbriqué. Au point que toute la pile réseau est obliger de s'adapter à SystemD. C'est hyper handicapant.
Aucun autre système d'Init n'a quelque chose de pareil.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par Voltairine . Évalué à 4 (+3/-0). Dernière modification le 19 février 2025 à 09:47.
De quel sorte de « DNS » veux-tu parler ? D'un résolveur cache local comme le fait systemd-resolved ?
C'est imbriqué dans quoi ? systemd-resolved peut être utilisé ou pas c'est au choix et il ne fait pas partie du système d'init !
J'ai l'impression que tu es très critique sur une technologie que tu ne comprends pas vraiment.
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par Faya . Évalué à 3 (+1/-0).
Et aussi qu'il reproche à systemd les choix fait par les mainteneurs de la distribution. Ma distro démarre bien avec systemd mais je n'utilise pas systemd-resolved à moins de l'activer.
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par Jean Gabes (site web personnel) . Évalué à 3 (+2/-1).
Industrialisation je dit ton nom.
Voila c'est juste ça. Les artisans sont mis dehors, et on uniformise le tout, pour scaler sans problème et avoir une qualité gérable dans le temps.
Alors oui un expert/artisan ne sera pas content et voudra continuer à faire comme avant, à maitriser chaque brique (et donc y passer sa vie à ne faire que ça, car le sujet est massif). Là où l'industrie a juste besoin d'une brique que tout le monde peut utiliser de la même manière, qu'une modification se fasse partout pareil, et surtout qu'elle puisse se concentrer sur les applications, et non pas sur l'init d'un foutu serveur. Car l'init ne rapporte rien, les applications si.
Et on a la même avec les systèmes de packages et de distribution d'application: pris seul oui techniquement rpm ou deb est mieux, mais ça ne scale pas à une industrie entière, d'où l'arrivée des flatpack et autre système uniforme. Au moins avec systemd on a eu un vainqueur rapidement. Avec les distributions d'applications on en a malheureusement plusieurs. Et je dis bien malheureusement car au moins avoir un champion par défaut, et des alternatives à côté permettrait de continuer d'innover sans bloquer l'industrie qui elle a besoin d'uniformisation.
Ce n'est juste plus un métier pour les artisans, au mieux un hobby et c'est déjà très bien. Mais ce temps est passé, l'argent est arrivé en masse, avec une masse de salariés, et donc un besoin d'uniformisation.
C'est un peu triste car il y a beaucoup moins de projets foufous, mais une industrie n'a pas besoin d'eux.
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par da_kal . Évalué à 2 (+1/-0).
Merci.
IBMusiness is business
# Linux Torwald
Posté par abriotde (site web personnel, Mastodon) . Évalué à -8 (+1/-10).
J'attaque SystemD dans mes messages pour la philosophie et les choix non UNIX pris. Mais concrètement je n'ai pas toujours la solution technique. Mais je sais, que même si elle n'est pas simple, elle existe certainement.
Fondamentalement on voit une différence profonde de compréhension technique et de la philosophie KISS (maintenable) entre L'encart Potering et Linus Torwald. Linux à une capacité à taper du point sur la table et à dire non à l'ajout de fonctionnalités utiles car le choix technique ne convient pas. C'est frustrant mais on finit par trouver ue solution technique. C'est grâce à ça que son nées les fonctionnalités avancées de sécurité qui ont permis de créer Docker. Et vous remarquerez que Docker (et ses concurrents) sont des projets indépendant du noyau Linux.
Lennart n'a pas cette force de caractère et en plus il est affaibli par son historique. C'est un mauvais leader technique.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Linux Torwald
Posté par David Delassus (site web personnel) . Évalué à 7 (+5/-0).
Je m'attendais pas en postant ce lien de créer une telle flamewar. Je pensais que systemd avait tellement bien fait ses preuves que ses débats étaient d'une autre époque.
Par contre, je note bien qu'après que tout tes arguments techniques ont été contré, tu passe aux attaques personnelles à l'encontre de Lennart.
Tu le connais personnellement pour dire ça ?
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Linux Torwald
Posté par abriotde (site web personnel, Mastodon) . Évalué à -1 (+1/-3).
Non les arguments technique restent, il n'y a rien de personnel contre Lennart. C'est contre les choix techniques qu'il a fait. (Après il n'est sans doute pas seul).
SystemD est parfait pour le néophyte. La documentation est plutôt bien faite et ce n'est pas difficile de s'y mettre… le problème c'est de le debugger en cas de problème. Que l'on soit expert ou pas. Mais le problème n'est même pas vraiment là. Le problème c'est que l'on sait qu'une partie de ces problèmes sont du aux choix de SystemD. La pluspart sont résolu en contournant SystemD… voir pour certain en le subtilisant.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Linux Torwald
Posté par Faya . Évalué à 7 (+5/-0).
Est-ce que tu vois la contradiction ? Tant qu'on est dans le personnel, tu parles de "force de caractère" mais j'ai régulièrement l'impression que tes messages (à propos de systemd, Rust, ou même musk & l'IA) sont un genre de patchwork de morceaux trouvés sur le net. Tu balances des pseudo-facts sans jamais argumenter.
C'est à dire ? Pourquoi un service systemd serait plus compliqué à débugguer qu'un script SysVinit ?
Subtiliser systemd ? Il est libre, tu peux le prendre pas besoin de le voler (oui je fais l'idiot, je suppose que tu voulais dire "substituer")
[^] # Re: Linux Torwald
Posté par Nicolas . Évalué à 1 (+3/-3).
Pas vraiment non. Et le prosélytisme ainsi que l'agressivité du projet pour intégrer des besoins indépendants devrait interroger sur sa finalité (ne pas oublier que Microsoft est à la manœuvre). C'est très politique tout ça.
Techniquement j'ai fais le chemin inverse Systemd -> SysV (nu). Les prisons dorées, ça attire toujours, jusqu'à…
[^] # Re: Linux Torwald
Posté par raphj . Évalué à 4 (+4/-2). Dernière modification le 19 février 2025 à 11:17.
Le fait que Lennart bosse pour Microsoft est assez récent dans l'histoire de systemd.
Tu as des hypothèses ? J'en vois deux :
La deuxième hypothèse, en plus de sentir un peu la théorie du complot (qu'il faut donc bien étayer), n'explique pas l'absence totale de changement de situation entre le passage de Lennart de Red Hat à Microsoft, qui pourtant ne sont pas trop partenaires (Red Hat n'est d'ailleurs pas dans le store de Microsoft comme distribution installable pour WSL). Il faut aussi bien voir que l'hypothèse 2 ne serait pas une bonne nouvelle sur la gestion d'aucune distribution majeur, et en particulier Debian. En vrai, c'est même une accusation assez grave sur leur fonctionnement, donc ce n'est pas léger.
Alors, il me reste l'hypothèse 1, qui correspond également à mon ressenti personnel (je trouve les système linux incroyablement plus simple à utiliser et à administrer depuis systemd.
Je suis ouvert à d'autres hypothèses ou à des preuves pour étayer l'hypothèse 2 bien sûr.
[^] # Re: Linux Torwald
Posté par Nicolas . Évalué à -4 (+0/-5).
On peut sortir de cette vision binaire et manichéenne ?
Toutefois, étant donné le nombre de contre-vérités sur sysV on est tout de même en droit de se poser des questions. La très grande majorité des reproches qui lui sont adressés étaient le fait d'un certain historique mais pas d'un problème intrinsèque. On en reparle dans 10 ans, quand j'ai switché c'était déjà une belle usine à gaz.
Ces logiciels répondent à des besoins différents. Par contre il y'a très clairement une volonté, satisfaite, d'hégémonie.
[^] # Re: Linux Torwald
Posté par Nicolas . Évalué à -3 (+0/-4).
Je parlai de systemd comme usine à gaz. Bien sûr.
[^] # Re: Linux Torwald
Posté par David Delassus (site web personnel) . Évalué à 8 (+7/-1).
Les scripts shells illisible, inmaintenable, qui changent d'une distro a l'autre car ils ont implémenté un framework shell différent comme base (avec comme mention honorable, debian qui requiert des commentaires avec une syntaxe spécifique)
^
C'est pas un problème intrinsèque à SysV qui a été reproché maintes et maintes fois ?
Et que upstart/systemd ont remplacé par un fichier de conf simple, unifié entre distro, et surtout bien documenté ?
C'est une contre vérité ? C'était mieux avant ?
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Linux Torwald
Posté par Nicolas . Évalué à -3 (+0/-4).
Lol. Faut pas se mettre dans ces états…
[^] # Re: Linux Torwald
Posté par raphj . Évalué à 3 (+2/-1).
Où est la vision manichéenne ? J'ai demandé d'étayer des accusations sous-entendues dont *je ne suis pas l'origine. J'ai développé cette demande pour montrer les contradictions sur lesquelles on tombe rapidement avec ces accusations.
Accusations que systemd poursuit une finalité questionable, juste après un rappel sur le fait que systemd a un lien avec Microsoft, sans d'ailleurs expliquer lequel. En partant de la supposition que Microsoft c'est le mal, j'imagine.
C'est moi qui suis manichéen ? Si mon raisonnement parait grotesque, il fallait être plus explicite en premier lieu.
Je suis sûr que systemd a des défauts, mais malheureusement, les critiques constructives, factuelles et informées se font rares dans les commentaires de cette page, à la place on a le droit à des tartines de frustrations profondes essentiellement causées par une méconnaissance du sujet, et maintenant, du fud. Super. En vrai, les gens semblent détester systemd de manière complètement irrationnelle. Rien de nouveau depuis 15 ans finalement.
Tant pis, j'irai lire des comparatifs informés avec les alternatives ailleurs à l'occasion pour satisfaire ma curiosité.
[^] # Re: Linux Torwald
Posté par Nicolas . Évalué à -6 (+0/-7).
Tu en es totalement à l’origine. Tu as juste projeté sur moi une pensée sociale et politique très pauvre. Parce que tu n’es pas capable de mieux.
C’est pas moi qui le dit. C’est toi. CQFD.
Elles sont là. Faut juste arrêter d’être sectaire. Pareil, avant de critiquer SysV il faut connaître un minimum. J’ai utilisé les deux, à un niveau plutôt avancé. J’en connais les limites et choisirai en fonction de mon besoin. Quiconque en fait de même reconnaît les idiosynchrasies un peu pénibles, la documentation abyssale à s’avaler, pour trouver exactement le paramètre sur lequel jouer pour remplir son besoin. D’un autre côté ne pas avoir compris que SysV, tout comme Systemd, sont totalement agnostiques de l’exécutable lancé (les deux lancent du shell, du binaire, etc.), ben ça invite pas à la discussion… je suis pas là pour vous tenir la main.
Après on peut se demander pourquoi les projets de Lennart suscitent autant de «passions» (on va dire ça comme ça hein). Du peu que j’en ai lu, lui-même a une manière bien toxique de défendre le bien fondé de ses projets et à les imposer par la force (cf. udev). Insidueusement il fait passer le message de l’homme providentiel qui a sauvé l’écosystème Linux courant à la catastrophe. On aime ça en France les hommes providentiels. Et en Allemagne.
[^] # Re: Linux Torwald
Posté par raphj . Évalué à 3 (+1/-0). Dernière modification le 20 février 2025 à 14:32.
Non
Bah oui, à défaut d'avoir une explication demandée à répétition de ce que tu sous-entendais par :
Okay, ça ça pue vraiment du cul comme remarque.
Perso, je n'ai pas de passion pour systemd, si c'était une autre accusation que tu souhaitais exprimer. Mais j'avoue, j'ai du mal avec les argumentations pétées.
En fait, je me demande qui est le plus passionné ici.
Cet échange est mort, je m'arrête là.
[^] # Re: Linux Torwald
Posté par abriotde (site web personnel, Mastodon) . Évalué à -3 (+1/-5).
Cela ne fait pas Lennart un mauvais développeur ou leader…
C'est un peu la théorie qui dit que le capitalisme tends à mener à son incompétence (on progresse dans la hiérarchie quand on est bon et on stagne quand on est mauvais…)
Plus largement la communauté open-source à plus souvent raison que le leader… c'est un des super pouvoir de l'open-source… il permet un fork par un autre pour mettre en compétition des choix techniques.
Null doute que SystemD tombera un jour. Mais cela peut prendre du temps. En attendant c'est vrai qu'il est intéressant… à défaut de mieux
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Linux Torwald
Posté par Sacha Trémoureux (site web personnel) . Évalué à 3 (+3/-1).
Pwah mais t’es dans ton monde toi c’est fou.
[^] # Re: Linux Torwald
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
C’est complètement lié à linux. Docker desktop utilise une machine virtuelle ubuntu.
Microsoft a porté les APIs pour avoir des images Windows, mais il s’agit de réimplémenter linux (et ça ne marche pas très bien de ce qu’on m’a dit).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Linux Torwald
Posté par raphj . Évalué à 3 (+1/-0). Dernière modification le 19 février 2025 à 11:23.
Je ne vois pas trop le rapport avec Docker, mais la majorité de ce qui fait fonctionner Docker et ses copains aujourd'hui, c'est des fonctionnalités du noyau Linux et c'est dans le noyau Linux que les développements se sont passés. Notamment tout ce qui concerne l'isolation des différents namespaces. Ces systèmes sont des couches très légères sur des fonctionnalités puissantes du noyau (plus, éventuellement, tout un système de format et de distribution de conteneurs, et un système de virtualization sur les systèmes qui ne sont pas basés sur Linux, peut-être en faisant appel à des briques de toute façon existantes comme Qemu ou Hyper-V, à vérifier).
[^] # Re: Linux Torwald
Posté par Olivier Abad . Évalué à 7 (+6/-0).
Mouais, il m'a fallu 30s de recherche pour trouver ce commentaire de Linus :
[^] # Re: Linux Torwald
Posté par gUI (Mastodon) . Évalué à 6 (+3/-0).
Ouais après considérer le monstrueux kernel Linux comme un truc KISS relève un peu de la mauvaise foi. Entre les millions de lignes de code et les méga-octets de binaire final, on est loin de l'architecture d'un micro-kernel par exemple.
J'ai pas dit que ce serait moins bien ou mieux (le débat existe depuis la publication du premier code source par Linus), je dis juste que le kernel Linux n'a rien de KISS contrairement à ce que tu sous-entends.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Linus Torvalds (titre édité)
Posté par Benoît Sibaud (site web personnel) . Évalué à 6 (+3/-0). Dernière modification le 20 février 2025 à 09:32.
La première chose que tu devrais faire avant de râler sur le boulot d'autres personnes, c'est d'apprendre à orthographier correctement leur nom, ce qui serait un poil plus respectueux donc : Lennart Poettering et Linus Torvalds.
[^] # Re: Linus Torvalds (titre édité)
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 6 (+4/-0).
En fait si ça se trouve il parle de deux autres personnes depuis le début, c’est pour ça qu’on comprends pas !
La connaissance libre : https://zestedesavoir.com
[^] # Re: Linus Torvalds (titre édité)
Posté par sebas . Évalué à 4 (+2/-0).
— On se connaît, non ? Vous n'étiez pas au FOSDEM ?
— Ben, non …
— Ah ? Bon, en fait, moi non plus, il doit s'agir de deux autres personnes.
# Une soluce + une relance de troll (ou pas)
Posté par AncalagonTotof . Évalué à 1 (+1/-2).
1) Je commence par le troll : c'était pas le but. Si, si, je n'en rajoute pas là.
Mais je trouve quand même positif d'avoir mis en lumière la division qui existe toujours entre les pros et les contres systemd. Je ne sais pas si on peut tracer une frontière claire pour délimiter les camps. D'ailleurs, il y a certainement plus d'une seule frontière, et plus que deux camps.
Il y en a une, de frontière, que je situerais entre :
Vous n'êtes pas obligés de relancer la guerre là-dessus.
Non, franchement, y'a des arguments dans tous les camps. Et si je ne me trompe pas, personne ne trouvera l'argument ultime pour mettre tous le monde d'accord.
2) la soluce. À quel problème ? La console effacée à la fin du boot. Quand j'ai eu ce problème de réseau pas totalement/du tout UP alors que systemd tentait quand même de monter les partages réseau, je me suis battu pour essayer d'éviter que la console ne soit effacée à la fin du boot, pas le prompt de login (stop, je sais maintenant, cf plus bas).
"Dans le temps", c'était facile, il suffisait d'ajouter
--noclearaux lignes*ttydu fichier/etc/inittab.Donc, dans un premier temps, j'ai cherché à faire de même, mais à la sauce systemd.
Et j'ai trouvé un paradoxe : l'option est présente dans tous les fichiers de service
agetty, trouvé à grands coups defind par-ci par-là -type f -exec grep -Hn noclear "{}" \;par exemple, mais la console est effacée quand même.Buh ?
DuckDuckGo ? Bof, rien d'utile.
Au final, je n'ai réussi qu'à foirer la console : plus du tout de login sur tty1.
C'était il y a plusieurs semaines.
Hier, nouvelle recherche.
Là, j'ai trouvé. Pourquoi seulement hier, et pas la première fois ? Je ne sais pas formuler une recherche ? Qu'est-ce que ça va être quand les prompts/IA seront incontournables … N'en rajoutons pas, c'est de la matière à un autre troll …
Alors ? Cette soluce, c'est quoi ?
systemctl statuspertinent cette fois, sur le bon service. Ce qui m'a permis de découvrir que mes tentatives, mes bricolages, m'ont fait faire une connerie conduisant à deuxExecStartpar le biais de/etc/systemd/system/getty@tty1.service.d/override.conf. OK, problème de démarrage résolu. Mais quid du--noclear?--noclearfait son office. Tout simplement parce que ça n'est pas lui qui efface la console. Devinez … Oui, c'est systemd ! Stop, halte, zut à la fin. Oui, je comprends la logique, y'a pas forcément de rapport entre "il faut effacer la console pour des raisons de sécurité" et "prompt de login" parce que ce dernier n'est pas forcément utile/recommandable sur tous les systèmes, ou dans tous les cas de figure; mais il faut absolument effacer la console quand même, même sansagetty. Par contre, j'espère que vous allez admettre que l'option à la sauce systemd qui permet de ne plus effacer cette console est bel et bien obscure :TTYVTDisallocate=yes(à changer en=nodonc). Source ici. Bon, honnêtement, je n'ai pas encore testé jusqu'au bout : système mis en veille, et non pas rebooté. Mais ça sent bon la soluce quand même.On est d'accord, y'a pas que moi qui soit le problème dans cette histoire ? Il faut du bol pour tomber là-dessus ? Ou être un pro dont c'est le métier d'apprendre, de se former, si possible en avance et de façon méthodique, en lisant la doc, toute la doc. Pas un amateur qui subit le changement imposé ?
[^] # Re: Une soluce + une relance de troll (ou pas)
Posté par orfenor . Évalué à 5 (+3/-0). Dernière modification le 20 février 2025 à 14:13.
La console effacée (ou qui semble telle) c'est vieux comme une distro Linux. Je cherchais déjà les messages de boot en 1994.
Par contre, merci systemd, je les retrouve facilement sur Debian. J'ai oublié comment (ça sert pas souvent), va falloir chercher un peu (j'ai vraiment oublié).
En lisant tes messages, je me suis plusieurs fois dit que tu cherchais des solutions aux problèmes de ta bécane, plutôt que participer au débat. Franchement, penses-y, parce qu'une discussion technique aurait été plus enrichissante (même si tu as suscité des belles réponses).
[^] # Re: Une soluce + une relance de troll (ou pas)
Posté par AncalagonTotof . Évalué à 1 (+0/-1).
:-)
[^] # Re: Une soluce + une relance de troll (ou pas)
Posté par Faya . Évalué à 1 (+0/-1).
Peut-être que ta distribution devrait améliorer sa documentation.
[^] # Re: Une soluce + une relance de troll (ou pas)
Posté par AncalagonTotof . Évalué à 1 (+0/-1).
Oui, et je ne pense pas l'avoir présenté autrement que : j'ai eu ces soucis, et sans m'être fait imposer systemd, je les aurais résolus plus vite.
On est d'accord que la question n'est pas tranchée, rapport à mon histoire de camps et de frontières ?
On est d'accord que ce qui se justifie parfaitement dans un contexte peut devenir une énorme charge pour ceux dont ce n'est pas le métier ?
Est-ce qu'il faut limiter l'accès, ou le droit de publier ou répondre sur ce site à une ou certaines catégories d'utilisateurs ?
Accessoirement, on s'écarte aussi de la technique en poursuivant le troll, et en négligeant la soluce que j'ai fini par trouver.
[^] # Re: Une soluce + une relance de troll (ou pas)
Posté par orfenor . Évalué à 1 (+0/-1).
Je voulais dire que ce n'était peut-être pas le bon endroit pour poser ta question: le forum avec une question directe sans y annexer de troll ;-) aurait amené plus vite la réponse
[^] # Re: Une soluce + une relance de troll (ou pas)
Posté par David Delassus (site web personnel) . Évalué à 1 (+0/-1).
C'est bien connu que sur internet, si on veut une solution à un problème, il vaut mieux poster la mauvaise réponse, plutôt que la question.
https://meta.wikimedia.org/wiki/Cunningham%27s_Law/fr
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Une soluce + une relance de troll (ou pas)
Posté par barmic 🦦 . Évalué à 1 (+0/-1).
J’ai laissé passé du temps. Je suis sincèrement désolé que les esprits se soient si vite échauffés. Je vais tenter de donner mon point de vu en espérant que cela se passe mieux. Et je commence pas te présenter mes excuses.
Je me permet[1]. Pour moi il n’y a pas de camps. Je me fou de systemd et il n’est d’ailleurs pas présent sur la machine que j’utilise le plus.
Pour moi c’est fondamentalement une question d’état d’esprit et de réaction à l’évolution. De manière caricaturale est-ce que la réaction primaire a une évolution est la curiosité ou la réactance ? C’est de cette réaction primaire que découle les procès d’intention qu’on peut lire plus haut ou la position qui consiste à se dire que chacun fait de son mieux et que oui systemd peut faire des erreurs, debian aussi et que l’on peut payer les pots casser.
Je n’ai pas encore utilisé wayland par exemple pas parce que je ne l’aime pas je suis sûre que c’est bien debian ne m’a juste pas encore fais switcher.
Il ne faut pas voir ces points de vus comme des camps au quel on appartient (quelque soit le sens qu’on y met) et qu’il faudrait défendre. Il y a tout un gradient entre ces points de vu et les gens peuvent être en réactance sur des sujets et curieux sur d’autres.
Hors d’une question de vérité absolue qui ne me parait pas pertinent, il me semble qu’il est plus agréable d’arriver à adopter une position curieuse que de réactance1. J’ai par exemple plus de mal avec les LLM, mais je test, je me renseigne pour tenter de trouver aussi sincèrement que je peux à quoi ça pourrait servir.
Du coup
La question n’est pas de savoir qui est le problème. De mon point de vu je suis convaincu que les mainteneurs de Debian, les développeurs de systemd et toutes les personnes impliquées font de leur mieux. Des fois ça marche mieux et des fois cette chaîne humaine connaît des couacs. Pour moi quand je choisi d’utiliser un système communautaire je reconnais que ce sont des personnes et que je ne suis pas un simple client/consommateur.
Tu parle de moteur de recherche et tu te lamente sur l’IA, mais la force des projet communautaires c’est l’humain justement. Tu as des forums et autres communauté d’utilisateurs qui se feront une mission de trouver des solutions. Si tu ne sais pas où commencer les issues du projet upstream peuvent être un point de démarrage pour demander de l’aide (en respectant la netiquette en vérifiant que la question n’a pas était posée). Cela permet en plus d’aider à la compréhension dev/utilisateur et ce n’est que de l’humain.
ne me faites pas dire ce que je n’ai pas, ne sortait pas ça de son contexte. ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.