Reprise du message précédent :

Si on veut des améliorations pour du desktop: parfait améliorez les surcouches graphiques, les navigateurs de fichier, tout ce que vous voulez.
Il n'y a pas à réclamer de modifs dans le kernel pour ça ni à aller modifier le système en profondeur pour ce genre de problématique.
 

 
C'pas une référence hein  

Ah bon ?

Essayer de retenir vos trolls, j'ai essayé de faire un first post relativement documenté, ca serait bien que la discussion soit, y compris techniquement, plus intéressante que systemd c'est bien / systemd c'est mal.

Désolé je vois pas où est le troll.

 
Si, a la rigueur on donnait aucuns liens vers des sources, on pourrait dire qu'on troll, mais là ...

http://ewontfix.com/14/
 
Un avis très négatif mais plutôt bien explicité
 
je suis notamment d'accord avec la conclusion :  

 
En parlant de ça, faudrait éditer la FP :  
OpenRC date de 2006 en beta, 2007 en stable. Il est donc plus vieux que systemd. OpenRC se base sur l'init de la distribution (qu'elle soit *BSD, *nix, linux où autre). En gros quand on parle d'OpenRC dans le monde Linux, on parle du couple OpenRC/SysVinit : SysVinit reste PID1 en mode zombifié. Il utilise le mode baselayout pour la gestion des scripts (qui défini une arborescence spécifique et une organisation de /etc /var et /usr modulaire, tu peu mixer sans soucis). Sachant que baselayout 1 est un system gentooisé sans openrc et baselayout 2 un system gentooisé avec OpenRC.
Comparativement, OpenRC est meilleur en tout points a systemd, ses seuls manque majeurs sont :
-Pas d'activation socket , se qui implique pas d'autospawn et autodespawn des demons, on reste en mode init a l'ancienne quoi (who cares ? Avec udev/mdev/evdev/eudev bien configuré, tu peut spawn n'importe quoi pépère, et avec les cgroups en plus, aucuns soucis pour le suivis. C'est de la conf qui normalement devrait rester oneshot ou réservée aux admins/poweruser, par défaut ça marche au poil et pas besoin sur un profil desktop)
-Supervision des process, vue que les cgroups ont été vampirisés pendant un temps par Red Hat, ils sont tellement obscures que même pour d'autres dev c'est chiant a implémenté un truc qui fonctionne, mais vue que Linus a stoppé de commit du code red hat qui change les fonctionnalités toutes les 2 secondes dans le kernel, le dev avance a grands pas.
-Pas de gros supporter et adopter derrière et encore, c'est un point discutable, y'a pas de dev payé par une entreprise pour dev OpenRC, pas de Red hat derrière, ou de canonical.
 
