En divisant la communauté, en méprisant tout ce qui s'écarte de sa cible immédiate (Linux+GLibc), le projet a introduit une ambiance assez malsaine alors que ça aurait pu être plus consensuel et progressif (une première étape "à la uselessd" ou "à la Pardus". Je pense que beaucoup de monde s'accordait à dire que sysvinit était très imparfait. L'approche Pardus était fort sympathique AMHA : garder init car ce n'était pas le composant qui posait problème, mais refondre l'infrastructure de scripts rc derrière... Certaines expérimentations chez IBM étaient sympathiques aussi).
Créer des dépendances fortes entre composants est selon moi préjudiciable sur le long terme. Le souci de portabilité ne concerne pas que les BSD => un exemple qui m'agace : musl-libc semble très prometteuse, et certaines distributions comme Alpine l'ont déjà adopté. Mais systemd ne marche qu'avec la glibc et Lennard a clairement dit qu'il refusait de résoudre le problème ("we will rely on good APIs exposed in the generally accepted Linux API which is the one glibc exposes". Dit autrement: l'API de référence est pour lui la glibc avec toutes ses extensions et GNUisms et non juste POSIX, les autres libc n'ont qu'à réimplémenter le bloat...). Or pour autre chose que de l'embarqué (au hasard, pour une machine desktop avec Gnome), les dépendances élargies du type Gnome->systemd->glibc compliquent le passage à autre chose que systemd et par voie de conséquence empêchent durablement toute distro majeure de proposer autre chose que la glibc. La compatibilité avec musl et uclibc est pour moi un argument majeur pour toutes les alternatives à systemd — notamment uselessd !
[^] # Re: Fonctionnalités clées.
Posté par karteum59 (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 10. Dernière modification le 01 décembre 2014 à 02:32.
En divisant la communauté, en méprisant tout ce qui s'écarte de sa cible immédiate (Linux+GLibc), le projet a introduit une ambiance assez malsaine alors que ça aurait pu être plus consensuel et progressif (une première étape "à la uselessd" ou "à la Pardus". Je pense que beaucoup de monde s'accordait à dire que sysvinit était très imparfait. L'approche Pardus était fort sympathique AMHA : garder init car ce n'était pas le composant qui posait problème, mais refondre l'infrastructure de scripts rc derrière... Certaines expérimentations chez IBM étaient sympathiques aussi).
Créer des dépendances fortes entre composants est selon moi préjudiciable sur le long terme. Le souci de portabilité ne concerne pas que les BSD => un exemple qui m'agace : musl-libc semble très prometteuse, et certaines distributions comme Alpine l'ont déjà adopté. Mais systemd ne marche qu'avec la glibc et Lennard a clairement dit qu'il refusait de résoudre le problème ("we will rely on good APIs exposed in the generally accepted Linux API which is the one glibc exposes". Dit autrement: l'API de référence est pour lui la glibc avec toutes ses extensions et GNUisms et non juste POSIX, les autres libc n'ont qu'à réimplémenter le bloat...). Or pour autre chose que de l'embarqué (au hasard, pour une machine desktop avec Gnome), les dépendances élargies du type Gnome->systemd->glibc compliquent le passage à autre chose que systemd et par voie de conséquence empêchent durablement toute distro majeure de proposer autre chose que la glibc. La compatibilité avec musl et uclibc est pour moi un argument majeur pour toutes les alternatives à systemd — notamment uselessd !