Slashdot Mirror
New Kernel 2.4 Development Branch (-mjc)
Ivo writes: "kerneltrap is reporting: Michael Cohen announced to the lkml his intention to begin a new 2.4 development tree. The first release of his -mjc branch includes a number of performance enhancing patches, including Robert Love's preemptible kernel patch, Rick van Riel's reverse mapping patch and George Anzinger's real time scheduler patch. Michael says of this patch, "I feel that there's need for a rapidly developing '-ac [like]' tree, and so, here we go. Feel free to test it""
That's a question I had, as well... isn't one of the big "selling points" about Linux the fact that there aren't branches and forks everywhere? The appearance of one may prompt the appearance of others. It may not confuse us, but corporates looking at Linux may be stumped by the sudden availability of several different "versions" of the 2.4 kernel. And it's the exact sort of thing that Microsoft loves to make fun of Linux for (I recall a German magazine ad directed against Linux. It showed the same animal 4 times, but each time it had a different head. The gist of the ad was "Code forking is bad, Linux can be forked, so ignore the Win9x/WinNT thing and use Microsoft.").
I think the terminology here should be used very carefully; these are patches to the official 2.4 kernel. Not kernel branches. Branches indicate disagreement between programmers (remember, corporate viewpoint here). Patches are just additions by independant groups, which is far more acceptable to the corporate mindset. I wouldn't make such a big deal of this, but this is a very delicate time for Linux. A lot of people are truly beginning to take it very seriously, and the one thing the Linux community needs to do is present a united front to the people inspecting it. Any indication, real or perceived, of internal turmoil will drive businesses (and individual users) away.
End of lesson. You may press the button.
Read what the maintainer says on the slashdot article:
"I feel that there's need for a rapidly developing '-ac [like]' tree, and so, here we go." --Michael
The -ac tree has moved on to the 2.5 world. He feels the need that -ac filled in the 2.4 world is still there, so he's doing something about it. This really isn't any more fragmentation than there was beforehand.
The -ac tree existed as a 2.4 (and 2.2 before it, and 2.0 before that) testbed (sort of a development kernel in the stable kernel code) that saw a decent bit of testing from developers. People could submit patches to Alan, and they had a much better chance of getting included. After they'd been tested for a few versions, and cleaned up some, and whatnot, the patch would go to Linus for inclusion in 2.4. Michael is offering his services to do the same job now that -ac has moved on to 2.5.
Zapman
Most of the performace patches (pre-emptible, etc) are just patches to the current kernels that the stable kernel's maintainer hasn't accepted, for one reason or another. Chances are, they will go straight into 2.5 so that they can be tested and improved upon.
The reason for -mjc is to allow people to use the performance patches without having to worry about conflicts between the patches, applying them, etc - it looks just like a normal kernel package, except with -mjc at the end.
The -ac series follows the same guidelines - it tends to have slightly fancier features, newer drivers, etc. Every once in a while, when the stable kernel's maintainer decides that the -ac series is stable enough, a lot of the patches that went into -ac are put into the stable series, to get all the new drivers in there.
I doubt that will happen the same way for -mjc, since the patches are more along the lines of getting every little bit of performance possible, instead of having a wide testing ground for new drivers, vm's, etc.
Sure, the free sound drivers could be better (remember, though, that OSS from 4-Front is available for FreeBSD, so this isn't a monumental issue), 3D support isn't fantastic, and quality SMP support isn't going to hit FreeBSD until probably version 5.0.
Regardless, your comment about FreeBSD being an inferior desktop OS is simply, undeniably, completely wrong. The same open source and free software available for Linux (with VERY few exceptions) is available for FreeBSD. If you're a gamer then 3D and sound may be an issue for you, but call a spade a spade, "desktop box" != "game box". When I think of desktop machines, I think of productivity, machines that help you get lots of important stuff done easily and quickly. When I think of game machines I think of Playstation 2s. Sorry, but I would rather spend $300 on a PS2 than dedicate my $2,000 PC to gaming (the PS2 would probably run better anyway).
Yes, I am another Linux --> FreeBSD convert. My machine does run better with FreeBSD, Mozilla actually works efficiently even with debugging stuff compiled in, and I get LOTS less zombie processes and frozen apps, etc. now that I've switched over. And yes, my Linux machine at work runs the exact same software and window manager as my machine at home (except for Mozilla, of course).
Both OSes have their plusses and minuses. Linux is more ubiquitous, but I still think FreeBSD has eeked ahead in some areas. Not all -- Linux will be in the lead for quite some time, I'm sure -- but some.
Rather than poo poo FreeBSD based on game stuff, why not try it as an actual desktop OS?
So how much gain in performance (or apparent performance) should one expect after applying this combined patch? Are the performance gains only applicable under special circumstances? Are they focused more on desktop apps than server?
I doubt you will see ANY performance enhancements with this patch - in fact, under most circumstances, performance will be worse.
The patch MOSTLY addresses a need to have shorter latency responses under linux. So the real benefit will be seen if you, say, run xmms, browse the web on a java intensive site, and do a make -j10 bzImage at the same time. On most machines this will cause xmms to stutter a little - either an audio skip or the text in the scrolling windows will stop and start. With the patch you can expect perfect xmms performance under broader circumstances.
This has the most significant implications for audio and video under linux - things that require short latencies to perform properly. This is questionably the most needed area of improvement for the linux kernel for desktop use.
However, if you time kernel compiles or run lmbench, you'll probably see slightly (but not hugely) worse results. You can expect that changes to address these issues will be incorporated in mainline kernels eventually, although not necessarily in the form that these patches take. Maybe - it will be interesting to see it sort out.
If you really wanted to get technical FreeBSD is heavily fragmented within for the purpose of code creation without toe stepping.
:)
TrustedBSD, SMPng, and KSE stuff were all seperate BSDs (temporarily anyway).
Branching source for the purpose of better co-ordinating development without forcing others to wade through your broken source or wait on you is a good thing.
However, I'm not overly fond of Linux branching for development by indivials rather than for a specific project -- but thats just a labelling issue
Rod Taylor