On pourrait rajouter un inconvénient : la doc est plus que succinte (mais a quoi bon faire une doc quand le code et les man page sont limpides, OpenRC c'est limite le KISS dans sa plus pure tradition)
 
https://wiki.debian.org/Debate/initsystem/openrc
 
Edit seconde chose a explicité aussi :  
udev a été forké 2 fois par les dev gentoo, une première fois parce qu'ils n'avaient pas la voix sur des modifications néfaste aux environs de 2008/2009, finalement leurs commit sur leurs fork sont passés dans une version ultérieure de udev, se qui a avorté le fork. Le fork actuel est en réponse a l'intégration dans systemd et le fait que ça casse/oblige des dépendances profondes.

Dire que je me suis mangé 7 jours de TT sur une autre section pour moins que ça..
 
C'est gentil de faire la pub pour OpenRC, mais vu comment tu bashes à coté de la plaque systemd ça donne pas trop envie de "croire" ce que tu peux nous raconter par pur évangélisme à son sujet. Et ça c'est fort dommage au demeurant.
 
Autant y'a des sujets où je ne permettrai pas de remettre en causes tes connaissances et tes posts, autant la, entre grao et toi bonjour le trolling.
 
systemd n'est pas l'usine à gaz tant décriée, je l'utilise depuis des mois avec la Arch dans des scénarios différents et il apporte des solutions et de la cohérence où parfois il en manquait. Alors ouais tout le monde n'a peut être pas les mêmes contraintes / objectifs / envies mais pénible le bashing.

Merci pour les nombreux liens en première page. Je trouve celui-ci particulièrement intéressant (les commentaires évoquent également d'autres briques "système" qui suscitent des polémiques) :

Parmi les avantages potentiels de systemd: une homogénéisation des briques de base ?
 
EDIT: je ne nie pas les côtés négatifs de systemd (principalement la difficulté d'attribuer un bug au kernel plutôt qu'à systemd ou vice-versa par exemple; plus la nécessité de compiler si on veut proposer une solution de bug, entre autre)

Une bonne fois pour toute on va arrêter de dire que je trolle par ce que j'explique que l'exemple de feature qu'on me donne n'apporte rien à ce que je fais tous les jours au boulot .
C'est vraiment lourd quoi.
 

 
Je parlais de la partie sur windows

Un long article assez critique mais bien étayé et intéressant par Rob Landley, développeur Busybox et Aboriginal linux :  
 
http://www.landley.net/notes.html#23-04-2014
 

Les 2 derniers liens que tu as donné montrent bien que les réticences vis à vis de systemd sont plutôt d'ordre "philosophique" (portabilité, phagocytage) que technique: le premier (http://ewontfix.com/14/) ne cite que 3 problèmes techniques majeurs : pid 1, vulnérabilité accrue, nécessité de reboot poour upgrade systemd (comme le kernel).
 
Inversement, les avis favorables ne se basent que sur les avancées techniques (principalement exposition des fonctionnalités kernel en userspace) et occultent complètement la difficulté future de switcher vers autre chose que systemd; ça se comprend, puisque pour les personnes favorables à systemd, c'est le meilleur init...
 
C'est particulièrement visible dans le lien que tu avais donné (débat sur le wiki Debian) :
https://wiki.debian.org/Debate/initsystem/systemd
 
J'ai Fedora 20 sur mes systèmes persos, et j'avoue que je n'ai jamais cherché à trifouiller systemd, bien que ce soit une des distrib qui l'implémente le plus complètement; les différents liens (favorables) dans ce post m'ont donné l'envie de mettre les mains dans le cambouis (bien que ça fonctionne à la perfection sans toucher à rien   )
 
EDIT: un lien "pro-systemd" (on comprend vite pourquoi) que je n'ai pas vu en FP:
http://0pointer.de/blog/projects/t [...] myths.html

 
Prosélytisme et évangélisme. Je crois pas dans ce genre de religions.
PID1 : J'attend qu'un PID1 soit quelque chose d'ouvert, qu'il ne se permette pas de charger des blobs binaires sans mon avis, qu'il soit stable, plante pas pour un oui ou pour un non.
Vulnérabilité accrue : le code est truffé de mines
Nécessité de reboot : je vais de LTS en LTS par rapport a l'upstream et j'implémente mes hotpatch kernel sous forme de modules, je reboot qu'en cas de changements majeurs avec des uptime proches des 18 mois. On va me répondre que l'uptime c'est de la branlette d'admin, oui mais en attendant, ça montre que le système est stable et résilient.
 
Les avancées techniques sont présentes, ailleurs, dans d'autres systèmes, sans avoir besoin de systemd : grao l'a expliqué pour journalctl, la flemme de l'expliquer pour autre chose, et non, ça n'occulte absolument pas la difficulté, qui elle, risque carrément de tuer la philosophie de linux (multiples distro pour multiples besoins).
 
Niveau du troll : paille, poutre.
 
La front page est toujours fausse au sujet d'openrc, mkdev, eudev etc ...

Ok. Je ne vais pas débattre sur des subjectivités. Juste 2 choses :
 
1)  journalctl est compatible avec syslog (redirection possible)
 
2)

Ah! il me semblait qu'il existait déjà de multiples distros pour de multiples besoins (Android, systèmes embarqués,...) qui utilisent des systèmes d'init très differents?
 
Quant à:

Pas de ma part, toujours...

 
Effectivement puisque c'est un lien de la page officielle de systemd qui est dans la fp ;-)
 
Les avantages techniques de systemd sont pour certains intéressants (parallélisation, socket) mais quels sont les compromis en face ?
 

que veux-tu dire par "compromis"  (régression technique ou philosophie OS) ?

