Moonz a écrit 3657 commentaires

Linux n’a pas les drivers dont ton écran n’a pas besoin ? J’ai du mal à voir où est le souci du coup.

En fait, plus je te relis, plus je me dis que tu es très très mal parti.

De deux choses l’une :

• Soit ton but est de produire un langage. Dans ce cas tu prends les choses d’un très mauvais angle en lisant le dragon rouge ; c’est un très bon bouquin pour qui veut comprendre les bases d’une toolchain de compilation, mais aujourd’hui on peut très bien écrire un langage sans écrire un compilateur. Et les chaînes de compilation d’aujourd’hui sont bien bien plus évoluées ; jamais tu n’arriveras à leur cheville avec cette approche. Ce serait quelqu’un qui dirait « bon, mon but est de concurrencer Intel. Étape numéro 1 : bouquiner un peu de logique booléenne ». Aujourd’hui, pour faire un langage pour de vrai, soit tu es un géant (et dans ce cas tu ne posterais pas ce genre de questions ici), soit tu t’appuies sur un géant (LLVM au plus bas niveau, Rust/F#/Nim au plus haut niveau, étant donné que plus haut niveau = chemin de moindre résistance)

• Soit ton but est de te faire plaisir en apprenant, et dans ce cas oublie l’idée de « réutiliser un langage existant ». Ce serait comme essayer d’apprendre la mécanique newtonienne en faisant du reverse-engineering sur un airbus.

Bref : dans ton message, un truc n’a absolument rien à faire là, soit le Dragon Book, soit Python. Commence déjà par clarifier ça :)

Dans le désordre :

1. Prend un langage qui n’a aucun (ou presque) mot de clé de base comme Lisp

2. Lua est connu pour être aisément modifiable

3. En Ruby, tu peux quasiment tout faire sans utiliser de mot clé, par exemple tu peux définir une méthode si sur la classe bool pour te permettre de transformer :

if toto then
tata
end

en

toto.si {
tata
}

J’ai ouïe dire que tu peux aussi faire ce genre de chose en F#, SmallTalk, Nim, Scala et Rust. Les versions récentes de JavaScript (Harmony) sont aussi un bon candidat.

1. Si tu veux faire une chaine complète, diriges toi vers LLVM au lieu de vouloir réinventer la roue.

Je laisserai à d’autres le soin de troller sur l’intérêt douteux de la chose :)

C’est écrit dans l’article lié plus haut.

The encoding has traditionally been either ASCII, one of its many derivatives such as ISO/IEC 646 etc., or sometimes EBCDIC. Unicode-based encodings such as UTF-8 and UTF-16 are gradually replacing the older ASCII derivatives limited to 7 or 8 bit codes.

Et j'me souviens aussi que le pilote générique pour l'écran, ça marchait pas forcément sous Windows 9X (on pouvait choisir un autre pilote).

Généralement ça marchait mais en mode dégradé, limité à 640x480 avec 16 bits de profondeur.

Je vois pas ou est marqué "du texte brut" dans ce qui est cité, c'est une interprétation de ta part sur ce que tu estime être clair. Techniquement, du xml serait aussi du texte brut, ça n'a rien de clair en pratique.

« Voici la philosophie Unix : écrire un bon programme qui ne réalise qu’une seule tâche. Écrire des programmes coopérant entre eux. Écrire des programmes qui gèrent des flots de données textuelles, car cette interface est universelle. » (McIlroy)

« La tradition Unix encourage les programmes qui manipulent des formats simples, en mode texte, orientés flot et indépendants des équipements. Unix appelle de tels programmes des filtres ; ils reçoivent un simple flot de texte en entrée, le traitent et génèrent un simple flot de texte en sortie. » (Eric Raymond)

On peut quand même voi comment une simple phrase sorti de son contexte et répété advitam eternam en guise d’épitome d'un ouvrage exposant l'état de l'art de la recherche d'il y a 40 ans dans un domaine bougant à toute vitesse est encore trop compliqué pour que les gens l'utilisent pour exprimer une idée clair.

