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.

Comments

The folly of Open Source

[Anonymous Coward]

Open Source has shown itself to be an effective strategy for the implementation of small to medium sized projects. Many eyes, blah blah blah, and the project leader makes the final decision on what goes in. It's very cool.

However, as was discussed on /. before, when projects pass the "medium sized" mark, the effectiveness of having such an open system becomes self-defeating. It's simply a case of too many people having too many different ideas about the direction the project should take.

With closed source, a single person can make all the final decisions about what will make it into the final release, but Open Source has no such system. A person who feels that his ideas are not being taken seriously can fork the project and create his own possibly incompatible tree. This seems to be what is happening now with Linux.

At the early stages of tree forking, there is usually little problem. Most of the forks coexist with each other peacefully with only minor manual tweaking to fix any conflicts. Over time, though, further development along one of the forks will inherently diverge further from the root tree.

The argument that good patches will make it back into the root tree, thus preventing fairly deep splitting, is fallacious. Many of the reasons for forking are precisely because the root project refuses to take a fix from a contributor. What happens afterwards is that users will get 'locked into' a particular strain of the project and will be unable to incorporate other good features that are present in other strains which, for whatever reason, can't be merged into their chosen strain.

Kernel hacking just isn't as fun as it used to be. :-(

Re:It's about the uptime, stupid!

[AaronStJ]

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.


It is about how fast your kernel is, if you want to use Linux on your Desktop. I, personally, don't , for a couple of reasons. One is, I don't have to fiddle with obscure text files every time I want to change some little thing. But the major reason is that when running it in a desktop enviroment (Ximian Gnome, the whole shebang), it's noticiably sluggish. Now from what I've gathered, this is partly due to the windowing system, etc., buty also largely due to VM issues and such like. If you want the average guy to run Linux on the desktop, you're going to have to design a system that doesn't feel sluggish. I hyave a fairly nimble computer. My windows should appear where I want them when I want them, not a tenth of a second later.

Oh, and testing how often a kernel crashes in 100 days? I sure hope your kernel doesn't crash at all is that long. Even my Win2k box can veat 100 days uptime easily.