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.
Well, you could bug Rob.. I work for GameSpy, and I have tons of stuff .. hats (not limited to GameSpy -- I have Half Life, etc) shirts, mouse pads.. I'm sure that CmdrTaco has a similar stash. (OF CLOTHES! Don't think about dirty stuff.)
------------
CitizenC
January 13, 2002
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
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.
"Homo sum: humani nil a me alienum puto"
(I am a man: nothing human is alien to me)
My only political goal is to see to it that no political party achieves its goals.
"With one exception, every prime number is odd"
"2 is an even prime number"
I'm wondering what that exception could be...
Okay... I'll do the stupid things first, then you shy people follow.
Okay... I'll do the stupid things first, then you shy people follow.
[Zappa]
Users aren't stupid.
You've never worked tech support, have you? :)
1st Law Of Networking: Loose ends are bad, termination is good.
WWJD? JWRTFM!!!
I think the point was more rather than rewriting several major parts of the kernel for one release, why not let 2.4 rewrite one major system, then 2.6 rewrite the next, etc. And of course get updated drivers and other nice things along the way. Say 2.4 was released a year ago with all the nice hardware support improvements (USB, card services, PCI changes, anything else I missed), and then 2.6 came out now with all the memory management rewrites? I don't see a downside to that. I never heard complaints about memory management before, but plenty of people wanted USB. So why not cut back on the scale of each release? Targetting for roughly yearly releases sounds reasonable to me.
I don'I don't know much about Tux2, but it seems to me that everything Tux2 offers is already being shown by ReiserFS.
Ow, c'mon. At least you forgot the coolness factor. Tux2 is a "whole new technology", it has to face a patent to a similar system that is probably invalid or at least not applicable to Tux2 (because Tux2's predecessors itself form the prior art), it doesn't have to journal so it comes per definition with less overhead, and it introduces all kind of fluffy terms. Plus it didn't take all kinds of flames to get into the darned kernel (sorry Hans, I know emotions can run high on mailinlists sometimes).
I mean, comparing Tux2 to ReiserFS is like comparing Linux to BSD. They may both validly work in practice, but Linux seems to be the more sexy and to have the buzzword factor.
It's... It's...
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
You're calling the Linux *kernel* GNU/ Linux? That's plain filthy, you RMS! There's no GNU code in that thing (yes, it's GPLed, but no part of the GNU project)! And GNU/ Linus? What's that supposed to mean? Were his parents hippies?
Instead, we might rather talk about Linux/ HURD when referring to the HURD by now...
;-)
It's... It's...
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
I believe the linux kernel should go up to 11.
Slashdot is jumping the shark. I'm just driving the boat.
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
Or perhaps "an Itanium plated Box"...
"Depression is merely anger without enthusiasm." - Anonymous
Another issue to consider is the constant advancement in hardware. One reason for changes at the memory management level was the the existing system was inefficient when run on large memory machines. Your mechanism will lead to stagnation in the development tree. Commercial distributions will ignore this, releasing patched kernels with source that hasn't been fully audited, leading to stability problems.
Didn't ANYBODY watch that show on last night about World Sports Exchange? Basically, three guys founded an online sports gambling startup, in Antigua, just to be safe. Now the US gov considers them criminals on the run from the law!
It's 10 PM. Do you know if you're un-American?
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...
we should put the vaporware list on the vaporware list. It has not been delivered to spec, and I doubt it will ever will be. Plus it would be full of recursive sillyness :)
"Let him go, Ralph. He knows what he's doing." --Otto Mann (simpsons)
Check here. I can't find a link to the VA Linux shirt, although I'm almost positive I saw one there ..
------------
CitizenC
I would make the date November 20th.
* Hey, just joking about that part! :)
* also, this would not technically be cheating on Mrs. Torvalds, since it would really be me inside the Finnish Love Machine**.
** I don't think anyone has ever put the words "Love," "Machine" and "Finnish" in that particular order before, certainly not in this context.
jrnl: http://tinyurl.com/c2l8yr / foes: http://tinyurl.com/ckjno5
If these trends continue, I'd probably expect to see the next kernel on February 31st, 2001. ;)
> 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
Well, you may be right, and (separate issue) Linus may agree;)
... the diff. between 2.2 and 2.4 in terms of features (can't speak for performance personally yet, but all I hear is good so far :) ) is really amazing, and that's refreshing. It's craft, pride of workmanship and engineering over marketing, a rare triumph!
.c -- that usb problem was cleared up, and now it's got XFree 4.5 by default."
I hope not, though -- the conservative version numbering system so far employed has demonstrated restraint and non-craven humility
Now it might make sense, as some have suggested, to go straight to 3.0 from here -- ok, that I could live with, it's at least the next integer in line, and "three point oh" does have a nice ring to it. But to take the slackware leap would be ultimately futile -- if Linus calls the next kernel "Linux 7.0" then some distro will busily repackage all their disks with that kernel until they are called "Official DistroName Linux 8.5!"
Maybe some distro (Debian leaps out, for version-numbering reasons) should introduce a 3rd version number or add a letter.
And a conversation like this one could happen:
"Hey, whatcha runnin' there?"
"Debian 2.6"
"Yeah? 2.6.b?"
"No,
Just a thought,
simon
"Hey Carlito, r'membah me? Benny Blanco from the Bronx!"
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
Do you really think it matters? Users aren't stupid. Most people can figure out that a higher versioned software isn't necessarily better. People have been doing this with model years and TV model names for years, the computer industry isn't so f*cking 'leet that people can't figure out revisioning. (there are exceptions, but you have idiots who use gearshits to hold handbags too.) The problem with Linux isn't the fact that the kernel and the distro have two seperate numbers (it really isn't an issue, MS has had seperate version numbers for DirectX and Windows or Word and Windows for a long time) but the fact that people aren't really clear on what "Linux" is. If the distro makers would stop calling their products "Linux" or somebody would change the name of the kernel to something else, then it wouldn't be confusing. In the end, it really doesn't make a rat's @ss of a difference. People shouldn't really care what kernel version is in there anyway. (For those 'leet users, not having the low-level system info shoved in your face doesn't make you any less 'leet. It just means you have to dig around in /proc from now on.) The kernel is just another part of a well organized, coherent whole that is the LinuxOS. (Yea right...)
A deep unwavering belief is a sure sign you're missing something...
I am sick and tired of everyone saying, "We should do X, so newbies won't have to learn Y". I am happy if people want to use GNU/Linux, but if it means having to dumb down everything, then what is the point anymore?
So why do you call it "GNU/Linux". Wasn't RMS's excuse that he wants newbies to know about GNU? So isn't calling is "GNU/Linux" really "dumbing down" the name so that newbies won't have to spend some time using Linux so they can find out for themselves that some of the command line utils and libc are GNU?
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...
It will probably be 3.0, if 1.2 -> 2.0 is any indication...
Is that part of the pool too? I think it should be included: what version you think it will be, and what release date you think it will be.
# debian/rules