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""
Isn`t 2.5 where the "fast paced" development is supposed to take place? anyway, i`m all for performance enhancing patches.. i run some fairly old hardware here for money saving purposes. The kpreempt patch seems to work well on x86, but it would be nice to see it ported to the alpha.. Is -mjc going to keep up with the performance related patches added to 2.5, and backport them?
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
I don't think there will be a problem, after all the AC branch has been around for a long time. I got from the report is this new branch will replace the AC branch now that Alan Cox has moved onto 2.5 development. Besides I see no reason to srop development on the 2.4 branch just because Linus opened 2.5, people are going to be using the 2.4 kernel for along time to come. So I say Why Not ?
"Our products just aren't engineered for security,"
-Brian Valentine,VP in charge of MS Windows Development
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
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?
When most people think Linux, they think of the operating system as a whole, and on that level we already have many multiple branches and forks. Debian, Redhat, Mandrake, etc...
If I was to pick a big selling point for Linux, it would be based on price and customisability - this branch targets Linux on the workstation whilst the official branch is more aimed at servers, or at least that's how I understand it.
I agree with you to a certain extent that terminology is important. Perhaps it should be given a catchy unofficial slogan, like "Desktop optimised", or "Linux for Workstations", or some such thing.
The whole idea of keeping things like the Linux kernel open is to allow things like fragmentation to happen. If you don't want to use the "-abc" kernels, they're easy to identify, so you shouldn't have any problem avoiding them.
Now, if someone made their own fork and named the files exactly the same as the "real" Linux kernel (i.e. not Alan Cox's, or any other non-Linus blessed kernel), then there would be problems. I'm not worried about this at all. In fact, I'm glad to see others who are either impatient with the slowness of Linus' team or are fed up with the petty bickering over crap like VMs pick up the ball and do things their way. And as always, if these one-off kernels have cool stuff, Linus and his merry men are free to harvest what they like and incorporate the stuff into their source tree.
One person's fragmentation is another person's diversification. This kind of fragmentation gave us multiple Linux distributions, embedded Linux innovations, and a host of other things that lots of folks are thankful to have.
I'm glad you're happy with BSD, but really you could have had the same thing by ignoring the various development trees and optional components and sticking with a distribution you like. The nice people at Debian, Red Hat, Mandrake, etc. will happily test everything for you and make sure it works. Each of the Linux distributions fulfills the same role for the end user as one of the BSDs.
It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. - Abraham Maslow
Novell Netware
Blaming GW Bush for the Iraq war is like blaming Ronald McDonald for the poor quality of food.
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
So this is an official 'fork()' of the linux kernel. It really depends on how they do this. If they take the default kernel or current 2.4.x and add their patches and work with that they can actually send patches back to the main kernel which could make it into 2.5 / 2.6.
Oh and their are more tahn 3 kernel trees, 2.0.x (yes it is still used), 2.2.x, 2.4.x, 2.5.x and the -ac tree, which seems to have gone as Alan stepped aside (I could be wrong about this). There are also ALL sorts of projects out there that have patches to the kernel tree. So what?
The only issue arrises when things like glibc become effected or the kernel structures and people program for a particular tree. If that happens then their could be problems.
Only 'flamers' flame!
Most ./ readers seem to think that it is all about Servers vs. The Desktop.
:-)
I can safely say: IT IS NOT!!!
For a great deal of embedded applications it is a necessity to have lower and deterministic latency. Therefore these patches will raise the acceptance of Linux as an alternative embedded OS.
I guess it will be a long time though before Linux itself will have REALLY low (microseconds) latencies and hard real time behaviour. Right now this can only be achieved with addons like RTAI or RTLinux.
The RTAI and RTLinux addons are really real time schedulers that run the Linux kernel as lowest priority thread. This gives an added complexity for the real time programmer. But maybe this "sandbox" approach is really a good thing and the way to go for hard real time, as it will be almost impossible to guarantee hard real time with a complex beast like the Linux kernel.
But for many applications the latency and quality of service you can get with the patched kernel will probably be enough - so keep up the good work!!!