Je commence à trouver ça curieux qu'un groupe fortement imprégné par l'esprit scientifique en revienne presque à des méthodes shamanique de vénération des textes "anciens" sans avoir le moindre recul vis à vis d'eux et de leur propre position.

Tu interprètes (très) mal la situation à mon avis.

Comme tu dis, Unix est là depuis plus de 40 ans, dans un domaine extrêmement mouvant. Ce n’est probablement pas un hasard ; il y a très certainement des invariants dessous susceptibles d’expliquer sa longévité. La « philosophie Unix » que beaucoup ici traitent avec mépris, c’est justement une tentative d’isoler et expliciter ces invariants, dans l’objectif d’en tirer des leçons pour l’architecture logicielle en général.

Bien sûr, l’analyse peut être fausse, les conclusions erronées voire contreproductives. Mais ce n’est pas en balançant nonchalamment « 40 ans ; trop vieux » (alors qu’au contraire, la longévité serait plutôt bon signe) ou « chamanisme irrationel » (alors que justement, quand on creuse un peu, on se rend compte que la philosophie Unix, elle sort pas d’un chapeau, elle sort d’un gros boulot d’analyse effectué par de nombreuses et éminentes personnes).

Si tu prends l’exemple justement de l’insistance des interfaces textuelles, il y a plusieurs raisons à ça. La plus importante selon moi est la suivante : cela te force à faire une distinction entre la représentation algorithmique de tes données, la représentation fonctionnelle de tes données, et la représentation sémantique de tes données. Représentation algorithmique : comment représenter les données en mémoire pour résoudre efficacement le problème. Représentation fonctionnelle des données : comment communiquer efficacement l’état du problème à la machine. Représentation sémantique des données : comment communiquer efficacement l’état du problème à l’humain. Quand tu forces tes entrées et tes sorties à être textuelles, tu es forcé de te poser ces questions, parce que tu es forcé d’écrire la conversion entre les différentes représentations et ce même si tu n’as pas idée de ces distinctions. Ça te donne quasiment-automatiquement un système aisément débuggable et aisément testable. À contrario, le binaire, en général, ça se passe comme ça : je code mon algorithme. À partir de mon algorithme, je décide comment sont représentées en mémoire les entrées et les sorties. Et de là, je définis mon protocole binaire : en entrée, read(struct ProblemSpecification), en sortie write(struct Solution).

Bien sûr, tu peux très bien faire cette analyse avec un format binaire (par exemple protobuf), et la foirer avec un format texte (pas mal de formats XML en sont un bon exemple effectivement, mais ce n’est pas étonnant si tu gardes en tête l’analyse précédente : beaucoup de formats XML sont juste une image de la structure interne du programme). Mais en pratique, si on accepte l’idée que faire l’analyse poussée des différentes représentations est une bonne idée, alors la spécification des entrées/sorties en format textuel est une bonne méthodologie, parce que les incitations naturelles derrière y tendent. Pour parler très abstraitement, il n’y a pas équivalence entre « protocole textuel » et « bien conçu », mais il y a certainement corrélation.

Ceci n’est qu’une raison parmi un certain nombre, mais mon message commence à être déjà assez long comme ça (et il faudrait que j’aille dormir ;)), et il y a des bouquins entiers qui analysent la « philosophie Unix » de cette manière. Pas en tant que révérence irrationnelle envers un passé idéalisé, mais en tant que leçons pragmatiques à tirer.

La philosophie Unix ce n’est pas un Dieu bienfaisant qui va te garantir le succès si tu répètes quelque mantras. La philosophie Unix ce n’est pas non plus un Dieu colérique qui va te punir si tu ne fais pas exactement comme écrit dans La Loi. Mais c’est la sagesse condensée de gens qui ont fait plus pour l’informatique que tout ce que tu pourras rêver de faire, et il est aussi bon d’avoir un peu d’humilité avant de mettre tout ça à la poubelle d’un revers de main.

