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..
The End of FreeBSD
[ed. note: in the following text, former FreeBSD developer Mike Smith gives his reasons for abandoning FreeBSD]
When I stood for election to the FreeBSD core team nearly two years ago, many of you will recall that it was after a long series of debates during which I maintained that too much organisation, too many rules and too much formality would be a bad thing for the project.
Today, as I read the latest discussions on the future of the FreeBSD project, I see the same problem; a few new faces and many of the old going over the same tired arguments and suggesting variations on the same worthless schemes. Frankly I'm sick of it.
FreeBSD used to be fun. It used to be about doing things the right way. It used to be something that you could sink your teeth into when the mundane chores of programming for a living got you down. It was something cool and exciting; a way to spend your spare time on an endeavour you loved that was at the same time wholesome and worthwhile.
It's not anymore. It's about bylaws and committees and reports and milestones, telling others what to do and doing what you're told. It's about who can rant the longest or shout the loudest or mislead the most people into a bloc in order to legitimise doing what they think is best. Individuals notwithstanding, the project as a whole has lost track of where it's going, and has instead become obsessed with process and mechanics.
So I'm leaving core. I don't want to feel like I should be "doing something" about a project that has lost interest in having something done for it. I don't have the energy to fight what has clearly become a losing battle; I have a life to live and a job to keep, and I won't achieve any of the goals I personally consider worthwhile if I remain obligated to care for the project.
Discussion
I'm sure that I've offended some people already; I'm sure that by the time I'm done here, I'll have offended more. If you feel a need to play to the crowd in your replies rather than make a sincere effort to address the problems I'm discussing here, please do us the courtesy of playing your politics openly.
From a technical perspective, the project faces a set of challenges that significantly outstrips our ability to deliver. Some of the resources that we need to address these challenges are tied up in the fruitless metadiscussions that have raged since we made the mistake of electing officers. Others have left in disgust, or been driven out by the culture of abuse and distraction that has grown up since then. More may well remain available to recruitment, but while the project is busy infighting our chances for successful outreach are sorely diminished.
There's no simple solution to this. For the project to move forward, one or the other of the warring philosophies must win out; either the project returns to its laid-back roots and gets on with the work, or it transforms into a super-organised engineering project and executes a brilliant plan to deliver what, ultimately, we all know we want.
Whatever path is chosen, whatever balance is struck, the choosing and the striking are the important parts. The current indecision and endless conflict are incompatible with any sort of progress.
Trying to dissect the above is far beyond the scope of any parting shot, no matter how distended. All I can really ask of you all is to let go of the minutiae for a moment and take a look at the big picture. What is the ultimate goal here? How can we get there with as little overhead as possible? How would you like to be treated by your fellow travellers?
Shouts
To the Slashdot "BSD is dying" crowd - big deal. Death is part of the cycle; take a look at your soft, pallid bodies and consider that right this very moment, parts of you are dying. See? It's not so bad.
To the bulk of the FreeBSD committerbase and the developer community at large - keep your eyes on the real goals. It's when you get distracted by the politickers
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!