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""
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.
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.
This is, of course, crap.
Here's a real-world example. The story began early last year. I had a spare PC with USB at the office, so I thought I'd put a couple of Keyspan USB-Serial adapters on it, load Red Hat 7.1, and use it as a console server for our SGI Origins.
Standard Pentium III PC-- no unsupported parts in it. GeForce2 graphics card, but I had no intention of installing X anyway, so minimal support is all that's required. The Keyspan USA-49W serial adapter is, according to the source tree, to Red Hat, and to Keyspan, supported completely under Linux 2.4. I felt pretty safe.
I don't enjoy messing with Linux, but I do prefer XFS to EFS for several reasons, so I thought I'd try SGI's modified Red Hat 7.1 installer that supports XFS. It installed a 2.4.3 (I think) kernel, which wasn't too far behind at that time. I'd used that installer before, so I felt safe with that, too.
I installed the OS, then I put the Keyspans on. They didn't work. Why not? Despite the fact that the Keyspan driver had been installed as a module with the Red Hat default install, it had been compiled with no firmware in it. So I had to load the sources, load the compiler, and recompile the kernel modules to add Keyspan firmware support.
Then I installed the new module and found that one of my Keyspans was working, but not the other. Turns out whichever one was plugged in first worked, but the subsequent ones wouldn't. Driver problem.
Frustrated, I gave up for the weekend and didn't touch the system again for several months.
Earlier this fall, I happened upon a mention of this bug being fixed in the Keyspan driver. Cool. So I downloaded the latest Keyspan driver source and put it on my machine and rebuilt modules. Only the new Keyspan sources wouldn't even compile. I'm sorry that I don't remember the error, but it had to do with the layout of a struct. The 2.4.3 source tree had a different struct than the Keyspan driver expected.
(An aside: it has always been my understanding that minor version changes must not introduce incompatibilities. I mean, that's what 2.5 is for, right? To have a data structure that's laid out one way in 2.4.3 and another, incompatible way in 2.4.9 strikes me as just wrong. End of aside.)
By that time, I thought I understood my problem. I would dump Red Hat with XFS and install vanilla Red Hat 7.1, then install the latest kernel sources and compiler, then install the new Keyspan sources, then compile the module, then it'd work.
Well, it didn't quite work that way, either. What with one thing and another, I was unable to get a working kernel.
Again, I gave up for a few months.
Then SGI released their modified Red Hat 7.2 installer, with a 2.4.9 kernel, so I decided to try just one more time. Install Red Hat 7.2 with XFS, install the sources, install the compiler, install the new Keyspan sources, make the module.
Success.
So I got my system working the way I want it to work, and I'm now very happy with it. But it took me three long weekends, spaced out over several months, and three start-over-from-scratch attempts.
I'm frustrated that Red Hat decided to include the firmwareless version of the Keyspan driver, since it would have been so much simpler to just compile the firmware into the module so it would work out of the box. I'm disappointed that the person who maintains the Keyspan driver was unable to QA his work sufficiently to prevent the only-one-adapter bug from hitting the streets. And I'm mad that a driver module should compile cleanly only under 2.4.9 or later, but not earlier versions. That's not the right way to maintain an OS.
Sorry for the overlong post, but your contention that the distributions are out-of-the-box solutions is just plain wrong.
This isn't meant to be a flame, but more of a wondering-if-you're-here-to-troll-or-not kind of thing, so please don't take this to heart or anything.
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.
No, games need developers, and linux doesn't have a game developer community to speak of, so you're hosed either way.
If you want to establish whether a named poster is a troll, an easy tip is to take a quick look through their posting history. In SumDeusExMachina's case, one will see that he/she/it mainly wades into /. discussions and posts trollish comments, and, in fact, often expresses inconsistent viewpoints in comments attached to different stories. Hence, one might conclude that he is, indeed, a troll.
/. newbie). If he actually has "troll" in his name he's more likely to be a pathetic crapflooder than a troll.
Another tip is to look at the UID of the named poster - the higher the UID, the more likely it is he's an extant troll (although he may well simply be a
You can have the most fun hunting down astroturfing accounts - generally look for reasonable sounding posts that are damning anything that MS opposes (including, but not limited, to linux) with faint praise (I like xyz but...), and the tend to use "clever" email addresses/usernames so that they can identify eachother - such as giving an email of "influencers.org", or "fifther" (for fifth columnist), since they're trying to socially engineer and polarise opinions of the linux crowd (it's easier for MS to fight us if we're all concentrated on one issue, not when we're buzzing about like a swarm of bees arguing about 1000s of different things).
The truth of your conclusions is based upon the truth of your underlying assumptions. Here, yours, AC, are wrong. I'd venture to say that most desktop systems are used for things *other* than games. Personally, I use mine probably 75% of the time on other activities (internet, business apps, music, pr0n, etc. etc).
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.