Je considère que le compromis sur la portabilité et la modularité est à la fois un compromis sur la philosophie et sur les aspects techniques puis qu'il contraint de façon relativement importante les évolutions.
 
Sur le plan technique, je pense qu'il y a un coté "overkill" a systemd, si il évolue vers un système modulaire dont on puisse utiliser certaines parties seulement, je pense qu'il sera populaire, sinon le risque de fragmentation me semble relativement problématique.

C'est déjà le cas il me semble; on n'est pas obligé d'utiliser toutes les briques (c'est orienté serveur/systèmes embarqués quand même).
 
Et la compatibilité sysvinit permet de choisir entre démarrage systemd ou sysvinit pour tous les composants fournissant les 2 formats; compatibilité qui ne disparaitra pas du jour au lendemain (RedHat par exemple ne se tirera pas une balle dans le pied en supprimant cette compatibilité dans les futures RHEL).
 
Non, à mon avis le gros défaut de systemd, c'est celui évoqué par beaucoup sur ce post: le risque de voir disparaître toute alternative sur les distribs majeures (Redhat-Suze/Debian-Ubuntu); et donc  d'être obligé de remettre les mains dans le cambouis si on veut se passer de systemd (avec Slack, LFS, Gentoo ou FreeBSD).
 
Edit: pour la dernière phrase, je ne parle que du côté Desktop...

LFS et CLFS proposent d'ailleurs deux modules, un en systemd , 'l'autre en sysV

