En fait, j'ai l'impression que Lennart ne fait que montrer les petits problèmes de "design" d'admin sys chez des utilisateurs ;-).
Le problème n'est pas tant les problèmes de « design »[1] qu'un changement dans les pratiques qu'imposent ce genre de choix techniques qui changent l'existant.
Il m'est arrivé de me travestir en www-data pour trouver la raison pour laquelle tel script/cgi/programme refuse de fonctionner ; si demain il est décidé que l'on ne doit pas se connecter/déconnecter avec un utilisateur système parce que ce n'est pas « le bien »[2], alors à quoi devrais-je m'attendre ? Suis-je vraiment un abruti si jusqu'à maintenant c'est permis, que c'est bien pratique et que je fais cela ?
Après reste la question de comment faire évoluer Linux, i.e. comment faire « bien », tout en gardant toujours une compatibilité ascendante ?
Je ne sais pas, et je sais que travailler avec les inerties c'est très difficile. Peut-être plutôt en mettant/activant tel programme/fonctionnalité/option dans une distribution uniquement (e.g. Red Hat, Fedora, et CentOS) ? Après tout si le package est vraiment convaincant tout le monde l'utilisera, et c'est bien ce qu'il s'est produit avec systemd.
De plus si une feuille de route avec tous les éléments qui vont être changés, avec la nouvelle architecture proposée est accessible cela pourrait aider et cela permettrait également de discuter, faire participer tout le monde[4].
En bref je sais pas, par contre toujours dire que les autres sont des cons car ils ne font pas ceci cela, parce qu'ils n'acceptent pas le changement, ça me fatigue.[3]
P.S.:véritable question : en cas d'incident, après récupération des logs binaires sur une autre machine, comment fait-on pour les lire ? Sur le coup et à l'époque à part coder moi-même quelque chose, j'avais pas trouvé.
[1] sauf à considérer que les autres sont toujours des cons, et qu'ils savent pas (ce qu'ils font | travailler), il y a probablement eu des raisons qui ont poussées ces gens à faire telle ou telle chose. Souvent ces raisons étaient valables à un moment (le prosaïque « pas le temps », ou le classique « pas possible autrement techniquement » mais qui est possible quelques mois/années plus tard), et ne le sont plus plus tard
[2] parce que c'est de cela dont il s'agit : ils sont en train de concevoir un nouvel OS
[3] en revanche je comprends bien les réponses de Lennart qui ne pourrait pas faire avancer son projet en transigeant sur tout et n'importe quoi.
[4] en bref si il y a un processus de discussion autour du nouvel OS désiré ; c'est bien ce qu'arrive à faire le C++, HTML, etc.
[^] # Re: Moui
Posté par lem__mel . En réponse au journal systemd: attention à RemoveIPC. Évalué à 8.
Le problème n'est pas tant les problèmes de « design »[1] qu'un changement dans les pratiques qu'imposent ce genre de choix techniques qui changent l'existant.
Il m'est arrivé de me travestir en www-data pour trouver la raison pour laquelle tel script/cgi/programme refuse de fonctionner ; si demain il est décidé que l'on ne doit pas se connecter/déconnecter avec un utilisateur système parce que ce n'est pas « le bien »[2], alors à quoi devrais-je m'attendre ? Suis-je vraiment un abruti si jusqu'à maintenant c'est permis, que c'est bien pratique et que je fais cela ?
Après reste la question de comment faire évoluer Linux, i.e. comment faire « bien », tout en gardant toujours une compatibilité ascendante ?
Je ne sais pas, et je sais que travailler avec les inerties c'est très difficile. Peut-être plutôt en mettant/activant tel programme/fonctionnalité/option dans une distribution uniquement (e.g. Red Hat, Fedora, et CentOS) ? Après tout si le package est vraiment convaincant tout le monde l'utilisera, et c'est bien ce qu'il s'est produit avec systemd.
De plus si une feuille de route avec tous les éléments qui vont être changés, avec la nouvelle architecture proposée est accessible cela pourrait aider et cela permettrait également de discuter, faire participer tout le monde[4].
En bref je sais pas, par contre toujours dire que les autres sont des cons car ils ne font pas ceci cela, parce qu'ils n'acceptent pas le changement, ça me fatigue.[3]
P.S.:véritable question : en cas d'incident, après récupération des logs binaires sur une autre machine, comment fait-on pour les lire ? Sur le coup et à l'époque à part coder moi-même quelque chose, j'avais pas trouvé.
[1] sauf à considérer que les autres sont toujours des cons, et qu'ils savent pas (ce qu'ils font | travailler), il y a probablement eu des raisons qui ont poussées ces gens à faire telle ou telle chose. Souvent ces raisons étaient valables à un moment (le prosaïque « pas le temps », ou le classique « pas possible autrement techniquement » mais qui est possible quelques mois/années plus tard), et ne le sont plus plus tard
[2] parce que c'est de cela dont il s'agit : ils sont en train de concevoir un nouvel OS
[3] en revanche je comprends bien les réponses de Lennart qui ne pourrait pas faire avancer son projet en transigeant sur tout et n'importe quoi.
[4] en bref si il y a un processus de discussion autour du nouvel OS désiré ; c'est bien ce qu'arrive à faire le C++, HTML, etc.