Posted by
Roblimo
on from the kernel-updates dept.
Lface writes "Linus has just announced a feature freeze for Linux 2.4. He further says: 'The feature freeze should be turning into a code freeze in another two months or so, and a release by the end of the year. And as everybody knows, our targets never slip.'"
Re:How stable is this?
by
Eric+Seppanen
·
· Score: 3
...ran a story on Linux just because 2.2 was released and it was such a momentous achievement. Now 2.4 is around the corner and no one seems really worked up, which means less press for us.
Good.
Why? Because it's a kernel, not a car. The Linux kernel shouldn't depend on a public relations blitz to be good. It should be good because the code kicks ass. Having the media sit up and take notice is fine. I'll be thrilled when 2.4 is out. But I wish the media would take the view that free software is like a steamroller. It just keeps grinding forward, getting slightly better every day, while commercial software is constantly running this way and that trying to chase dollars.
-- 314-15-9265
Don't take Linus so seriously, PLEASE :-P
by
BadlandZ
·
· Score: 5
The feature freeze should be turning into a code freeze in another two months or so, and a release by the end of the year. And as everybody knows, our targets never slip.--Linus
For those of you to new to development kernel tracking, this is a JOKE, it's sarcasm. I have no doubt that Linus would like a freeze, and it COULD happen, but this is not written in stone.
Anyway, I personally don't see anything major pending. There are still various fixes that have yet to be integrated (some of the smbfs work by Bill etc), but on the whole I'd call this feature-freeze time. Have fun--Linus
As it happens, the development kernel kept going from 2.1.69 in 1-Dec-97 on to Linux 2.2.0-pre9 in 20-Jan-99, that's over a year.
Linus has a sence of humor, don't think every word out of his mouth is written in stone, this isn't Moses comeing down from the mountian with the ten commandments... . It's just a comment, and one said with tounge in cheek.
It could be "the freeze," but don't hold your breath.
Integrating the PCMCIA package was the one feature I really wanted to see, and this will finally happened. I hope the deadline-slip is a lot shorter this time.
Mais au contraire mon frere. Microsoft kindly pointed out to the Linux community that the 2.2 kernel could not beat NT on some specific benchmarks. Linus took it personally at first and then as constructive criticism from the competition. Shortly after, Linus announced the 2.4 kernel as the *performance* release.
I personally think that Linus wants 2.4 to beat the pants off Windows NT on all benchmarks on any hardware. And when it does, you will see that all the penguins will have a proud grin carved in their faces.
So, having that said, has anyone benchmarked 2.3.18 lately?
I am somewhat bummed to see devfs being left out of kernel tree. The patch was around before 2.3 branch was started but never made it in. Does anybody know the reasons behind this? I am running devfs and it seems to be a very well behaving patch. unless you enable devfs - kernel compiles normally. Did Linus disklike it for some reason or was there some other reason for leaving it out of the tree?
There has been quite a bit of discussion about it on the linux kernel development mailing list, with many people on different sides.. Look here to see what people on the list have been saying.
-- Does Rain Man use the Autistic License for his software?
Linus has certain technical "issues" with the whole concept of devfs (although it is indeed very stable; Richard Gooch has been very tenacious in releasing devfs patches for new kernels within a day or two).
However, if I recall correctly (you tend to skim any threads about devfs in linux-kernel after the 1000th post asking about it:), Linus has relented a little lately, so it might be a candidate for 2.5, I guess.
Linus answered a devfs question at the Linux Expo last month in San Jose. He said he likes the idea of devfs, but doesn't like the naming schemes.
I personally would really love to see devfs included in the official kernel. There are so many hot pluggable hard drives these days, it's really ridiculous to have to rename each device every time you pull out or insert a disk.
Well, if you define "regular event" as "once in two years or so", then yes, it is;)
A feature freeze for the development branch of the kernel takes place when Linus decides that he doesn't want to accept anymore major changes - in other words, the development kernel (in this case, 2.3), is "feature complete", and all that remains before the release of the next stable kernel is a whole pile of bug-squashing.
In reality, it means that Linus won't accept anything unless you're really, really persuasive (and he has accepted some major changes at a late stage before). However, this time he's taking two weeks vacation to "avoid temptation".
Yep, it will be in there. It might not work with everything out there, but it's a really good start. As of the latest development kernel (2.3.18), there's support for the following:
UHCI (intel PIIX4 and others) support
OHCI (compaq and some others) support
OHCI-HCD (other OHCI opt. Virt. Root Hub) support
USB hub support
USB mouse support
USB HP scanner support
USB keyboard support
USB audio parsing support
USB Communications Device Class (ACM) support
USB Printer support
USB CPiA Camera support
USB SCSI Support
EZUSB Firmware downloader
USS720 parport driver
Preliminary/proc/bus/usb support
-- Does Rain Man use the Autistic License for his software?
I wouldn't count on XFS being included, Linus said in his post that "if the changes aren't too major" From what I understand from the posts some of the SGI folks have made is that XFS is not a "plug-in" filesystem driver, it requires changes all over the place. Ofcourse I could be totally wrong:-) since I don't work for SGI and never worked on/with the XFS filesystem.
No, there's no way XFS will make it into anything before 2.5 (the development branch for the 2.6 stable kernel), and maybe not even then. It's a pretty big chunk of code, and not originally designed for Linux, so it will most likely take quite a while to be ported. Linus' filesystem comment probably doesn't indicate anything specific on the horizon for 2.4, I would think.
Re:Code freeze --> new release?
by
smkndrkn
·
· Score: 2
A code freeze is a good way to start testing your code. You can start fixing small problems without having to worry about new code messing up the old code which can be a complete pain in the behind. With the code freeze you can be sure that new hunks of code aren't doing bad to the good. Code Freeze==Very good I'll gladly wait 2 months for a new kernel with "less" bugs:) Gary
-- ========
In the future, everything will be artificial.
========
Re:How stable is this?
by
Anonymous Coward
·
· Score: 2
Nah its like a 2 mile long freight that is costing out of the mountains on a 15% downgrade. Just imagine Microsoft tied to the rails at the end of the grade....
Please note that the announcement was for a feature freeze, not a code freeze. A code freeze means that the stable release is imminent. There's still a lot to before we reach that point, I would say:(
2G VFS limitation on x86 - no more.
by
CocaCola
·
· Score: 2
AFAIK Stephen Tweedie (Red Hat) has fixed the VM/VFS to deal with 64-bit files (even on 32-bit platforms). He now is at Linux Kongress, maybe we will hear more about this once he's back. So you do not have to wait for XFS to get 64-bit files. On a related note, Stephen Tweedie has also released his journalled-ext2fs (called ext3fs), the patch can be downloaded from here. Linux kernel development has really accelerated in the last couple of months...
I doubt Linus would ever admit to it, but my guess is that there is at least some motivation for him to get 2.4 out before W2K. I'm sure that M$ will do a big ad campaign when W2K launches, and I think Linus wants all the SMP, scheduler, khttpd, etc., speedups put into 2.3 to be in the standard kernel to curb off some of the benchmarketing that's bound to happen. My guess is he'll want to time the release to be as close to W2K as possible, to steal some of its media thunder, and possibly increase press coverage comparing the two new releases of the heavyweight OSes in their brand new iterations.
I know most of you think that Linus is oblivious to these sorts of things (or would like to believe that anyway), but I frankly doubt it.
I would guess it is probably a reiserfs reference. That is apparently very usable, and if it is only a build time option, I can't imagine it would interfere too much with anything else- thus, a possiblity for later inclusion. ~tieguy
So how stable is 2.3.18? I remember back in the mid 2.1.100s everything was pretty much stable and we all went ahead and switched over to the devel kernel, just because it had a grip of cool new features. Now, I have my eyes set on USB support in 2.3.18. Is this thing stable enough to go ahead and use? When will it be, if it's not.
Also, a more editorial comment - is anyone a little disappointed with the shortened release cycles? Nothing breeds anticipation like waiting for Linus to finally give the go ahead, after four months of bugfix releases, etc. But still, remember the madness when 2.2.0 was released? It was a damn fervor.. me and every Linux geek I know in RL had a party.. hehe. Now it seems like we've lost yet another cause for celebration. I don't see how the shortened devel cycles could possibly help, anyways. All that excitement spilled over into the media, and most of the major computer newsmags (A lot of ZD pubs, for example), ran a story on Linux just because 2.2 was released and it was such a momentous achievement. Now 2.4 is around the corner and no one seems really worked up, which means less press for us. What were Linus's reasons for doing this?
--
I think there is a world market for maybe five personal web logs.
The way that the current kernel(s) handle memory paging needs to be totally rewritten by linux for xfs, or xfs will need to be rewritten to handle linus's memory paging routines. They expect to have working xfs in minimum of 6 months, probably a year. This coems from ted T'so, kernle hacker, ext2fs writer, fsck writer.
I sure would like to know what the news is with SGI porting their XFS journalling file system to Linux. This will be awsome.
From what I've heard, XFS is going to require some heavy-duty changes to the VFS layer to allow for >2GB files on 32-bit systems. (It's also the VFS layer that keeps ext2 from allowing >2GB files, so this may end up killing two birds with one stone.) I don't think the SGI engineers working on XFS for Linux have any code that's fit for public consumption yet anyway.
--Troy
-- "My life's work has been to prompt others... and be
forgotten." --Cyrano de Bergerac
Quick minor releases, long major releases...
by
Ami+Ganguli
·
· Score: 4
A (roughly) once a year release cycle is good for minor releases. There's less temptation to back-port stuff from devel into the stable kernel and therefore less chance of bugs showing up in the stable tree.
The kind of hoopla that happened with 2.2 is good, but it should be reserved for major releases every few years.
What I'm not clear on is how earth-shattering features that justify a bump in major version number and lots of hoopla will ever make it into the devel kernel. Linus is opposed to parrallel development trees (probably with good reason), but I'm not sure how else you introduce big changes withough jeapardizing the quick release cycle.
I think Linus should annoint somebody to start a "3.0 experimental" tree with major new features like clustering. Linus and the regular gang could continue work on 2.5/2.6 for another year, and then synch up with the experimental kernel for 2.7/3.0.
Of course, I'm just a lurker on Linux Kernel, so I don't really have any right to give advice. It's just my idea.
-- It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. - Abraham Maslow
I am currently maintaining and developing the FireWire subsystem which hasn't made it into the dev kernels yet. I sent a patch to Linus two weeks ago, but he didn't reply, which basically means refused. Understandably, there were some missing features like a highlevel driver interface (highlevel drivers as in harddisk driver etc.), which I am working on now, and isochronous transmissions.
When I get that sorted out I will try again. As it does not change anything outside of its own directory apart from a few Makefiles, it could be accepted even into a feature freeze. The homepage for this all is ECLiPt, where you can also subscribe to mailing lists.
No, it's certainly not a regular event. It's happened roughly four times in the past 7 years. For.99 (1.0) For 1.1 (1.2) for 1.3 (2.0) for 2.1 (2.2) now 2.3 (2.4)
Slashdot Mirror
...ran a story on Linux just because 2.2 was released and it was such a momentous achievement. Now 2.4 is around the corner and no one seems really worked up, which means less press for us.
Good.
Why? Because it's a kernel, not a car. The Linux kernel shouldn't depend on a public relations blitz to be good. It should be good because the code kicks ass. Having the media sit up and take notice is fine. I'll be thrilled when 2.4 is out. But I wish the media would take the view that free software is like a steamroller. It just keeps grinding forward, getting slightly better every day, while commercial software is constantly running this way and that trying to chase dollars.
314-15-9265
For those of you to new to development kernel tracking, this is a JOKE, it's sarcasm. I have no doubt that Linus would like a freeze, and it COULD happen, but this is not written in stone.
I refer you to Kernel 2.1.69 notes where Linus said:
Anyway, I personally don't see anything major pending. There are still various fixes that have yet to be integrated (some of the smbfs work by Bill etc), but on the whole I'd call this feature-freeze time. Have fun--Linus
As it happens, the development kernel kept going from 2.1.69 in 1-Dec-97 on to Linux 2.2.0-pre9 in 20-Jan-99, that's over a year.
Linus has a sence of humor, don't think every word out of his mouth is written in stone, this isn't Moses comeing down from the mountian with the ten commandments... . It's just a comment, and one said with tounge in cheek.
It could be "the freeze," but don't hold your breath.
Integrating the PCMCIA package was the one feature I really wanted to see, and this will finally happened. I hope the deadline-slip is a lot shorter this time.
Mielipiteet omiani - Opinions personal, facts suspect.
Mais au contraire mon frere. Microsoft kindly pointed out to the Linux community that the 2.2 kernel could not beat NT on some specific benchmarks. Linus took it personally at first and then as constructive criticism from the competition. Shortly after, Linus announced the 2.4 kernel as the *performance* release.
I personally think that Linus wants 2.4 to beat the pants off Windows NT on all benchmarks on any hardware. And when it does, you will see that all the penguins will have a proud grin carved in their faces.
So, having that said, has anyone benchmarked 2.3.18 lately?
ayottesoftware.com
I am somewhat bummed to see devfs being left out of kernel tree. The patch was around before 2.3 branch was started but never made it in. Does anybody know the reasons behind this? I am running devfs and it seems to be a very well behaving patch. unless you enable devfs - kernel compiles normally. Did Linus disklike it for some reason or was there some other reason for leaving it out of the tree?
Well, if you define "regular event" as "once in two years or so", then yes, it is ;)
A feature freeze for the development branch of the kernel takes place when Linus decides that he doesn't want to accept anymore major changes - in other words, the development kernel (in this case, 2.3), is "feature complete", and all that remains before the release of the next stable kernel is a whole pile of bug-squashing.
In reality, it means that Linus won't accept anything unless you're really, really persuasive (and he has accepted some major changes at a late stage before). However, this time he's taking two weeks vacation to "avoid temptation".
UHCI (intel PIIX4 and others) support
OHCI (compaq and some others) support
OHCI-HCD (other OHCI opt. Virt. Root Hub) support
USB hub support
USB mouse support
USB HP scanner support
USB keyboard support
USB audio parsing support
USB Communications Device Class (ACM) support
USB Printer support
USB CPiA Camera support
USB SCSI Support
EZUSB Firmware downloader
USS720 parport driver
Preliminary /proc/bus/usb support
-- Does Rain Man use the Autistic License for his software?
Slashdot's first reaction to VMware
I wouldn't count on XFS being included, Linus said in his post that "if the changes aren't too major" :-) since I don't work for SGI and never worked on/with the XFS filesystem.
From what I understand from the posts some of the SGI folks have made is that XFS is not a "plug-in" filesystem driver, it requires changes all over the place.
Ofcourse I could be totally wrong
No, there's no way XFS will make it into anything before 2.5 (the development branch for the 2.6 stable kernel), and maybe not even then. It's a pretty big chunk of code, and not originally designed for Linux, so it will most likely take quite a while to be ported. Linus' filesystem comment probably doesn't indicate anything specific on the horizon for 2.4, I would think.
A code freeze is a good way to start testing your code. You can start fixing small problems without having to worry about new code messing up the old code which can be a complete pain in the behind. With the code freeze you can be sure that new hunks of code aren't doing bad to the good. Code Freeze==Very good I'll gladly wait 2 months for a new kernel with "less" bugs :) Gary
======== In the future, everything will be artificial. ========
Nah its like a 2 mile long freight that is costing out of the mountains on a 15% downgrade. Just imagine Microsoft tied to the rails at the end of the grade....
Please note that the announcement was for a feature freeze, not a code freeze. A code freeze means that the stable release is imminent. There's still a lot to before we reach that point, I would say
AFAIK Stephen Tweedie (Red Hat) has fixed the VM/VFS to deal with 64-bit files (even on 32-bit platforms). He now is at Linux Kongress, maybe we will hear more about this once he's back. So you do not have to wait for XFS to get 64-bit files. On a related note, Stephen Tweedie has also released his journalled-ext2fs (called ext3fs), the patch can be downloaded from here. Linux kernel development has really accelerated in the last couple of months ...
--Coke
I doubt Linus would ever admit to it, but my guess is that there is at least some motivation for him to get 2.4 out before W2K. I'm sure that M$ will do a big ad campaign when W2K launches, and I think Linus wants all the SMP, scheduler, khttpd, etc., speedups put into 2.3 to be in the standard kernel to curb off some of the benchmarketing that's bound to happen. My guess is he'll want to time the release to be as close to W2K as possible, to steal some of its media thunder, and possibly increase press coverage comparing the two new releases of the heavyweight OSes in their brand new iterations.
I know most of you think that Linus is oblivious to these sorts of things (or would like to believe that anyway), but I frankly doubt it.
I would guess it is probably a reiserfs reference. That is apparently very usable, and if it is only a build time option, I can't imagine it would interfere too much with anything else- thus, a possiblity for later inclusion.
~tieguy
IAAL,BIANLY
Also, a more editorial comment - is anyone a little disappointed with the shortened release cycles? Nothing breeds anticipation like waiting for Linus to finally give the go ahead, after four months of bugfix releases, etc. But still, remember the madness when 2.2.0 was released? It was a damn fervor.. me and every Linux geek I know in RL had a party.. hehe. Now it seems like we've lost yet another cause for celebration. I don't see how the shortened devel cycles could possibly help, anyways. All that excitement spilled over into the media, and most of the major computer newsmags (A lot of ZD pubs, for example), ran a story on Linux just because 2.2 was released and it was such a momentous achievement. Now 2.4 is around the corner and no one seems really worked up, which means less press for us. What were Linus's reasons for doing this?
I think there is a world market for maybe five personal web logs.
The way that the current kernel(s) handle memory paging needs to be totally rewritten by linux for xfs, or xfs will need to be rewritten to handle linus's memory paging routines. They expect to have working xfs in minimum of 6 months, probably a year. This coems from ted T'so, kernle hacker, ext2fs writer, fsck writer.
--dave
I sure would like to know what the news is with SGI porting their XFS journalling file system to Linux. This will be awsome.
From what I've heard, XFS is going to require some heavy-duty changes to the VFS layer to allow for >2GB files on 32-bit systems. (It's also the VFS layer that keeps ext2 from allowing >2GB files, so this may end up killing two birds with one stone.) I don't think the SGI engineers working on XFS for Linux have any code that's fit for public consumption yet anyway.
"My life's work has been to prompt others... and be forgotten." --Cyrano de Bergerac
A (roughly) once a year release cycle is good for minor releases. There's less temptation to back-port stuff from devel into the stable kernel and therefore less chance of bugs showing up in the stable tree.
The kind of hoopla that happened with 2.2 is good, but it should be reserved for major releases every few years.
What I'm not clear on is how earth-shattering features that justify a bump in major version number and lots of hoopla will ever make it into the devel kernel. Linus is opposed to parrallel development trees (probably with good reason), but I'm not sure how else you introduce big changes withough jeapardizing the quick release cycle.
I think Linus should annoint somebody to start a "3.0 experimental" tree with major new features like clustering. Linus and the regular gang could continue work on 2.5/2.6 for another year, and then synch up with the experimental kernel for 2.7/3.0.
Of course, I'm just a lurker on Linux Kernel, so I don't really have any right to give advice. It's just my idea.
It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. - Abraham Maslow
I am currently maintaining and developing the FireWire subsystem which hasn't made it into the dev kernels yet. I sent a patch to Linus two weeks ago, but he didn't reply, which basically means refused. Understandably, there were some missing features like a highlevel driver interface (highlevel drivers as in harddisk driver etc.), which I am working on now, and isochronous transmissions.
When I get that sorted out I will try again. As it does not change anything outside of its own directory apart from a few Makefiles, it could be accepted even into a feature freeze. The homepage for this all is ECLiPt, where you can also subscribe to mailing lists.
No, it's certainly not a regular event. It's happened roughly four times in the past 7 years. .99 (1.0)
For
For 1.1 (1.2)
for 1.3 (2.0)
for 2.1 (2.2)
now 2.3 (2.4)
BFS is used to boot SCO UnixWARE
I just saw patches on linux-kernel.
BeFS is used by BeOS (somebody in Japan wrote a
driver for this)
The FENRIS project has a driver for Netware's
local disk filesystems. You could dual-boot
with Netware and Linux, getting at the same
local files.