Je pose simplement la question de savoir si cette décision apportera une plusvalue en ce qui concerne une amélioration de la qualité des applications. J'en doute très fortement car je prends comme hypothèse que masquer des problème engendre une non-correction des bugs de la part des programmeurs, et je justifie cela non pas par leur fainéantise innée, mais parce que ces bugs ne seront tout simplement pas rapportés par les utilisateurs. Bref, dans le long terme, c'est une mauvaise décision selon moi :-)
En fait ce commentaire indique que la décision est excellente à court comme à long terme. En effet, aucun utilisateur n'est capable de remonter des problèmes survenus après la fermeture de sa session. Car l'immense majorité des utilisateurs, après s'être déconnecté, ne va pas se reconnecter ensuite pour voir s'il n'y aurait pas des mauvais comportements dans les logs ou des process fantômes, le seul endroit où ce comportement sera visible.
Les mauvais comportements seront au contraire désormais un peu plus visibles, car on pourra désormais voir ces process mourir dans les logs de l'utilisateur.
Cette décision apporte une énorme plus-value : elle permet d'indiquer clairement à l'init que les process qui restent actifs sont voulus ainsi, alors qu'auparavant, il n'était pas possible de faire la distinction avec des mauvais comportements de process, puisque c'était un hack pour tromper les autres init.
La plus grosse contradiction dans toute cette affaire, c'est que les soi-disant sysadmins qui se plaignent que systemd n'est pas fait pour leurs serveurs, sont les mêmes qui se plaignent de ce changement de comportement par défaut, alors qu'il est parfaitement adapté aux serveurs justement.
[^] # Re: Ne pas utiliser, recompiler... ou changer une option.
Posté par ookaze . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 2.
En fait ce commentaire indique que la décision est excellente à court comme à long terme. En effet, aucun utilisateur n'est capable de remonter des problèmes survenus après la fermeture de sa session. Car l'immense majorité des utilisateurs, après s'être déconnecté, ne va pas se reconnecter ensuite pour voir s'il n'y aurait pas des mauvais comportements dans les logs ou des process fantômes, le seul endroit où ce comportement sera visible.
Les mauvais comportements seront au contraire désormais un peu plus visibles, car on pourra désormais voir ces process mourir dans les logs de l'utilisateur.
Cette décision apporte une énorme plus-value : elle permet d'indiquer clairement à l'init que les process qui restent actifs sont voulus ainsi, alors qu'auparavant, il n'était pas possible de faire la distinction avec des mauvais comportements de process, puisque c'était un hack pour tromper les autres init.
La plus grosse contradiction dans toute cette affaire, c'est que les soi-disant sysadmins qui se plaignent que systemd n'est pas fait pour leurs serveurs, sont les mêmes qui se plaignent de ce changement de comportement par défaut, alors qu'il est parfaitement adapté aux serveurs justement.