[Systemd] Question à propos de SystemD vs OpenRC

[d2_racing]

Salut tout le monde, depuis que j'ai vu sur la mailing list de Gentoo-dev, plusieurs sujets à propos de SystemD et à propos de OpenRC qui serait en développement chez FreeBSD,Debian et le démarrage du projet Mdev j'ai plusieurs questions qui sont malheureusement sans réponse.

Voici mes questions :

1. Est-ce que quelqu'un pourrait me dire pourquoi les bureaux Gnome/KDE et Xfce ajoutent des dépendances à SystemD à tout prix ?
Je sais que SystemD a mergé le code de Udev, mais pourquoi forcer tous les utilisateurs à utiliser ce projet ?

2. Qu'est-ce qui va devenir de OpenRC dans tout ça, est-ce qu'on va devoir migrer notre Gentoo vers SystemD sous prétexte de vouloir utiliser Gnome/KDe et Xfce ?

3. Pourquoi tout d'un coup OpenRC est porté chez les BSD et Debian ?

4. Est-ce que OpenRC pourrait exister sur une Gentoo malgré les dépendances à Systemd ? Genre à l'intérieur du code de OpenRC, celui-ci pourrait appeler les API de SystemD/Udev et faire comme si on était sur SystemD ?

5. Est-ce que le projet Mdev serait une réponse aux devs de SystemD/Udev pour leur montrer qu'on peut avoir des fonctions de base sans passer par leur bidule ?


Bref, si quelqu'un a des réponses, j'aimerais bien savoir ce qui en est de tout ça

Merci !

[kwenspc]

1. Est-ce que quelqu'un pourrait me dire pourquoi les bureaux Gnome/KDE et Xfce ajoutent des dépendances à SystemD à tout prix ?
Je sais que SystemD a mergé le code de Udev, mais pourquoi forcer tous les utilisateurs à utiliser ce projet ?

Tu es sûr que c'est des dépendances fortes? Il me semble avoir lu que certaines distro avaient des dépendances fortes, mais parce qu'elles en faisaient spécifiquement le choix (en appliquant tel ou tel patch, en forcant la dépendance dans leur paquets etc...)

J'utilise pas systemd hein, mais t'es sûr aussi qu'ils ont bouffé udev? Si c'est le cas ça ressemble encore à un truc qui veut tout centraliser, et au final être tout bloated.

Sinon pour le reste c'est politique. Par exemple lenhart poettering aurait jamais pu pousser pour _aucun_ de ses projets aussi facilement si il n'avait pas le poste qu'il a chez RH.
Je ne dis pas ça pour dévaluer son travail, mais apporter un nouveau projets finit à 30%, tout buggé, et le voir quand même être accepté quasi partout très rapidement (et pour le coup: finit et stabilisé, merci la communauté), ça n'arrive plus de nos jours sans influence fortes. Et c'est pareil pour pas mal d'autres projets/boites. Une grosse guerre d'influence, d'ego etc... on dirait pas comme ça, en surface.

2. Qu'est-ce qui va devenir de OpenRC dans tout ça, est-ce qu'on va devoir migrer notre Gentoo vers SystemD sous prétexte de vouloir utiliser Gnome/KDe et Xfce ?

En principe non, cf question 1 sur les dépendances.

Bon après je m'en fiche j'utilise pas de DM.

3. Pourquoi tout d'un coup OpenRC est porté chez les BSD et Debian ?

OpenRC était dès le départ prévu pour être cross-platform (il pouvait tourner sur FreeBSD il me semble), c'est pas centré sur Gentoo uniquement donc rien de surprenant.

4. Est-ce que OpenRC pourrait exister sur une Gentoo malgré les dépendances à Systemd ? Genre à l'intérieur du code de OpenRC, celui-ci pourrait appeler les API de SystemD/Udev et faire comme si on était sur SystemD ?

cf question 1 sur les dépendances.

Franchement je doute qu'on en arrive là. Ça serait hyper moche.

