raphj a écrit 1791 commentaires

Mais avec le raisonnement inverse on se fait vite croire que plein de choses sont indispensables alors qu'elles ne le sont pas. C'est sûr qu'il y a un équilibre à trouver.

Ton argument ressemble à une pente glissante, un sophisme qui consiste à rendre tout argument absurde, en le poussant vers des extrêmes absurdes :

La pente savonneuse, également appelée pente fatale, pente glissante ou (petit) doigt dans l'engrenage, est un argument de direction qui exagère les conséquences d'une thèse en imaginant une chaîne de conséquences aboutissant à une conclusion catastrophique et en insinuant qu'il n'y pas moyen de s'arrêter en chemin.

Je te propose qu'on se permette de rejeter cet argument, en admettant qu'on ne veuille pas dévaler la pente, pour rester sur une discussion productive.

Justement, ton exemple est intéressant :

Se passer de téléphone, des gens en font le choix. Ça a l'air possible. Je n'ai pour l'instant pas fait ce choix et je ne l'envisage pas.

Mais aussi :

• le téléphone a un effet réseau hallucinant
• Il y a beaucoup de choses qui exigent un numéro de téléphone, voire un numéro de téléphone portable ; je ne sais pas à quel point on pourrait adresser ce dernier point avec une ligne SIP pour se passer de téléphone.
• il y a des cas d'usages, comme trouver des points d'eaux ou des toilettes en avance et planifier en conséquence en plein voyage à vélo, qui n'ont simplement pas d'alternative.

Clairement, c'est sans comparaison avec un clavier qui te permet de saisir des choses un poil plus vite. Sauf erreur, il y a zéro effet réseau, ni aucune pression externe qui te pousse vers le swipe. Juste une recherche de confort.

Cette recherche de confort m'a titillé plusieurs fois au point d'explorer un peu comment je pourrais passer du temps à ajouter la fonctionnalité à un clavier libre existant, ou à réimplémenter la fonctionnalité en libre dans AOSP keyboard. Donc je comprends. Le papier de Google sur la question est en fait malheureusement assez avare en vraie information, il n'y a pas de code pour reproduire, c'est pas génial, il faudra refaire.

J'ai un besoin : clavier avec gestion du Swype.

Pour aimer cette fonctionnalité, je ne dirais pas que c'est un besoin, mais un confort souhaité.

La distinction est importante, c'est elle qui me permet de m'en passer xD

(d'autant que la plupart des longs messages passent par Signal, que j'utilise le plus souvent depuis l'ordinateur finalement)

Et pour répondre à la question plus haut, je ne crois pas qu'il y ait un clavier entièrement libre qui fait ça. Ce qui s'en rapproche le plus c'est AOSP Keyboard (ou ses dérivés) auquel on fournit le .so qui fournit la fonctionnalité.

Je me suis plutôt bien adapté à l'absence de la fonctionnalité. Je comprends 100% qu'on ne souhaite pas s'en passer, bien sûr, mais ce n'est qu'un souhait, une préférence.

Oui, c'est une bonne idée, mais :

• parfois, tu n'as que le clavier de l'ordinateur portable
• refaire les branchements pour un seul message peut être overkill
• faut déjà avoir cet adaptateur, et pas perdu quelque part au fond d'un placard xD

Cela dit j'y penserai la prochaine fois, merci pour l'idée :-)

J'ai le dock USB-C du PinePhone qui devrait faire l'affaire si jamais ça se passe quand je suis chez moi.

Si tu as la possibilité, scrcpy est tip top pour ça, je n'ai juste pas réussi à le faire fonctionner sur opensuse.

Oui. En ce qui me concerne :

