Mais bon, il y en a d'autres des systèmes d'init, qui résolvent le principal grief fait à systemV (qui n'est pas le système d'init de Slackware, on est plus sur un truc BSD compatible systemV) c'est à dire le démarrage de services en parallèle, pour avoir un système opérationnel plus rapidement (et la gestion de dépendances, là encore tiens !).
Aucun n'a fait autant jaser.
Et c'est lié à l'approche « je suis La Solution, virez tout le reste et ne laissez que Moi ! » du projet.
Et de multiples erreurs de communications comme d'envoyer chier les gens qui s'étonnaient que screen se fasse tuer par systemd.
Comment tu peux apprécier l'approche d'un développeur principal qui répond des choses du genre « bah c'est pas comme ça que je fais les choses, donc je m'en fous » ? Ok, c'est son logiciel, il le fait comme il veut, mais à un moment, si le logiciel est utilisé, ben tu peux plus.
Donc le projet est parti avec une réputation de merde, il casse des trucs qui fonctionnaient avant, oblige à changer ses habitudes et en apprendre de nouvelles, pour ne pas apporter forcément plus que ce que d'autres projets apportaient déjà.
C'est peut-être bien, mais tant que ça ne reste pas une obligation, et qu'on a le choix, on le prend...
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par Yth (Mastodon) . En réponse à la dépêche Tout arrive, même Slackware 15.0. Évalué à 10.
J'avais prévenu que ça partait en troll hein :)
Mais bon, il y en a d'autres des systèmes d'init, qui résolvent le principal grief fait à systemV (qui n'est pas le système d'init de Slackware, on est plus sur un truc BSD compatible systemV) c'est à dire le démarrage de services en parallèle, pour avoir un système opérationnel plus rapidement (et la gestion de dépendances, là encore tiens !).
Aucun n'a fait autant jaser.
Et c'est lié à l'approche « je suis La Solution, virez tout le reste et ne laissez que Moi ! » du projet.
Et de multiples erreurs de communications comme d'envoyer chier les gens qui s'étonnaient que screen se fasse tuer par systemd.
Comment tu peux apprécier l'approche d'un développeur principal qui répond des choses du genre « bah c'est pas comme ça que je fais les choses, donc je m'en fous » ? Ok, c'est son logiciel, il le fait comme il veut, mais à un moment, si le logiciel est utilisé, ben tu peux plus.
Donc le projet est parti avec une réputation de merde, il casse des trucs qui fonctionnaient avant, oblige à changer ses habitudes et en apprendre de nouvelles, pour ne pas apporter forcément plus que ce que d'autres projets apportaient déjà.
C'est peut-être bien, mais tant que ça ne reste pas une obligation, et qu'on a le choix, on le prend...