Tu peux critiquer la philosophie Unix. Seulement, si tu veux la critiquer efficacement, il faut d’abord la comprendre. Quelqu’un qui dit « philosophie Unix : texte, par exemple json_encode($internalStruct) » est bien plus éloigné de la philosophie Unix que quelqu’un qui dit « OK, mon programme va communiquer en protobuf (binaire), mais que ça ne me dispense pas de réfléchir aux différentes représentations de mon problème ». Mais le plus éloigné de tous, c’est celui qui dit « haha, utiliser du texte en 2015 juste parce que quelqu’un en 1970 a dit que c’était cool ? ridicule ! ». En fait, j’en envie de dire que c’est bel et bien ceux qui l’ont comprise qui sont le mieux placé pour violer les règles. Si je devais faire du 100% « strict philosophie Unix » à mon boulot, ça ferait longtemps que je serais à la porte (parce que bon, un programme en ligne de commande pour le service compta, ça va pas le faire :)) ; par contre, je suis bien placé pour savoir que mon efficacité sur l’analyse du problème et la recherche de solutions provient directement d’un état d’esprit qui découle de la philosophie Unix — et ce d’autant plus que je n’ai pas toujous été « Unixien », et que je vois clairement la différence entre « avant » et « après », en terme d’efficacité.

Plain text

(qui est explicitement écrit dans l’article Text-based protocol)

Ho, et avant de me dire « oui mais texte brut en français c’est pas ça », regardez quelle est la version française de l’article anglais…

(et pour continuer à faire du mal à ces pauvres insectes, « texte brut » est tout à fait clair et fait référence à une dichotomie bien réelle, c’est par opposition à « texte formaté » type .doc/.rtf/.odt)

C’est la séparation d’un problème en sous-problèmes distincts.

Par exemple, pour le problème « je veux compter le nombre de commentaires dans un code python », je peux séparer mon problème en « extraire les commentaires d’un fichier python » (grep '#' < script.py) et « compter le nombre de lignes extraites (| wc -l). Le premier outil se fiche de ce que je veux faire de mon extraction (je pourrai les supprimer, faire une traduction automatique avec Google translate, whatever), le second outil se fiche d’où viennent mes lignes : les deux sont orthogonaux.

L’avantage c’est que je peux tester les outils indépendamment l’un de l’autre, et réutiliser l’un ou l’autre dans d’autres contextes.

ça n'existe tout simplement pas

Text-based protocol

Ce que je retiens, c'est surtout que si ce point de la philosophie unix était important, on tournerais plus sous qnx ou le hurd. Voir même sur darwin, si je me souviens bien.

Si les éviter les bugs était important, on utiliserait aucun outil plus compliqué que ed.

Comme si RH avait le moindre pouvoir sur Canonical, Debian, et surtout son concurrent SUSE.

Bien sûr que oui il en a, non pas en tant que concurrent, mais en tant q’upstream (RH est un très gros contributeur aux projets upstreams, que ce soit du côté du kernel, de Gnome, ou de systemd).

à quel moment systemd va lui donner plus de boulot qu'avant ?

Exemple:

You need the userspace code to set up the bus and its policy and handle
activation. That's not a trivial task. For us, that's what sytemd does
in PID 1. You'd need to come up with an alternative for that.

Lennart Poettering

Note aux altercomprenants qui sévissent dans le coin. Je ne dis pas (je précise : je ne sous-entend même pas) que les devs systemd sont obligés de faire ce qu’on dit parce qu’ils sont nos esclaves (oui, aussi bizarre que ça puisse paraître, il faut préciser ça si on veut pas se faire traiter d’esclavagiste). Tout ce que je dis, c’est que l’assertion « le mouvement dans l’écosystème Linux initié par systemd impose plus de boulot aux développeurs de solutions alternatives » est un fait admis par Lennart lui-même, ce n’est pas une lubie des anti-systemd. D’ailleurs, ceux qui ont un peu de mémoire se souviendront que ça a même été un argument utilisé par Lennart lors du débat systemd/upstart chez Debian : avec tous les changements à venir (chamboulement des cgroups, intégration kdbus/wayland, changements udev…), upstart va avoir beaucoup de difficultés à tenir le rythme :

