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.
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par raphj (site web personnel) . En réponse au lien 14 ans de systemd. Évalué à 7.
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.