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""

Comments

this sounds really cool but

[kraada]

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 . . .

Re:this sounds really cool but

[Verteiron]

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.

Re:this sounds really cool but

[NumberSyx]

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 ?

Re:this sounds really cool but

[Synn]

I don't think an extra kernel source tree will really add much confusion. We'll always have the stable base 2.4 and the seat of your pants 2.5. MJC and AC will be something in between.

And MJC will live and die by how well it's mantained.

Re:this sounds really cool but

[(H)elix1]

Maybee I'm a bit of a n00b, but I thought the point of a 2.5 was for new development and experimental code. Bug fixes, stability, and tuning sound great in the 2.4.x series - I _USE_ that kernel series (usually a couple revs behind) for real development work, not just for play on a scratch box that can be fdisk'ed on a whim.

When the 2.5 stuff gets up to snuff, I'm sure we will see a 2.6 released (rebranded, perhaps). By moving stuff into dev that needs to be in dev, we might not have the LONG wait we like the 2.4 series did before it hit prime time.

Re:this sounds really cool but

[uchian]

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.

Re:this sounds really cool but

[NumberSyx]

You are correct, the 2.5 kernel is the development kernel. The difference is the 2.5 kernel is targeted to eventually become 2.6 or possibly 3.0. This new branch -mjc is specificly for developing and testing new features/bug fixes for the 2.4.x kernel.

Re:this sounds really cool but

[xanadu-xtroot.com]

For workstations people are mnore likely to use 2.4 kernels with patches.

Yes, people (read as: geeks) like us /.'ers will. Sure. I'm LITTERALY recompiling my kernel as I type this with the above mentioned patches. But that's not the issue. This is about the (L)users. People who don't or can't know this stuff. To say "people" (read as: general public) I think requires a bit of a disclaimer at the end (so to speak, I don't mean it litteraly). The public doesn't know or care about this stuff, they just want to have the stupid thing work when they press the power button. That's all they know or care to know about "computers".

Re:this sounds really cool but

[RedWizzard]

isn't one of the big "selling points" about Linux the fact that there aren't branches and forks everywhere?

No. None of the major distributions ship with a plain Linus or -ac kernel. They all apply different patches in order to pass their own test suites. And from the point of view of the vast majority of users the kernel doesn't matter anyway - it is the distribution as a whole that they see, and there are literally hundreds of different distributions. As far as corporations are concerned it's a good thing. It lets them choose the distribution and kernel patches that they feel is the best.

Re:this sounds really cool but

[pi_rules]

This is an excellent move to make. I'd prefer that it be accomplished with compile-time directives[*] rather than another series of kernels but it's still a great move.

This is -exactly- what MS does with their kernels. It's really a great move. Think Win2k pro, server, advanced server, and datacenter server versions. They have different kernels. Different schedules, different priorities. It's great. It scares some people but the thing to remember is that there are NO API CHANGES going on here. It doesen't matter if you're running the -ac tree, the Linus tree or this new one. The application doesn't even need to be recompiled to move kernels.

*Doing something like that would be a coding nightmare and things would be -really- ugly looking. The pre-empt patch touches alot of places in the kernel and I'd hate to see code with a bunch of #ifdef's splattered about. When I say it'd be nice I mean nice from a user point of view, not as a coder or somebody who cares about things working right.

Re:this sounds really cool but

[BRTB]

Slackware has always used an unpatched kernel and managed to keep its high stability level intact... (the Reiser patch in Slack8 being the only exception I can remember, and it was unnecessary unless you were using a Reiser FS)

Of course you may not think Slack's a major distro, but there are those who would beg to differ ;)

Re:this sounds really cool but

[jdavidb]

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?

Good question, and good points. For me, though, one of the big selling points of Linux is that there can be branches and forks. The "right to fork," to me, is what makes free software free and what makes free software better. (That's why I've decided the GNU/Linux vs. Linux debate is all wrong; just call Linux a fork of GNU.)

