Quand on voit la réponse de Lennart https://bugzilla.redhat.com/show_bug.cgi?id=833105, on ne peut s'empêcher de voir la mauvaise foi de partout : il ignore l'utilisation de SIGSTOP seulement si un flag/variable d'environnement est mis, dit que ça peut être utilisé pour autre chose, mais là c'est dans le cas où le process l'utilise sur lui-même, il indique qu'il ne voit pas de différence entre appeler une fonction de la libc et introduire une dépendance à sa lib (il doit s'en foutre du boulot de mise à jour de tous les paquets, même les plus vieux/exotiques/etc...), ... Alors que le rapport original demande juste une simple mesure pour être compatible optionnellement avec certains programmes !
Il est trop reulou. Techniquement, c'est à dire au niveau des capacités, je trouve que systemd bat de loin tous les autres. Ça serait la raison qui me fait le supporter. Mais entre son implémentation lourdingue, sa volonté de vouloir tout remplacer d'un coup (génial), l'intégration de tout dans systemd ce qui rend udev et d'autres utilitaires essentiels forcément dépendants de systemd sans toujours de bonne raisons, le « j'en n'ai rien à foutre des autres qui ne peuvent pas suivre », et l'ego démesuré de ce mec... c'est super chiant. Alors oui, je ne vois pas de solution aussi « bien » que la sienne, mais on sent tellement une sorte d'imposition de l'avis de RedHat sur un paquet de choses d'un coup, et que plein de monde va être largué parce que non compatible, que ça fait très peur.
[^] # Re: Mini précision, variable d'environnement
Posté par benoar . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 9.
Quand on voit la réponse de Lennart https://bugzilla.redhat.com/show_bug.cgi?id=833105, on ne peut s'empêcher de voir la mauvaise foi de partout : il ignore l'utilisation de SIGSTOP seulement si un flag/variable d'environnement est mis, dit que ça peut être utilisé pour autre chose, mais là c'est dans le cas où le process l'utilise sur lui-même, il indique qu'il ne voit pas de différence entre appeler une fonction de la libc et introduire une dépendance à sa lib (il doit s'en foutre du boulot de mise à jour de tous les paquets, même les plus vieux/exotiques/etc...), ... Alors que le rapport original demande juste une simple mesure pour être compatible optionnellement avec certains programmes !
Il est trop reulou. Techniquement, c'est à dire au niveau des capacités, je trouve que systemd bat de loin tous les autres. Ça serait la raison qui me fait le supporter. Mais entre son implémentation lourdingue, sa volonté de vouloir tout remplacer d'un coup (génial), l'intégration de tout dans systemd ce qui rend udev et d'autres utilitaires essentiels forcément dépendants de systemd sans toujours de bonne raisons, le « j'en n'ai rien à foutre des autres qui ne peuvent pas suivre », et l'ego démesuré de ce mec... c'est super chiant. Alors oui, je ne vois pas de solution aussi « bien » que la sienne, mais on sent tellement une sorte d'imposition de l'avis de RedHat sur un paquet de choses d'un coup, et que plein de monde va être largué parce que non compatible, que ça fait très peur.