Je viens de lire les interventions de MysterieuseX (que j'avais squizzé au départ parce que je trouvais le ton hyper-agressif) et il y a pas mal d'arguments qui sonnent juste: entre autre sur les problèmes de licence ( la FSF ne doit pas péricliter) et sur la possibilité pour une alternative de systemd de voir le jour (par exemple eudev/openrc + un dev sur les API D-bus).
 
Concernant les licences (GPL vs LGPL), il semblerait qu'il n'y pas de souci, donc implémentation des fonctionnalités de systemd sous eudev/openrc possible (bon le ratio de développeurs sur l'un et l'autre projet n'est pas en faveur de eudev/openrc) ?
http://lists.freedesktop.org/archi [...] 13403.html
 
D'autre part, Debian Hurd/BSD doit avoir un autre init que systemd; donc choix possible sur noyau Linux entre 2 systèmes ? (maintien de la diversité)  
 
PS : ceci-dit je maintiens que systemd est une belle pièce de logiciel  

Debian hurd je sais pas (d'ailleurs je pense qu'en micro noyaux, Minix 3 a fait plus de progrès concrets que le hurd)
 
Mais Debian/BSD il serait logique que ca bascule sur launchd dont le portage FreeBSD a repris récemment.
 
https://github.com/rtyler/openlaunchd

Pour une comparaison :  
 
Launchd (Mac Os, plus tard freebsd) : http://en.wikipedia.org/wiki/Launchd
Systemd (Linux) : http://en.wikipedia.org/wiki/Systemd
Rc.d (NetBSD) : http://www.mewburn.net/luke/talks/auug-2003/

 
Crois moi, je parle en connaissance de causes, systemd intègre du code fermé sur RHEL/Fedora, archlinux a du blobage binaire pour certains device, et les promoteurs sont pas forcément très très "open source friendly".
OpenRC est viable, il existe depuis longtemps, il est modulaire, compatible avec plein d'OSes et d'archis (toutes les archi gentoo)
eudev réinvente un peu la roue, faute de pouvoir commit dans udev et d'avoir un environnement "clean", d'ailleurs y'a des bruits de couloir au sujet d'un support prioritaire du kernel vers eudev au détriment de udev
Et l'alternative que tu cite existe déjà, puisque c'est environs 70% des utilisateurs gentoo (les autres veulent gnome "natif" )
OpenRC peut tourner sans *dev et sans *kit, il supporte pleinement les architectures modulaires X.org etc ... Et en plus, le code est beau  

 
ça n'arrivera pas sur "mes" serveurs. devoir rebooter parce qu'on a updaté un composant userland ? Faut atterrir là.  
Vous je sais pas, mais ici les contraintes de dispo c'est 24/7 365j par an....
 
et si ce seul programme par en vrille il emporte tout ? l'init actuel ne fait "rien" et je ne l'ai *jamais* vu planter.
les logs binaires et les since/until c'est mignon mais c'est cosmétique.. une vraie feature c'est une indexation de logs correcte, pas un truc bidouillé dans un coin. Les protocoles binaires, en soit c'est mal. Je veux pouvoir debugger et vérifier mon traffic avec tcpdump en live quand un pain arrive...  
 
Bref, reste les fanboys et leurs drapeaux qui font du bruit. seul et dernier post pour moi sur le sujet, de toute façon.
 
Bisous

1 jour d'avance  
 

Puisque c'est vendredi, j'ai retrouvé une longue et très bonne interview des devs français d'OpenBSD réalisée par linuxfr.org
 
http://linuxfr.org/news/entretien- [...] d-partie-1
 
et ca cause de systemd
 
LinuxFr.org : Le sujet polémique du moment c'est la question de la compatibilité multi-OS des développements. Entre les protestations d'Xfce au sujet des technologies compatibles seulement avec Linux (udev) et les propositions de Lennart Poettering de rendre GNOME dépendant du noyau Linux (systemd) il semble que nous traversions une période de crise. Quel est ton sentiment à ce sujet ?
 

Ca a presque 3 ans le truc de Linuxfr quand même. Le dernier article venant d'un dev *BSD (je sais plus si c'est Net ou Open, je crois que c'est Open) sur Linuxfr qui s'est lis à basher systemd c'est totalement fait démonté dans les commentaires à l'époque... D'un autre coté, il a fini par avouer ne pas l'utiliser. Donc on en revient à des querelles limite idéologiques pour des queues de cerises.
 
 
MisterieuseX: où ce trouve donc les blobs binaires dans https://www.archlinux.org/packages/ [...] emd/files/ au fait pour ma culture personnelle ?
 
Blacklord: tu avais un jour d'avance, parce que quasiment tout ce que tu as dit est quasiment faux ou à coté de la plaque. J'imagine bien RH mettre à terme dans leur RH Linux à support payant un truc totalement foireux et non stable, super réaliste.

depmod-install te charge des libs /usr/lib binaire dans le kernell sans demander l'avis de l'utilisateur, entre autres.
 
usr/lib/udev/hwdb.d/
usr/lib/udev/hwdb.d/20-OUI.hwdb
usr/lib/udev/hwdb.d/20-acpi-vendor.hwdb
usr/lib/udev/hwdb.d/20-bluetooth-vendor-product.hwdb
usr/lib/udev/hwdb.d/20-net-ifname.hwdb
usr/lib/udev/hwdb.d/20-pci-classes.hwdb
usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb
usr/lib/udev/hwdb.d/20-sdio-classes.hwdb
usr/lib/udev/hwdb.d/20-sdio-vendor-model.hwdb
usr/lib/udev/hwdb.d/20-usb-classes.hwdb
usr/lib/udev/hwdb.d/20-usb-vendor-model.hwdb
usr/lib/udev/hwdb.d/60-keyboard.hwdb
 Références dans ces fichiers a des fournisseurs de matos qui utilisent des blobs binaires
usr/lib/udev/rules.d/50-firmware.rules
A modifier pour son comportement par défaut qui va charger systématiquement les firmwares souvent binaire des devices + références a des binaires sous licence red hat
 
Tout ça de manière transparente et silencieuse avec le comportement par défaut, se que les utilisateurs normaux ne savent pas forcément.

Non mais les .hwdb c'est comme http://standards.ieee.org/develop/regauth/oui/oui.txt ! D'ailleurs le 20-OUI-hwdb c'est la même chose dans un autre format, donc un peu RIEN à voir avec un blob binaire. Ça sert juste à identifier des vendors ou modèles via des "tags".
 
Et c'est pas depuis systemd que l'on charge des firmwares via udev, il me semble hein, on fait la même avec un init "oldsckool".
 
Bref, ça fait pas très sérieux.

 
Relit, avec le doigt s'il te plait.  

 
Il y a une différence pour l'utilisateur final entre choisir et imposé, c'est comme les licences pour lecture de fichier et l'affaire MP3 fraunhaufer, sauf que là, c'est a l'inverse : on charge par défaut, on réfléchit ensuite, et ce comportement est inacceptable. Surtout que les modifs en question ne sont plus triviales quand il s'agit d'aller toucher a udev, ses règles et pour certaines parties carrément son code.
Avant de troller, on relit le post et pas juste la moitié.

 
Bon, bref... Sur mes Arch !

 
Qui vient de "[systemd-devel] [PATCH 5/5] udev: make firmware loading optional and disable by default" voir http://lists.freedesktop.org/archi [...] 09708.html  
 
Je te laisses soin d'en tirer la BONNE conclusion cette fois.

 
Vérifie, et plusieurs fois, le comportement change a chaque version => régressions longuement discutées et entre autres source d'un des conflits Red Hat/Linus, je te laisse le soin également d'aller chercher les fameux "builtin" :>
En plus, sympa pour l'user la note qu'il faut pas éditer ce fichier qu'il est mis a jour par les update, génial la conf par défaut qui oblige l'utilisateur a se conformer au comportement de systemd. Et on s'étonne qu'on troll en tant qu'admin ? Mais merde on est libre de faire se qu'on veux de nos distros et on a pas a subir ce genre de comportements de la part des devs ou des mainteneurs de package.
 
De plus, si j'ai pas envie d'installer un seul des firmware listés, c'est mon problème, je maintien moi même ma liste j'ai pas envie de bloater mon init avec une database de matériel soit disant "compatibles".
A rajouter la règle sur les uevents, ou même si udev charge pas les firmware a l'init, avec un appel uevent (souvent via cgroups, bonne change pour le voir) les chargera quand même.
Bref, sur ce point, c'est totalement pas transparent, t'aura beau dire le contraire et remonter un patch de mars 2013, t'en fait pas que ça a changé depuis le temps.

Bon bah super, d'un autre coté, lorsqu'on a comme seul "arguments" des listes de vendor pour des tags d'adresses MAC comme "blobs binaires" entre autres (d'ailleurs, j'ai moi même ajouté mon ancienne boite dedans il y a 10 ans pour les OUI) et ensuite du vent (aucun lien, aucun code), je ne vais pas perdre plus de temps avec cela...  
 
Restez bien dans vos délires, j'aurais quand même trouvé bien marrant qu'un modérateur vienne troller "XXL" sur systemd (qu'il ne semble pas bien connaitre, mais pas grave hein) et que tu y viennes aussi y raconter n'importe quoi. Tu utilises la gentoo, bien à toi, ils ne passeront probablement jamais à systemd, tant mieux non ?  
 
Maintenant, il y a assez de personnes que ça soit ici ou sur lfr qui parlent de systemd sans rien n'y connaitre ou en ayant lu des articles de haters qui techniquement sont d'une vacuité absolue (comme la réflexion de certains) et c'est franchement pénible.
 
Au passage, ta liste de "matériel compatible" n'en est pas une, l'ajout de l'OUI que j'ai fait c'est fait dans le cadre de carte réseau ... avec un pilote directement dans le noyau et fait par la boite qui faisait le chip (bon je l'avais un peu modifié pour la BSD cible) pour Windows, Linux, (Free|Net|Open)BSD... Alors que tu ne veuilles pas de firmware, pourquoi pas, mais je me demande si tu vas jusqu'à exclure TOUS les pilotes dont tu ne te sers pas sur ta Gentoo.

Tu veux que je te dise quoi a ton post ? C'est du binaire d'un coté et hardcodé de l'autre, ça va être génial de te sortir les sources udev/udevd/ueventd et le loadfirmware de systemd tiens, c'est que c'est pas non plus 1 ligne de code ça hein, c'est approximativement 2/3k lignes au total.

Une page intéressante sur l'excellent site softpanorama

http://www.softpanorama.org/Commer [...] temd.shtml

petite maj du FP aussi

 
Je me suis (presque) arrêté la car ça va encore être l'opinion d'un mec qui n'y connait rien sur ce qu'il démonte... Il y a l'equivalent des runlevel, je l'utilise même souvent pour mes VM, mais bon... D'un autre coté, l'article n'est pas très récent, peut être son rédacteur a changé d'avis sur certains points (parce que la suite est franchement trollesque par moment).

214 out : http://lists.freedesktop.org/archi [...] 19925.html

Mise à jour du FP