New Kernel 2.4 Development Branch (-mjc) 197
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 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.
Re:this sounds really cool but (Score:3, Insightful)
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 (Score:1)
Not exactly, but thats probally how it works out in practice. Production servers tend to require 5 9's of reliability. If the latest kernel patch that provides better page swapping or whatever isn't as throughly tested as the 2.2 or 2.4 kernel, its not going to be incorporated into your production servers. However, for your workstations, having to restart X to get rid of memory leaks once a month or so isn't that big a deal. For workstations people are mnore likely to use 2.4 kernels with patches.
Re:this sounds really cool but (Score:2, Insightful)
Yes, people (read as: geeks) like us
Re:this sounds really cool but (Score:1)
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.
There are others. Lots of others. Always have been. Those branches are essential to the development of Linux, as Linus explains [theaimsgroup.com]. It is important to note that all those branches are compatible: their implementation is different, but they all look the same from userland.
I think the terminology here should be used very carefully; these are patches to the official 2.4 kernel. Not kernel branches.
The terminology is used very carefully. Patches and branches are two quite different things.
Re:this sounds really cool but (Score:2)
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 (Score:2, Informative)
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 (Score:2)
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 (Score:2)
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 (Score:2)
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 (Score:2)
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.
Re:this sounds really cool but (Score:3, Insightful)
Re:this sounds really cool but (Score:2)
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 (Score:2)
Re:this sounds really cool but (Score:2, Insightful)
And MJC will live and die by how well it's mantained.
Re:this sounds really cool but (Score:1, Offtopic)
If there are different goals, not a bad choice for fragmenting.
Re:this sounds really cool but (Score:2)
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.
2.4? 2.5? (Score:3, Insightful)
Re:2.4? 2.5? (Score:2)
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? (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:2)
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? (Score:2)
Agreed, SMP makes preempt a lot less necessary.
I'm not sure about all of them, but:
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: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.
Good news for embedded applications!!! (Score:3, Insightful)
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!!!
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
Re:FreeLinux, OpenLinux, NetLinux? (Score:2)
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:FreeLinux, OpenLinux, NetLinux? (Score:2)
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:FreeLinux, OpenLinux, NetLinux? (Score:2)
It wouldn't be bad in the end if Linux did fork though.
Re:FreeLinux, OpenLinux, NetLinux? (Score:2)
Linux Fragmentation (Score:1)
Re:Linux Fragmentation (Score:3, Insightful)
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.
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)
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)
Try doom (Score:2)
The reason why these patches are not in ... (Score:2)
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)
I wasn't bashing FreeBSD as a whole and just pointed out some flaws. There is enough stuff that FreeBSD got 'right', but after my experience with it, I find these "Linux is crap" unjustified.
hear, hear! (Score:1)
If you are a beginning unix user and have no clue about hardware and software in general, you're probably better off choosing linux. That way you can use a friendly, brainless distribution, and chances are your hardware will be supported no matter how wierd it is.
If you are somewhat clueful, then you're probably better off with freebsd, *assuming* that you have fully supported hardware. This may not have been the case a few years ago when the desktop was still pretty primitive, but these days the desktop is just as good as linux and unlike linux freebsd comes with a ports tree, which is awesome.
Re:Great, more fragmentation (Score:2)
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.
Re:Great, more fragmentation (Score:2)
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 (Score:2)
Re:Great, more fragmentation (Score:2)
"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.)
Re:Great, more fragmentation (Score:2)
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 (Score:2)
Re:Great, more fragmentation (Score:1)
Let's try changing a couple of words there and see how it sounds:
But of course: because WinModems aren't supported in Linux they OBVIOUSLY aren't needed and unimportant.
This is exactly the kind of crap I got when I tried to get my modem to work under Linux. "Your hardware sucks! It's not Linux's fault! Go get some real hardware!"
Re:Great, more fragmentation (Score:2, Insightful)
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:Great, more fragmentation (Score:1)
They both work fine for me under Windows and they are both unsupported in Linux. What's the difference again?
Re:Great, more fragmentation (Score:1)
In any case, the reason Winmodems "work fine" under Windows is because the manufacturers have released drivers for them. In almost every case, they will not release the specs for the hardware interface because they want to protect their IP (god knows why, they're only winmodems). Some manufacturers (Lucent, IBM[0]) have released Linux drivers for their weird-arse modems, and they also "work fine". Again, I'm talking from experience here[1].
Now, it so happens that, IIRC, G400s do work under Linux, and AFAIK, work as well as you can expect for a G400. FreeBSD support is under question here, but if support is in CVS, it will get released soon enough. Still, the fact that G400s work under Linux has nothing to do with vendor-supplied drivers, it's because people cared enough to write the driver for it. The reason you don't see this happening with Winmodems is because of the afore-mentioned suckage; people don't care about winmodems, so they're not going to bother writing drivers for them. It's much easier to buy a real modem in the first place.
So, if you really care about winmodems, please, feel free to write a driver (the Linux/BSD source is there, so is gcc and emacs).
Mike.
[0] - actually, IBM's mwaves are pretty good, they're diametrically(sp?) opposed to winmodems, but they're still sucky for being proprietry.
[1] - my old TP had a Lucent winmodem.
Re:Great, more fragmentation (Score:1)
Re:Great, more fragmentation (Score:2, Informative)
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: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)
Oh, you don't need it, it's just nice to have? Tell that to my boss. I do occasional consulting for a small law firm where I installed Debian as a fileserver for the Windows clients. Great idea, right? Wrong. Since the stupid office people just hit the "reset" button whenever they percieve that something's wrong (it isn't), then ext2 gets a little more fragmented and broken each time. Until it all came to a head this past week and ext2 was such a mess that everything on the system was unstable. 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.
Re:Great, more fragmentation (Score:1)
Re:Great, more fragmentation (Score:1)
Re:Great, more fragmentation (Score:2)
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.
Re:Great, more fragmentation (Score:1)
Re:Great, more fragmentation (Score:2)
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:
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 (Score:1)
Re:Great, more fragmentation (Score:1)
Hell, why not just have them all write an OS from scratch for every machine? That would be the best way, and the people would have to know what they're doing, right?
The point is, people would rather do something the easy way and save time. Especially in this case where you don't even lose anything in quality by switching.
Re:Great, more fragmentation (Score:1)
As for the easy way and saving time/money: I agree, and that is really the problem, not so much the forks. There are plenty of MSCAs out there, but as for *nixHacks - how should HR go about separating the wheat from the chaff? How can they be sure that if their *nixAdmin leaves, they will be able to find a replacement?
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.
Re:Great, more fragmentation (Score:3, Interesting)
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 (Score:1)
Re:Great, more fragmentation (Score:3, Funny)
I don't see how any of this is relavent. What you're complaining about is that:
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".
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:Great, more fragmentation (Score:2)
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 (Score:2)
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.
Re:Great, more fragmentation (Score:2)
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 (Score:2)
Re:Great, more fragmentation (Score:2)
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?"
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:Ugg, try installing ipnat on freebsd.. same thi (Score:3, Informative)
Looking forward to the day when kernel modules are a 'load on use' resource. That is, if you try to access
echo 'ipnat_enable="YES"' >>
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"' >>
may be required as well depending on current configuration.
Re:Ugg, try installing ipnat on freebsd.. same thi (Score:2)
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:Ugg, try installing ipnat on freebsd.. same thi (Score:1)
Give me one good OS where Java runs smoothly as baby ass skin.
Re:Ugg, try installing ipnat on freebsd.. same thi (Score:3, Insightful)
Re:Ugg, try installing ipnat on freebsd.. same thi (Score:2)
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.
dumbass (Score:2)
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 (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:Great, more fragmentation (Score:1, Interesting)
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).
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:2)
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: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: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)
/Janne
Re:Great, more fragmentation (Score:2)
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: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: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:This is a really bad idea (Score:3, Insightful)
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.
Re:This is a really bad idea (Score:2)
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.
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.