Slashdot Mirror
Kernel Pool Is Back For 2.6
Manuka writes: "Win Fabulous Prizes and the recognition of your peers! (well, OK, maybe not the latter). As it's become somewhat of a tradition, tummy.com is now taking bets for the release date of the next production Linux kernel. Congratulations to Bill Wendling who won the pool for 2.4." Hey waitaminute, I don't even have a Slashdot shirt, never mind a VA Polo -- where do you get these?! Of course, Linus has promised a shortening release cycle, so bet accordingly.
I don't think time_t even supports the year I'm thinking of.
- I don't care if they globalize against free speech. All my best free thoughts are done in my head.
Releasing less incremental updates makes it easier on users, developers and distributors, in that if they need a feature like, for example, a new VM, they can just blanketly tell users they need Linux 2.4. If the new VM was released for 2.2, you'd have to require people to have a 2.2.27 kernel or newer. That doesn't sound too difficult, but it soon becomes a major headache. `I have 2.2.26 and it doesn't work for me'. Remember, most current Linux users don't match the profile of most future Linux users.
/dev/dvd, despite the fact they have DVD support in their new 2.2.50, my app might fail if it was looking for /dev/dvd [which it should be].
As it is now, bleedign edge folk can get incremental updates via odd kernels.
A new release neatly bundles all those incremental changes. 2.4 is a known quantity. A minor release isn't, becuase nobody can afford to keep track of the incremental updates in each release. If a user needs DVD support for my game, I tell them to get 2.4. I could tell them to get a 2.2.50 if it had those features, but better to break everything in their distribution at one time rather than cause many small annoying issues. Eg, since their 2.2.7 distro didn't create
The standard file system shouldn't be dictated by the kernel at all. The current ext2isms in the kernel vfs code should be hunted down and eliminated, but not replaced by Reiserisms. Let the distros and users decide which fs they want to use; the kernel should be completely fs neutral.
There's no "we" in team, only "me"
I'm betting on two weeks after the next time it's featuredon the vaporware list.... ;-)
S.t.e.v.e.
Better not tell you now...
I say July 2, 2002
=== The price of freedom is eternal vigilance
I don't think so. First, the hardware drivers should be entirely independant of the kernel. I'd really like to see drivers forked as independant projects with strong ties to the kernel developers. Second, you don't really point out *how* these developments are interrelated. As far as I can see, USB has nothing to do with the new VM. The news filesystems such as ReiserFS and the like have little to do with other kernel components other than the VFS (thought, technically, the VFS should require no changes for new filesystems...) agpgart is totally unrelated to the VM, as is DRI, etc. Starting to get the idea? While it may be true that changing one subsystem requires changes to other subsystems, it is not true that they require *major* changes at the same time. If the kernel was upgraded incrementally, then the resulting product would not only be easier to support (less stuff to break) but the transition would be easier. I remember that upgrading from 2.0 to 2.2 was a huge pain (I had to change distros) because so much stuff had changed. 2.4 will be a similarly big leap, and I can't help wondering how people will handle the 3.0 jump. Recently on BeDevTalk (the BeOS mailing list) there was some talk of what would happen if Be had to break binary compatibility (to move to GCC 3.0, if they ever do it.) There was also talk what would happen if changes to the InterfaceKit (the UI API) needed a break in binary compatiblity. Somebody (me) suggested lumping all of these breaks together. Of course I was (rightfully) chastised by a developer who pointed out that such major changes should be handled gradually, and it would be insane to make developers deal with both a new binary standard and a new API.
A deep unwavering belief is a sure sign you're missing something...
> The one thing I want to see between now and 2.6/3.0 is ReiserFS replacing ext2
It sounds likely that ReiserFS will make it into the kernel sometime 2.4.x, perhaps early in the lifecycle. And once one journalling filesystem goes in, the rest will come rather quickly. Quite a bit of the difficulty has been in introducing journalling features into the VFS layer. This is code that will be reused for every journalling-style filesystem implemented.
Also, once ReiserFS becomes stable, it will not necessarily replace ext2fs. I expect ext2 will be around for quite some time, and will remain the default on installs for some time.
--Lenny
- http://linuxquality.sunsite.dk
So far it's just a proposal. In the short term there will be resources on testing strategies, as well as tips on writing quality code. I the long run will come a nice web form for reporting bugs in a way that will be especially meaningful for kernel developers (capturing and searching hardware configuration and kernel config options).Michael D. Crawford
GoingWare Inc
-- Could you use my software consulting serv
Of course, Linus has promised a shortening release cycle, so bet accordingly.
Oh really? Is this like the time he said that in 1999 about 2.4? Not bashing or anything, I think Linus should release when he thinks it's ready, I'm just saying that you might want to bet on it (ha ha).
My other
Sure they lack factors of 2, but they are still numbers. With one exception, every prime number is odd and prime numbers are important. Does Linus Torvals hate prime numbers?
This 'even-numbered' favoritism is surely a sign of some deeply rooted hatred and fear.
Keeping
Lotteries are a tax on people who can't do math.
Does this mean this pool is a tax on people who haven't read "Mythical Man Month"...
marty
PS: yeah, i know you don't pay to enter, go along with the joke...
"I can't buy want I want because it's free. Can't be what they want because I'm me." -Corduroy, Pearl Jam
I'd beg to differ. If, instead of huge, long in coding major releases, the kernel had shorter, more succinct releases. then progress would be faster (less stuff to test for each release) and the product would be higher quality (less stuff that could break for each release.) When you write a major program, you don't code major subsystems at one time do you? Of course not. You code the thing incrementally. For example, if you wanted to change the VM, you change the VM and release a minor release. That's what .x releases are for. Major, structure changing releases (which 2.4 is) should increment the major version number (x.0) Of course, IANAKE (I am not a kernel engineer) so take this with a grain of salt ;)
A deep unwavering belief is a sure sign you're missing something...