Byte Benchmarks Various Linux Trees
urbanjunkie writes: "Moshe Bar has an interesting article, essentially benchmarking the standard kernel (with aa VM) against the -ac kernel (with Rik's VM)." He also raises some very interesting points about how patches (and entire development trees) interact.
Interesting. I've not managed to run into bugs like that on my computers here, so you must be running a very different workload to trigger such a bug.
Would you have the time to help me debug this problem and is it still happening with the latest rmap VM ?
C'mon guys. Show a little open-mindedness. One of the things I really missed from the Windows world when I switched to Linux was the "Windows Update" feature. Want to install the latest security or feature patches? Click a check box and hit "install". No dependencies, no patch conflicts, no esoteric config options, it just worked. Admittedly Ximian's Red Carpet comes close, but it's still a little quirky sometimes.
I know there will always be those people who want to manually tweak their kernel (god bless 'em!). There's a lot of us, though, that don't want to deal with it. I'd rather have one-click shopping for all of my patch needs so that I can spend more time writing code or playing Quake. MS understands this. Apple understands this. Why doesn't the Linux community understand?
This
A major problem with alot of linux admins is shown in the article. It's not about how fast your kernel is, especially when it comes to a 2 second difference in 50 seconds of computing time, but how long your machine will stay up.
If a user compiles 35 gigs of code on a 6 processor box and it takes 5 minutes longer, he is not going to complain. If he compiles 35 gigs of code on a 6 processor box and it crashes half-way through the compile, your going to here it from your boss.
Benchmarking kernels is plain pointless. Take a machine for each kernel, put it under real load and tell me how many times it crashes in 100 days, and I will you which kernel I want to use.
Linux O Muerte!
I take your points about forking, but as a counter-example I'd think about the BSDs instead. They all operate under the same license, all forks from roughly the same code base.
The advantage here is that with three BSDs you have three separately-tuned operating systems that attack different problems very well, yet maintain a certain level of commonality and compatibility.
Call me a starry-eyed optimist, but my exposure to this open source fad started with the Wired article in the autumn of 1997. In it the writer painted a picture of a 'computing epic', one collectively started and maintained. I still think that metaphor is accurate and useful.
========================================
Death will come, and will have your eyes
-- Pavese