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?"
From the linked email:
Having that mentioned, I pretend to: - Fix pending problems which might required more intrusive modifications during 2.4.24. New drivers will be accept during this period (for example, Cyclades PC300 driver, input userlevel driver support, or other sane driver which might come up). - From 2.4.25 on, fix only critical/security problems.
Heh, so that solves the issue of being a kernel maintainer with little time on your hands, only pretend to do stuff :)
From the story text:
. 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
Seriously, are people expecting major changes and new features to be added to a kernel that is supposed to be the stable branch? Doesnt this stuff belong in 2.6? or hell, even 2.7? I for one wouldnt like my kernel to constantly have new and untested features when its supposed to be production capable!
I don't know, but shouldn't someone actually test it to become tested? This is the way Open Source works, everyone should help developing the software, even non-programmers, by testing, and I guess the kernel team won't release something for production until it is ready for.
The IT section color scheme sucks.
Hasn't this discussion been held before? Stable kernel remain just that - Stable.
New features always go in new releases. Since 2.6 is around the corner, any new feature need to go in 2.7 now. Big deal. Move along, nothing new or interesting to see here.
Of course people want new features AND stability.
Pretty funny.
If the "well tested" 2.4 kernel were to be adding new features, such new features might risk making it unstable, therefore the time-tested status it has would have to be restarted.
If 2.6 isn't "well tested" enough for your production servers, wait a while. The test of time will perform itself... of course, if you want the new features, you'll just have to take the plunge because somebody's gotta do the testing...
Well then "some people" can get off their butts, or cough up the cash to do it themselves. It's amazing how some people who use free software think that the developers owe them something.
Erm, no. They wrote it, they can do what they like, how they like and when they like. They don't have to put in features if they don't want to. They certainly don't have to justify their work or decisions to anyone except their contributing peers. If you don't like it please whine to somebody else. Nobody is stopping you from backporting code or doing it yourself.
this discussion happens every time there's a new stable kernel version. people get mad, the new kernel is a bit buggy at first, but then things smooth out and pretty much everybody upgrades unless they don't need to or don't want to..
move along folks, nothing to see here.
Some of their claims seem legitimate, but I wonder if all these people will really be left in the cold?
Of course they will, and they will get the traditional open source answer to such situations - "If you want it so bad stop whining and do it yourself. Nobody is stopping you, and, after all, you do have the source. See how great open source is? If this were Microsoft you would be stuck, no source, no nothing."
Sorry but this the way the world of software works. The old version gets put into maintainance mode and eventually is retired. In the Linux world as far as kernels go users and companies have much better deal then they get in the commercial closed source world. For example company X wants to stay on 2.4 for some odd reason. Once 2.6 comes out 2.4 will still be around and updated for security flaws AND they can add/remove/improve 2.4 inhouse any way they want. Sounds like these people just want OSS hackers to continue to do free work for them on an old kernel without regard for the natural order of things. It's all a bit selfish really. They are course free to migrate to an OS where they have Zero control over the kernel and when updates stop, they just stop.
If you wanna get rich, you know that payback is a bitch
In the meantime, there are some bugfixes that look like new features; that's the way software works. There are some new features that look like bugs; ditto. We know that security bugs are considered vital no matter how old the kernel (well, to a point). And so someone often will fix that.
All that to say that it's called "software" because it's squishy and can change (or be changed). And there's nothing besides lack of time that keeps you from including a new feature in 2.0, 2.2, or 2.4 and putting up a patch archive to support your favorite feature/fix that "someone" really should have put in long ago. To paraphrase my Subject line, "one man's trash is another man's treasure".
Marcello's position means that the 2.4.x will become much more solid than any Linux kernel has ever been. As new hardware is introduced, there will be pressure to accept drivers to support popular hardware. I expect that Marcello will accept drivers as necessary for 2.4.x to run on popular hardware -- after all, such new drivers impose minimal risk on users without such hardware. I welcome this development, but will keep on open mind as time prove its merit or lack thereof.
I'd like this for my college:
Hibernate-logout hybrid: save data relevant to all programs you have running and logout. Next login starts up everything as you left it. To be presented as an option on logout, for use in shared computers (particularly at a college).
Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
Their example is of people who are using XFS with a 2.4 kernel. These people are (according to CNet) "upset" because XFS won't get added to 2.4. Now just think about this for a second: they are using XFS with 2.4 right now! So obviously, they are not being prevented from doing what they want. The whole issue (which CNet is trying to make out as a big deal) is that these people wish they didn't have to perform an extra step (applying a third-party patch). I hardly think it's going to kill these people to keep on doing what they have been doing for a little while longer (i.e. until they decide that the 2.6 series is sufficiently tested that they're willing to trust it). No one is being "left in the cold".
Actually, to be fair to CNet, they're only mildly misrepresenting the situation. The major source of confusion and misrepresentation is (as usual) the slashdot summary.
Exactly what are they bitching about? If they don't want to run untested software, they should run 2.4. If they want new features, they should run 2.6.
So, if untested patches go into 2.4, does that make them anything more stable? The logics of this just escapes me...
This isn't a problem. A kernel is a kernel, not a complete OS installation. If 2.6 doesn't work dandy, people can (freely) hop back to 2.4 until 2.6 is solidified, even if it has "gone gold".
This doesn't even begin to sound like a problem. They'll be on 2.6 soon enough - whether it's a "tried platform" sooner or later.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
If you want to know better the status of XFS read up on the lkml. The cnet article doesn't even explain the good reasons not to include it. Even in 2.6, just in the last couple days, some serious issues have cropped up with it. At there has been some indication that XFS is related to the slab corruption.
There is very little reason to include it in the stable 2.4, when there may be unresolved issues. I'm not saying that you shouldn't use XFS, but it needs more work than to be in 2.4 by default. Lets face it, XFS has alot of cruft still. The main development right now is in the unstable branch 2.6, which is basically XFS's status. If XFS wants to prove it's stable enough for 2.4, it should do so in 2.6, and then it will get back ported then.
Generally, when something is not ready for a stable line, it doesn't have enough people using it. Even linus said recently that he knows very few people that use XFS.
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.
This is really not true, since almost ALL the features in the 2.6 branch are available as patches for the 2.4. The 2.4 branch has achieved a nice level of maturity and adding a lot of new stuff to it now makes no sense.
The people complaining should learn the magic of open source. They should realise that at any desirable time they can start mantaining their own tree with their desired features. Hell, starting a new tree is not even necessary since there is such a big variety of 2.4 trees around that the feature they want is most likely already beeing supported by someone else in one of them.
I don't get your point. He is about STABILISING 2.4 kernel, NOT about adding new and new features to vanilla kernel and so causing maintaining 2.4 kernel difficult. It's stable now, so let's leave it alone. If you want use XFS with 2.4 kernel, do your patching and go. No one forbids you to do that. And about a trust - I trust my Linux systems. Only because I run them by myself. Not because Linux development is somehow more superior that FreeBSD (or vice versa).
user@ubuntubox:~$ stfu This server is going down for shutdown NOW!
The big deal is the 2.4 kernel was receiving massive changes (i.e. completely new VM system) in the 2.4.1x range. It really took a while for 2.4 to become a reliable platform. People are scared of the same thing happening here.
Comment removed based on user account deletion
> Want information? Ask RedHat. Ask Linus. Ask the folks at SuSE.
Yes. I mean, God knows those people won't be biased. It's only Linus' most famous accomplishment. He's a good guy, so he'll not have the slightest bias what-so-ever in any way. And RedHat's not supporting their business model on this stuff, are they? And SuSE, well, they're Germans! That alone should tell you that they'll have no bias for something that their income depends on.
Dashboard: another "desk accessory" I can see myself completely not using. I already know what I want to about the people I talk to. For the obscure stuff, theres corporate directories, and while I doubt they use IRC, I'd sooner use the directory than Dashboard.
Zero Install: Say the zero-install servers get hacked and compromised. Instant virus on millions of computers at once.
Gnome Storage: Hello BeOS. This will be nice, but its been done before.
The future of linux may include these things, but people will sooner care about the new X-server patches with alpha blending and such than they will about this stuff.
"I am terrified of the following scenario, which is extremely probable to happen soon," responded Jan Rychter in a Wednesday post. "2.4 is being moved into 'pure maintenance' mode and people are being encouraged to move to 2.6. While people slowly start using 2.6, Linus starts 2.7 and all kernel developers move on to the really cool and fashionable things. 2.6 bug reports receive little attention, as it's much cooler to work on new features than fix bugs."
What insight! I can't imagine how anybody could see that far into the future as Jan Rychter.
So many people use the "cooler to work on new features" argument without evidence. Since when has Linux favoured new features over fewer bugs? Linux 2.4 bugs receive plenty of attention, thank you very much -- so do Linux 2.2 bugs and 2.0 bugs.
Isn't the joy of the OSS model, that if this were truely a problem, a group of users (presumable corperations interested in the viability of thier 2.4 kernel) could get together to create and maintain a patch for the 2.4 kernel that would back port more then just the critical updates from 2.6? I thought that the whole point of having an open model was to allow everyone to mess with the code to make it fit their needs. I know there is always a fear of forking, and that someone will bring up the issue, but there are many patches some like the -ac patch even get posted on kernel.org.
There has alwasy been a gap between the needs of buisness for stable and realiable software and the desire of enthusiests for the latest and greatest. as Linux continues to gain share in diverse markets, I antisipate that the number of patches will likewize increase, making a kernel that can meet the needs of several different types of users.
JFMILLER
Strive to make your client happy, not necessarly give them what they ask for
I sympathize with the SGI developers, about the inclusion of the xfs filesystem into the kernel. The reasoning for this is because there is a perception that something that is not included into the main kernel branch is unstable, which is absolutely wrong. So it is beneficial for a developers to have their module included into the branch, so it can be considered a proper part of the kernel. I think this is a major weakness to how the kernel releasing structure it set up.
Honestly, I would like to have this releasing structure changed. For example, filesystems don't need to be inside of the kernel branch, only the virtual file system. Let the distributions take care of putting all of the different filesystems into their kernel branch. The kernel branch should be the base point of all the other distribution branches. If you want ext2 in your kernel then go to the ext2 guys and grab the patch and apply to the kernel, no more inclusion. I have already heard people state that patching should not be done by a regular user, which is correct; but that is why you have distributions that have there kernel branches with all of the filesystems they think should be included. No more arguments why one module is inside of the kernel branch and the other isn't.
Linus and his maintainers can now only worry about the main system and let everyone else deal with there on patches. If your patch needs a change to the kernel branch then you talk to Linus and his maintainers. Which they decide if it is a good idea, or if you need to change something in your code. This would lower the amount of releases of the main kernel branch, since there is a smaller amount code that can be changed. Also the releases can be base on if a interface to the main system has been changed which effects the other patches, or just a fix to the internal code. This can lead to easier maintenance of other patches. The more code that can be taken out and put into there out tree the better. Kinda like having a hierarchy of trees.
This can lead to cool pseudo linux distributions where one can say I have xx branch of the kernel. This is already happening like mm-sources, redhat-sources, etc; But taking out the favoritism of the main kernel developers. This could also solve a problem with the size of the kernel source tree in the future when there is tons of different drivers,filesystem,etc.
This is just an example of what it could be like, and I am sure there is more that has to be look at; but think this approach has some credits.
Nothing more, For me to say; About my life, A life of dreams....
Now, this comment is mildly off topic, but the article in question does show up a problem with the current structure of the Linux kernel, namely that drivers (including filesystem drivers) are closely intertwined with the workings of the kernel at a source level.
Currently, there is no way that you can have a totally stable kernel and yet have device drivers and filesystems develop independently. To do this, Linux would need at the very least a standardised device driver and filesystem API or better yet, a standardised ABI which doesn't change for the lifetime of a major revision.
All the major commercial UNIX's I know of have a standard ABI for their drivers, as do Windows. This is why you can still get hardware developers who maintain and release versions of device drivers for old releases of kernels for those operating systems for new hardware, because they can. I'd like to see someone try doing that for the current crop of Linux kernels.. oh yes, which version and sub-version from who's source tree was that for?
Not having a standard ABI for drivers helps cause a support hell, not only for end users, but as demonstrated here, the kernel maintainers as well.
Agrajag: "Oh no, not again!"
Keep in mind that innovation is treacherous ground: most innovative software won't find a significant usage niche. Reality has a way of turning neat research ideas into stupid user frustrations. This is not to critize efforts like Dashboard and Gnome Storage, but it's a given that you have to go through a lot of bad ideas to get the really good ideas. Just take Microsoft Word: the product that gave us both Clippy [bad!], and background spellchecking [good!].
-1, Too Many Layers Of Abstraction
XFS gets a lot of flak. Most of it completely unfounded and wholly inconsiderate of the hard work done by the fine people at SGI to port XFS to Linux. Never mind that it's wholly inconsiderate to the large body of people relying on XFS daily.
... I dont like the XFS code in general.
The kernel maintainers have been clear on their reasons *not* accepting xfs into linus's tree
The kernel maintainers haven't been clear on this at all. It's not even true, since XFS has been a part of Linus' tree since 2.6.early.
Considering that so many of the people who clamor for xfs (imx) are kids who're principally attracted to it's rep for high
XFS has been in service with SGI for over a decade. Arguably it has seen more heavy duty action than most every other filesystem in Linux. It's reputation for being "unreliable" is completely unfounded. At the same time another filesystem for which many, many reports of data loss have come across the lkml, viz. ReiserFS, gets merged into the kernel almost as soon as it compiles. But nobody seems to mind that.
I'm sure if SGI actually cleans up the interface it'll go in but who knows if _that_ will ever happen.
This has *always* been the argument against the inclusion of XFS, even though the SGI people have done virtually *nothing but* clean up the XFS interfaces since XFS release v1.0. The facts are that there is little, if anything, remaining to clean up: people just don't like XFS.
Marcello on XFS:
That is what it boils down to.
The reality is that Marcello has held off on merging 2.4 for over a year, telling the XFS developers to "come back later" or to "clean up X". Now that pretty much everything has been cleaned up, and the definitive deadline is getting near, the real reason for the holdup has finally emerged: Marcello doesn't like the XFS code.
Well, that's his prerogative. But he should have told them in advance. They could have spared themselves the effort!
Wow, the argument as I understand it is that MS allowed for continued improvements in older product, like it does occur in Linux (stability, security patches if not new features).
That's the part I don't understand. There is no *forced* upgrade when the security/stability updates are still being backported (from what I've been reading here, there's people still using 2.2!).
It's actually an honest trade (which is what doesn't always happen with closed software); you want the shiny new features? Well, you'll have to put up with not-yet-throughly tested software. There's a trade off.
If security matters to you, for example, and security patches aren't backported, *then* you're forced to upgrade, deal with new software but this time you're doing it for the sake of the same functionality. There is no trade off, you just lose (time and money).
I'm a technical PHB. I started working as a System Admin back on SCO (the original) Xenix in the late 80's. I'm still fairly technical and hands on, but now, at 36, I manage a team and make purchasing decisions, etc., as well.
This is simply WAY WAY WAY too early to talk about stagnating the 2.4 kernel. It feeds directly into the "open source is really a bunch of geeks who are far more interested in shiny new baubles than core business requirements!"
2.6 isn't out yet. And it's not known when it will stabilize (my definition of stable is when revs "live" for more than 30 days).
It's quite possible that a 'stable' 2.6 won't be out for a year. Then it needs to be tested, and a migration plan (since this is NOT a 'build and drop in' kernel) put into place, and that tested.
Easily 18 months or more -- and that's assuming that as soon as the kernel stabilizes, it becomes a company priority to migrate.
Again, MS loves to tout "with open source, you have to build your business around your solution, rather than building your solution around your business."
Big companies don't want to be on this treadmill, they don't want to develop and maintain their own kernel team and kernel tree -- they want stuff that WORKS. And having your own dev organization is a fast way to spend more money than buying someone else's solution.
Hopefully this won't come to pass. But sadly, the fuel's been added to the fire.
Steve
Not quite. "In late 1994, SGI released an advanced, journaled file system called XFS on IRIX"> I was managing SGI engineering stations ca '96 when sgi's workstations still by default installed efs. At that time I had been streaming engineering analysis data 24x7 on rs/6000-jfs for months at a time since '93 (when we thought of continuous read/write at 5MB/s as fast :-)) JFS was released with rs/6000/aix3.1 in 1990.
Linux is Linux, if One need clarify their dist: <Dist>/GNU Linux
bsds are of course just BSD