Slashdot Log In
New Kernel 2.4 Development Branch (-mjc)
Posted by
michael
on Tue Jan 01, 2002 10:51 AM
from the wild-cherry-jello-seems-to-be-the-best dept.
from the wild-cherry-jello-seems-to-be-the-best dept.
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""
This discussion has been archived.
No new comments can be posted.
New Kernel 2.4 Development Branch (-mjc)
|
Log In/Create an Account
| Top
| 197 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
this sounds really cool but (Score:2, Insightful)
Re:this sounds really cool but (Score:4, Redundant)
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.
2.4? 2.5? (Score:3, Insightful)
Re:2.4? 2.5? (Score:5, Interesting)
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.
Real world impact? (Score:2)
Re:Real world impact? (Score:5, Informative)
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.
FreeLinux, OpenLinux, NetLinux? (Score:1, Insightful)
Ok, so maybe I'm just being devil's advocate.
Re:FreeLinux, OpenLinux, NetLinux? (Score:4, Insightful)
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
Linux Fragmentation (Score:1)
news? (Score:1)
New kernel tree akin to ac tree. (Score:4, Insightful)
"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.
Rick van Riel (Score:1)
I just thought I should mention that it should be Rik van Riel, not Rick.
PalmOS -mj branch (Score:1, Funny)
This is a really bad idea (Score:1)
2.4-stable-experimental (Score:1)
Basically it could be a good idea maintaining (read *actively* maintaining) more diverse ports of the kernel tree, though it's more coatic than just having a stable and development branches.
The problematic side of this stable-expermintal tree is locating the cause of crashes when instabilty strikes. When the patches are seperated, it's easier to isolate the cause.
So you want ONLY ONE BRANCH? (Score:2)
It's funny. With all these naysayers who say they only want ONE branch, you have to begin to wonder what the benefits of open source are really supposed to be to them. The ability to grab source and create an improvement is the heart and soul of open source. If you don't like that, do yourself a favor and run windows. Or something.
C//
The *real* question is: (Score:2, Funny)
The reason why these patches are not in ... (Score:2)
Avoid the rush! (Score:1)
What with the recently defunct (?) 2.4.x-ac, the new 2.4.y-mjc, the merged 2.5.z-dj, and also the 2.a.b-aa and others (not forgetting the 'official' kernel), this is getting a bit confusing!
For something like this (-mjc) I'd most likely find it easier to track the particular patches I need for my system, as someone else is unlikely to replicate my exact setup. It's the same reason I compile my kernel in the first place, instead of blindly accepting the distro default.
Is the likely usage of this branch worth the effort of maintaining it? I guess that's up to the maintainer to decide...
Re:Great, more fragmentation (Score:2, Insightful)
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.
Re:Great, more fragmentation (Score:4, Offtopic)
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?
Re:Great, more fragmentation (Score:1)
Debian, for instance, lets you apt-get to what WORKS.
But hey, I don't need XFS when I have EXT3, and I didn't really need EXT3 to begin with, it's just nice to have.
FreeBSD is a distribution. It has a kernel and native apps. Thats essentially what you get with ANY Linux distrib. If you go off course with FreeBSD, you encounter the same problem that you do with Linux.
Re:Great, more fragmentation (Score:1)
Gee, I'd hate to see good design get in the way of tradition. And Linux is incredibly standards compliant. Take system-independent includes for example: in Linux, they are placed in include/linux. Why? Well, presumably so you can't make portable code that works on a non-Linux platform. But I'm sure you already knew that.
Re:Great, more fragmentation (Score:1)
Re:Great, more fragmentation (Score:3, Insightful)
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.
Ugg, try installing ipnat on freebsd.. same thing. (Score:2, Insightful)
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.
Re:Great, more fragmentation (Score:2, Insightful)
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.
good for you (Score:1)
Glad you let us all know, this is such valuable information.
Re:Great, more fragmentation (Score:2, Interesting)
RTM. Seriously. The -ac trees and -mjc trees have their purpose well-documented. For example, if you search the lkml for 'Cohen', his post about the branch comes up, and (in it and a follow-up) he makes it clear what he's doing: bringing a bunch of patches together so you don't have to worry about all of that stuff and can just go to one place. He also states that he wants to keep his branch as close to the stable branch as possible.
About what to do when there's a bug - just save your config (.config - it's in the docs - you did read those, right?) and download/recompile while you're eating dinner or sleeping, copy the new one into place, add a couple of lines into lilo.conf, run lilo, and reboot. Simple as that.
If you're just looking for simplicity and not losing much time, don't upgrade to XFS or worry about which VM you want, but it seems like you want all the exotic new stuff to be already completed, stabilized, and integrated into the kernel. Without having to look at the different branches to see if they've already got it in place. Good luck, you'll need it.
Believe it or not, FreeBSD is also imperfect - it has bugs from time to time (which you said you didn't like about Linux), and (unlikely) security holes (which Linux has also). The fixing process is the same. As long as you just stuck with a stable branch and didn't go for the not-yet-accepted stuff.
And for the rest of the post, that fits the guidelines for troll pretty well (A does this thing better/a different way than B, so A is better than B, etc).
Anyway, please don't take any of this personally, I just get annoyed easily by a lot of stuff like this.
Re:good to help introduce linux to desktops... (Score:1, Interesting)
No, games need developers, and linux doesn't have a game developer community to speak of, so you're hosed either way.
Re:Great, more fragmentation (Score:3, Offtopic)
Great! I'm glad you found an OS that makes you productive and happy. However, those things which you list do not make *BSD a better OS. They make it a different OS. *BSD appeals to a different type of user, imo. Ignoring the masses on both sides and looking at the core userbase that is. Some of us like having flexibility and choice, and we don't mind putting in the time to know all about our system. When that's the case little things like a lot of kernel versions just aren't a big deal.
Linux is not for everybody. Neither is *BSD. Each person has to decide for themselves which system fits their needs and then use it. All this OS bigotry is just ridiculous.
I'm all for proselytizing, and cheering the benefits. The problem (for me at least) comes in when people have this underlying tone of trying to declare one OS better than the other. Isn't it enough that you use it? (speaking generally here, not specifically to the previous poster) Or do you need the masses to agree with you before your choice can be validated?
Re:Great, more fragmentation (Score:1)
Uhm, excuse me, but what the fuck?
At least linux gives you the option of running with XFS, because last I checked that feature wasn't available in freebsd land. Next you'll be complaining that you can't have the NSA's enhanced security features without rebooting your 200 day uptimed computers. Sorry FreeBSDers, there are some things more important than uptime.
Re:Great, more fragmentation (Score:1)
Re:Great, more fragmentation (Score:2, Insightful)
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.
Re:good to help introduce linux to desktops... (Score:2, Interesting)
For those activities, stability is important. There's nothing more annoying than Netscape locking up Win98 when I'm doing something as simple as sending an IM. Linux *never* does that.
As far as whether or not this series is a good idea, I don't know. For me, choosing to use the preemptable patch was simple; I play MP3's while compiling code. A better idea might be to distribute the patches with the latest kernel versions as part of the tarball, and let people decide whether or not they want to use them. If there's concern that a particular patch will lessen stability, put it in the documentation.
Re:Great, more fragmentation (Score:1)
http://marc.theaimsgroup.com/?l=linux-kernel&m=
Here's a tiny summary;
- competition keeps people honest.
- Different taste.
- Different goals.
- And imperfect patch retention.
Re:I'm not so sure this is a good thing (Score:1)
well neither did Redhat