Quotes of the week

[Posted November 18, 2009 by corbet]

Well the purpose of the kernel isn't to provide an idiot filter, that is what the security policies and not giving people root is for.

-- Alan Cox

The lesson learnt here? Panic makes for poor decisions. I sent one patch what looked great at the time but have found out in the last few hours that it really sucks. While figuring this out for sure, I have to wait looking at a screen to painfully slowly update. To help the waiting, I found some beer, it's the Irish thing to do. Wonder what the rest of ye do.

-- Mel Gorman

Or to say in a more sarcastic way: the most visible effect the extra code you have to write for making things OOM-safe will be that due to higher memory/address space consumption the OOM situation will be coming earlier then without it.

-- Lennart Poettering

Yes, I realize it's ugly voodoo magic but dammit, it used to work!

-- Pekka Enberg

Quotes of the week

Posted Nov 28, 2009 21:13 UTC (Sat) by oak (guest, #2786) [Link] (1 responses)

Lennart's whole mail on why and when not to handle allocation
failure "gracefully" is quite good.

Quotes of the week

Posted Nov 28, 2009 23:54 UTC (Sat) by nix (subscriber, #2304) [Link]

Exactly. *If* you test these things (look e.g. at sqlite for a clue as to
just how hard that is), then that's one thing. If you don't have a
malloc() that can inject OOM on demand, and don't use it to force your
allocations to fail individually, then error-checking them is pretty much
a waste of time, at least if you do anything but quit. (I *have* found
that reporting which allocation failed can be useful in cases where a bug
leads to runaway allocation. But there's still little point doing anything
but exit(1) afterwards. Let some higher layer in a monitoring process or
something like that handle recovery.)