Anyway, summary is: I wish them good luck, they are now going their own way, stuck in a legacy stack with little new engineering, becoming an island of their own. In the short time frame they might save money with this decision, in the long run this is going to be quite expensive for them, since as our stacks start to diverge more and more adopting systemd later on will get more and more expensive.

Autrement dit : dans le futur, les alternatives à systemd seront forcées de suivre le rythme d’évolution imposé par systemd, et ce sera quelque chose loin d’être trivial.

Voilà : le message est clair : si on arrête pas systemd, Linux va disparaître et Red Hat avec. Il faut stopper Red Hat dans son action suicidaire, etc…

Où arrives-tu à lire ça ?

Le mec il dit :

then you may as well just surrender Linux to them

Et non pas seulement (qui pour le coup irait dans le sens de ton interprétation) :

then you may as well just surrender Linux

Le type ne dit pas que Linux va disparaître, le mec dit que Linux va être approprié par RedHat.

Et là du coup tu vas nous expliquer ce que tu pouvais faire avec sysv que tu ne peux pas faire avec systemd (niveau bidouillage)

Pourquoi est-il nécessaire de le répéter pour la 15e fois ?

La possibilité de changer un composant (par exemple /bin/init) sans avoir à chambouler tout le reste (udev, dbus,…)

Mais je les ai compris depuis le début, tu ne fais que confrimer ma compréhension.

Ou pas. Si tu m’avais compris, je ne serai pas obligé à chaque réponse de te hurler dans les oreilles « arrête de me faire dire ce que je n’ai pas dit » (en vain on dirait).

Moi par contre, je savais exactement ce que tu allais répondre (mais bon comme tu dis c’est pas difficile, c’est pas comme si tu savais faire autre chose que répéter ton discours haineux « vous êtes des esclavagistes, des cons et des ignares »)

une fois le dorure "on est méchant contre nous" enlevé.

Je n’ai jamais dit ou sous-entendu ça. Sauf si on = Zenitram bien sûr, parce qu’il faut n’avoir aucun respect pour son interlocuteur pour agir comme tu le fais avec moi (me mettre dans une case anti-systemd haineux, m’attribuer des propos que je n’ai pas en fonction de cette case, et persister alors que ton modèle est constamment à côté de la plaque).

Par contre si on = les mainteneurs des ditribs et de systemd, non.

pourquoi ne pas assumer simplement regretter que les autres ne veulent plus bosser gratos pour soit, et devoir râler parce que les gens utilisent leur liberté?

Perdu, encore une fois.

