Slashdot Mirror
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
What you are proposing is a very fascinating concept...essentially, a detailed comparison/benching of various metrics of a kernel's performance performed by an objective third party on a semi-frequent basis (at least, I believe that is where you were headed...).
Immediately, I see a great deal of benefit that could be derived from such a venture for the common Linux user. This information could not only render which kernel is the "fastest", but could also provide information on which kernel design is best optimized for a given task. Effectively, we would have "Open Information on Open Source" (TM).
Alternatively, however, I would never want to see this go to the extreme of a kernel tree being abandoned nor neglected as a result of these "Kernel Olympics" - variety is the spice of life, and IMHO the strength and diversity that drives Open Source!!!
Beer is proof that God loves us and wants us to be happy. -- Benjamin Franklin
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
Ash OS durbatulk, ash OS gimbatul, ash OS thrakatulk, agh burzum-ishi krimpatul! Uzg-MS-ishi amal fauthut burgulli.
From looking at van Riel's comments here, he vehemently believes his kernel is perfect and Moshe just got it wrong... The problem is that lots of people seem to "get it wrong" with that VM, including Linus... Overall in Rik I get the sense of an aggressive person who may have trouble admitting mistakes or accepting failure; not good traits in a programmer, since it's humility and communication skills which can often be the critical factors in a team programming effort... and lack of them can cause exactly the kinds of problems we've observed.
ehh... when i think "top rank" open-source programmer, I think: Theo de Raadt (his early work on netbsd/sun alone is brilliance), RMS (GCC, emacs, etc), Jordan Hubbard (of FreeBSD fame), Linus Torvalds, Alan Cox, etc.
Of that group, Only Jordan and Alan strike me as having "humility and communications skills." Linus is often curt, sometimes cordial, and sometimes very rude. Theo is almost always rude. One look at RMS' TCL outburst and 'communications skills' obviously don't belong in the same sentance with that guy. I'm not trying to troll or flame here, I'm just saying that expecting open source (or Free Software, whatever floats your boat) programmers who run insanely popular projects and who get treated like gods whenever they show up in Slashdot (ooh.. it's Alan, +5 - not that he doesn't usually deserve it), at a Con, or on IRC or something... expecting these guys to have normal-sized human egos is asking a lot. It's clearly asking too much of most of them.
also please note that i'm not slotting rick in next to AC, Linus and John... yet. Just making a comparison.
All Rob was suggesting was a formalisation of a de facto practise. Hardly a fundamental paradigm shift in kernel development.
It did unearth a number of gripes people had; eg. Linus dropping maintainer patches. The thrust seems to be that Linus wants to trust ten or so people, and only accept patches from them. So if Linus is dropping your patches, push them on to a 'trusted' maintainer instead.
IMHO Linus needs to step forward and deal with this a little more assertively. But everyone loves a good bit of controversy, and the Linux kernel is the tall poppy of the open-source community that everyone wants to chop down ...
Ash OS durbatulk, ash OS gimbatul, ash OS thrakatulk, agh burzum-ishi krimpatul! Uzg-MS-ishi amal fauthut burgulli.
The reason VMs usually work well is because most programs don't actively use all the memory they allocate at once, so the VM swaps out the memory that isn't being used. If your program uses all the memory it allocates, the VM has no choice but to use the slow disk to store some of it. No magic VM will solve your troubles.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
I'm going to disagree with this notion of evolution. Evolution is not undirected. The current environment gives a good deal of direction to the sorts of evolution that occurs. For example: evolution appropriate to tropical beaches is unlikely to occur in the arctic tundra.
Similarly, Evolution in the Linux world is also mostly in reaction to environmental needs. Where the difference in randomness comes is that the mutations that lead to biological evolution are generally random in nature -- but environment and statistics choose which mutations lead to enhanced viability.
For Linux, patches are generally in direct response to specific needs. The nature of these changes are directed by nature but generally random in form -- ranging from the icky to the elegant. Fork maintainers like Torvalds and Cox are more like the social interactions which can shift the survivability of an otherwise brilliant mutation/patch. Although this social rejectin will deeply affect survivability, an especially bright change can still give a survivabillity edge that makes up for the rejection
This is really the pleasant aspect of the Linux community; exactly those people who are busy and sought after by many journalists and hackers are also those who take time to answer questions with enthusiasm and a very positive attitude. Thank you Andrea, thank you Alan.
This is something of a chicken and egg proposition. Those people "who take time to answer questions with enthusiasm and a very positive attitude" are precisely those who will likely be sought out by Journalists and others. I mean -- come on! Are you going to take your question to someone who regularly beats into submission anybody who comes to them with (what they consider) a non-profound queston?
Journalists, especially often need their question answered today , and can't be bothered to wait for someone who berates them for half an hour for asking a straightforward question -- especially if they then forget what the origina question was (no known anectdote comes to my mind).
Sometimes boldness is in fashion. Sometimes only the brave will be bold.