5. Est-ce que le projet Mdev serait une réponse aux devs de SystemD/Udev pour leur montrer qu'on peut avoir des fonctions de base sans passer par leur bidule ?

Je connaissais pas, ça y ressemble oui.

[guilc]

http://thread.gmane.org/gmane.linux.gentoo.devel/79186

Comment tu t'es fait griller

[d2_racing]

Je suis bien content de voir que quelqu'un a répondu sur la liste aussi.

J'étais certain que ça l'allait passer comme dans du beurre, genre aucune réponse comme ça arrive sur la dev-list.

[guilc]

Héhé. Bah en même temps c'est le sujet chaud de ces derniers temps, donc y a du monde pour réagir dessus

Mais je te rassure, systemd n'est pas le seul bloatware que nous ramène redhat. On va aussi avoir droit aux logs XML. Certains ont décrété que syslog devait mourir. https://fedorahosted.org/lumberjack/

[d2_racing]

J'ai trouvé des projets en cours à propos de SystemD sur les mailing list de KDE,Gnome(bien sûr) et XFCE.

Il va rester les *box(Openbox,Fluxbox...etc...) et les autres qui devraient fonctionner out of the box avec Mdev.

On verra pour les bureaux si ceux-ci peuvent fonctionner normalement avec Mdev malgré tout.

[guilc]

Cette tendance à l'intégration verticale sous linux pose aussi pas mal de soucis aux autres unix. Chez BSD, ça commence visiblement à les inquiéter.
Déja les derniers drivers opensource ne fonctionnent plus que sous FreeBSD qui a fait un port de KMS. Les autres BSD l'ont dans l'os (ex OpenBSD qui n'a plus la possibilité d'utiliser les derniers driver à jour depuis qu'ils retirent la version UMS, qui a par exemple disparue des drivers intel, n'a jamais existé avec nouveau).

Maintenant, les BSD vont devoir faire une croix sur les DM s'appuyant sur systemd, linuxocentré... De toute façon, lennart poettering a décrété que BSD était mort (http://bsd.slashdot.org/story/11/07/16/ ... nt-anymore), donc ça l'empêchera pas de dormir. Mais mine de rien, c'est en train de faire exploser les unix... Je trouve que ça pue vraiment, et que RedHat à pousser ces projets joue le fossoyeur des Unix...

[GentooUser@Clubic]

J'ai Gnome d’installé en ~x86 et je n'ai pas systemd en dépendance (sauf si j'active l'useflag), normal docteur ?

Faut arrêter de psychoter, Gnome communique avec systemd via des appels dbus, rien n'empêche les *BSD et Linux qui ne veulent pas l'utiliser d'implémenter des backends compatibles pour gérer ces appels.

Systemd un bloatware ? Non il est correctement spécifié : Il lance des processus en réponse à des évènements (démarrage, horaire, évènements réseau, appel dbus...) et gère le suivi de leur état.
Je l'ai testé et comparé avec un système d'init sysV classique il est beaucoup plus rapide et encourage les bonnes pratiques en imposant l'usage de helpers externe plutôt que de mettre du code bash à la gruik dans /etc/init.d.

Je suis revenu à OpenRC car plus facile à maintenir au quotidien, systemd n'était pas encore très intégré à Gentoo.

On assiste surtout à un refus d'évoluer classique: Oh My God l'init n’est plus géré par une collection de scripts en shell, c’est la fin du monde

[truc]

J'ai pas lu[encore hein? pas taper...] le fil sur la ML, mais pour les dépendances il me semble que c'est dans l'autre sens, style, systemd qui va avoir une dépendence sur gnome. J'comprends pas trop non plus comment on en arrive encore à avoir des idées... hum... aussi surprenantes:)


Sinon, le trip avec mdev, c'est lié au fait qu'udev exige maintenant d'avoir /usr accessible au démarrage, et que donc, pour avoir un /usr séparé il faut avoir un initramfs(c'est aussi un sujet sanglant, donc simple pour trouver des infos plus précise à ce sujet). Ce changement dans udev est fermement défendu par le fameux lennart.


