personne n'a dit que systemd répond à tous les besoin maintenant.
et les seuls qui ne veulent pas sont ceux qui n'aiment pas le changement et veulent garder le "bohneur" de la maintenance pourrie de ce qui existe avant.
Là, il va falloir choisir un des deux. Soit les personnes qui ne veulent pas de systemd sont des connards passéistes réactionnaires aigris et mal informés, soit il reste encore de vraies bonnes raisons de s'inquiéter de l'impact de systemd sur l'administration de certains systèmes dans certaines situations particulières.
Tout ce que je demande c'est que la possibilité numéro ne soit pas ridiculisée systématiquement.
Pour caricaturer, il y a deux possibilités :
- soit systemd devient turing complet et on va se retrouver dans deux, trois, quatre ans dans le même bordel de maintenance des scripts d'init.
- soit systemd ne devient pas turing complet et il y aura des admins qui ne pourront plus faire leur système comme ils ont l'habitude et qui devront recréer, tester et migrer vers une nouvelle architecture logicielle (nouvelles logiques d'init, nouvelles policies, potentiellement nouveaux logiciels).
combien de logiciels à la HAProxy qui en plus va refuser de s'adapter?
Typiquement un cas à la con pour systemd : mettre HAProxy derrière un wrapper entraine une perte de perfs, sortir HAProxy de son mode "single process, event driven" entraine une perte de perfs, bidouiller avec un pseudo-wrappo-manager à la nginx entrainne une perte de perf.
Grosso-modo si HAProxy "s'adapte" à systemd, il devient un autre logiciel.
[^] # Re: GNU/SystemD/Linux
Posté par Kaane . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 7.
personne n'a dit que systemd répond à tous les besoin maintenant.
et les seuls qui ne veulent pas sont ceux qui n'aiment pas le changement et veulent garder le "bohneur" de la maintenance pourrie de ce qui existe avant.
Là, il va falloir choisir un des deux. Soit les personnes qui ne veulent pas de systemd sont des connards passéistes réactionnaires aigris et mal informés, soit il reste encore de vraies bonnes raisons de s'inquiéter de l'impact de systemd sur l'administration de certains systèmes dans certaines situations particulières.
Tout ce que je demande c'est que la possibilité numéro ne soit pas ridiculisée systématiquement.
Pour caricaturer, il y a deux possibilités :
- soit systemd devient turing complet et on va se retrouver dans deux, trois, quatre ans dans le même bordel de maintenance des scripts d'init.
- soit systemd ne devient pas turing complet et il y aura des admins qui ne pourront plus faire leur système comme ils ont l'habitude et qui devront recréer, tester et migrer vers une nouvelle architecture logicielle (nouvelles logiques d'init, nouvelles policies, potentiellement nouveaux logiciels).
combien de logiciels à la HAProxy qui en plus va refuser de s'adapter?
Typiquement un cas à la con pour systemd : mettre HAProxy derrière un wrapper entraine une perte de perfs, sortir HAProxy de son mode "single process, event driven" entraine une perte de perfs, bidouiller avec un pseudo-wrappo-manager à la nginx entrainne une perte de perf.
Grosso-modo si HAProxy "s'adapte" à systemd, il devient un autre logiciel.