Hacker News Reader

Comment by freedomben | Hacker News Reader

My favorite all time bug was the infamous "Bumblebee" commit of 2011[1]. IIRC this was the first github commit to go viral. Make sure you have 30 minutes to read the thread. It is gold.

I have written variants of "GIANT BUG... causing /usr to be deleted... so sorry...." into commit messages over the years. Such a classic part of history.

[1] Commit thread: https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/commi...

[2] Issue thread (not as good): https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issue...

EDIT: Github is timing out trying to load it. May want to use archive.org: https://web.archive.org/web/20130613012555/https://github.co...

View on HN

Hah, that is a good one (and earns sympathetic winces). Though my continuing "favorite" (more amusing in hindsight) similar one was when Apple did that, back in like 2001 with, iTunes 1? iTunes 2? Or maybe it was one of the Mac OS X 10.1 updates, because it was end up of 2001 and I think we'd already had 10.1 by that point, I moved to 10.0 from PB right away and 10.1 was still out real fast. Edit: actually yeah it was iTunes 2.0 end of October/November, I did have that saved somewhere.

At any rate, lots of people at Apple back then brand new to Unix, NeXT was still integrating, everything was still coming together. And they made one of the absolute most classic Unix newbie whoops moments: they wanted to clean up old versions of iTunes, so the used rm -rf... without quoting the path. It had this IIRC:

  rm -rf $2Applications/iTunes.app 2

with $2 as the path. But of course classic Mac users were used to having spaces in drive names and folders and so on. If you only had the startup drive no problem. But if you'd partitioned or had an external drive and it had a space in the name, ie "Disk 1", then that'd become rm -rf Disk 1/Applications/iTunes.app 2 and you were off to the races. There were some fun discussion threads about it, although unfortunately the only Apple Discussions bookmarks I have saved from back then all seem to be dead. Not sure if they're still archived somewhere and the links just no longer redirect or it was cleared out sometime.

They got that pulled real quick too, but I always secretly wondered if the genesis of Time Machine was somewhere around there... backups were pretty rough at that stage of the game. Well, everything about Mac OS X was pretty rough, though exciting too.

Edit 2: Did find an old /. discussion about it that still works. Bit of a blast from the past reading through some of those, both in what has changed and what hasn't:

https://apple.slashdot.org/story/01/11/04/0412209/itunes-20-...

Whoa, I’d entirely forgotten about this. Hard to believe that almost 20 years have passed. It wiped an external drive filled with MP3s and other media. I still have a slight aversion to any spaces in partition/folder/file names.

Reminds me of the time when Steam might remove your whole home directory under some circumstances. This thing happened pretty often in the past and people now actually starting to follow best practices (e.g. adding 'set -euxo pipefail` at the top of the script before doing anything else) when writing bash script to avoid these kind of accidental deletion. Also, I regard `rm` as taboo when I had to do something as root, and use `mv` to move it to a temporary folder instead. I can then clean up the temp folder using unprivileged user later.

If there is anything docker is helping a lot with, this is probably one. Except when you volume mount, but then damage is probably limited!

Or NixOS/Guix, which treat the system as immutable (ie. in Nix pretty much everything but the Nix store at /nix is built after boot anyway). Or macOS by using a read-only system volume.

The grandparent bug is as much a failing of the grandparent's script as the OS, which exposes itself as one global mutable namespace.

Removing /usr isn't all that bad in the grand scope of things. /home is where the important bits typically live, so this would be more of an annoyance than an unmitigated disaster.

In an early experience with Go, while debugging a problem, I realized (with strace) that one of the go commands was attempting to write into the system tree (/usr, /etc--I can't remember now). f###, f###ity, f### f### f###!!!

It didn't succeed because I wasn't 'root'. Maybe it was a local misconfiguration in this company. Not sure. But I've never looked at Go the same way again.

That's the most hilarious diff I've ever seen.

At least it's hilarious now, for some people it must've been horrifying.

Lost in space ...

This is why in general I am not the first to get an update, unless I've been waiting for a fix for a while. I also think how shitty the person must have felt for the screw-up. We all screwed up at some point too, I remember removing a database by accident (it was a Dev, luckily not Prod and i was a junior 20 years ago. ), but having that stick like it does nowadays is not pleasant thought. I learned my lesson, and as a rule of thumb I always comb the code a couple of times before I commit.

Also why web-powered rolling/staggered updates are a thing

Reply on news.ycombinator.com