Hacker News Reader

Comment by windlep | Hacker News Reader

Seriously, no disclaimer that this will hang Firefox, and will likely lock up a system for 20+ seconds before it will let you kill Firefox (linux)? (Thankfully I run linux in a vmware image, so I can go play a game while waiting for linux to figure out the process went rogue)

I didn't realize HN was the new 4chan/8chan. Sigh.

View on HN

I don't know what you expected.

A big label on the page saying "Not really, FF is rock-solid. Have a nice day HN!"?

I just sshed into my computer from my phone to kill firefox, although I probably could have switched to a VT as well.

I continue to be incredibly sad that any OS considers it ok to lock-up the entire UX for a program running amok. Most people would consider such an OS defective, and consider what else is out there, rather than ssh into it. I can't really fault them, I do wonder what is wrong with people making such systems that think this is an acceptable situation.

When a program aggressively allocates memory, buffers must be flushed back to disk, stuff may need to get moved into swap, etc. I/O bound stuff gets higher priority because... I don't know why... probably the throughput is greater that way, or perhaps it's more urgent. Not sure if there's a solution other than having enough RAM that you are never I/O bound. Perhaps if Linux wasn't so aggressive about caching, it would happen less, but things would be slower overall.

The title is named crash firefox isn't it?

Yes, it's not named "lock-up the entire system". I was expecting a segfault, quite disappointed.

There was at least one clue provided by the name of the site...

A crash is not a hang. Firefox never crashed, eventually linux asked if I wanted to kill it, but there was no segfault, no crash.

Reply on news.ycombinator.com