Slashdot Mirror
Future of 2.4 and 2.6 Kernels
Blair16 writes "According to this article on C|Net, not everybody is chomping at the bit for the new Linux 2.6.0 kernel. Marcelo Tosatti, the appointed deputy for the 2.4 kernel is not expecting to make any non-crucial additions to the popular kernel, saying that all new projects should be pumped into the new 2.6. This has upset some people who are not quite willing to move to so-called untested software. Some of their claims seem legitimate, but I wonder if all these people will really be left in the cold?"
I think the benefits of a few bugs outweigh the problems they may cause. If I can save 5 million dollars in a server deployment and there's a slight risk of a crash but my data is safe then I'll run that risk.
However some companies are still running RH 7.2 so there will be those who stick with the 2.4 kernel as long as they can. This will more likely be the groups that are unable to move their software from 2.4 to 2.6 due to how they built their systems possibly.
Fortunately, there are a few really interesting technologies that have received surprisingly little attention, but which I believe point the way toward Linux overtaking Microsoft, and perhaps even Apple on the desktop:
- Dashboard
- Zero Install
- Gnome Storage
These projects are the future of Linux, they are novel ideas that will allow Linux to leap-frog its non-free competitors on the desktop. It is a shame that they receive so little attention.This is a wonderful idea where a "dashboard" essentially acts as a memory augmentation tool. It watches what you are doing and presents information it thinks might be relevant. For example, if you are chatting with someone on IRC, it will look for information about that person and present it to you (such as their name, homepage, recent blog entries etc). Applications can support it by sending it "clue packets" to alert it to what it might want to pay attention to.
This software essentially eliminates the process of information by mapping web-servers to the filesystem, and combining this with a fast local cache. If your software relies on another piece of software, it can just refer to its binary or libraries on this "web" filesystem, and the appropriate files will be downloaded transparently. The next time you need them, they will be cached. It is infinitely cooler than DEBs or RPMs, and very flexible indeed.
This project blurs the line between filesystems and databases, creating much more flexibility than is possible with more conventional filesystems. This is particularly powerful when combined with Zero Install. Microsoft is also moving in this direction with their WinFS that will be part of Longhorn.
I personaly do not see any problems with this. If someone want the latest and greatest in the current version of the kernel. They can either port it themsevles or pay someone to do it for them. This is the beauty of opensource. In any case the major vendors of linux will do this at times the featues is really wanted by thier customer base.
Get Movie Posters
There is an nForce configuration option at least in 2.6.0-test10, but, according to discussions that took place this week, there are stability problems. So I guess that yes, this board is going to be supported somehow.
It is interesting to note that Linus doesn't like nVidia releasing binary-only, proprietary drivers, and thus doesn't plan to make it easy for graphics card makers to distribute modules in binary form. To quote him: It's a two-way street: if you don't help me, I don't help you.
So, I don't know whether the nForce documentation comes with hidden "trade secrets" or such, but if nVidia's attitude is the same as for graphic cards, it may not motivate developpers to support their products.
When Linus released 2.4.0, there was a several
month pause before opening 2.5.0. This was to
allow continued bugfix and stabilization work
to happen on 2.4.0. It seems reasonable that
he would do the same w/ 2.6/2.7. So, there should
not be any fear of 2.6 suffering from developer
inattention in the several months after release.
If Linus doesn't release 2.7, the developers can't
ignore 2.6.
I'd like to point out that the nature of open-source de-emphasizes the importance of central decisions such as this.
Linus and his helpers are the de-facto maintainers, yes, because people find they generally make a good job of it. AFAIK the only legal claim they have is to the name "linux".
If you want the 2.4 kernel line to still have new features added, fine. Download the source, add the features, put it up for download. You could even apply the security and stabilisation patches from the main tree to your "experimental" tree..
You know... in the kernel configuration, you can choose yourself what features you want. Simply disable(do not enable) the new scary features and you're done.
I for one, welcome new EXPERIMENTAL/DANGEROUS features.
The virtual
Oh, and the
Also, the framebuffer stuff rocks.
Oh yeah. Sound, IDE, and AGP I believe are all supported and working for the nForce2 in 2.6. There is an alpha ethernet driver patch available. I don't see any reason why nvidia should do closed source drivers for a motherboard chipset. If they truly believe there are trade secrets in it, they are truly sick. But since they are new at at it, time will tell if they will change, and if I will buy any more of their products.
The kernel maintainers have been clear on their reasons *not* accepting xfs into linus's tree (see prior posts in this thread). Considering that so many of the people who clamor for xfs (imx) are kids who're principally attracted to it's rep for high performance, yet have no concept of the tradeoffs delineated above -- well I can see why it's not being accepted into mainline. I'm sure if SGI actually cleans up the interface it'll go in but who knows if _that_ will ever happen.
Marcello on XFS:
Linux is Linux, if One need clarify their dist: <Dist>/GNU Linux
bsds are of course just BSD
I wish someone on the kernel team would consider this issue from a user's perspective. Sure, I understand their objections to binary drivers on a moral and a support-headache perspective, but what options do the users have?
nVidia: binary-only drivers, but mostly stable
ATI: binary-only drivers, unstable and out of date
Everybody else: my favorite game is "Unreal Tournament 2003:The Slideshow"
XFS is apparently a bit unusual in that it requires changes to the generic portions of the kernel as well, so its presence could adversely affect stability even when it's not configured; this is the main reason why Marcelo is reluctant to merge it.
:-]), and perhaps will merge it based on that.
However, he's apparently also decided to wait for a pending review of the XFS changes by Christoph Hellwig (who's a widely trusted kernel hacker, and more pedantic than most [pedantic used in a good sense here
[From what I understand, part of the problem is that SGI still uses Irix as the `native' platform for XFS, and so the linux port of XFS tries a bit to make linux look like Irix in order to minimize linux-specific changes to the XFS code-base.]
This post is based merely on casual readership of the LKML, not on actual knowledge of the linux XFS implementation!
We live, as we dream -- alone....
I disagree, in this case.
2.6 is getting more positive reports and more good buzz on lkml than I have ever seen for a 2.x stable series. There can be no comparison to 2.4's rocky childhood, for example.
I think 2.6 is going to be the smoothest early stable series yet, and that 2.4 is going to be looked back upon as a relative stinker. The subtext in Marcello's posts about 2.4 imply that he thinks the same.
Sometimes I wonder if the difference between 2.4 and 2.6 is the change in the development maintainer's (Linus') source control model -- that is to say, he finally started using one (bitkeeper).
Back in the day, when everyone was excited for the 2.4 kernels to come out, I was waiting very eagerly. You see, I had just purchased a quad-processer machine, and 2.4 was supposed to scale much better than the 2.2 series. Now, as should be imagined, this wasn't a "toy" or "testing" machine, it was a production database server that the entire company depended on.
When 2.4.1 came out, I downloaded it, compiled it, and installed it on the production machine. It purred along beautifully. I completely forgot about it.
Some time later, the o(1) scheduler patches came out, so I downloaded what was the then-current version, 2.4.17. Here's where it gets good: The database server with the 2.4.1 kernel was still running.
No, I don't mean that I was just still using it. I mean that it was *still running*. It had never been shut down, crashed, or had a reboot for any reason.
Based on that experience, I'm not terribly worried about using the 2.6 kernels.
Oh, you're not stuck, you're just unable to let go of the onion rings.
Okay. I'll spend a six or so months learning the UDF specification and how the drives work. Then I'll spend a year or two (probably two) learning how the kernel works (because it would be necessary to understand most of the kernel for this process), and another year making the largescale modification that would be necessary to solve this problem. Then I'll spend two more years supporting the project so that it'll make it into the kernel.
At this point, I've taken about as long as it will take for the people who already know how to do it to decide that making the change is a worthwhile endeavor, even from this point.
This comes to a fundamental nature of monolithic development: it takes much, much longer for anyone who didn't write it to write things for it than it does for it's developers to do something on it.
Mod me down and I will become more powerful than you can possibly imagine!