Ceci étant dit, y'a pas mal d'idées qui semblent bien dans systemd, (au hasard, le délire avec la "réservation" des sockets avant que le service ne soit vraiment lancé, le système de log, et enfin, cet item me tient à coeur, le fait d'abandonner les init scripts qui font tout à la place de l'admin (vérifier les droits, créer les fichiers/répertoires kivonbien,bref, v'voyez l'idée...))

EDIT: les logs XML, j'dis OHÉFOR non, mais pourquoi pas dans un format binaire avec des outils _simples_ de conversion (je crois avoir entendu que les logs d'haproxy suivent ce principe mais je me trompe peut-être?)

[guilc]

J'ai Gnome d’installé en ~x86 et je n'ai pas systemd en dépendance (sauf si j'active l'useflag), normal docteur ?

Faut arrêter de psychoter, Gnome communique avec systemd via des appels dbus, rien n'empêche les *BSD et Linux qui ne veulent pas l'utiliser d'implémenter des backends compatibles pour gérer ces appels.

Pour l'instant.

Systemd un bloatware ? Non il est correctement spécifié : Il lance des processus en réponse à des évènements (démarrage, horaire, évènements réseau, appel dbus...) et gère le suivi de leur état.
Je l'ai testé et comparé avec un système d'init sysV classique il est beaucoup plus rapide et encourage les bonnes pratiques en imposant l'usage de helpers externe plutôt que de mettre du code bash à la gruik dans /etc/init.d.

C'est un bloatware dans le sens ou pour un serveur, il a tout un tas de prérequis issus du desktop, et impose d'installer sur les serveurs tout un tas de saletés inutiles, qui multiplient les sources de bug, et font perdre la maitrise du système à l'admin-sys en rajoutant 40 couches d'abstraction. Un démon c'est simple. La gestion à travers 40 bus de communications de ce même démon, c'est du bloat. les "helpers" dans tous les sens justement, c'est la plaie sur un serveur. Et pour l'embarqué j'en parle même pas...
Le devs de systemd pensent et vivent DESKTOP sous LINUX. Et ils n'ont strictement rien à faire des serveurs, encore pire des BSD. Et ils sont en train de péter le KISS de linux qui fait que c'est du bon pour les serveurs pour en faire des espèces de boites noires à la windows, sous prétexte que ça permet de mettre du kikoolol dans gnome...

On assiste surtout à un refus d'évoluer classique: Oh My God l'init n’est plus géré par une collection de scripts en shell, c’est la fin du monde

Non, un refus d'une évolution qui casse des choses "qui marchent ©" et qui sont simples sous prétexte de faire évoluer une utilisation minoritaire de linux (parceque sisi, le desktop sous linux, c'est minoritaire)

