raphj a écrit 1687 commentaires

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.

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