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.'"
This discussion has been archived.
No new comments can be posted.
Wasn't there something on here recently about ext3? Saying that the author (forget his name, sorry) had gotten to where it didn't destroy HIS hard drive, but made no promises about any one else's...
...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.
I'm subscribed to the kernel digest, but unfortunately don't get to read all of it. I have two questions about the current state of the 2.3.x kernel (I stopped compiling successively newer kernels after 2.3.5[merely recompiling for difference options]. This was b/c 2.3.6 was broken pretty badly (IIRC) and 2.3.7 (And also 2.3.6) was when the vfat was broken w/ the page cache rewrites)
So, does VFAT work yet??? I've seen something about VFAT being Read/only, but I may have read that wrong, having never read the original post.
Second, I had heard that ALSA was going to be put into the kernel, to replace/supplement OSS/Free. Is this not going to happen in 2.3.x, or maybe it'll be a minor change doable in 2.4? Is ALSA not considered complete/stable enough. Comments welcome on both q's.
I am not a kernel hacker (I wish) but from browsing of the kernel list I don't think this comment:
"I sent a patch to Linus two weeks ago, but he didn't reply, which basically means refused."
Is fully true. I am fairly certain Linus has been known to purge his mail (as he actually mentions doing in this article) or pass stuff onto others to manage overload.
I assume you mailed it to the linux kernel list as well? That seems to be where new features find supporters to lean on Linus:)
That it worked in 2.0.x doesn't mean it can't be broken in 2.3.y, especially since the latter is a development series. And yes, it was broken in 2.3.7 and some successive kernels. At least since 2.3.15 it has been compiling again, but I haven't really testesd it so I can't promise it's fully stable. (It probably is though, or they wouldn't have repaired it.)
ALSA is not in the main kernel at the moment, and I have no idea whether it will still be included or not. It does not seem very likely.
I think this is inevitable. Quite a few people (including myself) wouldn't dream of putting a x.[N*2+1].y kernel on machines they expect to do any standard work on, because they are known to be "unstable". As a net result these kernels probably aren't subjected to the same kind of rigorous beta (or pilot?) testing as their "current" (to steal from the FreeBSD jargon) counterparts, so it's inevitable that hitherto unnoticed bugs will be found.
Though I take your point. My experience with FreeBSD taught me not to trust version-zero releases and wait at least for the first or second round of patches before installing them on any machine that is going to do any real work. A case in point was the release of 3.0 (and 3.1 was still a bit flaky), not least because in the early 3.x releases they were still migrating from a.out to ELF. (And the equally flaky USB support that IIRC disappeared in 3.2 due to popular frustration.)
Having said that - the sooner and the more people install 2.4.0(? I assume), the sooner the bugs will be found and fixed. I would be _very_ surprised if any remaining bugs were really significant. But then, I'm probably just being naïve...;)
-- This isn't the post you're looking for. Move along.
Having looked at ALSA's web site [alsa-project.org], I'd say that it has a way to go before it replaces OSS/Free. It still does not support many soundcards (or at least, the list on their site isn't particularly long) and the fact that the latest release (this month) is still a 0.x probably shouldn't fill anyone with confidence.
Aside: Linus has adopted Microsoft version numbering, he's just not telling anybody. That '.' between the two and the four really stands for '00' - which means, of course, that the 2.4 kernel will actually be released in 2006.
-- This isn't the post you're looking for. Move along.
I'm not really following the Kernel-Mailinglist (just what people forward to me), and I wonder, if there will be a stable and working ISDN-Driver in there.
Seems to me, that Linus somehow is pretty pissed at the attitude of the ISDN-Developers, who seem to release only Big Driver Chunks, when it is close to a feature freeze.
Any updates on that (I need a working ISDN-Driver)?
I don't expect Linus will pay any attention to the W2k launch date. He's often said that he enjoys doing The Right Thing for technical reasons, and not being driven by marketing.
If, OTOH, he has taken the Mindcraft study personally, we might see kernel development targetted specifically towards beating NT. But personally, I think that other features deserve more attention - Linux is already much faster than NT for me.
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.
Currently netfilter comes as a separate package and you have to compile it againt your kernel tree if you want modules for NAT and iptables. Is there a plan to include the modules into main tree? Or will this be left as a separate package?
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.
I'm not part of the kernel development team, and I have not kept up with the 2.3.x series. So, I'm a little behind. I would love to see a list of the updated/new features in the new series. I'm aware of the USB support, but what about FireWire? Are there any major changes to the ext2 filesystem? I realize that everything is tentative right now, but it would be nice to have a sort of refresher on the current happenings in the kernel development group.
Well, considering Linus's philsophy of "release often", there is really never NOT a release. What changes are the claims made about a particular revision. 2.4 will be explicitly proclaimed as a "stable release" (though there are some who argue about the true stability of the even versions - bugs are always being found and fixed). You're welcome to grab the "release" right after feature freeze - if you're feeling brave. Hell, it might even work for you.
I mailed information on the ongoing works and where to find homepage, patches and mailing lists to the linux-kernel. The whole patch is 230kB uncompressed (and still growing), so I only sent it to Linus and not the list.
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 have heard that XFS and IRIX paging/scheduling are "Siamese Twins Connected at the Bung", as my late father would say. This does not make any porting easy, and many design decisions need to be made as to what should change to keep the functionality and the performance goals.
>start a "3.0 experimental" tree with major new features like clustering
Actually that "tree" exists in every OS lab on every college campus, and in every corporate R&D lab in the world, and in the mind of every kernel hacker on the net. The "experimental" tree you want needs to start from an stable kernel and attempt to add some specific feature to it from the outside - not part of the kernel development, but part of a standalone function development. Then the knowledge and experience that is gained from that endeavor comes back into the next release level (major or minor - depending on how big it is) and gets re-implemented (well, hopefully... in reality there will be some copy and paste-ism). Any time you're playing with cutting edge stuff the first draft is ususally less than optimal for general use... but oh the lessons you learned! How many times have you been involved in something to come back after several months and have to fix a bug only to ask "why did I structure it like this??"
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".
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 [linuxcare.com] to see what people on the list have been saying.
-- Does Rain Man use the Autistic License for his software?
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?
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.
Gosh....... Too bad he isn't checking his email. I sure would like to know what the news is with SGI porting their XFS journalling file system to Linux. This will be awsome. I hope this is what Linus was refering to by the term "file system"???
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.
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
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....
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.
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.org]. 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 think another reason for short devel. cycles is the speed at which hardware technology advances... as much as you may hate the features M$ or Intel 'force' into the hardware market, it's still very sexy when Linux can use them! (eg. USB... well ok, i doubt you hate the idea of cutting the number of cables behind your desk in half...)
Linus won't even accept new drivers during that times, even if they supposedly don't effect anything. He wants everyone to concentrate of finding bugs so the the release, which will literally be picked up by millions of people, will not hose a large portion of the linux community.
Basicly it's "Don't send me new anything. If it doesn't fix existing code, I'm throwing it out. No new features anywhere, we don't have time to deal with them."
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?
Does anyone know how WELL they work with USB? I want to buy a scanner soon but Linux compatibility is ESSENTIAL, and I don't want tons of headaches getting it working. Is there a reasonably stable SANE driver? Any experiences?
Hm.."code freeze" sounded like "Nobody touches that code for *any* reason beginning NOW!" to me - which admittedly wouldn't make sense. After all, removing bugs is still changing code.
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.
GART didn't make it in to the freeze. Anyone following the GLX project (MesaGL acceleration for Matrox, nVidea and now ATI cards) would know that GART is a nifty AGP related thing.
Well maybe we'll do like has happened in the past, convince Linus to add something after the freeze =)
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.
The kind of hoopla that happened with 2.2 is good, but it should be reserved for major releases every few years.
Actually, the 2.2 kernel really did have some major new stuff (if you're like me and don't run the alpha kernels--I need a *stable* development platform and don't care for non-stable kernels) it was the first stable release to have full support for SMP, which is important. And the speed improvements over 2.0.x were pretty nice, too. (Unlike M$ software, sometimes new releases mean FASTER software, not just freeping creaturism)
Aside from that, Linux doesn't *need* to rely on good press. The code stands for itself. That said, if Linux is going to succeed in the corporate arena, it does need to stay in the press, good or bad. So getting in the press is never a bad thing, and it always helps.
I think Linus should annoint somebody to start a "3.0 experimental" tree with major new features like clustering.
Starting a new tree isn't always a good thing. It makes code management much tricker and more difficult. What if someone adds a feature in the new tree, but another feature is added to the old tree that breaks the new feature? Or vice-versa? And lets not forget the possibility of duplication of effort... phew. It gives me a headache just thinking about it.
Right now PPP doesn't work at all (2.3.17) neither does support for hpfs. The kernel won't even compile if you put hpfs in the kernel and PPP just doesn't work whether you put it into the kernel or in a module. I use ppp-2.3.8-14 which is what came with SuSE 6.2
Of course there will be changes before the release. Someone would look like a big moron if PPP was still not working at the release time.
Why does the kernel paging mechanism depend on the file system? The swap partition is a totally seperate type from the FS - it's Linux swap and not formatted as ext2. So it seems like the main FS type would be irrevelent to paging.
But then, I'm not a kernel hacker. This was more a question and/or a hunch than offering advice.
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 [uni-klu.ac.at], 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)
Of course some certain events happen everyday, but that does not mean you call them regular. Murder happens everyday and it is always news. Besides, how often does our little OS have any kind of freeze?
The feature freeze means that no new features are added, except for the reasons Linus outlined. A code freeze means that no new development occurs on the kernel, just bug fixes. Usually this takes a month or more to complete. If you bypassed the code freeze for release, you could be in for a nasty surprise, which is why the kernel is developed this way. The last thing you want is to release a stable Linux kernel with major bugs.
Re:What about ext3 (Score:1)
--
Re:How stable is this? (Score:3)
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.
Re:What about ext3 (Score:1)
VFAT & ALSA (Score:1)
So, does VFAT work yet??? I've seen something about VFAT being Read/only, but I may have read that wrong, having never read the original post.
Second, I had heard that ALSA was going to be put into the kernel, to replace/supplement OSS/Free. Is this not going to happen in 2.3.x, or maybe it'll be a minor change doable in 2.4? Is ALSA not considered complete/stable enough. Comments welcome on both q's.
USB CD-RW's (Score:1)
Re:FireWire support (Score:1)
"I sent a patch to Linus two weeks ago, but he didn't reply, which basically means refused."
Is fully true. I am fairly certain Linus has been known to purge his mail (as he actually mentions doing
in this article) or pass stuff onto others to manage overload.
I assume you mailed it to the linux kernel list as well? That seems to be where new features find
supporters to lean on Linus
Re:VFAT & ALSA (Score:1)
ALSA is not in the main kernel at the moment, and I have no idea whether it will still be included or not. It does not seem very likely.
Re:Always Releasing (Score:1)
Though I take your point. My experience with FreeBSD taught me not to trust version-zero releases and wait at least for the first or second round of patches before installing them on any machine that is going to do any real work. A case in point was the release of 3.0 (and 3.1 was still a bit flaky), not least because in the early 3.x releases they were still migrating from a.out to ELF. (And the equally flaky USB support that IIRC disappeared in 3.2 due to popular frustration.)
Having said that - the sooner and the more people install 2.4.0(? I assume), the sooner the bugs will be found and fixed. I would be _very_ surprised if any remaining bugs were really significant. But then, I'm probably just being naïve...
--
This isn't the post you're looking for. Move along.
Re:VFAT & ALSA (Score:1)
Having looked at ALSA's web site [alsa-project.org], I'd say that it has a way to go before it replaces OSS/Free. It still does not support many soundcards (or at least, the list on their site isn't particularly long) and the fact that the latest release (this month) is still a 0.x probably shouldn't fill anyone with confidence.
Aside: Linus has adopted Microsoft version numbering, he's just not telling anybody. That '.' between the two and the four really stands for '00' - which means, of course, that the 2.4 kernel will actually be released in 2006.
--
This isn't the post you're looking for. Move along.
So what about ISDN? (Score:1)
Seems to me, that Linus somehow is pretty pissed at the attitude of the ISDN-Developers, who seem to release only Big Driver Chunks, when it is close to a feature freeze.
Any updates on that (I need a working ISDN-Driver)?
Ralph
Re:How stable is this? (Score:1)
If, OTOH, he has taken the Mindcraft study personally, we might see kernel development targetted specifically towards beating NT. But personally, I think that other features deserve more attention - Linux is already much faster than NT for me.
Don't take Linus so seriously, PLEASE :-P (Score:5)
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 [linuxhq.com] 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.
Netfilter (Score:1)
PCMCIA finally made it. (Score:2)
List of features (Score:1)
Always Releasing (Score:1)
Just a thought...
Re:How stable is this? (Score:1)
Re:FireWire support (Score:1)
Re:How stable is this? (Score:2)
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?
Re:xfs file system (Score:1)
Re:Quick minor releases, long major releases... (Score:1)
Actually that "tree" exists in every OS lab on every college campus, and in every corporate R&D lab in the world, and in the mind of every kernel hacker on the net. The "experimental" tree you want needs to start from an stable kernel and attempt to add some specific feature to it from the outside - not part of the kernel development, but part of a standalone function development. Then the knowledge and experience that is gained from that endeavor comes back into the next release level (major or minor - depending on how big it is) and gets re-implemented (well, hopefully... in reality there will be some copy and paste-ism). Any time you're playing with cutting edge stuff the first draft is ususally less than optimal for general use... but oh the lessons you learned! How many times have you been involved in something to come back after several months and have to fix a bug only to ask "why did I structure it like this??"
USB? (Score:1)
Re:USB? (Score:1)
Re:Code freeze --> new release? (Score:1)
... of'course they are not that big as elephants like we are used from some software gigants ala Microsoft(tm)(r)(c)82-99.
Freaker / TuC
devfs inclusion (Score:3)
Re:so? (Score:3)
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".
Re:devfs inclusion (Score:4)
-- Does Rain Man use the Autistic License for his software?
Re:Code freeze --> new release? (Score:1)
Re:USB? (Score:5)
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?
Code freeze --> new release? (Score:1)
Re:devfs inclusion (Score:2)
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.
NEW FILES SYSTEMS??? (Score:1)
Who knows..... But if ya do please do tell..
-Diz
Re:NEW FILES SYSTEMS??? (Score:4)
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
Re:NEW FILES SYSTEMS??? (Score:3)
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? (Score:2)
Re:so...it's news (Score:1)
Re:How stable is this? (Score:2)
Re:devfs inclusion (Score:2)
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.
Re:Code freeze (Score:3)
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
LVM please (Score:1)
2G VFS limitation on x86 - no more. (Score:2)
Re:How stable is this? (Score:2)
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.
Re:How stable is this? (Score:1)
(eg. USB... well ok, i doubt you hate the idea of cutting the number of cables behind your desk in half...)
dufke
________________________________________
Re:USB? (Score:1)
Re:Code freeze --> new release? (Score:1)
Basicly it's "Don't send me new anything. If it doesn't fix existing code, I'm throwing it out. No new features anywhere, we don't have time to deal with them."
Reiser? (Score:2)
~tieguy
Re:"our targets never slip" (Score:1)
Oh well. Such are the clueless.
How stable is this? (Score:3)
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?
HP Scanners (Score:1)
Thanks
Re:Code freeze --> new release? (Score:1)
xfs file system (Score:3)
--dave
Re:NEW FILES SYSTEMS??? (Score:4)
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.
Doh! (Score:1)
Well maybe we'll do like has happened in the past, convince Linus to add something after the freeze =)
Quick minor releases, long major releases... (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.
Re:Code freeze --> new release? (Score:1)
Just curious... (Score:1)
But who's PAYING him!?!?! should we be starting a fund?
Re:Quick minor releases, long major releases... (Score:1)
Actually, the 2.2 kernel really did have some major new stuff (if you're like me and don't run the alpha kernels--I need a *stable* development platform and don't care for non-stable kernels) it was the first stable release to have full support for SMP, which is important. And the speed improvements over 2.0.x were pretty nice, too. (Unlike M$ software, sometimes new releases mean FASTER software, not just freeping creaturism)
Aside from that, Linux doesn't *need* to rely on good press. The code stands for itself. That said, if Linux is going to succeed in the corporate arena, it does need to stay in the press, good or bad. So getting in the press is never a bad thing, and it always helps.
I think Linus should annoint somebody to start a "3.0 experimental" tree with major new features like clustering.
Starting a new tree isn't always a good thing. It makes code management much tricker and more difficult. What if someone adds a feature in the new tree, but another feature is added to the old tree that breaks the new feature? Or vice-versa? And lets not forget the possibility of duplication of effort
USB Quickcam (Score:1)
Re:Code freeze --> new release? (Score:1)
neither does support for hpfs. The kernel
won't even compile if you put hpfs in the
kernel and PPP just doesn't work whether you
put it into the kernel or in a module.
I use ppp-2.3.8-14 which is what came
with SuSE 6.2
Of course there will be changes before the
release. Someone would look like a big
moron if PPP was still not working at the
release time.
http://www.netonecom.net/~bbcat/
Re:Just curious... (Score:1)
Re:xfs file system (Score:1)
But then, I'm not a kernel hacker. This was more a question and/or a hunch than offering advice.
FireWire support (Score:2)
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 [uni-klu.ac.at], where you can also subscribe to mailing lists.
Re:so? (Score:3)
For
For 1.1 (1.2)
for 1.3 (2.0)
for 2.1 (2.2)
now 2.3 (2.4)
Re:NEW FILES SYSTEMS??? (Score:1)
But that's no worry... as we are getting stable releases more frequently from now on.
BFS, BeFS, NetWare FastFAT (Score:2)
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.
It is not regular news (Score:1)
Re:Code freeze --> new release? (Score:1)