Il s'agit là de l'API technique actuelle. Il n'y a pas de raison de ne pas faire générer ces XML autrement voir si une solution devient fondamentalement meilleure de la rendre native. À mon avis c'est le fait de ne pas s'en servir qui fait que ça n'est pas amélioré. Je suis pour la pratique qui consiste à dire que si quelque chose est compliqué, il faut le faire plus souvent. Plus fréquemment on fait les choses, plus on va se débrouiller pour l'améliorer.
Je suis pas forcément convaincu de cette approche. On peut justifier à peu près tout, et j'ai déjà vu ça dans des projets de dev. Un dev "influent" va pousser une vague solution à un vague problème qu'il rencontre, et fait face à de la résistance. du coup, les managers utilisent cet argument: "si vous râlez, c'est que vous l'utilisez pas, on va forcer l'usage, et la simplicité viendra". Et ensuite, bah certains devs poussent des rustines, contournent le problème, et le dev influent est content, il dit que sa solution est la meilleure!
C'est tjs un peu pareil : "olalala, c'est trop complexe, je vais faire ça plus simple. step1: un cas unique qui couvre mes besoins. step2: on augmente et on couvre 95% des besoins. step3: on ajoute pleins de cas particuliers. step4: c'est devenu trètrètrècompliqué didon!" rinse and repeat. Il y a un step3 aussi: "vos cas particuliers ne seront pas traités, modifiez tout pour coller à mon cas d'usage que j'ai défini. Pliez vous y ou dégagez, c'est du LL, libre à toi de tout redev dans ton coin".
[^] # Re: Conf Polkit pour remplacer sudo
Posté par octane . En réponse au lien Lennart veut remplacer sudo par run0 dans SystemD. Évalué à 9.
Je suis pas forcément convaincu de cette approche. On peut justifier à peu près tout, et j'ai déjà vu ça dans des projets de dev. Un dev "influent" va pousser une vague solution à un vague problème qu'il rencontre, et fait face à de la résistance. du coup, les managers utilisent cet argument: "si vous râlez, c'est que vous l'utilisez pas, on va forcer l'usage, et la simplicité viendra". Et ensuite, bah certains devs poussent des rustines, contournent le problème, et le dev influent est content, il dit que sa solution est la meilleure!
C'est tjs un peu pareil : "olalala, c'est trop complexe, je vais faire ça plus simple. step1: un cas unique qui couvre mes besoins. step2: on augmente et on couvre 95% des besoins. step3: on ajoute pleins de cas particuliers. step4: c'est devenu trètrètrècompliqué didon!" rinse and repeat. Il y a un step3 aussi: "vos cas particuliers ne seront pas traités, modifiez tout pour coller à mon cas d'usage que j'ai défini. Pliez vous y ou dégagez, c'est du LL, libre à toi de tout redev dans ton coin".