/dev/sda n'est pas un fichier régulier, il y a une confusion sémantique dans tes commentaires.
La confusion sémantique est dans le message de Lennart. Fais vraiment à cela, c’est un troll très subtile : la confusion sémantique est dans le message de Lennart et c’est cela que je pointe : par cette confusion sémantique Lennart formule un argument fallacieux qui appelle immanquablement des réactions vives qui lui permettent de prendre la posture de la victime et de clore le débat pour raison sociale plutôt que technique. Ce glissement « débat technique » vers « prise de bec » est opéré par l’emploi d’argument fallacieux qui sont vécus comme du foutage de gueule, et c’est très efficace : personne ne peut reprocher à personne de taire un débat après de insultes, quand bien même elles ont été sacrément cherchées. L’avantage de la méthode c’est que le débat technique peut être clôt avec des arguments non techniques, et c’est du pur troll.
Maintenant tu me parles de sauvegarder et restaurer /dev/sda, je pense immédiatement à la commande dd, et ça marche très bien.
Tu es complètement tombé dans le troll de Lennart.
On compare rm /dev/sda et rm /sys/sys/firmware/efi/efivars/qqch.
Cela signifie aussi que l’on compare cp /dev/sda et cp /sys/sys/firmware/efi/efivars/qqch, et pas dd.
Le gars qui se plaint de pouvoir briquer un appareil ne se plaint pas de le faire en ayant écrit des octets dans un fichier (comme tu l’as fait pour déplomber ton système), auquel cas on pourrait lui répondre « il fallait être prudent et pas écrire n’importe quoi », il se plaint de pouvoir briquer un appareil en supprimant un fichier virtuel dans /sys, ce qui est sensé être comparable à supprimer le fichier /dev/sda par exemple.
Dans mon exemple plus haut, si je fais cat /sys/.../rom je dump le vbios de ma carte graphique, mais si je fais rm /sys/.../rom, je ne détruit pas le vbios de ma carte graphique, encore heureux ! Il devrait en être exactement de même pour le firmware de la carte mère.
Donc restaurer les variables UEFI (tout à fait faisable) ne remet pas forcément ton BIOS dans l'état où il était au moment de la sauvegarde (si des variables non-UEFI ont changé).
Non, tu peux restaurer certaines valeurs mais pas toutes car dans certains cas la machine est définitivement briquée donc tu ne peux pas restaurer.
Enfin, tout a déjà été dit, et au delà de la confusion sur les fichier spéciaux, rincer un disque dur n’a pas la même conséquence que de rincer un firmware de carte-mère surtout quand il n’est pas restaurable. J’ai déjà rincé des disques durs, je n’ai jamais perdu de données. j’ai même déjà cramé un disque dur avec une mauvaise manipulation, je n’ai pas perdu de données, je n’ai pas rendu le système indémarrable, j’ai seulement remplacé le disque.
Au delà des arguments les plus techniques, cet argument est imparable. Même dans le cas où l’on se permet de comparer dd et rm sur un fichier spécial (ce qui n’a pas de sens), la comparaison « donnée standard sur stockage de masse » et « firmware de carte mère » ne tient pas la route, et le faire sciemment tient du troll.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Incompétence sociale (ce n’est pas une insulte)
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal rm -rf tue votre bios UEFI. Évalué à 10.
La confusion sémantique est dans le message de Lennart. Fais vraiment à cela, c’est un troll très subtile : la confusion sémantique est dans le message de Lennart et c’est cela que je pointe : par cette confusion sémantique Lennart formule un argument fallacieux qui appelle immanquablement des réactions vives qui lui permettent de prendre la posture de la victime et de clore le débat pour raison sociale plutôt que technique. Ce glissement « débat technique » vers « prise de bec » est opéré par l’emploi d’argument fallacieux qui sont vécus comme du foutage de gueule, et c’est très efficace : personne ne peut reprocher à personne de taire un débat après de insultes, quand bien même elles ont été sacrément cherchées. L’avantage de la méthode c’est que le débat technique peut être clôt avec des arguments non techniques, et c’est du pur troll.
Tu es complètement tombé dans le troll de Lennart.
On compare
rm /dev/sdaetrm /sys/sys/firmware/efi/efivars/qqch.Cela signifie aussi que l’on compare
cp /dev/sdaetcp /sys/sys/firmware/efi/efivars/qqch, et pasdd.Le gars qui se plaint de pouvoir briquer un appareil ne se plaint pas de le faire en ayant écrit des octets dans un fichier (comme tu l’as fait pour déplomber ton système), auquel cas on pourrait lui répondre « il fallait être prudent et pas écrire n’importe quoi », il se plaint de pouvoir briquer un appareil en supprimant un fichier virtuel dans
/sys, ce qui est sensé être comparable à supprimer le fichier/dev/sdapar exemple.Dans mon exemple plus haut, si je fais
cat /sys/.../romje dump le vbios de ma carte graphique, mais si je faisrm /sys/.../rom, je ne détruit pas le vbios de ma carte graphique, encore heureux ! Il devrait en être exactement de même pour le firmware de la carte mère.Non, tu peux restaurer certaines valeurs mais pas toutes car dans certains cas la machine est définitivement briquée donc tu ne peux pas restaurer.
Enfin, tout a déjà été dit, et au delà de la confusion sur les fichier spéciaux, rincer un disque dur n’a pas la même conséquence que de rincer un firmware de carte-mère surtout quand il n’est pas restaurable. J’ai déjà rincé des disques durs, je n’ai jamais perdu de données. j’ai même déjà cramé un disque dur avec une mauvaise manipulation, je n’ai pas perdu de données, je n’ai pas rendu le système indémarrable, j’ai seulement remplacé le disque.
Au delà des arguments les plus techniques, cet argument est imparable. Même dans le cas où l’on se permet de comparer
ddetrmsur un fichier spécial (ce qui n’a pas de sens), la comparaison « donnée standard sur stockage de masse » et « firmware de carte mère » ne tient pas la route, et le faire sciemment tient du troll.ce commentaire est sous licence cc by 4 et précédentes