Ce que je regrette, c’est, par exemple, le choix du mainteneur de systemd-udev de rendre systemd nécessaire pour le bon fonctionnement de udev. Et histoire d’éviter un cycle de « Zenitram : en fait tu dis que … — Moi : non, pas du tout » : je ne fais que dire que je regrette et pourquoi je regrette (exactement ce qui s’est dit ici, plus précisément Zenitram: Et pour le moment, personne n'a pu avancer le moindre argument qui se tient sur pourquoi il regrette.). Je ne dit pas, je ne sous-entend pas que les devs de systemd-udev devraient faire comme j’ai décidé parce que ce sont mes esclaves.

Au final, l'écosystème essaye d'avancer malgré le conservatisme, c'est tout, rien de nouveau, ça a été toujorus comme ça dans la vie et ça le sera sans doute toujours dans le futur.

Encore perdu. Ce n’est pas du conservatisme, puisque les mêmes qui critiquent systemd parce que réduisant la bidouillabilité sont au contraire plutôt enthousiastes pour Wayland qui augmente la bidouillabilité (en simplifiant le bordel mosntre qu’est X.org).

Et personnellement, j’ai changé de système d’init avant même que tu aies la moindre idée qu’il y avait des alternatives. Autant pour le « conservatisme ». De fait, les bidouilleurs sont rarement des conservateurs.

Bon, un conseil entre nous : quand un modèle (type « les anti-systemd sont des esclavagistes en puissance ») te donne des prédictions systématiquement à côté de la plaque, c’est une bonne indication qu’il est temps d’en changer. Après tu fais ce que tu veux hein, je ne dis pas que tu es mon esclave et que tu dois faire ce que je dis (apparemment il faut préciser). Si tu refuses c’est juste par conservatisme, c’est tout.

en attendant que le bidouilleur propose autant de possibilités tout en étant bidouillable

J’attends toujours un exemple concret de ce que je peux pas faire avec uselessd.

Mais au final on parle de la même chose

Ben non, et tu le dit toi même : point de vue bidouilleur vs point de vue utilisateur.

C’est quand même impressionnant cette capacité à s’auto-contredire en deux phrases.

dont on se fout un peu

Dont tu te fous. Donc beaucoup de gens qui veulent le « l’année de Linux sur le Desktop » se foutent.

Dont les bidouilleurs comme moi ou totof2000 ou moi ne se foutent pas (bon, remarque moi je m’en fous un peu aujourd’hui en pratique. Mais la bidouillabilité de Linux, c’est ce qui m’a initié à l’informatique, et oui, ça me fait un pincement au cœur de le voir disparaître au nom de « le clipping au démarrage de l’ordinateur ça fait so 80's »)

Le jour où tu auras compris ça, tu auras compris les anti-systemd.

Mais je ne me fais pas d’illusion : je sais exactement ce que tu vas répondre, parce que tu ne veux pas comprendre, tu veux juste troller pour passer le temps.

Creuser un trou pour le reboucher,

De quoi tu parles ? En quoi les devs de nosh, par exemple, « creusent un trou pour le reboucher » ?

Et après c’est moi qui suis insultant envers ceux qui bossent ?

Tu dis que oui c'est une preuve que les gens sont motivés, on dit que non c'est juste ne rien faire.

Faire quelque chose c’est ne rien faire. L’ignorance c’est la force, la guerre c’est la paix, la liberté c’est l’esclavage.

Moonz, qui ne fait pas de maintenance de grosse distro, a raison sur les mainteneurs de distros!

Où ai-je dit, sous-entendu, que j’avais raison sur les mainteneurs de distributions ?

Il n’y a aucune, 0, contradiction entre « les mainteneurs de distrib n’ont pas intégré initng » et « initng était largement prêt pour la prod et feature-complete (pour les features de son époque) ». Scoop : pour un tel composant de base, il y a plein d’autres axes d’analyse pertinents qui peuvent changer la réponse.

Mais bon pour Zenitram les mainteneurs des distrib sont des types complètement irrationnels qui sautent sur le dernier truc à la mode pour peu que ça apporte la moindre fonctionnalité (t’as vu, moi aussi je sais mettre des débilités dans la bouche des autres)

Ce qui a l'air de déranger, c'est que tout le monde qui bosse a décidé de migrer vers systemd

C’est pour ça que tu dis plus loin « mais non systemd est pas obligatoire il y a des distribs qui l’ont pas mis par défaut » (comme Slackware et Gentoo).

Ou alors faut croire que pour toi bosser c’est intégrer systemd et ceux qui le font pas ne font que creuser des trous pour les reboucher.

Et leur mainteneur a admit que systemd était meilleur globalement (en plus de la dure réalité que personne d'autre n'était interessé par ce logiciel, qui n'a pas su démontrer ses valeurs il faut croire, mais toi pense qu'il avait plus de qualité que systemd?), il va migrer sur systemd

Et qui a dit le contraire ici, bordel de merde ?

Je n’ai pas dit « upstart (entre autre) est meilleur que systemd ». J’ai dit « upstart est la preuve que des gens prêt à bosser sur les système d’init, ça existe ».

Quant à initng ou runit, ils sont très loin de couvrir tous les cas d'utilisation que systemd couvre car qui les utilisent ? à peu près personne.

La vache d’argument.

Des tas de logiciels qui ont une couverture fonctionnelle correcte ne sont pas utilisés hein (Opera chez les browsers a longtemps été plus fonctionnel que tout les autres navigateurs du marché, en étant incapable de décoller)

Et aucune distrib ne l’utilise par défaut ≠ personne ne l’utilise (oui, je sais, un truc de fou !)

Initng (pour ce que je connais, runit j’ai jamais testé) effectivement n’a pas la même couverture fonctionnelle que systemd : il n’a pas de gestion des cgroups par exemple. Tout simplement parce qu’à l’époque de son développement, ça n’existait pas, pas parce que c’était un proof of concept pas sérieux.

Et sinon, ça change quoi à l’argument de base qui est « il existe des mainteneurs d’init alternatifs donc oui il y a des gens qui sont prêt à bosser » ?

Euh, je le trouve justement moins rigide que SysV ou Upstart, dans le sens où je peux remplacer les options d'une unité présente dans /etc en la copiant ailleurs en étant sûr que ça marchera, plutôt que d'être obligé de modifier des scripts bash en root dans /etc/init.d/

Vous parlez pas de la même chose.

Rigidité dans le sens de totof2000, c’est la capacité de remplacer/supprimer un composant individuel (par exemple /bin/init) sans avoir à chambouler les 3/4 du reste du système.

Au fait, qui paie les dévs de udev?

RedHat, pourquoi ?

Donc si un projet Gtk devient un projet Gnome, ou si un projet Qt devient un projet KDE, on doit s'attendre à voir le même foin que pour udev dans systemd?

Figure toi que oui, ça a râlé quand Gtk a proposé de dépendre de certaines parties de Gnome.

Et ça change quoi à l’assertion que l’existence d’init alternatifs est la preuve que les gens sont prêt à bosser ?

Sinon, on voit bien que tu as pas testé tes « proofs of concept pas sérieux » pour dire ça (contrairement aux fanboys ici, je n’ai pas attendu saint Lennart pour me dire que sur l’init, il y avait une certaine marge d’amélioration possible, pour dire les choses poliment). Initng était dans un état d’avancement largement suffisant pour être mis en prod, son seul gros défaut était que hors des gros logiciels genre apache, il fallait écrire les unit soi-même. Upstart a été mis en prod dans deux distributions majeures ! Et Pardus a beau être une distribution mineure, ils ont pu remplacer entièrement le vieil init par le leur en situation réelle. À ce niveau ça va plus loin que « simple proof of concept ».

Si tu crois que tout ça est dans le PID 1, c'est que tu n'as vraiment aucune connaissance de base sur ce qu'est systemd ce qui rend ton argumentation contre lui caduque (je ne peux pas considérer comme sérieux des arguments de quelqu'un contre un truc pour lequel il ignore tout).

Lennart lui-même a dit que l’activation dbus serait dans le PID 1, dans le thread qui annonçait que udev ne fonctionnerait plus sans systemd.

Mais je suppose qu’il n’y connait rien.

À un moment il faut faire confiance aux outils que tu utilises et non vouloir tout comprendre et maîtriser car tu n'as pas le temps humainement de tenir la charge. Sinon si tu pars de ce principe là tu dois maîtriser aussi l'électronique de ta machine.

Encore une fois tu poses d’une manière binaire un problème qui ne l’est pas. Tu auras toujours une certaine complexité nécessaire, c’est entendu. La question qui nous occupe est, pour répondre en majeure partie au besoin, telle complexité est-elle nécessaire ? C’est sur cette question spécifique que je me positionne, et je répond non, en prenant comme preuve que uselessd semble répondre en grande majorité au besoin en étant plus simple.

Et encore une fois, c’est facile de me détromper : me pointer du doigt un besoin important, rempli par systemd, non rempli et non remplissable par uselessd sans le complexifier au niveau de systemd.

L'abstraction signifie que tu te dispenses de comprendre les couches inférieures pour que ça te reste simple. Quand tu programmes tu te fous bien souvent de ce que fait un objet par exemple, tu t'intéresse à l'interface.

Non, l’abstraction c’est répondre à un ensemble de problèmes différents mais structurellement semblables par une solution générique au lieu de plusieurs solutions différents.

Par exemple, « démarrer un service quand je branche une clé USB » et « démarrer un service quand je branche ma souris » peuvent s’abstraire en un « gestionnaire d’événements matériels » au lieu d’un gestionnaire de clé USB + un gestionnaire de souris USB. Ensuite, on peut remarquer qu’il y a des événements autre que matériels (comme le démarrage de la machine) et on peut abstraire ça en « gestionnaire d’événements-services ». Dans ce processus d’abstraction, rien ne t’interdit de comprendre ton gestionnaire abstrait.

Et si tu demandais aux mainteneurs des distributions leurs avis sur tes solutions plus simples et iso-fonctionnelles ? Ces gens ne sont pas masos et accepteraient volontiers quelque chose de plus simple qui répond au même besoin.

La complexité du point de vue du mainteneur d’une distrib ce n’est pas la même chose que la simplicité du point de vue d’un utilisateur, ou encore de l’upstream, ou encore du curieux qui veut comprendre comment ça marche, ou encore du bidouilleur qui veut changer quelques trucs.

Du point de vue d’une distrib, c’est toujours plus simple de suivre l’upstream, ou une grosse distrib comme RedHat, quelle que soit la complexité de la solution de l’upstream/grosse distrib derrière. Debian est plus complexe que LFS, mais si je devais faire une nouvelle distrib pour un besoin précis, c’est évidemment vers Debian que se porterait mon choix initial.

plus simple car on sait mieux coder

Qui à dit ça ?

Tu es fatiguant à force…

Je te défie de reprendre les dernières dépèches sur systemd et de préciser que uselessd fait tout pareil, vraiment.

Cgroups : check

Templates : check

Se-débarasser-des-saloperies-de-scripts-shell : check

Scripts multi-distribution : check

Bon, sinon, un truc concret que tu peux pas faire avec uselessd + anciens outils (oui, uselessd n’a pas systemd-networkd, mais network-manager/wicd/ifupdown répond très bien au besoin) ?

Toi a décidé que ceux qui se font chier à maintenir ont décidé parce qu'on leur a posé un flingue sur la tempe plutôt que de réfléchir, pourquoi ne pas imaginer que les mainteneurs (et admins) ont choisi systemd pour de bonnes raisons?

Tu es vraiment [autocensuré] de pénible à me faire dire ce que je n’ai pas dit. Je n’ai pas dit qu’ils avaient fait un mauvais choix. J’aurais probablement fait le même si j’étais le mainteneur d’une distrib majeure. uselessd est un fork maintenu par une seule personne. systemd était là avant, et a derrière lui la puissance de RedHat pour avoir la garantie d’être maintenu sur le long terme. Et c’est au final l’upstream, donc le jour où il aura été décidé que X ne fonctionnera plus sans systemd (avec X = udev aujourd’hui, kmscon depuis, devinez-quoi après-demain), ce sera prise de tête garantie pour la distrib qui choisi uselessd. Je fais juste remarquer que uselessd est une très bonne indication que la complexité introduite par systemd n’est pas strictement nécessaire pour répondre à la grosse majorité du besoin. Et je suis prêt à attendre un contre-exemple.

Mais je crois que de ta part, je peux toujours me brosser pour des arguments concrets.

En fait, le problème est le refus de voir que d'autres (et pas 0.01%) ont des besoins différents.

Apparemment toi non plus vu que tu ne sembles pas capable de me pointer un exemple concret.

Pourquoi ne suis-je pas étonné ?

ce qui est fort est d'imaginer que 0.01% d'utilisateurs ont réussi à faire plier les mainteneurs de toutes les distros à large diffusion. comme si les mainteneurs étaient de gros idiots incapable de mesurer les impacts face aux nouveautés. Et après on se fout pas de la gueule du monde? Enorme. La, c'est juste insultant envers tous les mainteneurs de distro à large diffusion.

Ma thèse : « la plupart des fonctionnalités remplies par systemd peuvent l’être d’une manière bien plus simple, cf uselessd, significativement plus simple et qui ne me semble pas manquer de beaucoup de fonctionnalités modernes apportées par systemd ».

Ma thèse selon Zenitram : « systemd n’apporte aucune fonctionnalité pour 99.9% des utilisateurs ».

Si moi j’admets avoir des problèmes avec mes acquis de maternelle (coloriage, découpage, j’ai du mal), toi c’est plutôt CP (lecture).