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.
[^] # Re: Du bon et du mauvais
Posté par Moonz . En réponse au journal SD-Boot, l'EFI Boot Manager & Stub Loader de systemd, arrive. Évalué à 9.
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.
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.
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.
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.