Le constat, c'est que la baraque est faite de matériaux inflammables, et en gros, tu dis qu'il vaut mieux utiliser des allumettes qu'un briquet... Le fait est qu'il est beaucoup trop facile de faire des conneries irrattrappables en ligne de commande, ça n'a pas grand chose à voir avec les options de rm. Tu peux aussi péter un système avec chmod, ou avec plus ou moins n'importe quel utilitaire qui fait quelque chose. On ne va pas changer les options par défaut des commandes UNIX, ça n'a pas de sens. Ça n'aurait pas non plus beaucoup de sens de diminuer la puissance de ces outils ; les demandes de confirmation sont pénibles et sans aucun effet (tout le monde va taper -f automatiquement, et puis voila).
Bien sûr, la remarque des vieux barbons, c'est que ça a toujours été comme ça, que les gens n'ont qu'à faire attention, qu'eux ne font jamais d'erreurs et/ou que quand ils font des erreurs, c'est qu'ils l'ont bien cherché, etc. Mon avis là-dessus, c'est que ces "opinions" sont sans grand intérêt. Ce genre de discours ne revient qu'à nier les problèmes, à faire porter les problèmes sur les gens plutôt que sur les logiciels, et à nier les pertes de données, d'argent, et de temps dûs à la mauvaise conception de nos interfaces.
De facto, la très grande majorité des commandes qu'on tape dans un terminal sont trivialement réversibles. D'autres, comme rm, seraient également trivialement modifiables pour être réversibles. Le coût associé à une réversibilité serait très faible; il suffirait d'avoir un historique simplifié des actions sur le système (sachant que tous les shells courants logguent déja la liste des commandes dans un fichier d'historique, la liste des effets ne serait pas bien coûteux...).
Alors oui, YAKA, FAUKON, toussa toussa. Il n'est pas non plus évident de savoir à quel niveau l'intervention doit être faite (est-ce à ln ou chmod de garder un historique d'appels systèmes, ou est-ce au shell d'interpréter les commandes usuelles?). Mais je trouve qu'on est beaucoup trop complaisants avec le statu quo ; se complaire dans une ergonomie dégueulasse n'est à l'honneur de personne.
[^] # Re: Blame the victim
Posté par arnaudus . En réponse au journal [MaVie] La grosse gaffe du jour ..... Évalué à 2.
Le constat, c'est que la baraque est faite de matériaux inflammables, et en gros, tu dis qu'il vaut mieux utiliser des allumettes qu'un briquet... Le fait est qu'il est beaucoup trop facile de faire des conneries irrattrappables en ligne de commande, ça n'a pas grand chose à voir avec les options de rm. Tu peux aussi péter un système avec chmod, ou avec plus ou moins n'importe quel utilitaire qui fait quelque chose. On ne va pas changer les options par défaut des commandes UNIX, ça n'a pas de sens. Ça n'aurait pas non plus beaucoup de sens de diminuer la puissance de ces outils ; les demandes de confirmation sont pénibles et sans aucun effet (tout le monde va taper -f automatiquement, et puis voila).
Bien sûr, la remarque des vieux barbons, c'est que ça a toujours été comme ça, que les gens n'ont qu'à faire attention, qu'eux ne font jamais d'erreurs et/ou que quand ils font des erreurs, c'est qu'ils l'ont bien cherché, etc. Mon avis là-dessus, c'est que ces "opinions" sont sans grand intérêt. Ce genre de discours ne revient qu'à nier les problèmes, à faire porter les problèmes sur les gens plutôt que sur les logiciels, et à nier les pertes de données, d'argent, et de temps dûs à la mauvaise conception de nos interfaces.
De facto, la très grande majorité des commandes qu'on tape dans un terminal sont trivialement réversibles. D'autres, comme rm, seraient également trivialement modifiables pour être réversibles. Le coût associé à une réversibilité serait très faible; il suffirait d'avoir un historique simplifié des actions sur le système (sachant que tous les shells courants logguent déja la liste des commandes dans un fichier d'historique, la liste des effets ne serait pas bien coûteux...).
Alors oui, YAKA, FAUKON, toussa toussa. Il n'est pas non plus évident de savoir à quel niveau l'intervention doit être faite (est-ce à ln ou chmod de garder un historique d'appels systèmes, ou est-ce au shell d'interpréter les commandes usuelles?). Mais je trouve qu'on est beaucoup trop complaisants avec le statu quo ; se complaire dans une ergonomie dégueulasse n'est à l'honneur de personne.