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.
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?
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.
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:(
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
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.
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.
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
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
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)