The thing is, we just have to learn to fork in a civilized manner and not give bad impressions to the outside world. It looks like this is an excellent example of a civilized fork (but I don't read lkml, so there may be same flaming over it; who knows). Along with you, I hope it doesn't give the wrong impression to the outside world.

Re:this sounds really cool but

[psamuels]

This is -exactly- what MS does with their kernels. It's really a great move. Think Win2k pro, server, advanced server, and datacenter server versions. They have different kernels.

Is that so? (If so, good move.) NT4 didn't. NT Workstation and NT Server shared the same kernel - or kernels, actually, a UP kernel and an SMP kernel.

Considering the quite different instruction scheduling properties of the Pentium/Pentium-MMX from CPUs that came before and after it, the fact that MS doesn't ship kernels compiled to optimise for a given CPU must have hurt. I don't know if they have any other measures to compensate.

("Must have hurt", past tense, because they almost certainly no longer optimise for a Pentium, if they ever did. And subsequent Intel CPUs are much more "compatible" in the optimisation sense.)

Re:this sounds really cool but

[psamuels]

but i'm afraid it will really confuse a lot of people out there

Yes but confuse which people? If you aren't willing to keep up with the issues of 2.0.x vs 2.2.x vs 2.2.x-ac vs 2.4.x vs 2.4.x-ac vs 2.4.x-mjc vs 2.5.x vs 2.5.x-dj, you will probably do just fine running your vendor-installed kernel, which is yet another branch, generally.

Now I don't get confused about those eight major branches - but hey, what a coincidence, I'm the target audience for some of those branches.

Does anyone in the real world care about the two branches of HP-UX 11.00? That is, the standard release and the ccr builds? What, you say? You've never heard of 11.00-ccr? My point exactly. Most people don't need to know or care.

Re:this sounds really cool but

[scrytch]

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).

Spin. They are branches. Ask AC or Linus, they'll call 'em branches, and AC will tell you chapter and verse where he thinks Linus is a complete bonehead for doing or not doing x, y, or z and why it isn't that way in -ac. They're all binary compatible with each other, they're configuration differences, not architecture differences. What they're not are forks. LinuxPPC and ucLinux, to name a couple, are forks.

2.4? 2.5?

[Bert64]

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?

Re:2.4? 2.5?

[GregWebb]

Re-read, wrong bit is fast :-)

2.5 is for bleeding edge development, pushing linux into the future. 2.4-mjc is a funny 2.4 which is focussing on improving system performance.

