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""
but i'm afraid it will really confuse a lot of people out there . . . we have the 2.2 kernel tree, 2.4 kernel tree and 2.5 kernel tree already. now throwing in 2.4-mjc? yes extra performance enhancing stuff will be cool, but man are a lot of people going to be confused . . .
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!
Sure, but what if you have a G400 and want 3D acceleration? Bad luck, it (currently) doesn't work without CVS XF86.
What if you want to hear something on your rear speakers with an emu10k1? Bad luck, it isn't supported.
In fact, the drivers for "desktop" hardware like soundcards, 3d accelerators and such are HORRIBLE in FreeBSD when comparing with Linux. FreeBSD may be the better server OS, but it surely is an inferior desktop OS.
So please stop with this "awww.. Linux is sooo shitty when compared to the almighty FreeBSD" crap.
-- The plural of 'anecdote' is not 'data'.
Nothing is wrong with fragmentation. It might be amusing and good to see 3 Linux's on the scene. Hope the reasons for splitting would be more.. friendly than not. After all, has anyone really criticized the existance of 5 BSDs? Net,Open,Free,BSD/OS and Darwin. At least binary compatability would remain, no?
:)
Ok, so maybe I'm just being devil's advocate.
-
ping -f 255.255.255.255 # if only
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
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
I basically went through the same crap to get it working for my firewall. Recompiling kernel on freebsd was not any easier. If you use what works without having to mess with it.. it will be fine. One thing, if you like BSD you might want to try Debian. It's a bit older but everything seems to always work. I use it at work and we have finally standardized all our servers to debian in our server farm (14 machines). Anyway, freebsd is ok.. but I believe that the it being a better server than a linux machine is a myth. The reality is it's probably a little less tempting to mess with so it doesn't have to many problems generally.
Without solid java support FreeBSD is unfortunately disqualified as even an option for me.
I think the development model behind the *BSD's is one of the major plus points over Linux.
Having a group of people control the direction the system takes, and able to commit to the CVS tree, comment on other changes etc, and having every change to the system for the past decade documented goes a long way towards a clean well balanced system, something having a single hacker deciding on everything doesn't provide.
The system of having -RELEASE, -STABLE and -CURRENT branches also makes for well defined areas where new bleeding edge stuff can be put in and tested far away from development systems (-CURRENT), but where changes can be (if possible) merged back into the stable-but-being-changed-carefully branch (-STABLE), and where users who want to stick to known good configs can just hold onto -RELEASE.
The Linux model, on the other hand, relies on two branches - release (even numbers) and development (odd), where the development branches tend to disappear completely when they're most needed (damn our new VM system sucks, quick, put a new one in!).
Maybe once Linux gains the maturity of the BSD's it will have a development model which is more, um, stable.
Your hardware sucks! It's not Linux's fault! Go get some real hardware!
Hey, I hate to have to point it out to you, but if you're using a Winmodem, you *are* using crap hardware. Honestly, they are pimples on the wart that is PC hardware.
Don't get me wrong, I'm using a PC (Athalon-based, so I don't feel too bad) to type this, my servers are 486's and up, and my sexxy IBM Thinkpad has an Linux-unsupported mini-pci winmodem. *I know* exactly how crap they are.
So please, deal with it. Be pragmatic; use what works for you. If you really need to use shite hardware, then be prepared to put up with the inevitable pain that comes along with it. Use the OS that best suits your needs, but don't bitch an moan about software that people write for free, when you're obviously not capable of doing anything about it, even if it was legally possible to support such festeringly putrid hardware.
Will someone please mod this post, and the parent down?
Geeze.
-- "So, what's the deal with Auntie Gerschwitz et all?"
Novell Netware
Blaming GW Bush for the Iraq war is like blaming Ronald McDonald for the poor quality of food.
But I love to hear whining lamers from the *BSD world bitch about linux kernel short commings. Gee, couldn't get XFS running by inmod'ing the binary into a fresh kernel. Well XFS on FreeBSD will save the day? Ooops, no XFS on FreeBSD you say, well that solves your problem. Less features makes it much harder to screw up. No one fooled you, No one advertised otherwise; The misconception comes from rejects from the proprietary OS world where closed-source REQUIRES binary kernel driver compatability.
BTW, bitching about binary compatability of kernel modules, in a open source OS; PuhLeeaase! The linux kernel, of all open source kernels, doesn't give two shits about binary kernel module compatability.
no more retarded Linux VM
Oh lord of all mercy! Commetary from the below 100 crowd, Joy. Linux's VM did have serious suckage, news at 11. But these things become harder when you actually have FEATURES. Like fine grained locking of all the major sub-systems. FreeBSD 4.x is languishing in the BKL world of Linux 2.x. Wow what superior technology! Look at how SMP-ng in the upcoming FreeBSD 5.0 is lagging behind schedule. That is because it is HARD, not EASY. So yeah the FreeBSD VM is well balanced, but it's maintainer admits it's short commings, and BSD as a whole lags far behind Linux in many other areas (like your beloved XFS filesystem).
I'd like to state once more for the non-moron *BSD crowd, that the *BSDs are great and I hope competiion between *BSDs and Linux is as productive as the Gnome v. KDE competiion seems to have been.
-- I am not a fanatic, I am a true believer.
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!!!