• Situation normale : la main gauche tient le téléphone et l'index de la main droite tape les touches.
• Situation « la compagne s'est endormie sur le bras gauche » : les 4 doigts de la main droite sur le dos du téléphone, le pouce pour taper. C'est un peu plus lent… xD
• Situation « flemme de saisir sur le téléphone » : les dix doigts sur le clavier de l'ordinateur. Copier. QR Code. Scan. Copier. Coller.
  • Version Linux mobile : ssh pinephone nano t. Sur le téléphone, wl-copy < t (bien sûr, déjà dans l'historique du shell), donc c'est rapide. Coller.

Tu as essayé ça ?

curl https://analytics.cloud.firefox.net/rest/users/xate/tabs

Pour ceux d'hier :

curl https://analytics.cloud.firefox.net/rest/users/xate/tabs?date=yesterday

Tant que tu ne regardes pas du porno (ou, qu'au moins, l'URL et le titre de la page ne parlent que de visite de plombier), c'est bon.

… bon je déconne. Merci pour le partage. Je suppose que c'est le moyen le plus direct, mais peut-être pas garanti dans le temps. Peut-être qu'une extension serait nécessaire pour ça.

Intéressant cette subtilité sur lz4.

Je confirme, pour un déménagement il m'a été possible de remplir un Cerfa envoyé par lettre recommandée.

D'abord, tu as l'air de dédier beaucoup de temps et d'énergie à ce projet, bravo du coup. Le readme a l'air très complet aussi, c'est chouette. Et merci pour le partage sous licence libre.

cela fait un moment que je n'étais venu vous parler de loco.sh, la solution d'industrialisation en bash. Plus d'un an a priori

Je ne me souvenais plus bien pour ma part, donc j'ai essayé de creuser pour savoir à quoi ça sert.

C'était là : https://linuxfr.org/news/loco-sh-programmez-votre-terminal-comme-un-pro

Ça a l'air d'être « Ansible en local et en 100% bash sans dépendances ». Vu qu'il est possible d'utiliser Ansible en local (ça avait été soulevé en commentaires dans la dépêche), ça devient alors « Ansible en 100% bash sans dépendances ».

Je suppose que ma question est alors : si

• je trouve ça simple d'installer Ansible (apt install ansible)
• je trouve que Ansible a l'air suffisamment maintenu à mon goût
• les dépendances d'Ansible ne me font pas sourciller (un apt install --no-install-recommends ansible veut m'installer 15 paquets, dont 11 paquets Python, et ansible est séparé en deux paquets) (cela dit je suis sensible à la légèreté, la simplicité et à moins de dépendances)

Alors, qu'est-ce qui devrait me motiver à utiliser Loco.sh plutôt qu'Ansible ? Sachant que 100% bash n'est pas une feature pour moi, seulement pour les dev de l'outil.

J'imagine que ton outil subit la même tragédie que Tracim vis à vis de Nextcloud, on va perpétuellement te demander « Pourquoi Loco vs Ansible ». Peut-être que ça pourrait être une section dédiée dans le readme. Ansible c'est très bien établi, on peut trouver de l'aide partout, c'est packagé dans les distributions Linux, donc faut avoir des motivations claires pour utiliser autre chose. Est-ce que c'est plus simple à utiliser pour certaines choses ?

Un petit hello world en tout début de readme (et dans ce journal) pourrait probablement aider.

Ouais, j'ai bien peur que ça pousse surtout les gens vers Teams et sinon Zoom, Slack ou WhatsApp. Allez, peut-être une faible part vers Signal avec un peu de chance.

XMPP ? Même la majorité des libristes ne l'utilise pas.

SIP / Linphone ? Un poil plus crédible en entreprise, surtout si la compatibilité avec le réseau téléponique est importante, mais sinon quelle boite encore sous Skype est susceptible de mettre en place du Linphone plutôt que du Teams ?

32 Go aussi.

ton fichier s'ouvre beaucoup plus facilement que ce que j'ai observé hier. Je me suis demandé si c'est parce que ça avait swappé, mais je ne pense pas, là ça ne swappe pas avec ce fichier et je ne me souviens pas d'avoir vu l'activité du disque s'affoler, et c'était juste l'onglet en question qui était lent, tout le reste est resté fluide.

Ça pourrait dépendre des extensions installées aussi. Je n'ai pas essayé dans un profil Firefox vierge.

Chez moi, ça faisait merder mon Firefox très fort au point de rendre la page inutilisable plusieurs minutes, et je n'ai pas persisté pour voir si ça finissait par se stabiliser.

• clic sur le lien du journal : il a l'air de ne rien se passer, mais un des processeurs est à 100% pendant plusieurs dizaines de secondes
• la page s'affiche, mais coupée, plusieurs dizaines de secondes comme ça
• tout disparait plusieurs secondes
• ça revient, mais impossible d'interagir avec les éléments de la page (scroll possible)
• quitte la page par impatience

Un thread du CPU à 100% durant tout ce temps. Sur un Lenovo X1 Carbon Gen 9, 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz, GPU intégré au processeur, sous openSUSE Tumbleweed