Not sure whether this is a good idea (heck, doesn't affect me much, using Win2K here...) but that's what's going on here :-)

Re:2.4? 2.5?

[Zog]

Is -mjc going to keep up with the performance related patches added to 2.5, and backport them?

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?

[thing12]

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?

Re:Real world impact?

[NumberSyx]

Now this is the question of the day. I never used the AC kernel because I prefered to stick closer to stable tree, but I did add patches as I needed them. The VM stuff did wonders for me, but the PreEmpt patch made no noticable difference, probably because I use a dual processor system.

Of the included patches; Reverse Mapping patch #9, Preemptible Kernel Patch, Lock-Break Patch, CPU affinity /proc entry, Netdev-random, Software Suspend, Real Time Scheduler for Linux, IDE updates. Which ones can we expect to have an impact on preformance ? and which ones simply fix a long standing problem ?

Re:Real world impact?

[blakestah]

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.

Re:Real world impact?

[psamuels]

but the PreEmpt patch made no noticable difference, probably because I use a dual processor system.

Agreed, SMP makes preempt a lot less necessary.

Of the included patches; Reverse Mapping patch #9, Preemptible Kernel Patch, Lock-Break Patch, CPU affinity /proc entry, Netdev-random, Software Suspend, Real Time Scheduler for Linux, IDE updates. Which ones can we expect to have an impact on preformance ? and which ones simply fix a long standing problem?

I'm not sure about all of them, but:

• Reverse Mapping: not sure if it helps VM performance by itself but it was designed to make it easier to perform certain VM-related optimisations.
• Preemptible: you know what this one does - for UP systems in particular, should give lower latency. Good especially for smoother interactive feel (eg. mouse movements) and multimedia (eg. no-skip sound playback). Small performance hit.
• Lock-Break: not sure what this is. I think it's about bug reporting - shouldn't be noticed in real life.
• CPU affinity /proc entry: lets you associate a specific job with a specific CPU. "If you don't know whether you need it or not, you don't." Used to override the scheduler when you think you're smarter than it.
• Netdev-random: collect entropy out of incoming network packet timings. Good especially for a headless, diskless server (like a floppy-based router) because most of the usual sources of entropy aren't present. Bad in that an external source can control your entropy input - considered a security risk by purists. Linus rejected this one because of objections on L-K by Ted Ts'o and others. You shouldn't need this on the desktop. Probably minimal performance impact.
• Software suspend: save memory and device state to disk before letting a laptop (or a desktop I suppose) go to sleep or shut down - then restore on wakeup / bootup. Probably no performance impact, just a new feature. As you'll know if you use this on Windows 98 or Win2k, reliability is a big problem with this sort of thing thanks to its extreme dependence on hardware behaving to spec on power management issues.
• Realtime Scheduler: allow a process to hog the CPU and have it basically any time it wants. Again, probably for multimedia purposes, or data collection, or other real-time tasks. I don't know the implementation details, or how hard the guarantees are.
• IDE updates: Andre Hedrick and Linus Torvalds, um, do not get along very well. It's not personal (or not only that), Linus doesn't like Andre's philosophy of development - Andre sits on the IDE standards board, and in Linus's opinion trusts the standards too blindly - whereas Linus comes from a background of assuming that hardware won't follow its specs so you have to dig in and figure out what it does not just what it says it does.
  This adds up to the sad fact that official 2.2 and 2.4 kernels are never even close to up-to-date w/r/t Hedrick's IDE work. New IDE drivers, random bug fixes, etc.

HTH.

Re:Great, more fragmentation

[entrox]

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.

New kernel tree akin to ac tree.

[Zapman]

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.

Re:Great, more fragmentation

[entrox]

But of course: because it isn't supported in FreeBSD it OBVIOUSLY isn't needed and unimportant. Who in their right mind would use them anyway, right? Must be some Linux weenies who should use Windows anyway.

Re:Great, more fragmentation

[erat]

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?

Re:Linux Fragmentation

[erat]

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.

Re:Great, more fragmentation

[Ami Ganguli]

Hmmm... I wonder if I can run XFS without recompiling... Nope, looks like I'll have to upgrade the kernel. But wait! Do I use the -ac kernel with its new VM or do I use the main branch with the most "standard" stuff? Oh crap, looks like 2.4.whatever had a really bad bug by default, and they didn't fix it until 2.4.later. Shit, I don't have the time for this.

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.

Re:Great, more fragmentation

[phaze3000]

Which meant I had to transfer EVERYTHING over to a spare Windows 98 machine while I sorted out the whole mess. You know what I would have had to do in FreeBSD? I would have had to just turn on Soft Updates. No screaming and pulling hair, just messing with a config file or two.

In FreeBSD, if the file system was dead you would have had to do exactly the same thing.

In Linux, to convert an ext2 partition to ext3 you only have to do tune2fs -j. If you're running a kernel that doesn't support ext3 you need to upgrade to a new one of course, but that's really nothing too major, an apt-get install will sort that out for you.

Ugg, try installing ipnat on freebsd.. same thing.

[Pengo]

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

[Fweeky]

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.

Re:Great, more fragmentation

[mike_sucks]

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.

Re:FreeLinux, OpenLinux, NetLinux?

[sporty]

Well, I mean compatability for just common executables in elf format. So no, kernel modules may not end up being compatable in the very end of things, but gcc would have to write the same ASM and hopefully the same glibc will stick about. So in the end, the only big difference is how memory is addressed, how task switching works, swapping.. all of those things that matter except in the binary code being read off of the disc.

Re:Great, more fragmentation

[foobar104]

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.

Re:Great, more fragmentation

[Zog]

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.

Re:Ugg, try installing ipnat on freebsd.. same thi

[Pengo]

As far as solid Java support, FreeBSD does support Java, as reported in this Slashdot article.

In my experience, Java on BSD doesn't scale. It core dumps often under load and performance isn't that great compared to linux (especially with IBM JVM). Linux api layer is not a smart thing to use on a production box imho... especially when my sleeping habits are at risk.

I haven't seen any real influence from the Stalin er *cough* Stallman side to negate the good experiences with the software. Most of my debian boxes are headless and on a high speed connection. Their package manager is a dream. (yes, I personally like it better than the bsd ports system.. and after figuring out the horid dselect tool find it strangely simple).

I agree though, for all the stalman might do for the world... he is enough to make me want to disassociate myself with the linux community as a whole.

Anyway, I am glad that bsd works well for ya.. I have used it in the past and never really had any problems with it other than lack of java support. I do enjoy hacking around on my wifes g4 w/OSX and will probably put osx on a ibook we have sitting on the shelf seldom used.

Cheers... happy new year.

Re:Great, more fragmentation

[Mark Bainter]

[snip] Just the other night I decided to dump Linux off my home machine all together and went with FreeBSD. [snip] I have absolutely no regrets.

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:Ugg, try installing ipnat on freebsd.. same thi

[phaze3000]

Novell Netware

Re:Ugg, try installing ipnat on freebsd.. same thi

[rtaylor]

ipnat, ipf, and various other tools of that nature have modules installed by default.

Looking forward to the day when kernel modules are a 'load on use' resource. That is, if you try to access /dev/snd it'll load sound drivers until it finds one that works and goes with it. devfs will do some of that, and the rc.conf options also do some of it (in 4.3 or so it does for ipnat).

echo 'ipnat_enable="YES"' >> /etc/rc.conf

The above should load the ipnat kernel module and get you on your way at the next reboot.

NOTE: The above statement depends on ipfilter running, so:

echo 'ipfilter_enable="YES"' >> /etc/rc.conf

may be required as well depending on current configuration.

Re:Great, more fragmentation

[rtaylor]

To achieve 3d acceleration for the G400 on FreeBSD one needs to install XF86 from the ports tree (or the package -- as they're generated from the ports tree).

Next install the graphics/drm-kmod port.

Either reboot, or run:

/usr/local/etc/rc.d/drm.sh start

then restart X (if its running, otherwise start it).

glgears should get several hundred fps on a G450. Total time from install to 3d support was around 3 minutes for me -- most of that shutting down and starting X (many many applications run by default for my configuration).

Re:Great, more fragmentation

[Ami Ganguli]

I don't see how any of this is relavent. What you're complaining about is that:

• The packaged kernel doesn't have all the latest features and drivers.
• Some drivers have bugs.

This is of course true. That will be true of any system. Obviously you're going to give up something in the trade-off between "easy to use and stable" vs. "bleeding edge".

your contention that the distributions are out-of-the-box solutions is just plain wrong.

No it's not. Distributions are the out-of-the-box solution. Your problem is that you aren't satisfied with the out-of-the-box solution. Would you have faired better with one of the BSDs? Do they even have XFS?

Re:FreeLinux, OpenLinux, NetLinux?

[rtaylor]

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 :)

Re:FreeLinux, OpenLinux, NetLinux?

[sporty]

You are absolutely right.

I guess what it really comes down to is when the best of the best of all the branching is found, is it possible to remerge and is it in thebest interest to.

Hey, maybe the individuals may "lead the way" for certain projects in the end.

Re:Great, more fragmentation

[foobar104]

Obviously you're going to give up something in the trade-off between "easy to use and stable" vs. "bleeding edge".

If I were trying to do anything "bleeding-edge," I'd be the last to complain. As it is, I was trying to use supported (whatever that means in this context) hardware with a packaged distribution.

My point is simply that the distributions with which I have had experience (not all of them, by any stretch) are incomplete. They do not support, out of the box, everything they claim to support.

A counter-example is my QL2200 fibre channel adapters. Thanks to Red Hat, those suckers work as soon as you plug them in.

That level of functionality should be there for everything on the "supported" list. It doesn't appear to be.

Re:Great, more fragmentation

[swright]

er, G400s are supported fine in Linux... (from the posts above it appears not in FreeBSD)

WindModems are shite because they do all the signal processing in software - so you take a CPU hit and a transfer rate hit. Much better to have a real modem (for like $5 more..) that does it in hardware, no bandwidth loss and no CPU wastage...

Re:FreeLinux, OpenLinux, NetLinux?

[MikeBabcock]

The Devil understands the situation better than you do, and since you mentioned Darwin, read up on Linus' thoughts on how the Linux kernel evolves, it might help.

See, the -ac series was a testbed series of kernels, often used in practice, as patches to the mainline kernel. It was not a fork, and neither is this.

2.4.5-ac3, for example, would be Alan Cox's third patch release to Linus' 2.4.5. Now, Michael will be doing the same thing with Marcelo's kernels.

Re:Great, more fragmentation

[LunaticLeo]

DISCLAIMER: I do this cuz I like flamage. FreeBSD is a decent and valuable OS.

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...

[idiotnot]

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.

Re:Great, more fragmentation

[Howie]

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?

Amen! This attitude characterises any number of 'religious wars' in the geek world: emacs vs vi, amiga vs st (going back a bit), mac vs pc.

I have favourites in each of those (pc, st, emacs), but I don't care if you like them or not - why does it matter?

Re:FreeLinux, OpenLinux, NetLinux?

[sporty]

Oh, I understand the role that -ac holds, but if anything, FreeBSD and -ac have similarities in that they are used more than OBsd and NetBSD for adding new features. I'd suspect that the non-branch more akin to NetBSD. Only difference between BSD's and Linux is that the -ac stuff gets put back into the "main branch".

It wouldn't be bad in the end if Linux did fork though.

Re:This is a really bad idea

[josepha48]

Not really. This is really no different than Redhat having their own kernel that they ship with their distribution. They include none standard patches. They were including ext3 before it became part of the default tree. They include lmsensors, and many other patches. SuSE does (or used to when I tried their distro) ship their own custom kernel.

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.

So you want ONLY ONE BRANCH?

[Courageous]

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:

[soupforare]

Will this new dev patch increase performance when playing Linux Quake on my 486DX/2??

Re:Great, more fragmentation

[Ami Ganguli]

They do not support, out of the box, everything they claim to support.

Ok. I see what you're saying. Sounds like a quality issue with Red Hat. Certainly if it says on the box that it's supported then it should work.

What I was trying to say with my original post was that Linux distributions fill the same role as the *BSD distributions. They represent the safe, stable solution for the end user.

Good news for embedded applications!!!

[PastaAnta]

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!!! :-)

