raphj a écrit 1730 commentaires

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.

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 ?

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…

tout les soft doivent être redéveloppé quasiment pour SystemD

Tu peux en dire plus ? Si ton soft est intimement lié au boot, ça paraît normal, mais sinon, que faut-il adapter ?

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

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.

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.

Oui, et avec un peu de chance, le richesse va un peu ruisseler sur nous :-)

S'asseoir sur la Constitution

Malheureusement, une partie des problèmes est que la Constitution contient des backdoors démocratiques et que ces backdoors sont empruntées…

Disons que les deux affirmations ne sont pas mutuellement exclusives :-)

L'actualité sur le site du service public : https://entreprendre.service-public.fr/actualites/A15683

La facture électronique, en soit je trouve ça pas mal. Aujourd'hui j'édite manuellement les quelques rares factures que j'émets en espérant que je respecte bien les obligations. On peut espérer de plus fortes garanties là dessus avec un service dédié. On peut aussi espérer des garanties de conservations, et même peut-être des déclarations directes à l'URSSAF : une étape de moins (bon, ça, je ne pense pas que ça arrivera cela dit).

Par contre, l'obligation de passer par un prestataire privé, c'est quand même un problème :

Les factures électroniques transiteront sur une plateforme utilisée par l'émetteur et le destinataire de la facture. Celle-ci sera nécessairement une plateforme de dématérialisation partenaire (PDP) accréditée par l'administration fiscale. Le portail public de facturation n'étant finalement pas mis en place.

Au lieu de se tuer à mettre en place des processus pour auditer et accréditer des boites privées qui ne devraient avoir rien avoir avec l'activité d'une autre boite, je préférerais que le service public mette en place une plateforme pour ça, avec des API solides si besoin. Libre ensuite à des boites privées pour fournir des services autour, et libre aux entreprises de les utiliser ou non.

Là, on va avoir le droit à une usine à gaz qui coûte plus cher (il n'y a pas de mystère, on va forcément payer le temps de travail nécessaire à mettre en place une plateforme de facturation électronique), impliquant des intermédiaires indésirables.

C'est comme pour les bulletins de salaires électroniques, c'est naze de devoir passer par des "coffres forts" privés. C'est comme France Connect +.

Le service public doit se donner les moyens de fournir les outils nécessaires pour respecter. Mais bon, cette logique libérale n'est pas étonnante. On a, collectivement, voté pour.

Oui, c'est vrai. J'avais un couteau de cuisine en tête, le premier que tu affiches est clairement une arme. Un couteau de cuisine bien aiguisé peut servir d'arme mais n'est pas particulièrement orienté vers cette utilisation. Mais je suis d'accord avec toi, on peut toujours trouver une manière de montrer qu'un outil n'est pas neutre. Je suis même près à penser qu'aucun outil n'est absolument neutre, au moins parce qu'il biaise vers au moins une utilisation en particulier, et cette utilisation peut elle-même être discutable (et c'est vrai pour le couteau de cuisine : s'il est optimisé pour couper de la viande par exemple, on peut déjà trouver à discuter). Disons que sans arriver à la neutralité, une arme ou un LLM me paraissent plus sujets à controverses qu'un couteau de cuisine, qu'on absolument toutes et tous chez soi sans que le principe soit trop remis en question. J'ai plutôt du mal à trouver des problématiques éthiques liées au couteau de cuisine à soulever.

il fallait pas blâmer

Ah non, je n'ai pas cette lecture. La guerre en Ukraine est bien une matérialisation de plus du comportement de la Russie, mais ce n'est pas pour ça qu'elle n'est pas critiquable en tant que telle. Mais si tu veux raisonner sur cette guerre voire te battre contre, fatalement, tu vas devoir te pencher sur le comportement de la Russie. Mais il n'est vraiment pas question de s'interdire de s'émouvoir de la guerre elle-même.

Pareil pour l'IA : il faut être clair dans les idées et voir que des choses se généralisent, mais ça n'empêche pas de voir des aspects de l'IA d'un mauvais œil.

Après tout, c'est bien les manifestations spécifiques des travers du cadre plus large qu'on n'aime pas, sinon il n'y aurait pas vraiment de problème.