What to do with the “rm -rf” hoax question

- You can post questions out of simple curiosity. - You can post rhetoric questions where you already now the answer ( http://stackoverflow.com/help/self-answer ).

It shouldn't matter whether the question was based on a real situation, or if the story was just made up for "motivating" the question [1]. I often (> 50% of the time) make up or change the backstory for my SO posts, to prevent people from asking "But what is your real problem", "What have you tried", and so on, and because I want just a simple answer to my question goddamnit.

([1] Even if it is a hoax, or a joke, the question has merit. Just close as duplicate without getting all worked up about it.)

if one wants subjective questions and answers, there are other sites in stackexchange for that

I wonder what he's making of all of the people now conflating Stack Overflow with Server Fault. Server Fault says its blurb, is a question and answer site for system and network administrators.

Having done rm -fr / on a box before, I think it should stay. The incident was fake, the problem is real, it elicited real responses and has value.

Also, I don't see who benefits from this hoax. Who is going to use him as a hosting provider whether the problem was real or fake. Both indicate that he's not a reliable provider.

Ah yes, the old "rm -rf $TEMPBASEEDIR/lib" bug. It is so easy to have that happen.

Or like I did, write a script that assumes a certain environment variable is set outside the script... and then forget to set the variable before running it!

To prevent these problems, use "set -u" at the top of your bash scripts. This will halt the script instead of silently inserting an empty string if you use an undefined variable.

"set -e" (halt on nonzero return code) and "set -o pipefail" (propagate error returns through a pipe) are also useful options, or combine them with:

  set -euo pipefail

http://redsymbol.net/articles/unofficial-bash-strict-mode/

it was a hoax. a troll. not very far away from screaming bomb on an train.

What happened next? This cliffhanger is killing me.

The problem with this narrative is that it is almost never substantiated. So instead, let me posit an alternative hypothesis, as someone who has gotten his hands dirty on the various Meta sites:

The reason most people feel that SE has a moderation problem is because the moderation process on SE is significantly more transparent than almost any sites out there. And because of this transparency, people find it easier to point blame at these users.

The transparency part I hope is obvious - when a post get moderated on other sites, the full edit history and name of the moderators involved are almost never revealed. The close reasons are in general decided upon by the users themselves. Individual moderation decisions can be contested and debated on the Meta sites, and there are checks on almost every level.

In other words, the moderation process is already fairer than most other sites, where the moderation process is essentially a black box with no means of appeal. But people don't like it because the content which elsewhere would have been swept quietly under the rug is still visible and indexable.

Now it has also been merged with this question. The helpful replies are still there, but the incentive to use the Stack Exchange sites for other purposes is reduced. I think this was a nice solution in this case.

http://www.ee.ryerson.ca:8080/~elf/hack/recovery.html

HN discussion:

Unix Recovery Legend (1986): https://news.ycombinator.com/item?id=10160417 (143 points, 228 days ago, 60 comments)

I wrote Ansible, but no longer work on it.

There are numerous problems with the hoax.

(A) the user skipped --no-preserve-root to the command, if he really wanted to delete /, he would need to try harder on a modern distro, because the rm command would stop the attempt (B) ansible by default fails on undefined variables, meaning it would never execute the command (C) Jinja template variables are actually {{foo}} not {foo}, so {foo} in bash prints a literal foo

So this triply couldn't happen. Finally, most people should probably be using the file module to delete files, though if people want to call out to the shell they can with any config tool.

I hate this was even posted because it reflects poorly on me and was in exceptionally bad taste to imply ansible would let it happen.

But can you shoot yourself in the foot with any config tool? If you want to, yes. Can you be bitten by a bug? Yes. Do tool authors make mistakes? Yes.

But it was a mean thing to do, and it's not something the tool would even allow, and it hurts when tech journalists (arguably some of the worst reporters in existance) blindly parrot the article without fake checking (just like they'll also do fake comparisons that just recycle blog posts).

[1] This was added in 2006, apparently: http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=af...

Question was then about recovery advice.