Re:Great, more fragmentation

[foobar104]

What I was trying to say with my original post was that Linux distributions fill the same role as the *BSD distributions. They represent the safe, stable solution for the end user.

Okay, I'll buy that. I only wish in my case my choice of distribution and hardware had been safer and more stable.

Re:Great, more fragmentation

[Billly Gates]

I like Freebsd technically and the more stable development model. But its a pain in the ass to setup and until version 4.5 shows up, java support sucks. I recently purchased FreeBSD 4.4 and it does its job fairly well but as I workstation I need to setup every menu item manually. Quite unacceptable when you have over a thousand apps installed. With Linux distro's the menu items under the window managers are already setup. After the install just start x and all your apps are there. Under WindowMaker you can select sample menu's and drag your distro's name into the main menu and voila. All your program menu's are there. Also I never installed the freebsd ports collection without an error causing the installation to pause. This means I can't do an unattended installation and that all the software I select will be installed. Its a painfully slow installation as a workstation OS. Also I need to select each package manually on the other cd's which is a huge pain in the ass when dealing with dependancies.

Linux has proven to be questionable as a server os thanks to the recent bugs found in all the patches. A year ago I would but my job on linux as a server OS but today I would not. But as a unix workstation I would have to pick linux untill Freebsd becomes more desktop friendly. Freebsd is great technically but its hampered by the elitists attitude by the developers who only think about server use.