[EDIT]
Attention : je ne nie pas qu'il y a des bonnes idées pour le Desktop (l'intégration verticale qui peut permettre de faire des choses sympa au niveau du réseau en roaming par exemple). Mais ce que je reproche très sérieusement à ce projet, c'est un très fort manque de vision d'ensemble sur l'écosystème UNIX, et de se focaliser sur ce qui une utilisation extrêmement minoritaire, et en plus de l'imposer à tout le monde de manière violente et non-concertée (parce que c'est un projet redhat qui ne touche pas que redhat, loin de là...).

[DuF]

Je vais faire court car sinon j'ai peur d'échapper des propos trop méchant.

Personnellement je m'en fou que techniquement ça soit bien spécifié ou que ça aille dans le sens de l'état de l'art mais je constate que globalement ses 2 projets majeurs (PulseAudio et SystemD) sont merdiques. Je précise juste que dans mon activité professionnelle j'utilise quotidiennement des RHEL, SLES, OpenBSD et Debian et que personnellement j'utilise Ubuntu (parents, compagne), Debian et Gentoo. Pourquoi je dis ça, car ces 2 projets n'ont absolument pas répondus aux promesses auxquels ils prétendaient et ont cassé ce qui faisait le liant entre le monde BSD et Linux. Pour moi (j'insiste sur le fait que ce n'est que mon opinion), c'est pas parce qu'on a une idée de génie qu'il faille mépriser ceux qui gravitent timidement à côté. Avec ce même type de comportement, c'est Linux qui aurait pu passer à la trappe. Cette mentalité m'exaspère et me débecte.

En même temps c'est un peu tôt, pour l'instant le mal n'est pas fait, mais je partage l'avis de beaucoup, je ne suis pas persuadé que l'interpendance Gnome/SystemD n'arrivera pas plus tôt que prévu.

Y a pas besoin de psychoter ou de refus d'évoluer, surtout que la majorité des personnes ici passent leur temps à évoluer depuis des années (depuis 2002 sous Gentoo pour ma part). Mais quand des choix merdiques sont faits, tout le monde a le droit de le dire même les utilisateurs qui n'ont pas de solutions.

[DuF]

C'est un bloatware dans le sens ou pour un serveur, il a tout un tas de prérequis issus du desktop, et impose d'installer sur les serveurs tout un tas de saletés inutiles, qui multiplient les sources de bug, et font perdre la maitrise du système à l'admin-sys en rajoutant 40 couches d'abstraction. Un démon c'est simple. La gestion à travers 40 bus de communications de ce même démon, c'est du bloat. les "helpers" dans tous les sens justement, c'est la plaie sur un serveur. Et pour l'embarqué j'en parle même pas...
Le devs de systemd pensent et vivent DESKTOP sous LINUX. Et ils n'ont strictement rien à faire des serveurs, encore pire des BSD. Et ils sont en train de péter le KISS de linux qui fait que c'est du bon pour les serveurs pour en faire des espèces de boites noires à la windows, sous prétexte que ça permet de mettre du kikoolol dans gnome...

MERCI !!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Voilà exactement ce que j'aurai aimé dire, mais bon la rhétorique et moi ça fait 2....

Le jour où j'ai un serveur avec SystemD, je déterrerai ce topic à la pelleteuse et viendrais vous réveiller et faire mon vieux con en prononçant : "Vous ne pourrez pas dire qu'on ne vous avait pas prévenu !"

[guilc]

Pour rajouter des éléments, il y a aussi ce mail, d'un dev debian : http://lists.debian.org/debian-devel/20 ... 00269.html
Enfin, my bad, je fais un peu dériver le sujet là, sorry

[GentooUser@Clubic]

Pour l'instant.

La seule dépendance de Gnome à systemd dont j'ai entendu parler c'est le réglage du fuseau horaire. Et encore c’est même pas vrai, Gnome utilise juste un appel dbus normalisé par freedesktop, mais proposé uniquement par systemd.

C'est un bloatware dans le sens ou pour un serveur, il a tout un tas de prérequis issus du desktop, et impose d'installer sur les serveurs tout un tas de saletés inutiles, qui multiplient les sources de bug

Très franchement à pars dbus je ne trouve pas dans l'arbre de dépendances de systemd grand chose qui ne soit pas déjà dans une install server classique.
Pour vous faire une idée:

Code: Select all

vi /usr/portage/sys-apps/systemd/systemd-186.ebuild /usr/portage/sys-apps/dbus/dbus-1.6.4.ebuild

les "helpers" dans tous les sens justement, c'est la plaie sur un serveur.

Très franchement tu préfère que les capacités astronomiques de /etc/fstab soit gérées par mount -a (un helper) ou un /etc/init.d/mount en shell ? Parce que les helpers de systemd vont dans ce sens : virer des scripts d'init des taches lourdes qui n'ont jamais eu rien à y faire.

Pour rajouter des éléments, il y a aussi ce mail, d'un dev debian : http://lists.debian.org/debian-devel/20 ... 00269.html
Enfin, my bad, je fais un peu dériver le sujet là, sorry

Debian n'a jamais voulu intégrer un vrai système d'init (à la OpenRC ou Upstart) à leurs distribution, leur système de boot se limite à une collection de scripts hétéroclites sans consistance et sans aucune interface de gestion. Il n'ont pas évolués depuis les années pré SystemV c'est pas systemd qui va leur faire changer d'avis. Et c'est à cause de ce système d'init que je vomi Debian, chacun ses goûts.

SystemD et DBus pas pour les serveurs ? Maintenant qu'il va débarquer sur RHEL j'entrevoit au contraire pleins de possibilités

[DuF]

Au contraire, je trouve que les scripts shell sont une vraie puissance et permettent avec facilité de corriger un problème. Sur un serveur on s'en fou que ça boot en 20s de plus, l'important c'est que ça tienne la route longtemps. J'imagine bien demain les admins qui devront faire du C pour corriger un problème d'init... Le shell, n'importe quel admin pourra bosser avec, c'est facile à lire, cela permet de comprendre ce qui se passe. Et en général quand il faut corriger quelque chose il faut aller vite, avec du shell c'est facile.

Toute façon le mec est tout sauf crédible et ne comprend rien à l'aspect serveur des choses, suffit de lire ça : http://0pointer.de/blog/projects/systemd.html

(...)And even SSH: as long as nobody wants to contact your machine there is no need to run it, as long as it is then started on the first connection. (And admit it, on most machines where sshd might be listening somebody connects to it only every other month or so.)

On voit bien que le mec est dans le vrai pour tout ce qui est desktop (les exemples qu'il donne juste avant pour le bluetooth, l'imprimante sont tout ce qu'il y a de plus juste) mais sur SSH, il est à côté de la plaque.

SystemD c'est sans doute très bien pour le grand public, mais il devrait proposer sa révolution chez Apple, il serait pil dans le coeur de cible.

Toute façon ça a le temps d'arriver (et de repartir), là où je bosse on migre de RHEL 5.2 à 5.6

[truc]

d'accord pour le shell, mais pas d'accord sur la complexité des initscripts qui se veulent parés à toute épreuve. Les exemples qui "m'ennervent" un peu sont ceux qui par exemple vont vérifier la syntaxe de la conf du dit service et s'arrêter à la place de laisser le service s'en occuper, ceux qui initialisent des choses qui auraient dû être initialisées par l'admin etc...

Tout ce que ces initscripts font, à mon avis, ce n'est que permettre à n'importe qui de lancer n'importe quoi (...) sans avoir lu _un minimum_ la doc, résultat: quand ça n'marche pas y'a plus personne...

Quelques exemples concrets qui me viennent à l'esprit: les initscripts de squid qui vont voir où se trouve le cache, vont les initialiser au besoin et autres joyeusetés, la vérification de syntaxe de ceux de dnsmasq (qui cache le message prévus par dnsmasq et t'affiche un message générique IIRC)...

Cette complexité est parfois bloquante pour d'autres choses(je n'ai plus d'exemple en tête, mais ça m'a déjà "ennuyé"...

La plupart des "démons" se démarre avec une bête ligne de commande. Je ne suis pas contre la mise en place d'un chroot, de limites en tout genre, mais y'en a marre des scripts qui se veulent trop génériques

Pour les besoins spéciaux, à mon avis, il faut "devoir" revenir au shell script et point final. KISS quoi!

[DuF]

Là dessus je suis d'accord et encore une fois, même si c'est un peu radical comme discours, j'ai pas vraiment de grief contre systemd pour le desktop ou tout autre terminal grand public, au contraire même.

Après pour le bordel potentiel des scripts d'init, ça j'ai envie de dire c'est avant tout un problème humain (de moyens ou de compétences).

Je pense que si le mec avait pris en compte quelques remarques (pourtant pas nombreuses) sur l'aspect serveur des choses voir, imaginons un mode serveur, ce serait bien !

[El_Goretto]

Perso, je suis d'accord avec tout ce qui s'est dit ici.
Je me suis fait une idée plus précise sur le personnage le jour où j'ai lu en détails la page de son projet sur un remplaçant pour syslog. Si si, ya de super moment "OMG OMG", qui font que ce type est dangereux dans le registre "fausses bonnes idées". Après, il a de l'énergie et des soutiens, c'est dommage qu'il n'y ait pas quelqu'un pour le canaliser ce brave homme.

[j'ai supprimé un paquet de texte, je radote ce que vous avez déjà dit de toute façon]

[guilc]

Bon, là je trolle, on n'est pas vendredi, mais c'est trop bon : Debian dégage Gnome par défaut pour le remplacer par... XFCE : http://www.phoronix.com/scan.php?page=n ... px=MTE1NTk
Et je cite : "There may be other reasons to prefer xfce as the default as well, but that is a complex and subjective topic. Unfortunatly, Debian does not have a well-defined procedure for making such choices, though it certianly has well-defined procedures for reviewing them. So, I've decided to be bold, and continue the tradition of making an arbitrary desktop selection for Debian in tasksel."

Lire entre les lignes : on dégage parcequ'on veut pas de systemd ?

[truc]

Lire entre les lignes : on dégage parcequ'on veut pas de systemd ?

hehe, on n'est toujours pas vendredi, mais j'avoue que c'est pas mal:)

C'est certainement une des bonnes raisons qui ont motivé ce changement, d'autant plus que debian/BSD est maintenant comptée parmi les "architectures" officiellement supportées, donc maintenir une version spécifique linux et une autre BSD de leur système n'est surement aisé ni souhaitable.

[geekounet]

Pour systemd, le principe est bon, mais l'implémentation est vraiment mauvaise, on ne devrait pas laisser Lennart écrire une seule ligne de code, tout ce qu'il produit est foireux. Du dire d'autres devs sur les ML, systemd aurait pu être facilement portable s'il était correctement codé, en le faisant suffisamment modulaire pour que les autres Unix implémentent à leur sauce les bouts manquants, mais Lennart a fait exprès de rendre le code difficilement portable (il le dit noir sur blanc dans ses réponses), du fait de sa haine injustifiée des Unix non-Linux. C'est pas le seul abruti de chez RedHat en plus, Ulrich (lead dev de la glibc) en tient une bonne couche aussi, en refusant des correctifs, des optimisations, en rejettant toute critique constructive de son code pendant qu'il continue à coder n'importe comment. D'où le fork de la glibc par Debian du coup, eglibc, visant à l'intégration des patchs pour l'embarqué. Bref...

Pour OpenRC, il est porté sous FreeBSD pour le projet Gentoo/FreeBSD il me semble, mais il n'y a aucun projet d'intégration officielle dans l'OS, rc.subr fonctionne parfaitement et a encore de beaux jours devant lui.

Enfin, concernant KMS que j'ai aperçu dans un message plus haut, il est porté sous FreeBSD pour les CG Intel oui, et ça marche plutôt pas mal (bien que le kernel me sort des centaines de messages de debug), par contre ce n'est pas encore fini pour le support des Radeon, encore moins pour Nouveau... (mais le driver Nvidia proprio fonctionne nickel lui). Apparemment ça sera facilement portable sous NetBSD et DragonflyBSD, c'est prévu, mais sous OpenBSD je ne sais pas comment ça se passera, ils ont des drivers bien à leur sauce déja.

[El_Goretto]

Merci pour ces éclairages de la "scène", c'est très instructif

[xaviermiller]

Hé bien, ça a bien trollé pendant mon congé

[DuF]

Hé bien, ça a bien trollé pendant mon congé

Depuis quand des faits véridiques de la vérité vraie sont un troll !!!!!

[d2_racing]

Arch Linux fait le saut officiellement : http://www.phoronix.com/scan.php?page=n ... px=MTE2MDE

Il y a plusieurs distributions qui vont dans ce sens, j'ai hâte de voir quand Gentoo va prendre une décision à ce sujet.

Quelqu'un a essayé dernièrement SystemD avec une carte ATI qui demande le chargement d'un firmware ?