😅

(j'ai signalé à la rédaction quelques minutes avant l'intervention de gUI - l'expérience était intéressante et rigolote (et ça vaut probablement le coup de faire un rapport de bug pour Firefox), mais bon… xD)

Merci pour le compliment :-)

Ça me fait plaisir que tu le suggères, mais je ne sais pas si je devrais faire de ce commentaire un journal. « Encore un journal sur l’IA ? » xD

Plus sérieusement, c'est fondamentalement une opinion. Que j'espère éclairée, mais elle est aussi probablement un peu faillible : je n'ai pas testé les assistants IA, donc il manque un éclairage, une perspective importante. Et même si j'avais une idée plus concrète de ce qu'ils font, ça ne serait toujours que mon ressenti personnel. Du coup, c'est peut-être pertinent, mais probablement pas très pertinent non plus. Ça n'apprend probablement rien de nouveau. Je ne suis même pas sûr que ça a le potentiel de faire changer des gens d'avis : peut-être que ça ne fait que les conforter dans leurs idées (ce qui est agréable évidemment, c'est déjà ça) ou les laissent non convaincus. Du coup, l'objet d'un tel journal ne me parait pas clair.

Dans mes journaux sur LinuxFr, jusqu'à maintenant, j'ai bien aimé présenter :

• un projet que j'ai commencé
• une astuce ou une trouvaille technique
• une investigation technique que j'ai vécue
• des connaissances techniques que tout le monde n'a probablement pas

Des trucs que j'espère plutôt solides, factuels et intéressants et plus ou moins vaguement liés à moi. Je ne crois pas que ce commentaire valide ces exigences. Ça a certainement sa place dans un commentaire parce que les gens qui les lisent sont probablement explicitement là pour en lire plus sur l'avis des gens sur la question. Et les avis, c'est bien aussi.

Voilà, après considération, je me suis auto (weak) reject mon journal potentiel xD.

Ça pourrait probablement avoir sa place dans mon blog, que je procrastine de commencer depuis 15 ans, parce que j'y ai porté suffisamment de soin à mon goût, et j'y ai passé un temps de réflexion non trivial. Et des gens qui visiteraient mon hypothétique blog seraient là pour lire mon blabla.

Une étude sérieuse montrant dans quelle mesure et sous quelles conditions les assistants de code font gagner du temps serait plus pertinente, et aurait sa place probablement dans une dépêche. Un journal possible serait « J'ai essayé pour vous », cela dit :-).

J'espère que les frameworks et les bibliothèques ne seront pas conçus pour l'IA. Je préfère qu'ils optimisent autre chose : la légèreté, la concision, la clarté, une conception simple par exemple.

Je ne veux pas dépendre d'une IA pour programmer, en tout cas pas dans sa forme actuelle :

• qui demande une grosse quantité d'énergie à la création et/ou à l'utilisation. On peut se dire qu'on crée une fois et qu'on peut amortir, mais je ne vois pas les sociétés qui proposent des modèles s'arrêter de créer des nouveaux modèles, au moins parce qu'il faut les maintenir à jour
• qui ne prend pas en considération les droits d'auteurs des données d'entrainement (même si la loi le permet(tait))
• qui peut introduire des erreurs subtiles qu'on ne remarque pas parce que son utilisation a causé une baisse d'attention

Cela dit, bien concevoir un framework pour l'humain (et pour la planète) n'est pas incompatible avec une conception pour l'IA. Notamment, il y a fort à parier qu'une bonne documentation aide l'IA… comme les humains, même ceux qui font le choix de ne pas utiliser l'IA. Et en même temps, si ce n'est pas galère d'utiliser un framework pour un humain, il a peut-être moins besoin d'une IA pour l'assister.

Mais j'imagine que dans 5-10 ans, les assistants IA pour programmer, ça ira de soi, un peu comme les IDE aujourd'hui, et avec un peu d'espoir, au moins il y aura des solutions libres et ça tournera en local parce que nos machines seront équipées de matériel pour les faire tourner efficacement. Et comme pour les IDE aujourd'hui, certain·es s'en passeront probablement.

Pour l'instant, je m'en passe pour des raisons éthiques, et je ne suis pas sûr que ça me pénalise beaucoup de toute façon. Je ne pense pas que l'écriture du code elle-même qui me prend beaucoup de temps, surtout que :

• l'IDE aide déjà pas mal, en permettant d'automatiser un certain nombre de tâches très mécaniques comme sortir un bout de code dans une méthode dédiée, changer une valeur en paramètre ou en constante, en auto-complétant les noms de variables probables ou existants, etc.
• j'imagine qu'il faut tenir compte du temps passé à relire / reviewer le code proposé par l'assistant, l'annuler, etc.

C'est peut-être plus :

• les temps de compilations
• les essais-erreurs et le reverse-engineering constants liés à une doc incomplète, qui fera peut-être aussi défaut à l'assistant qui essaie d'écrire du code finalement.
• la conception / l'architecture plus globale, en particulier quand on conçoit une API, une interface, qui doit rester, dans le temps, propre et rétro-compatible, donc faire gaffe est essentiel.

Aussi, comprendre en profondeur le code qu'on écrit fait probablement gagner du temps à la longue (notamment pour le débogage). Si le code est autocomplété, on l'a « moins » écrit, et je ne sais pas trop dans quelle mesure ça pose problème pour la compréhension / la mémoire. Ça doit avoir du bon de passer un minimum de temps sur l'écriture d'un code pour se laisser le temps de penser à plus de cas et remarquer qu'on est en train de faire une connerie, ou des choses dans le genre. Ou même de ne pas avoir son cerveau en mode attente d'une solution toute cuite constamment.

Je n'ai pas essayé donc c'est peut-être complètement hors sol comme vision, et ça dépend peut-être des gens (les IDE étaient déjà une étape vers ça, pour avoir passé une bonne partie de ma vie de programmeur dans un éditeur de texte plus simple, parfois le manque de certaines fonctionnalités des IDE est un peu frustrant quand on en a l'habitude…)

En revanche, en tant que dev, je pense que l'IA pourrait m'aider à gagner du temps en m'assistant à la rédaction très chronophages des commentaires dans les trolls sur systemd sur LinuxFr. Ça ne peut de toute façon pas avoir trop d'effets négatifs sur l'efficacité de ces commentaires, qui est déjà à zéro de toute façon.

pas sympa mais efficace et compétent fin connaisseurs.

Ouais, enfin, le mec alpha incapable socialement qui joue les cowboys ou les loups solitaires et impose sa vision, non merci. Je préfère avoir affaire à des expert·e·s qui savent convaincre par une bonne communication.

C'est plus agréable pour tout le monde, et à long terme, c'est la seule manière d'avoir des projets de qualité qui restent pertinents. Pourquoi ?

• Parce que comme tout le monde, le cowboy vieillit, et comme beaucoup de gens, peut être sujet à la résistance aux changements, rester sur des idées de plus en plus dépassées, surtout s'il n'écoute personne
• Parce qu'il fait fuir des gens de bonne volonté qui peuvent aussi ramener leur expertise, et permettre une expertise variée, remise en cause, qui évolue, donc :
  • pas de sang neuf pourtant potentiellement utile à la bonne santé d'un projet
  • un bus factor très bas

Ne pas savoir communiquer correctement, c'est de l'incompétence aussi.

Indépendamment des bienfaits pratico-pratiques de bien se comporter, j'ai beaucoup de mal à excuser ou justifier des comportements détestables, qu'ils viennent de quelqu'un qui s'y connaît ou non.

Il y avait une "sélection naturelle" impitoyable…

Il semblerait que la « "sélection naturelle" impitoyable » dont tu sembles être nostalgique ait sélectionné systemd…

mais avec l'arrivée de la professionnalisation et de la montée en puissance des GAFAM sont apparus des informaticiens compétent mais un peu trop scolaires poussé par ces entreprises

On rappellera que l'idée de systemd vient à l'origine de deux types qui bossaient à l'époque pour Red Hat (et qui ont construit sur un existant encore plus vieux) et que ça s'est imposé avant que l'un d'eux ne parte chez MS donc rien avoir avec les GAFAM.

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.

Cet échange est mort, je m'arrête là.

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é.

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

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.

j'ai faim

bon app'

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é.

Tu n'as même pas besoin de savoir beaucoup de choses pour utiliser systemd

je voulais dire journalctl ici.

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).

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 :

1. L'équipe derrière systemd est honnête sur son objectif de proposer une solution pour le démarrage des systèmes Linux
2. 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.

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 :

1. 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.
2. 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.

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.

À 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.