Tu te trompes. C’est justement parce qu’il est aussi possible d’utiliser Python à des fin burelesques qu’il surpasse Ruby : lui (Python) au moins n’a pas une pierre coincée dans l’oignon.
Après le monkey patching de Ruby, je crois que le burlesque n'a plus de limites que ce soit pour Ruby ou pour Python…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Il y a l'OS (Windows)
Il y a la suite antivirus (si pas de chance, c'est un truc Symantec, qui bouffe…)
Il y a 3 autres applications
Bref, à la fin, il lui reste plus grand chose à Firefox, qui doit être quasiment un OS à lui tout seul (html5, css, javascript, moteur de rendu des pages, sécurité (TLS + certificats), gestion du cache, etc, etc, etc…).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Euh ma mère se perd dans GMail (c'est le type d'utilisateur qui utilise son ordi 1 fois par an). Elle préfère son Thunderbird préconfiguré (une fois pour toutes) par mes soins. :)
GMail a plein de trucs qu'elle utilisera jamais et qui lui font poser des questions inutilement. Et sur les dernières années, l'interface a complètement changé plusieurs fois (ce qui est über-chiant quand tu veux juste utiliser ton ordi).
Thunderbird, on peut pas dire qu'il bouge beaucoup son IHM, et ça c'est bien pour ce type d'utilisateur.
Et quitte à utiliser un logiciel non-libre tel que Outlook, autant en utiliser un gratuit tel que GMail (ou mieux un truc libre comme Thunderbird ;-) )
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
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 !)
[^] # Re: Merci, ô grand merci ...
Posté par xcomcmdr . En réponse au journal Esod mumixam !. Évalué à 3.
Après le monkey patching de Ruby, je crois que le burlesque n'a plus de limites que ce soit pour Ruby ou pour Python…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Thunderbird VS Seamonkey/mail
Posté par xcomcmdr . En réponse à la dépêche Du nouveau pour Thunderbird. Évalué à 7. Dernière modification le 04 décembre 2014 à 14:05.
Ce n'est pas Firefox seul qui utilise 1 Go
Il y a l'OS (Windows)
Il y a la suite antivirus (si pas de chance, c'est un truc Symantec, qui bouffe…)
Il y a 3 autres applications
Bref, à la fin, il lui reste plus grand chose à Firefox, qui doit être quasiment un OS à lui tout seul (html5, css, javascript, moteur de rendu des pages, sécurité (TLS + certificats), gestion du cache, etc, etc, etc…).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Thunderbird VS Seamonkey/mail
Posté par xcomcmdr . En réponse à la dépêche Du nouveau pour Thunderbird. Évalué à 2.
1 Go de nos jours c'est limite. Au vu du prix de la mémoire, 2 Go c'est pas du luxe.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Le client soft dépassé pour l'utilisateur lambda ?
Posté par xcomcmdr . En réponse à la dépêche Du nouveau pour Thunderbird. Évalué à 10.
Euh ma mère se perd dans GMail (c'est le type d'utilisateur qui utilise son ordi 1 fois par an). Elle préfère son Thunderbird préconfiguré (une fois pour toutes) par mes soins. :)
GMail a plein de trucs qu'elle utilisera jamais et qui lui font poser des questions inutilement. Et sur les dernières années, l'interface a complètement changé plusieurs fois (ce qui est über-chiant quand tu veux juste utiliser ton ordi).
Thunderbird, on peut pas dire qu'il bouge beaucoup son IHM, et ça c'est bien pour ce type d'utilisateur.
Et quitte à utiliser un logiciel non-libre tel que Outlook, autant en utiliser un gratuit tel que GMail (ou mieux un truc libre comme Thunderbird ;-) )
"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 !)