Try doom

[Billly Gates]

I personally like doom1 better then quake1 and I find the graphics better. Doom1 and Doom2 run fluidly on 486 systems with decent video cards. You would need the windows program Kali to play an internet game. I don't think there is a linux equilivant. Doom1 and Doom2 are freely available now and there is an active linuxdoom port believe it or not. Just don't download the really old one from idsoftware. ITs not compatible with any linux version above 1.1x. Try Tkdoom which is currently under active development and should run on modern linux kernels. It may eat up memory on your 486 though.

Re:Great, more fragmentation

[Billly Gates]

Maybe its time you use a real distro.

dumbass

[Ender Ryan]

The Linux development process is much, much different from *BSD, different but not worse or better. If you want to always have a stable kernel, use a distro and only use the updates specifically for that distro, which is equivalent to what you do when you use *BSD. Debian is an excellent distro, RedHat is pretty good, Slackware rocks(not for what you want, really), Mandrake is good, etc.

If you don't want to keep up with kernel development in Linux, you don't friggin have to, so STFU, you're full of shit.

note: My apparent hostility is not actually real, I'm only being halfway serious, so, no offense is intended.

Re:Great, more fragmentation

[defile]

You know what I would have had to do in FreeBSD? I would have had to just turn on Soft Updates. No screaming and pulling hair, just messing with a config file or two.

Messing with a config file or two!? Dear god man, while you're at it, why not build an atomic bomb out of household appliances?!

We don't all have the luxury of beaming our servers up to the Enteprise so Captain Kirk can reconfigure them. Fortunately, we do have Debian:

