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.
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.
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.
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.
[^] # 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 19 février 2015 à 10:31.
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 »)
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.
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.
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.
[^] # 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’attends toujours un exemple concret de ce que je peux pas faire avec uselessd.
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 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.
[^] # 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.
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 ?
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.
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)
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 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 ».
[^] # 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é à 3.
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 » ?
[^] # 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é à 3.
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.
[^] # 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.
RedHat, pourquoi ?
Figure toi que oui, ça a râlé quand Gtk a proposé de dépendre de certaines parties de Gnome.
[^] # 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.