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.
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).
systemd répond à des problématiques qui sont apparus avec l'informatique moderne tels que la mobilité, le caractère asynchrone de pas mal de services et périphériques, etc. Des choses dont les anciens outils y répondaient parfois partiellement ou mal car nécessitant des contorsions énormes pour parvenir au résultat souhaité.
Je reprend la question que j’ai posé à Zenitram (parce que mon petit doigt me dit que j’ai plus de chance d’avoir une vraie réponse avec toi…) : uselessd est significativement plus simple que systemd ; quels besoins sont loupés par lui, et sont-ils suffisamment répandus pour justifier de ne pas faire une solution spécifique pour des besoins très spécifiques ?
Tu viens de poser la problématique à laquelle doit répondre un gestionnaire de services moderne. Et je suis assez d’accord avec ça. Bon, mais pourquoi systemd-logind, dbus activation dans le PID 1 ? Pourquoi udev intégré fortement à l’init, alors qu’on avait déjà des gestionnaires d’événements qui pouvaient gérer les événements « périphériques » sans ça ? (d’ailleurs systemd avant l’intégration d’udev le pouvait dans une certaine mesure).
J’entends bien qu’il y ait dans les Linux moderne une certaine complexité qui n’était pas là avant (je pense aux cgroups, namespaces et capabilities principalement), mais c’est loin d’être insurmontable. De fait, ce n’est généralement pas la gestion des cgroups de systemd qui est critiqué quand on critique sa complexité.
De plus tu fais une grosse erreur en pensant « à problème complexe solution complexe ». La notion d’abstraction est très puissante. Un gestionnaire d’événements répond à une problématique fonctionnelle bien plus complexe qu’un gestionnaire de services, mais n’est pas conceptuellement plus complexe (au contraire, c’est plus simple : dans le premier cas on a une définition implicite et extensive de la notion d’événement, pas dans le second cas), et n’a pas à être énormément plus complexe dans l’implémentation.
Je veux bien croire que parfois on ne puisse pas faire autrement que complexifier les choses. Simplement, étant donné les besoins auxquels sont capables de répondre les concurrents de systemd et leur complexité bien inférieure, j’ai un a priori très négatif sur la « nécessité » de cette complexité.
Si tu as la solution pour faire des choses simples, mais faites quand même (pas un "on fait aussi basique qu'avant, rien à foutre des nouvelles demandes utilisateurs"), tout le monde va être interessé par ton savoir, ta maitrise.
Quel besoin est rempli par systemd et pas par uselessd + anciens outils ? Ce besoin est-il majoritaire, i.e. est-il nécessaire de complexifier pour tout le monde pour répondre au besoin de 0.01% d’utilisateurs ?
L'informatique s'est complexifiée depuis les débuts de Linux. Pratiquement personne maitrise des projets tels que Linux ou X.org en entier, sans compter le fonctionnement des interactions de tous les composants du système et du matériel.
Parce qu’il existe des injustices, cela justifierait d’accepter encore plus d’injustices ?
Parce qu’on ne comprend pas certaines choses, cela justifierait de répandre encore plus d’ignorance ?
Désolé, mais l’existence de X n’est pas une preuve que X n’est pas un souci (ni dans l’autre sens d’ailleurs).
Pourquoi systemd serait différent ?
Il y a une différence de dynamique : systemd passe d’un système relativement simple à un système relativement complexe. Linux et X.org ne sont pas dans cette situation (X.org est même dans la situation inverse si on considère Wayland)
La situation actuelle (ou plutôt la situation "hier") ? Chaque plateforme a son système de boot, ses utilitaires, ses scripts… Tu es donc libre de galérer avec ta propre distribution.
Nope. Il y a quatre ans tous mes systèmes, Gentoo comme Arch étaient sous initng alors que ce n’était pas du tout les init par défaut. Ma Gentoo était encore plus étrange que ça en fait, c’était un mix perso de Mudur + init-ng (Mudur pour l’init, init-ng pour la gestion des services). Et je suis passé sous systemd bien avant que mes distribs l’intègrent officiellement (mais à l’époque c’était juste un init alternatif vachement sympa, pas un "system environment" qui cherche à tout contrôler).
Donc oui, avant tu pouvais remplacer assez facilement ton init.
C’est marrant mais pour les gens qui ont déjà bricolés des distribs "customs", c'est tellement bon de voir systemd arriver, unifier tout les outils, avec des features qui demandaient auparavant des jours de développement et 3 tonnes de scripts shells sur mesures
Ça sert à quoi de faire une distrib "custom" pour retomber sur exactement la même chose qu’une distrib générique ?
Ceux qui font une distrib custom c’est justement pour sortir des sentiers battus, et à ce niveau sytemd complexifie la tâche.
Mais que si! Tu demandes à ce qu'on ne change rien.
Et voilà, encore un procès d’intention.
uselessd est un changement, et aucune des critiques ici faites à systemd ne s’y applique (et est au contraire plutôt bien reçu parmi les anti-systemd). Il n’y a pas eu de levée de bouclier « bouh changement » quand Gentoo a proposé initng. Il n’y a pas eu de hurlement « Pardus c’est de la merde ils ont changé d’init » quand ils ont imposé mudur dans leur distribution. Ça n’a posé problème à personne quand upstart est passé par défaut dans Fedora et Ubuntu. Ça ne râle que sur systemd.
Zenitram en déduit que pour les anti-systemd le problème c’est le changement en soi.
C’est quand même magnifique cette capacité à s’auto-illusionner.
C’est pas la croix et la bannière sous Linux (une seule commande pour uploader le fichier qui va bien sur la partition UEFI), c’est plutôt la croix et la bannière pour savoir pourquoi l’UEFI ignore royalement ledit fichier.
C’est pas une formation Linux qu’il faut, mais une formation UEFI :)
Et pour le moment, personne n'a pu avancer le moindre argument qui se tient sur pourquoi il regrette.
Alors ça c’est fort. On explique depuis le début pourquoi on regrette cette évolution : parce qu’elle rend impossible l’écriture d’alternatives de composants individuels (il faut tout réécrire), rendant l’expérimentation plus difficile, et le nombre de choix effectifs plus réduits (parce que moins de développeurs s’embêteront à tout réecrire), choses qui ont attiré un certain nombre de personnes sous Linux. Mais selon toi on a jamais expliqué ça apparemment.
Je jette l’éponge et je te laisse dans ton monde où les anti-systemd, êtres irrationnels s’il en est, le sont sans aucune raison.
Je pense plus que ça s'est passé comme ça :
* systemd a inclus une fonctionnalité auparavant dévolu à un programme tiers ;
* les mainteneurs de ces programmes n'existaient plus ou ont abandonné le support du programme tiers car ils trouvent systemd plus attrayant.
Nope, ça s’est passé comme ça : les devs de udev et les devs de systemd sont les mêmes (le mainteneur de udev pré-systemd c’était Kay Sievers, qui est un dev sytemd) et ont décidé de fusionner les deux projets.
Donc, si je résume ta position, c’est qu’il est interdit d’exprimer le moindre regret ou la moindre critique sur l’évolution d’une situation qu’on regrette ou qu’on considère critiquable, dès lors qu’on a autre chose à faire que tout reprendre de zéro ?
Genre, ceux qui critiquent l’obsolescence programmée ont juste à la fermer, après tout « yaka » construire tes propres objets ? Ceux qui regrettent le tout électronique dans l’automobile parce qu’ils aimaient réparer eux-même, ils ont juste à la fermer parce qu’ils ont « juste » à maintenir leur propre ligne de production automobile ?
Ça explique pas mal de chose. Je pensais que tu voulais débattre, en fait depuis le début tout ce que tu dis c’est « fermez là ». Je comprend maintenant pourquoi on se comprenait pas.
Mais cela reste le choix des projets, ce n'est pas à toi ni à ta distrib de le dicter
Où ai-je dit le contraire ?
Je ne fais que 1. regretter ce choix 2. expliquer pourquoi je le regrette et en quoi je le considère regrettable ? C’est un crime ?
Et avant de nous dire « ça sert à rien » : que le premier qui n’a jamais rien critiqué me jette la première pierre. Je pense que je vais pouvoir attendre.
Je suis exactement dans la même situation que toi et Mozilla sur le sujet de H264/signature des extensions.
Je ne suis utilisateur non-développeur de Firefox (= utilisateur non-développeur de l’écosystème Linux), Firefox me convient (= l’écosystème Linux me convient), Mozilla (= les mainteneurs des distribs) font des choix qui me déplaisent, par exemple la signature des extensions ou l’interdiction de H264 (= rendre interdépendant des composants basiques qui ne l’étaient pas), j’explique pourquoi ça me semble une mauvaise idée, par exemple parce que l’extensibilité de Firefox est une de ses forces et que si on commence à limiter les extensions autant aller sous Chrome (= parce que ça nuit à la possibilité d’écrire des choix alternatifs de composants isolés, et qui si j’étais pas intéressé par cette possibilité je serais sous OSX/Windows).
Quelle est la différence entre toi et moi ? Pourquoi moi je suis un haineux anti-systemd et pas toi ? Quelle forme devrait prendre mon argumentation pour que tu la prennes autant au sérieux que tu te prends au sérieux toi-même ?
Et je vois pas, c'est quoi qui t’empêche de continuer à utiliser une distrib avec un init classique?
Rien pour l’instant. Mais quand ma nouvelle distribution n’aura pas d’autre choix que de passer à systemd, parce que les mainteneurs de ma distribution ont autre chose à faire que maintenir udev+dbus activation+logind+… rien que pour avoir une alternative à /bin/init, je fais quoi ?
Il y a comme une petite inversion des rôles… Ah oui, réagir quand quelqu'un crache, c'est cracher, faudrait la fermer et laisser cracher. Ben non.
Paille, poutre, tout ça…
« Les anti-systemd sont de grosses feignasses (= qui veulent pas bosser) esclavagistes (= qui veulent forcer les autres à bosser) » c’est pas « réagir », c’est faire un procès d’intention, et oui, je classe ça dans « haine ». Et c’est quasiment ton seul mode d’argumentation dès qu’on parle de systemd : ad-hominem, procès d’intention (pas seulement sur systemd d’ailleurs, mais bon, passons).
Et dis moi où j’ai craché sur systemd ? Je regrette la direction prise par l’écosystème linux à cause de systemd ≠ je crache sur systemd hein.
Donc oui je maintiens : ta haine des anti-systemd.
Oui, oui, on a compris : les détracteurs ne veulent pas de systemd, ne veulent pas bosser, ils veulent juste que les autres fassent ce que eux décide.
Les gens veulent bien bosser. La preuve : des init alternatifs, on en avait par paquets avant systemd.
Mais bon, je sais même pas pourquoi je continue à te répondre, puisque tu continueras à déverser ta haine des anti-systemd comme si je n’avais rien écrit.
Avant systemd : pour implémenter une alternative à /bin/init (fourni par sysvinit), j’avais à réécrire… /bin/init.
Après systemd : pour implémenter une alternative à /bin/init (fourni par systemd), j’ai à réécrire : init, la logique dbus activation, udev, logind, et ce même si je n’ai pas grand chose à reprocher à l’udev/dbus/… existant.
"Jusqu'ici j'avais rien contre systemd, mais la feature X c'en est trop, je me met en position fœtale et je migre sur BSD !!1one"
"Bouh, avant je me fichais bien de SysV ou d'Upstart, mais désormais vous me l’enlèverez uniquement lorsque je serais mort et enterré !"
Et après on va nous dire que c’est les anti-systemd qui sont agressifs, caricaturaux et sortent des arguments ridicules.
Avant on ne s’en fichait pas de la notion de choix : la preuve, les différentes alternatives à sysvinit qui étaient là quand Lennart jouait encore avec avahi (daemontools, initng, mudur pour ceux que j’avais testé), et les trillions d’alternatives sur les fonctionnalités que systemd cherche à remplacer (sur le network pour prendre un exemple: wicd, network-manager, ifupdown, netcfg…)
En tant que tel, pour que quelqu'un écrive une alternative à systemd, un second systemd doit pour l'essentiel être écrit.
Ceci est déjà un dilemme insoluble, car c'est précisément ce que les détracteurs ne veulent pas. Beaucoup des anti-systemd techniquement compétents souscrivent à des philosophies entièrement différentes, comme l'approche des daemontools ou autre chose
[…]
De ce ce point de vue, l'argument « implémenter une alternative » conduit seulement à empoisonner les débats avec l'assomption implicite que la philosophie de systemd est bonne, rendant ainsi les choses encore largement plus politiques.
Si vous voulez une alternative à systemd, proposez donc un 'system environment'.
Le truc c’est que tout le monde ne veut pas d’un "system environment". Pour reprendre l’analogie Gnome/KDE, il y en a qui sont parfaitement satisfait de leur xmonad/i3/whatever.
La véritable question, c'est déjà de se poser la question pourquoi tu doit avoir un avis sur systemd ? […] Mais pour une raison que j'ai pas pigé, tout d'un coup, tout le monde a cru bon avoir un avis sur l'init.
systemd n’est pas qu’un système d’init, c’est beaucoup plus
L’utilisateur lambda il s’en fiche effectivement, il a bien gobé Windows 95, il gobera à peu près n’importe quoi, mais c’est pas ma grand mère qui trolle sur systemd, c’est des gens un minimum intéressés par la technique. Et ce n’est pas un débat technique mais culturel.
les anti-systemd arrivent à ce que les gens n'utilisent pas systemd se foutent de leur gueule tellement les "arguments" sont ridicules.
Je te rassure: des arguments ridicules, il y en a des deux côtés.
C'est bien le prioblème des anti-ssytemd : ils n'arrivent même pas à imaginer que ce que les persones qui réagissent s'en foutent de systemd, ne l'utilsient pas, et prennen simplement ce uqe la distro donne.
Les 3/4 (en étant gentil) de tes interventions sur systemd c’est « les anti-systemd sont des réactionnaires ignares qui font que résister au changement ».
Si tu réagis comme ça comme tu t’en fous, j’aimerais pas être dans les parages quand on commence à critiquer quelque chose qui te tiens à cœur…
[^] # 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é à 7.
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 ».
[^] # 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.
[^] # 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.
Qui à dit ça ?
Tu es fatiguant à force…
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) ?
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.
[^] # 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é à 5.
Apparemment toi non plus vu que tu ne sembles pas capable de me pointer un exemple concret.
Pourquoi ne suis-je pas étonné ?
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).
[^] # 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é à 5. Dernière modification le 18 février 2015 à 13:12.
Je reprend la question que j’ai posé à Zenitram (parce que mon petit doigt me dit que j’ai plus de chance d’avoir une vraie réponse avec toi…) : uselessd est significativement plus simple que systemd ; quels besoins sont loupés par lui, et sont-ils suffisamment répandus pour justifier de ne pas faire une solution spécifique pour des besoins très spécifiques ?
Tu viens de poser la problématique à laquelle doit répondre un gestionnaire de services moderne. Et je suis assez d’accord avec ça. Bon, mais pourquoi systemd-logind, dbus activation dans le PID 1 ? Pourquoi udev intégré fortement à l’init, alors qu’on avait déjà des gestionnaires d’événements qui pouvaient gérer les événements « périphériques » sans ça ? (d’ailleurs systemd avant l’intégration d’udev le pouvait dans une certaine mesure).
J’entends bien qu’il y ait dans les Linux moderne une certaine complexité qui n’était pas là avant (je pense aux cgroups, namespaces et capabilities principalement), mais c’est loin d’être insurmontable. De fait, ce n’est généralement pas la gestion des cgroups de systemd qui est critiqué quand on critique sa complexité.
De plus tu fais une grosse erreur en pensant « à problème complexe solution complexe ». La notion d’abstraction est très puissante. Un gestionnaire d’événements répond à une problématique fonctionnelle bien plus complexe qu’un gestionnaire de services, mais n’est pas conceptuellement plus complexe (au contraire, c’est plus simple : dans le premier cas on a une définition implicite et extensive de la notion d’événement, pas dans le second cas), et n’a pas à être énormément plus complexe dans l’implémentation.
Je veux bien croire que parfois on ne puisse pas faire autrement que complexifier les choses. Simplement, étant donné les besoins auxquels sont capables de répondre les concurrents de systemd et leur complexité bien inférieure, j’ai un a priori très négatif sur la « nécessité » de cette complexité.
[^] # 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é à -1.
Quel besoin est rempli par systemd et pas par uselessd + anciens outils ? Ce besoin est-il majoritaire, i.e. est-il nécessaire de complexifier pour tout le monde pour répondre au besoin de 0.01% d’utilisateurs ?
[^] # 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é à 2.
Parce qu’il existe des injustices, cela justifierait d’accepter encore plus d’injustices ?
Parce qu’on ne comprend pas certaines choses, cela justifierait de répandre encore plus d’ignorance ?
Désolé, mais l’existence de X n’est pas une preuve que X n’est pas un souci (ni dans l’autre sens d’ailleurs).
Il y a une différence de dynamique : systemd passe d’un système relativement simple à un système relativement complexe. Linux et X.org ne sont pas dans cette situation (X.org est même dans la situation inverse si on considère Wayland)
[^] # Re: j'adore
Posté par Moonz . En réponse au journal SD-Boot, l'EFI Boot Manager & Stub Loader de systemd, arrive. Évalué à 2.
Nope. Il y a quatre ans tous mes systèmes, Gentoo comme Arch étaient sous initng alors que ce n’était pas du tout les init par défaut. Ma Gentoo était encore plus étrange que ça en fait, c’était un mix perso de Mudur + init-ng (Mudur pour l’init, init-ng pour la gestion des services). Et je suis passé sous systemd bien avant que mes distribs l’intègrent officiellement (mais à l’époque c’était juste un init alternatif vachement sympa, pas un "system environment" qui cherche à tout contrôler).
Donc oui, avant tu pouvais remplacer assez facilement ton init.
Ça sert à quoi de faire une distrib "custom" pour retomber sur exactement la même chose qu’une distrib générique ?
Ceux qui font une distrib custom c’est justement pour sortir des sentiers battus, et à ce niveau sytemd complexifie la tâche.
[^] # 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é à 5. Dernière modification le 18 février 2015 à 12:10.
Et voilà, encore un procès d’intention.
uselessd est un changement, et aucune des critiques ici faites à systemd ne s’y applique (et est au contraire plutôt bien reçu parmi les anti-systemd). Il n’y a pas eu de levée de bouclier « bouh changement » quand Gentoo a proposé initng. Il n’y a pas eu de hurlement « Pardus c’est de la merde ils ont changé d’init » quand ils ont imposé mudur dans leur distribution. Ça n’a posé problème à personne quand upstart est passé par défaut dans Fedora et Ubuntu. Ça ne râle que sur systemd.
Zenitram en déduit que pour les anti-systemd le problème c’est le changement en soi.
C’est quand même magnifique cette capacité à s’auto-illusionner.
[^] # 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é à 2.
J’ai dit ça moi ?
Non. Udev est toujours maintenu, et toujours par la même personne. Sauf qu’il l’est au sein du projet systemd au lieu d’être indépendant.
[^] # 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é à 6.
C’est pas la croix et la bannière sous Linux (une seule commande pour uploader le fichier qui va bien sur la partition UEFI), c’est plutôt la croix et la bannière pour savoir pourquoi l’UEFI ignore royalement ledit fichier.
C’est pas une formation Linux qu’il faut, mais une formation UEFI :)
[^] # 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é à 8.
Alors ça c’est fort. On explique depuis le début pourquoi on regrette cette évolution : parce qu’elle rend impossible l’écriture d’alternatives de composants individuels (il faut tout réécrire), rendant l’expérimentation plus difficile, et le nombre de choix effectifs plus réduits (parce que moins de développeurs s’embêteront à tout réecrire), choses qui ont attiré un certain nombre de personnes sous Linux. Mais selon toi on a jamais expliqué ça apparemment.
Je jette l’éponge et je te laisse dans ton monde où les anti-systemd, êtres irrationnels s’il en est, le sont sans aucune raison.
[^] # 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é à 4.
Nope, ça s’est passé comme ça : les devs de udev et les devs de systemd sont les mêmes (le mainteneur de udev pré-systemd c’était Kay Sievers, qui est un dev sytemd) et ont décidé de fusionner les deux projets.
[^] # 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é à 10.
Donc, si je résume ta position, c’est qu’il est interdit d’exprimer le moindre regret ou la moindre critique sur l’évolution d’une situation qu’on regrette ou qu’on considère critiquable, dès lors qu’on a autre chose à faire que tout reprendre de zéro ?
Genre, ceux qui critiquent l’obsolescence programmée ont juste à la fermer, après tout « yaka » construire tes propres objets ? Ceux qui regrettent le tout électronique dans l’automobile parce qu’ils aimaient réparer eux-même, ils ont juste à la fermer parce qu’ils ont « juste » à maintenir leur propre ligne de production automobile ?
Ça explique pas mal de chose. Je pensais que tu voulais débattre, en fait depuis le début tout ce que tu dis c’est « fermez là ». Je comprend maintenant pourquoi on se comprenait pas.
[^] # Re: j'adore
Posté par Moonz . En réponse au journal SD-Boot, l'EFI Boot Manager & Stub Loader de systemd, arrive. Évalué à 4.
Où ai-je dit le contraire ?
Je ne fais que 1. regretter ce choix 2. expliquer pourquoi je le regrette et en quoi je le considère regrettable ? C’est un crime ?
Et avant de nous dire « ça sert à rien » : que le premier qui n’a jamais rien critiqué me jette la première pierre. Je pense que je vais pouvoir attendre.
[^] # 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.
Je suis exactement dans la même situation que toi et Mozilla sur le sujet de H264/signature des extensions.
Je ne suis utilisateur non-développeur de Firefox (= utilisateur non-développeur de l’écosystème Linux), Firefox me convient (= l’écosystème Linux me convient), Mozilla (= les mainteneurs des distribs) font des choix qui me déplaisent, par exemple la signature des extensions ou l’interdiction de H264 (= rendre interdépendant des composants basiques qui ne l’étaient pas), j’explique pourquoi ça me semble une mauvaise idée, par exemple parce que l’extensibilité de Firefox est une de ses forces et que si on commence à limiter les extensions autant aller sous Chrome (= parce que ça nuit à la possibilité d’écrire des choix alternatifs de composants isolés, et qui si j’étais pas intéressé par cette possibilité je serais sous OSX/Windows).
Quelle est la différence entre toi et moi ? Pourquoi moi je suis un haineux anti-systemd et pas toi ? Quelle forme devrait prendre mon argumentation pour que tu la prennes autant au sérieux que tu te prends au sérieux toi-même ?
[^] # Re: j'adore
Posté par Moonz . En réponse au journal SD-Boot, l'EFI Boot Manager & Stub Loader de systemd, arrive. Évalué à 2.
Rien pour l’instant. Mais quand ma nouvelle distribution n’aura pas d’autre choix que de passer à systemd, parce que les mainteneurs de ma distribution ont autre chose à faire que maintenir udev+dbus activation+logind+… rien que pour avoir une alternative à /bin/init, je fais quoi ?
[^] # 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é à 10.
« Les anti-systemd sont de grosses feignasses (= qui veulent pas bosser) esclavagistes (= qui veulent forcer les autres à bosser) » c’est pas « réagir », c’est faire un procès d’intention, et oui, je classe ça dans « haine ». Et c’est quasiment ton seul mode d’argumentation dès qu’on parle de systemd : ad-hominem, procès d’intention (pas seulement sur systemd d’ailleurs, mais bon, passons).
Et dis moi où j’ai craché sur systemd ? Je regrette la direction prise par l’écosystème linux à cause de systemd ≠ je crache sur systemd hein.
Donc oui je maintiens : ta haine des anti-systemd.
[^] # 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é à 6.
Les gens veulent bien bosser. La preuve : des init alternatifs, on en avait par paquets avant systemd.
Mais bon, je sais même pas pourquoi je continue à te répondre, puisque tu continueras à déverser ta haine des anti-systemd comme si je n’avais rien écrit.
[^] # 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é à -2.
Avant systemd : pour implémenter une alternative à /bin/init (fourni par sysvinit), j’avais à réécrire… /bin/init.
Après systemd : pour implémenter une alternative à /bin/init (fourni par systemd), j’ai à réécrire : init, la logique dbus activation, udev, logind, et ce même si je n’ai pas grand chose à reprocher à l’udev/dbus/… existant.
[^] # Re: j'adore
Posté par Moonz . En réponse au journal SD-Boot, l'EFI Boot Manager & Stub Loader de systemd, arrive. Évalué à 3. Dernière modification le 18 février 2015 à 10:06.
Et après on va nous dire que c’est les anti-systemd qui sont agressifs, caricaturaux et sortent des arguments ridicules.
Avant on ne s’en fichait pas de la notion de choix : la preuve, les différentes alternatives à sysvinit qui étaient là quand Lennart jouait encore avec avahi (daemontools, initng, mudur pour ceux que j’avais testé), et les trillions d’alternatives sur les fonctionnalités que systemd cherche à remplacer (sur le network pour prendre un exemple: wicd, network-manager, ifupdown, netcfg…)
[^] # 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é à 6.
https://linuxfr.org/news/pourquoi-les-zelateurs-et-detracteurs-de-systemd-ne-s-entendront-jamais#%C3%89crire-une-alternative
[^] # 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é à 8.
Le truc c’est que tout le monde ne veut pas d’un "system environment". Pour reprendre l’analogie Gnome/KDE, il y en a qui sont parfaitement satisfait de leur xmonad/i3/whatever.
[^] # Re: Ahh linuxfr
Posté par Moonz . En réponse à la dépêche Devuan un fork de Debian qui va (peut-être) chambouler notre petit monde. Évalué à 3.
systemd n’est pas qu’un système d’init, c’est beaucoup plus
L’utilisateur lambda il s’en fiche effectivement, il a bien gobé Windows 95, il gobera à peu près n’importe quoi, mais c’est pas ma grand mère qui trolle sur systemd, c’est des gens un minimum intéressés par la technique. Et ce n’est pas un débat technique mais culturel.
[^] # Re: Ahh linuxfr
Posté par Moonz . En réponse à la dépêche Devuan un fork de Debian qui va (peut-être) chambouler notre petit monde. Évalué à 10.
Je te rassure: des arguments ridicules, il y en a des deux côtés.
Les 3/4 (en étant gentil) de tes interventions sur systemd c’est « les anti-systemd sont des réactionnaires ignares qui font que résister au changement ».
Si tu réagis comme ça comme tu t’en fous, j’aimerais pas être dans les parages quand on commence à critiquer quelque chose qui te tiens à cœur…