Parce que les APIs spécifiques n'existent pas ailleurs, ou du moins pas de manière équivalente !
Si on lit uniquement ce que tu cites, Lennart est le Malin.
Si on lit tout le mail, c'est beaucoup plus nuancé : quand c'est "portable" au prix de rajouter énormément de code à systemd (qui existe déjà dans la glibc), est-ce vraiment sain ?
La réponse de Lennart est non.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Ces fonctionnalités ont des équivalents sous d'autres OS
Vraiment ? (mythe 15 et 16) Même les control groups ?
Et est-ce vraiment utile de rendre systemd portable, avec toute la complexité associée, quand ça n'intéresse personne (par exemple, chez *BSD) ?
Myth: systemd could be ported to other kernels if its maintainers just wanted to.
That is simply not true. Porting systemd to other kernel is not feasible. We just use too many Linux-specific interfaces. For a few one might find replacements on other kernels, some features one might want to turn off, but for most this is nor really possible. Here's a small, very incomprehensive list: cgroups, fanotify, umount2(), /proc/self/mountinfo (including notification), /dev/swaps (same), udev, netlink, the structure of /sys, /proc/$PID/comm, /proc/$PID/cmdline, /proc/$PID/loginuid, /proc/$PID/stat, /proc/$PID/session, /proc/$PID/exe, /proc/$PID/fd, tmpfs, devtmpfs, capabilities, namespaces of all kinds, various prctl()s, numerous ioctls, the mount() system call and its semantics, selinux, audit, inotify, statfs, O_DIRECTORY, O_NOATIME, /proc/$PID/root, waitid(), SCM_CREDENTIALS, SCM_RIGHTS, mkostemp(), /dev/input, …
And no, if you look at this list and pick out the few where you can think of obvious counterparts on other kernels, then think again, and look at the others you didn't pick, and the complexity of replacing them.
Myth: systemd is not portable for no reason.
Non-sense! We use the Linux-specific functionality because we need it to implement what we want. Linux has so many features that UNIX/POSIX didn't have, and we want to empower the user with them. These features are incredibly useful, but only if they are actually exposed in a friendly way to the user, and that's what we do with systemd.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Moi ce que j'observe, c'est que mes distros basées sur Musl (et les BSD) ont de moins en moins de chances de pouvoir intégrer Gnome… (et non: musl n'a pas vocation à intégrer tous les GNUisms et les bloats de la glibc, tout comme les *BSD). Encore une fois: personne n'a demandé à Lennard de faire lui-même le boulot de portabilité (lennard code ce qu'il souhaite. Il a le droit de ne pas s'intéresser aux BSD ou à musl). Mais par contre il a clairement une responsabilité en refusant les patches qui lui sont envoyés pour permettre cette portabilité !
Alors déjà :
- refuser un patch en soit ça peut se comprendre, hein. Qui va le maintenir ? Est-il vraiment utile ? Le coût en termes de complexité de code vaut-il le jeu ? Est-il conforme aux normes de codage du projet ? etc…
- et puis systemd est fortement dépendant des APIs de Linux (control groups, fanotify, capabilities, inotify, …) pour remplir sa mission (contrôler les services), tellement que ne plus en dépendre ce n'est plus faire systemd, c'est faire autre chose, pour un autre public.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Bah j'ai systemd, et j'ai toujours /etc/rc.init, mon zsh, mes coreutils gnu et mes scripts utilisateur.
systemd vire uniquement la plupart des scripts de démarrage existants, mais il ne vire pas le shell (il lance même un shell de secours en cas de crash).
Quand aux DEs utilisant des composants tels que systemd-logind, ça existe déjà (gnome, xfce) et c'est plus sain que d'utiliser consolekit qui n'est plus maintenue depuis des années.
On est loin de Windows pourtant car dans ce dernier on ne peut pas remplacer la moindre brique.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
L'ensemble de l'usage et de l'administration de systemd se fait depuis la ligne de commandes, et systemd est écrit en c.
Donc bon j'ai du mal à voir le lien entre systemd et pro Windows/desktop.
C'est surtout encore à mon avis la rumeur tenace que systemd c'est pour le desktop (alors que sur desktop des trucs comme la réplication du journal ailleurs ou la détection de la virtualisation je m'en fiche un peu)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
! Vous avez bien lue une feuille de route ! Moi je croyais que maintenant les projets libres n'en faisait plus, que c'était "so 90's", développement agile-machin-toutssa,…).
Si on utilise l'Agilité comme excuse pour pas faire de roadmap ou de schémas/specs, c'est qu'on a rien compris à l'Agilité.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Euh, je suis le seul qui est dérangé par ce passage ?
En gros, les zélateurs ils utilisent Ubuntu (mythe que systemd est pour le destkop derrière ?) et courent après le mythe de l'année du bureau Linux, et n'aiment pas la bidouille.
Et les détracteurs, c'est des barbus, des vrais, avec un vrai bagage technique, qui utilise Slackware, Gentoo, & co, et adorent hacker.
Bref, ce sont deux gros clichés auxquels j'ai du mal à croire.
D'abord j'aimerais bien avoir des sources/stats/études avant d'affirmer des généralités sur une population.
De deux, c'est oublier qu'Archlinux a été l'une des premières distribs à intégrer systemd. L'année du bureau Linux, les mainteneurs d'Archlinux s'en contrefichent.
De trois, ce n'est pas parce que systemd qu'on a un bagage technique limité. C'est même l'inverse, vu la complexité de systemd face à SysV.
Et quatrièmement, systemd n'empêche en rien les hacks (du genre je vais bidouiller mon fstab, faire des règles udev bien barrées, et faire un script de 2k LOC que je vais lancer au démarrage parce que j'en ai besoin)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Autre gros point faible: quasi tout les projets de Lennart sont très mal documentés.
La doc de systemd est très bonne et complète. De plus, c'est le système d'init le plus documenté que j'ai jamais vu. Quand on compare à la non-doc de SysV ou Upstart, y'a pas photo !
Le fait que Lennart travail pour RedHat, et le fait que RedHat controle quasi entièrement Fedora et RHEL a fortement aidé à l'adoption de systemd. Le libre, ce n'est pas que des gens qui travaillent sur leur temps libre.
Non, systemd a aussi reçu beaucoup de résistance interne chez RH et a été au départ un sideproject de Lennart. Et Archlinux a été une des premières à l'adopter, pour les raisons expliqués ici : pas de trace de RH là dedans.
C'est un petit peu des deux. systemd est intéréssant, mais systemd est trop complexe, trop gros (80 binaires qui font des choses totalement différentes et normalement indépendante : logind, udev, networkd, …),
D'un autre côté, systemd est plus « performant », plus standardisé, peut-être plus facile à utiliser pour les developeur.
Il est plus facile à utiliser, tout simplement : plus de fiabilité, plus de retour sur les problèmes, plus d'informations utiles dans le journal, etc…
Si on me paye pour ça, si on me donne la capacité de le mettre ensuite par défaut dans deux des plus grosses distributions Linux, je fonce, comme Lennart. Sortir cet argument à chaque fois c'est vraiment de mauvaise foi.
Et concrètement ? Un pot de vin aux mainteneurs, tu crois ? Ha !
En plus il est fait en sorte que se soit difficile d'écrire une alternative car ils « standardisent » tout, en utilisant dbus, même des modules qui sont en théorie parfaitement indépendant d'un système d'initialisation, udev et networkd sont les exemples parfait. Ensuite les pro-systemd viennent dire : « Ah mais tu peux réécrire chaque module de systemd, ils sont totalement indépendants car ils utilisent une interface dbus standardisée ». Beuuuuurk.
networkd est optionnel.
udev permet de peupler /dev, c'est un peu important pour booter.
Et oui, systemd est un ensemble d'outils maintenus dans un seul dépôt, "à la BSD" : ça permet d'avoir un tout cohérent.
Quant au fait que faire une alternative à systemd revient à re-créer systemd : ça tient du fait que systemd est généralement adopté et que revenir en arrière ne sera pas accepté.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Cependant ce qui est nocif c'est de n'en avoir rien à faire de casser l'expérience utilisateur, c'est à dire que l'on se moque bien de savoir si il y a des régressions, perte de compatibilité ou autre effets de bords quand on passe de la version N à la version N+1. Et là dessus Lennart est champion.
Source ? Preuves ?
Je suis passé par des dizaines de versions de PA et de systemd (j'utilise PA depuis qu'il a été intégré à Ubuntu, et systemd depuis qu'Archlinux l'a adopté vers mi-2012) : aucune régression (j'ai pas dit aucun bug, hein).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Maintenant à l'inverse son maintien dans Linux, avec sa capacité à détruire l'expérience utilisateur et son dedain vis à vis de toute tentative de création d'environnement un poil perenne, me casse franchement les pieds.
Alors chez moi avahi je m'en suis jamais servi mais je comprends très bien le besoin. Wikipédia donne l'exemple suivant :
Par exemple, un utilisateur peut brancher son ordinateur sur un réseau et trouver instantanément des imprimantes pour imprimer, des fichiers à lire et des personnes à qui parler…
Un truc qui automatise la découverte de services, pour moi c'est clairement une amélioration de l'expérience utilisateur.
Quant à systemd… Je vais pas tout refaire, mais en gros :
tu as un contrôle plus fiable des services (expérience utilisateur améliorée)
tu as toutes les sorties d'erreurs dans le journal
tu as une compatibilité avec les scripts (on préserve l'expérience utilisateur : au pire, elle est pareil qu'avant)
la prise en charge du multiseat (oui on peut faire sans, mais le but c'est d'avoir la même qualité de support partout, pas juste de la débrouillardise au cas par cas),
avoir xorg rootless (une faille de sécurité en moins, c'est mauvais pour l'expérience utilisateur ?!)
lancer des services utilisateur (systemd --user)
avoir des entrées du journal qui commencent bien plus tôt dans le processus de démarrage qu'avec syslog
Alors oui ce n'est pas le premier systemd-like, ni le premier à résoudre les problèmes que j'ai cité, mais c'est le premier à être accepté par les distributions, et ça change tout. Parce que un systemd super mais utilisé par 3 tondus, c'est joli mais ça sert à rien.
les cartes sons sont de plus en plus bêtes. En 1998 sur ma AWE64 j'avais du hardware mixing, du MPU-401, de la synthé FM OPL3… y'a rien de tout ça sur un AC'97 ou un bidule HDA aujourd'hui. Tout se fait en espace utilisateur, via PA/ALSA (et Timdity pour le MIDI)
Si ce que fait Lennart et ses collègues et si "mauvais", qu'est ce que ça va être quand il va coder sérieusement ! ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Parce que pour systemd ce n'est pas une mise à jour, c'est un changement de logiciel. Il va, magiquement, savoir utiliser systemd juste après la mise à jour ?
Passer de linux 3.14 à linux 3.15, c'est pas un changement de logiciel peut-être ?
Une mise à jour, ça ne change pas le logiciel… Ben ça met à jour quoi alors ?
Quant à savoir utiliser systemd :
- y'en a pas besoin pour booter avec systemd, ça va fonctionner avec les scripts existants
- les commandes se ressemblent fortement (et c'est voulu)
- une mise à jour de sysV ver systemd, l'utilisateur lambda ne voit aucune différence… (il touche pas à l'init)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Alors pourquoi il accepte les mises à jours de toute le reste (y compris du kernel, qui peut tout autant avoir des bugs et qui est bien plus critique que l'init) et pas de SysV vers systemd, d'autant plus que ce dernier est compatible avec les scripts ?
C'est pas cohérent !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mature
Posté par xcomcmdr . En réponse à la dépêche Du nouveau pour Thunderbird. Évalué à 10.
L'état mûr, c'est ce qui par définition précède l'état pourri.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Bravo
Posté par xcomcmdr . En réponse à la dépêche Joker, un logiciel pour doubler des films sous licence GPL. Évalué à -1.
par opposition au libre pas open source ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Fonctionnalités clées.
Posté par xcomcmdr . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 4.
J'ai un doute, mais si tu le dis.
Tu as les cgroups… Et tout le reste ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Fonctionnalités clées.
Posté par xcomcmdr . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 2.
Sinon, sur ext4 fsck est extrêmement rapide.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Fonctionnalités clées.
Posté par xcomcmdr . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 3. Dernière modification le 01 décembre 2014 à 20:43.
tu en es sûr ?
http://www.rdeeson.com/weblog/125/how-to-cancel-an-fsck-disk-check-during-boot-on-arch-linux.html
Tiens, c'est dans la TODO-list de systemd on dirait :
http://cgit.freedesktop.org/systemd/systemd/tree/TODO?id=HEAD#n562
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Fonctionnalités clées.
Posté par xcomcmdr . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 5. Dernière modification le 01 décembre 2014 à 20:13.
Parce que les APIs spécifiques n'existent pas ailleurs, ou du moins pas de manière équivalente !
Si on lit uniquement ce que tu cites, Lennart est le Malin.
Si on lit tout le mail, c'est beaucoup plus nuancé : quand c'est "portable" au prix de rajouter énormément de code à systemd (qui existe déjà dans la glibc), est-ce vraiment sain ?
La réponse de Lennart est non.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Fonctionnalités clées.
Posté par xcomcmdr . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 4.
Vraiment ? (mythe 15 et 16) Même les control groups ?
Et est-ce vraiment utile de rendre systemd portable, avec toute la complexité associée, quand ça n'intéresse personne (par exemple, chez *BSD) ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Fonctionnalités clées.
Posté par xcomcmdr . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 3. Dernière modification le 01 décembre 2014 à 13:04.
Alors déjà :
- refuser un patch en soit ça peut se comprendre, hein. Qui va le maintenir ? Est-il vraiment utile ? Le coût en termes de complexité de code vaut-il le jeu ? Est-il conforme aux normes de codage du projet ? etc…
- et puis systemd est fortement dépendant des APIs de Linux (control groups, fanotify, capabilities, inotify, …) pour remplir sa mission (contrôler les services), tellement que ne plus en dépendre ce n'est plus faire systemd, c'est faire autre chose, pour un autre public.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Fonctionnalités clées.
Posté par xcomcmdr . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 0.
J'utilise NetworkManager sans souci, d'autant que networkd est optionnel.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Incompatible ?
Posté par xcomcmdr . En réponse au journal Devuan forks Debian: un choc ou c'était inévitable?. Évalué à 2.
Tu peux spécifier l'ordre (enfin, les dépendances).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
Posté par xcomcmdr . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 5.
Bah j'ai systemd, et j'ai toujours /etc/rc.init, mon zsh, mes coreutils gnu et mes scripts utilisateur.
systemd vire uniquement la plupart des scripts de démarrage existants, mais il ne vire pas le shell (il lance même un shell de secours en cas de crash).
Quand aux DEs utilisant des composants tels que systemd-logind, ça existe déjà (gnome, xfce) et c'est plus sain que d'utiliser consolekit qui n'est plus maintenue depuis des années.
On est loin de Windows pourtant car dans ce dernier on ne peut pas remplacer la moindre brique.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
Posté par xcomcmdr . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 8.
L'ensemble de l'usage et de l'administration de systemd se fait depuis la ligne de commandes, et systemd est écrit en c.
Donc bon j'ai du mal à voir le lien entre systemd et pro Windows/desktop.
C'est surtout encore à mon avis la rumeur tenace que systemd c'est pour le desktop (alors que sur desktop des trucs comme la réplication du journal ailleurs ou la détection de la virtualisation je m'en fiche un peu)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# wtf
Posté par xcomcmdr . En réponse au journal Du nouveau pour Thunderbird !. Évalué à 10.
Si on utilise l'Agilité comme excuse pour pas faire de roadmap ou de schémas/specs, c'est qu'on a rien compris à l'Agilité.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# Les milieux culturels et techniques des zélateurs/détracteurs
Posté par xcomcmdr . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 10.
Euh, je suis le seul qui est dérangé par ce passage ?
En gros, les zélateurs ils utilisent Ubuntu (mythe que systemd est pour le destkop derrière ?) et courent après le mythe de l'année du bureau Linux, et n'aiment pas la bidouille.
Et les détracteurs, c'est des barbus, des vrais, avec un vrai bagage technique, qui utilise Slackware, Gentoo, & co, et adorent hacker.
Bref, ce sont deux gros clichés auxquels j'ai du mal à croire.
D'abord j'aimerais bien avoir des sources/stats/études avant d'affirmer des généralités sur une population.
De deux, c'est oublier qu'Archlinux a été l'une des premières distribs à intégrer systemd. L'année du bureau Linux, les mainteneurs d'Archlinux s'en contrefichent.
De trois, ce n'est pas parce que systemd qu'on a un bagage technique limité. C'est même l'inverse, vu la complexité de systemd face à SysV.
Et quatrièmement, systemd n'empêche en rien les hacks (du genre je vais bidouiller mon fstab, faire des règles udev bien barrées, et faire un script de 2k LOC que je vais lancer au démarrage parce que j'en ai besoin)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Tracker au désespoir
Posté par xcomcmdr . En réponse au sondage Les fonctions de bureau social, sémantique, indexation automatique des fichiers. Évalué à 4.
Baloo est censé le résoudre et chez moi il n'y a rien à signaler
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Tracker au désespoir
Posté par xcomcmdr . En réponse au sondage Les fonctions de bureau social, sémantique, indexation automatique des fichiers. Évalué à 2.
On dirait les déboires de KDE4 avec Nepomuk/Baloo.
C'est tellement 2008. ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Ca ne règle pas la source du problème
Posté par xcomcmdr . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 8. Dernière modification le 28 novembre 2014 à 08:05.
Il te suffit d'enlever quiet aux arguments de boot… Par défaut systemd est plutôt bavard.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mwai
Posté par xcomcmdr . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 6.
Si tu installe et actives avahi sur ton serveur, c'est ton problème.
Très bien, c'est pas imposé.
Si tu installe et actives PulseAudio sur ton serveur, c'est ton problème.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mwai
Posté par xcomcmdr . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 10.
La doc de systemd est très bonne et complète. De plus, c'est le système d'init le plus documenté que j'ai jamais vu. Quand on compare à la non-doc de SysV ou Upstart, y'a pas photo !
Non, systemd a aussi reçu beaucoup de résistance interne chez RH et a été au départ un sideproject de Lennart. Et Archlinux a été une des premières à l'adopter, pour les raisons expliqués ici : pas de trace de RH là dedans.
Il est plus facile à utiliser, tout simplement : plus de fiabilité, plus de retour sur les problèmes, plus d'informations utiles dans le journal, etc…
Et concrètement ? Un pot de vin aux mainteneurs, tu crois ? Ha !
networkd est optionnel.
udev permet de peupler /dev, c'est un peu important pour booter.
Et oui, systemd est un ensemble d'outils maintenus dans un seul dépôt, "à la BSD" : ça permet d'avoir un tout cohérent.
Quant au fait que faire une alternative à systemd revient à re-créer systemd : ça tient du fait que systemd est généralement adopté et que revenir en arrière ne sera pas accepté.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mwai
Posté par xcomcmdr . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 2. Dernière modification le 27 novembre 2014 à 19:59.
Source ? Preuves ?
Je suis passé par des dizaines de versions de PA et de systemd (j'utilise PA depuis qu'il a été intégré à Ubuntu, et systemd depuis qu'Archlinux l'a adopté vers mi-2012) : aucune régression (j'ai pas dit aucun bug, hein).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Ca ne règle pas la source du problème
Posté par xcomcmdr . En réponse au journal Laisser systemd de côté dans Debian. Évalué à -1.
Toujours pas convaincu, et ce commentaire exprime ma pensée.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Dépendances
Posté par xcomcmdr . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 5.
Euh, c'est l'inverse : c'est systemd qui s'en inspire (enfin de ça, et d'upstart).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mwai
Posté par xcomcmdr . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 10.
Alors chez moi avahi je m'en suis jamais servi mais je comprends très bien le besoin.
Wikipédia donne l'exemple suivant :
Un truc qui automatise la découverte de services, pour moi c'est clairement une amélioration de l'expérience utilisateur.
Quant à systemd… Je vais pas tout refaire, mais en gros :
Alors oui ce n'est pas le premier systemd-like, ni le premier à résoudre les problèmes que j'ai cité, mais c'est le premier à être accepté par les distributions, et ça change tout. Parce que un systemd super mais utilisé par 3 tondus, c'est joli mais ça sert à rien.
D'ailleurs, systemd est tellement "mauvais" qu'il fait fait même des émules chez BSD… ;-)
Et pour PulseAudio est aussi clairement un plus pour l'expérience utilisateur :
Si ce que fait Lennart et ses collègues et si "mauvais", qu'est ce que ça va être quand il va coder sérieusement ! ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Ca ne règle pas la source du problème
Posté par xcomcmdr . En réponse au journal Laisser systemd de côté dans Debian. Évalué à -10. Dernière modification le 27 novembre 2014 à 15:31.
Passer de linux 3.14 à linux 3.15, c'est pas un changement de logiciel peut-être ?
Une mise à jour, ça ne change pas le logiciel… Ben ça met à jour quoi alors ?
Quant à savoir utiliser systemd :
- y'en a pas besoin pour booter avec systemd, ça va fonctionner avec les scripts existants
- les commandes se ressemblent fortement (et c'est voulu)
- une mise à jour de sysV ver systemd, l'utilisateur lambda ne voit aucune différence… (il touche pas à l'init)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Ca ne règle pas la source du problème
Posté par xcomcmdr . En réponse au journal Laisser systemd de côté dans Debian. Évalué à -2.
Alors pourquoi il accepte les mises à jours de toute le reste (y compris du kernel, qui peut tout autant avoir des bugs et qui est bien plus critique que l'init) et pas de SysV vers systemd, d'autant plus que ce dernier est compatible avec les scripts ?
C'est pas cohérent !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)