# apt-get install kernel-image-2.2.19-ext3
# tunefs -j [partition goes here]

Since the occasional Slashdot reader is humor impaired [not to claim that I'm funny], the moral of this story is that sys admin tasks are all relative, and difficult to measure fairly. FreeBSD rules, Linux rules, let's all hug and eat pudding.

Re:Great, more fragmentation

[ameoba]

WTF would you even bother going out of your way to add an advanced filesystem to a machine that was essentially being a dumb text terminal?

The reason why these patches are not in ...

[KidSock]

a stable Kernel is because the're not stable or they're not a performace enhancement. Robert Love's "preemptable kernel patch" will crash an SMP system with certain drivers. If you have a UP system or you know your hardware is kosher then you'll be OK. I don't think it's for production systems. It's more of a desktop performace enhancement. As for Rik's reverse mapping VM code, the last graphs from Safemode (it's a person), showed Andrea's VM still performed better. In fact, Rik's code still has problems on low memory systems (caused a lockup in one of Safemode's tests). But of course it's good to see these patches getting some visability. They might prove to be useful after some time.

Re:Great, more fragmentation

[foobar104]

WTF would you even bother going out of your way to add an advanced filesystem to a machine that was essentially being a dumb text terminal?

I'm an SGI guy. My life is easier if I only have to keep one set of filesystem commands in my head. Since the option was there, a better question would have been, "Why not use an advanced filesystem?"

Re:This is a really bad idea

[psamuels]

By adding more trees, kernel development will be slowed way to much. Lets concentrate on standardizing, not fragmenting the kernel.

No offense, but are you saying this as a kernel developer, or as a bystander? The developers themselves don't seem hostile to multiple trees at all - they usually maintain their own tree anyway. And judging by how many people developed against 2.2-ac rather than 2.2-linus, I'd say they like working that way.

The drawback here is if MJC doesn't accept responsibility for merging patches upstream to Marcelo. Alan has always been very good about this.

The different tracks for this new tree aughta be incorporated into the 2.5 tree.

Some of the patches in -mjc are being considered for 2.5 - some are not - for technical reasons. A maintainer doesn't have to choose between supporting 2.4 and 2.5 - why not do both? And if you want to support only 2.5, let MJC do the backport to 2.4. Conversely, if you want to support only 2.4, let Dave Jones do the forward port.

Sounds like a good system to me.

Re:Great, more fragmentation

[psamuels]

Linux has proven to be questionable as a server os thanks to the recent bugs found in all the patches. A year ago I would but my job on linux as a server OS but today I would not.

Out of curiosity, what changed? The kernel you were so happy with a year ago - did it suddenly fail to work?

Or are you saying current kernels aren't as stable as the then-current kernels? If that's the case, just keep using those. I don't think I've ever heard anyone complain about the stability of 2.2.16 - 2.2.20 - people complaining about kernel instability are generally referring to 2.4. The 2.2 series isn't dead yet!

Re:Great, more fragmentation

[psamuels]

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.

Actually, that's system-dependent includes, and the reason is historical. Five years ago you had to #include<linux/*.h> for quite a few random things ... but that was five years ago.

The world changed - glibc 2.1 came out - and nowadays you should never include <linux/*.h> except for OS-dependent stuff like CD burner software. The reason the directory still exists is that other files in /usr/include make use of it - but that's an implementation detail which as a mere software developer you shouldn't have to worry about.

Re:Ugg, try installing ipnat on freebsd.. same thi

[ThatComputerGuy]

Java on Netware 5 is amazingly slow... It's make you wonder, "WTF were they thinking??"

Re:Great, more fragmentation

[erat]

Out of all the folks I know with computers at home (that includes pretty much everyone I know except for some of my older relatives), probably 10% focus on gaming. The rest are using their computers in their home offices, or for Internet access, or for hobby/craft stuff, or even dinking around with programming (retirees mostly).

"Wager" all you want; my observation is you'd lose your bet. Most of the folks I know who have computers have digital sound cards and video adapters with >=32MB RAM, and all but about 10% of them do anything that requires even minimal video and/or sound. I view the inclusion of such hardware a tax much like many of you consider the inclusion of MS Windows a tax. Good luck downgrading, too. PC builders don't like that.

I guess you and I walk in different circles. C'est la vie. (Don't call me an elitist, though. Ever. I can oppose your opinion without being an elitist.)