Slashdot Mirror
Linux Kernel 2.4 out by this Fall?
Skeezix writes
"Linus says that he aims to make kernel upgrades more
incremental instead of cramming tons of features into each
major upgrade. The net result? The next major kernel upgrade
might be out by Fall."
I still haven't worked out all my kinks with 2.2 yet, at this
rate 2.4 will be out before I sort it out!
I think he was talking about the other reply :-)
Daniel
Hurry up and jump on the individualist bandwagon!
I have a few friends that are still on 1.2.13 and have no plans to upgrade. For them there is no reason to. All of the devices they use are supported, all of the features they want are already there, and 1.2.13 has a much smaller memory footprint.
--- A Jesus Fish eating a Darwin Fish only proves Darwin's point.
In the article they quoted Linus as saying:
I feel like going for another eight-and-a-half years.
Though I'm sure this has been talking about before but what would happen if Linus did hang it up? Do any of the other core kernel developers have what it takes to fill his shoes or is it likely that the kernel would fork in different directions under different leadership. Or maybe it would move to a more democratic development model like Debian has. Just something to think about :^)
Windows 1.1 was definately available separately from Excel. I ran it on my Laser Turbo XT. Well, I didn't run it often. It didn't recognise my mouse, was a pain to use with just a keyboard, and I didn't have any applications for it, but I did have it installed. I ran Geos most of the time.
I actually owned two copies of Windows 1.1 (both given two me, so I don't know how much it cost), and darn but I wish I hadn't wiped those floppies and used them for other things. I'd love to install it again just as a conversation piece.
"Be Happy or Die." -- AoN
Who cares about Linux 2.4 when FreeBSD exists ?
This is bunk. I do work for sun, but anyone who has 2.7 can pull up uname -a and see for themselves. SunOS 5.7 The decision to call it Solaris 7 was purely for marketing.
I've finally had it: until slashdot gets article moderation, I am not coming back.
Was there a version 1.0?
--
You got something to say about the Commodore 64?
That's what I thought!
No, really, in all honesty, Linux running as a command-line-only OS on a small device would not be that bad of an idea. Actually, in order to be effective, it would definitely have to be streamlined, but still, command-line-only OS's have a lot of potential in a small amount of computing power. Think about it, using a command-line-only version of Linux still gives you access to news groups, email, text editing (for notes), security, and compatibility with a full blown operating system for easy file transfer. Assuming there were a specialized Linux made to run on these little guys, I think it would be great.
The Palm Pilot example shows that you would need a graphical interface of some sort, but it would be very easy to do. Since Palm Pilot grpahics are black and white anyway, it's no big deal and requires very little memory. I say go for it.
Eric
By the way, I honestly believe the commodore 64 could do a decent job of running Linux provided it's graphical and sound capabilites are limited and ethernet is gonna have to be an engineering feat of its own. Still, you can operate modems just as fast with the C64 as you can with a PC and if Linux can provide a TCP/IP stack for the Commy, then you will sitll have access to networking. And, another engineering feat, but possible, would be to adapt a PCI bus to the commy and use video cards from the PC. Quite a novel little project really. Good for few sundays when there is nothing else to do . . .
It seems to me that this is a good move for one simple reason: fewer changes. What I mean by that is that you don't have to sit and debate over all the changes in the jump to the next major rev, (e.g., ipfwdadm vs ipchains, USB vs. broken down USB). There may very well be many features rolled into the quantums we've been taking in the past but the more releases that are made add a level of granularity to the upgrades that have been absent in the past, afforded only by patches. I think this actually reflects a much more meaningful use of the minor rev numbers, which seems to be a common point of contention.
Once it is released, I am sure things will work at quite a furious pace. Cygnus has signed the NDA and will make the compiler for Merced. Linux has always said Linux can be ported to any platform that gcc can run on, so don't sweat it.
From An RT-Linux Manifesto (in Proceedings of the 5th Annual Linux Expo), page 195:
6. What next and acknowledgements:
[...]
Linus Torvalds once said the the RTLinux core would become integrated with the standard kernel in 2.3, but the availability of pre-patched kernels makes this a less pressing issue.
(see subject line)
Chris Wareham
It was pure silliness -- inspired by the "version-number-as-marketing-tool" conditions you just described.
:)
I think the original "somebody already has" comment was actually directed at the AC who called the idea "absurd".
I added the comment because people sometimes assume that slashdot posters are trying to contribute serious, well-thought-out insights and ideas to the forum. That would be OTHER posters, not me.
Save the whales. Feed the hungry. Free the mallocs.
Alan would probably take over. As for democratic development model, that might be good for some thing, but I don't think the kernel is a good idea. Things designed by comitee bloat at the drop of a hat.
Think about it, how many of the programs of your distribution do you really use? The kernel isn't a place to play political games and democracy encourages compromise and horse trading.
I have not had any real problems with 2.2.9. My machine has been doing okay with it. Any problems that I have had were there in 2.0, but I found out they were BIOS related... first?
Only 'flamers' flame!
I think this is what more users expect. I've encountered some confusion from folks on 2.2: "if it's so much better, why isn't it 3.0?"
It would have been nice to have had a 2.4, 2.6, 2.8 somewhere in between.
I hope this doesn't lead to burnout. Linus does happen to have a life (i. e., wife, kids, job).
--
Get your fresh, hot kernels right here!
I really would'nt expect to see too much difference once the new cycle takes effect. It's either called 2.2.17 or 2.4.0, but you are still going to get basically the same feature set. Quicker kernel release cycles means that major version increments will not necessarily tie to majot feature injections.
;-)
1.2 -> 2.0 Major changes
2.0 -> 2.2 Major changes
2.2 -> 2.4 Minor changes
2.4 -> 2.6 Minor...
I would'nt look for anything huge until 3.0. But I suppose that could be a month away
Four-digit slashdot ID. Recognize.
Open Source: Release early. Release often.
Much better than MicroSoft: Promise early. Release maybe. Patch occasionally.
This is good news indeed.
--
"May I have ten thousand marbles, please?"
At this rate, 2.4 may be out before I switch to 2.2. I was working on it, but I munged my system badly, trying to upgrade to glibc by hand. I've installed Debian this time, and am still playing with configuration. Don't have much time to work on it.
thejeff
This means that there will be fewer "experimental" changes in each major release, much to the pleasure of us joe users.
Posted by unpHEAR:
... :)
Who's gonna maintain linux kernel developpement if Linus hang it up? Alan Cox for 3 imaginatives reasons.
1-)We always heard about kernel 2.2.xacx
2-)He was a good looking guy
3-)Linux will be called Lincux
Here is my 2 cents...
Iam not a Geek
It was my opinion
Sorry for my english
emman
-- Security Updates
-- New devices (I do have USB, but nothing on it currently)
-- Ensuring that 2.0.X users don't get forced to upgrade. (What? You want to run Gnome 2.0? That requires gtk1.4 which only support glibc 2.2.3 which requires Linux 2.6)
Piecing together one groundless rumour with another:
Maybe Transmeta's first product is going to something that'll make both the Palm Pilot and Isty look big, clunky, and out-dated.
Life is like an egg better scrambled than fried. -- Ken Sawatari
Check out the history of the clone() system call. I might be wrong about the specific patchlevel, but I know it was added sometime in the 1.3 series (the number 1.3.19 keeps coming to mind now).
I have absolutely no idea about SMP support. Was primitive SMP availible in 2.0.0?
---
DNA just wants to be free...
You have to love this kind of thinking. To the general public, even for technical products, Microsoft has given up all pretense of having the version numbers actually mean anything.
:)
Visual Interdev jumped from 1.0 to 6.0. What happened to the other numbers?
Still, when you get down to brass tacks, you still have proper version numbering, even from MS... "Oh, asp.dll 2.37.2.2 leaks memory - you need asp.dll version 2.39.17.4 to fix that!"
Ugh
Do you even know anything about perl? -- AC Replying to Tom Christiansen post.
That is something i was wondering since the Mincraft benchmark. Is there some kernel level thread.
If there wasn't up to now and if we add it and modify some part of the kernel to use it efficiently this could be a considerabvle boost in SMP performances.
Hope this will become true.
Imagine Linux kicking Nt's ass on high level harware (something like 16+ CPU's). that is one thing I would want to see (the sooner the better
just some of my dreams
"The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." Bill Gates,
First, as others have pointed out 2.4 will be the stable release of the 2.3 development kernel. Second, as no one else has pointed out, part of the kernel release process includes a feature freeze. There is a point during the 2.3 development when Linus will stop accepting new features, and only be accepting bug fixes. Essentially, what Linus is saying is that the feature freeze will occur sooner with fewer new features to debug resulting in more stable, but less featureful(sp?) stable kernel releases. This is probably a good thing.
Just think -- if Windows 2000 had a two-digit date, then it'd report itself as Windows 00, a pre-alfa version =)
Christopher A. Bohn
cb
Oooh! What does this button do!?
I say, "yes sure", why not ?
version 2.2 was out just before summer 1998 and the 2.4 will be out before the end of the year ?
ok. He can say so, as usual, but we're talkin' about software, don't forget it.
seb.
--
Memory fault -- brain fried
There are several good reasons I can think of of having more regular, but less dramitic, major version releases
Maturity: the kernel has setted down quite a lot at 2.2, and hopefully there won't be as much major upheavals as from 2.0 to 2.2, and it should me more an adding drivers/tweaking, rather than a redesign.
Marketing: or more accuratly, exposure. As the user market for linux gets more and more widespread, the impact of a major change will cause greater ripples. Most users (and distributions) will only run "stable" releases, so it makes sense to take lots of incremental upgrades (little steps) to that population, rather than on big jump (and possible fall over)
As the market of Linux increases, so does the potential interia to change. Take libc5-glibc for example, The linux bandwadgon hadn't really started rolling then, but if it had before the change, I think it would have been a lot more hassle to get people to migrate, because of all the apps that would have been released for libc5 systems.
As a result of this increasing inertia, I think companies will slowly drft from releaseing bleeding edge releases, "first with linux v x.y!!" to releasing "burnt-in" versons. For the end users, that's good, for the developers, that's bad, as there is less people to feedback bugs. Hence, the release stable versions of kernel often, will help allieviate this problem.
--
Exigo spamos et dona ferentes
Don't forget that LinuxOS 4 is also Linux 1 and runnig uname on Linux 7 reports "LinuxOS 5.7".
Sun's a great company and Solaris is a nice OS but the marketing people need to take a break.
-Mike
--
"L'IT c'est moi!"
That's possible. I hope that's how it turns out. What I'm afraid of is that as soon as the jump is made to 2.4.x, the work on 2.2.x will pretty much stop, except for fixing major security bugs (just like Alan Cox says that no more work will be done on 2.0.x unless some really major bug crops up). If you release 2.4.0 after 15 or so 2.2.x kernels, that means 2.2.x is the latest "stable" kernel for a lot shorter period of time, so you could conceivably have less testing and optimizations. The big bugs will still be fixed, but things may not be as smooth or well-optimized as with the 2.0.x series's long run.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
And 1.2.13 is much slower on anything newer than a 486, too. Can't beat that.
I am an average Joe and it makes me so mean :-P
If you read between the lines, you'll see that Linus wants more projects like the PCMCIA, isdn4linux, e2compr, etc, that develop separate (in parallel) from the kernel, and that go from proof-of-concept to kernel feature without especially being included in the development kernels untill they have become stable and popular patches, at which point it should not take much time to integrate it into Linus' release.
Such parallel development is necessary considering the amount of people working in parallel on kernel-related issues. In the old days, thing were tried out in the development kernels, nowadays people like andrea, rick, and the isdn4linux and pcmcia groups make their patches, and then ask on the mailing lists for people to test the patches. Such things start as hacks, tryouts, or proof-of-concept without hampering the development of any other part of the kernel. Once their patches, or sometimes just their idea's have been tested by some people and proven to be good, then Linus may decide to put the patch, or sometimes just the basic concept behind it, in the kernel.
You say 'unless everybody starts coding a lot faster', for which you assume that the number of people stays the same... which is not the case. There are a lot more people working on the kernel, or kernel-related projects right now then there were at the beginning of 2.1.x, and especially when compared to the old 1.3.x days.
With the patch archives maturing(kernelnotes, the patches at rock-projects, kernel traffic, and others), and with the support of Alan's -ac patches, such parallel developments will still be available to many for the testing and using, even before Linus decides to include it.
No more 2+ years of waiting for new stabilizing kernels, it's going to be great!
--- Hindsight is 20/20, but walking backwards is not the answer.
It's definitely a good thing, for a number of reasons.
The first is that the new features will get "to market" more quickly. That means more people using them, which in turn means more bugs found, which in turn means they get working more quickly.
A second, and important, reason in terms of World Domination(tm), is that it takes away a lot of the nay-sayers ammunition. For example, for a long time they said "Linux has poor SMP support", which of course was true for 2.0.x but not for 2.1.x. Now they are going to say the same thing about USB, but given the rate of USB development on 2.3 right now, a 2.4 in the fall should have fully-functional USB.
Finally, it should make each small upgrade much less painful, since they are more incremental.
That is an interesting take on it. I guess I assumed the opposite, that is that we might have fewer major feature changes per minor version than we do now. I mean, 2.0.x to 2.2.x was a humongous leap, and it seemed to me that releasing a minor every 6-12 months would maybe force better feature discipline.
As far as bugfix / optimization, I would assume that, for example, 2.2.x + (some features) + (2.2.x bugfixes) + (2.3.x bugfixes) = 2.4.0, in the cycle envisioned. This means that the 2.4.0 codebase should not be too far away as far as, e.g., filesystem or network drivers are concerned, but maybe 2.4.0 has features X, Y, and Z that comprise the main diff between 2.2.x and 2.4.x. I think that it could, therefore, turn out to enhance the stability of the system as a whole by integrating useful features into the stable branch when they are ready, rather than basing the stable branch on certain features.
-Chris
Seriously, especially since they're pushing WinNT vs Linux on WinNT-optimal machines as "the benchmark", we can just say:
"Oh, but that was version 2.0. We're already at version 2.6, which is five times faster at multi-processor static page hurls and still won't crash like IIS does..."
If it's got a higher version number, it must be better - Bill Gates law of increasing profits
Will in Seattle
Will in Seattle
Here's a few things that were noted in a comparison of linux vs Solaris. I assume these are valuable traits (I am not a guru):
/tmp
Journalling File System
Swap File System for
Real Time Scheduling
Intelligent Kernel Thread Scheduling (where threads of a process are spread among all CPUs)
Kernel Asynchronous I/O (KAIO)
Large file support (2GB)
I know SGI is going to opensource a journalling filesystem. That could be in a module I suppose. The others are of various importance, but I suppose they should be considered.
Any thoughts?
_damnit_
It's my job to freeze you. -- Logan's Run
Well, there seems to be some misunderstanding about Sun's choice of versioning, which is actually symbolic of some things that they have been changing in the core OS. As you may (or more obviously, may not) recall, SunOS4.x was BSD based. Sun decided to change to a more SysV based style, so they decided to start calling it Solaris and change the versioning scheme to 2.x (SunOS being 1.x, I guess), but lots of things still come up as SunOS5.x on a Solaris box. Solaris 2.7 actually completed their changeover, so instead of 2.7, which symbolizes the changes, they called it Solaris 7, symbolizing the completion of the change. Of course, it is still Solaris 2.7 and SunOS 5.7, but it makes more sense than M$ Winblows 9x or NT or 2000.
;).
I do not work for Sun. I do not work for M$. This is hearsay
-Chris
-- Ensuring that 2.0.X users don't get forced to upgrade. (What? You want to run Gnome 2.0? That requires gtk1.4 which only support glibc 2.2.3 which requires Linux 2.6)
Argh.. no. Glibc compiles on AIX, IRIX, etc, etc, etc.. Things like that have nothing to do with the kernel. (- generalization for sake of clarity.)
The things that DO matter as far as 'upgrading' a kernel are exactly what the previous person mentioned, support for hardware and features. If you want really GOOD NFS support, you're 'forced' to upgrade. Some programs might use, for instance, features of a newer kernel, (the new procfs comes to mind) but that is hardly a forced upgrade.
So, you make a choice. Live with your old kernel, or learn to use methods other than rpm to install software. No one's forcing you to do anything.
And, hell, if you don't like it, learn C.
--
blue
i browse at -1 because they're funnier than you are.
As someone noted in a different thread to this discussion, you assume that the number of kernel developers remains static.
Also, you assume that all kernel development is done by "kernel developers". But don't some packages run as kernel modules (for example, the lmsensors package) and yet they are developed by people who are not improving the main Linux kernel? I would think that it might help if features such as this would be merged into the main Linux Kernel. Especially the features that lmsensors (hardware health monitoring) which would be so useful.
Also, Alan Cox seems to put out an awful lot of patches quickly (I guess that the -ac patches are actually put together by a group of people that Alan supervises or organizes). While Linus can't mandate that developers work faster, as these developers learn more about the kernel, and how it operates, they can work more efficiently and thus produce more code/features/whatever-measurement-unit-you-want.
---------The early bird gets the worm, but the second mouse gets the cheese.
Sure, I agree with all that. I'm not sure I see the point.
What I was saying is that Linus' decision will not change development rate, just how often he decides to stop and create a stable release. Of course the development rate may change for the plus or minus, but this announcement isn't going to be a direct cause (contrarwise to what the origional post was about).
So the kernel development is probably going to continue similarly to how it has - blisteringly fast. The kernel patches will still be produced at the speed of Free Software, but now distributions will be able to take advantage of them more often. that's all.
The enemies of Democracy are
He was talking about NT. The first version was NT 3.1, supposedly to be parallel to the regular Windows version numbers. That didn't last long!
cpeterso
I remember Solaris uname would return SunOS 5. So if Solaris 2.6 is "SunOS 6", then Solaris 2.7 must be "SunOS 7"??
Anyways, "Solaris Seven" sounds cooler than "Solaris Two Point Seven".
cpeterso
I read that Linus wanted "at least a year" of testing with a brand new ext3 FS before it became the next official Linux FS. If Linux 2.4 is to released in less than one year, how could "untested" ext3 still be part of that release? One of these things will have to surrender.
cpeterso
If you really look at Solaris 7 you will see that it is really Solaris 2.7, they didn't just decide to make such a leap to go from 2.6 to 7.
Disclamer - Opinion of Person
> I'm assuming you're speaking of Windows 3.1
;)
Actually, I think he was referring to Windows NT, which started out at 3.1... of course, maybe they did that because it was based on the OS/2 codebase, and OS/2 already had a 2.x by then...
WWJD? JWRTFM!!!
The plan is to release security upgrades if needed.
For new devices, it's possible for third parties to provide drivers (however, USB may be another matter, requiring too much effort for all but the most senior kernel gurus to backport).
Userland programs don't care about the kernel, and it is never true that the source for something like gtk would need a particular C library (though someone's pre-installed binary might). Newer glibc's will run on older kernels, as well as non-Linux kernels; you can run Gnome on BSD or Unix systems.
If you let yourself fall way behind, it may mean that you have to build some software from source, rather than just install from an RPM or the 21st century equivalent.
Heheh. Sounds as if you were implying there is a problem with being version 15. They must realize that they are going to be version 15? Why? What's relevant of being in version 15? *grin*
Alejo.
I have a modem/ppp connection, and sometimes when somebody is getting a file from my computer through ftp, my network comes to a total stand still (except for the ftp tranfer in process). I can't even ping other hosts anymore.
This happens at least with 2.2.7-2.2.10. It is reproducable with one person whose connection is slirp-like through a Digital Unix box, using netscape. I don't know if it always happens with passive ftp. I do know that it doesn not happen with regular ftp (from other hosts) or http from that same Digital Unix host.
A committee with Alan Cox, David Miller, and 3-5 other core kernel hackers. Just like most of the other big and successful open source projects (egcs, glibc, etc).
Actually Microsoft Word is one of their few products where the version numbering is fairly correct. Versions 1.0 thru 5.1 were on the Mac, seperate versions 1.0 and 2.0 on Windows with a different feature set, and with version 6.0 they merged the codebase. The only real problem was that version 7 (95) was more like 6.1 in that the only new feature was red squigglies.
Better examples might be Windows NT (first version = 3.1), Exchange (first version = 4.0, jumped to 5.0 for no good reason), MS SQL (where'd version 5.0 go?), MS Access (MIA versions 3.0 - 6.0), and so on.
Thank god we still have companies like Apple that will produce a version number like 8.7.
--
Business. Numbers. Money. People. Computer World.
Just get rid of the '.'s and make the lower numbers three digit!
:)
So kernel 2.2.10 => 2002010 !!!
or 2,002,010 if you think it's more readable.
Big enough, MS?
All you're doing is taking what would've been called 2.2.25 and calling it 2.4.0
Not at all. According to the usual procedure, the goodies currently under development in the 2.3.xx tree will make it into 2.4, not into 2.2.xx (with few exceptions). Then guess what? MORE goodies will start to appear, in 2.5.xx.
Soooooo... the bottom line is: the sooner we see 2.4, the better.
Life's a bitch but somebody's gotta do it.
I've been going for a while now on a (very) old Slackware distribution, and I didn't have much trouble upgrading to glibc. As long as you read the installation instructions, and trust that the person who wrote them know what they're doing, you'll probably get through it fine (Then again, maybe I just had a very similar system to the person who wrote the INSTALL file...) The only major trouble was when I went to a glibc XFree86, and the install erased my libc5 X libraries....
-"One machine can do the work of fifty ordinary men. No machine can do the work of one extraordinary man." -EH
When its all said and done, I believe this to be a good thing. With the recent talk of the Mindcraft benchmarks, Linux will be able to mature faster and get fixes and improvements in quicker.
The biggest point that I agree on with Linus is that upgrading to 2.2 was a big deal for some people when it should not have been. Just look at how many distros drastically changed their products.
The only drawback I see is that bleeding-edgers will have to compile much more often and that the already light-speed trend of kernel suffix escallation will only get worse. But is that really bad?
-Clump
As part of their investment in Red Hat a while back, I remember one of the side-deals was that Intel was either going to work on or fund an effort to have Linux 64-bit on Merced as soon as it comes out, which shouldn't be much of a problem since we're already 64-bit on Alpha.
Look at it this way: Linux is gonna support Merced a lot sooner than MS is.
I believe it has been demonstrated to run on one of the Mercid simulators on HP. I'm sure the Mercid port will be available and more stable before Monterey takes off. Lets just home the IA64 chip sets will be cost effective or the who platform will die.
Linus said that it was a "done deal". A friend of mine who works on support chipsets told me that it's already running on the Merced simulator. I think that's why our fearful leader can say that with such confidence.
-russ
Don't piss off The Angry Economist
I'm not sure how good of an idea this is. Unless everybody starts coding a lot faster, the development is unlikely to speed up. All you're doing is taking what would've been called 2.2.25 and calling it 2.4.0 instead. However, this fiddling with the version numbers could lead to a decrease in overall quality, as moving from 2.2.x to 2.4.x will tend to tempt people to add more features, while keeping in the 2.2.x series leads to a bunch of bugfixes and optimizations, but few features added (i.e. 2.0.37 doesn't have that many more features than 2.0.0, but it is a lot more stable). More new features added and a shorter bugfix/optimization period leads to a more full-featured but less stable kernel. I suppose this is both a good and bad thing.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
VA has a team of five working on the merced portm (mainly kernel, IIRC), with support from Intel. The EGCS team (through Cygnus) are working on the compiler, again with Intel support (since an NDA is required to get any access to emulators, and until recently, specs.) It'll be done on time, don't worry.
~luge
IAAL,BIANLY
This press release from March says that VA Research is working on the port and that "VA Research will deliver the optimized port, in synch with Merced-based system availability in mid 2000." Apparently, HP, SGI, Caldera, Debian, RedHat and SuSE are all working on it as well.
It is a good thing, considering there are many persons stuck in 2.0.X, unwilling to switch to 2.2.X because of the big effort it takes:
Someone posted:
I believe this is exactly why they are going to change version numbers more often. Why bother mantaining 2.0.X?!
I understand your point of view, the effort related with switching is big and 2.2.X are not as stable as 2.0.X (or so it seems). But from another point of view, its like saying: I am running 2.0.36, will someone release 2.0.36.1? I don't want to update 2.0.37...
I know, there are no big differences between 2.0.36 and 2.0.37 so updating is not as big a pain as updating from 2.0.X to 2.2.X.
And that's what Linus is trying to fix, I suppose. He doesn't want to have people stuck with 2.2.X when he releases 2.4.X, so he's going to release stable kernels more often, hoping people will update their systems and distributions to stable kernels more often (but with less hassle).
Alejo.
Well, I think all things considered, this is *a good thing*. A couple of comments, though.
First - consider the open source development approach - it works well when there are a large number of people involved in the development and testing, and all the little dot releases and patches and pre releases are part of this process. In the traditional "closed shop / source" model, the same often happens - but only those in the development team sees it. Having the "stable / public" stream, and the "(b)leading edge / development" stream helps. As others have said many times - "release early, release often". That way, we all benefit from each others contributions, and can build on other's work sooner.
What is required, though, is a way to make kernel upgrades easier and simpler for the "average joe" - and i imclude myself here. I still have 2.0.36 on my machine at home - partially because personal circunstances at hame have prevented me from doing too much - but I also have a sneaking suspicion that if I dont take extra caution, I may trash something. Sure, if I spent the time reading and experimenting, I would have greater confidence. I upgraded my Win 95 to Win 98 in under and hour - and no damage was done (assuming that you don't class wunning Windoze as being of irrepairable damage in the first place). Kernel upgrades should be able to be run as fairly simple and painless activities - and with a suitable "backout" capability. maybe that is already there - but I haven't discovered it yet. (yes, I know - RTFM).
There is a fine line between showing a product is under active support, with new features being added quickly, improvements to security and performance coming all the time, and these enhancements being in response to what the users of the system want and need (and not just some market-droid's idea of how to sell more stuff); compared to having a product appear to be too experimental, with new versions released constantly without proper testing and quality control. I think that a major revision (2.0 => 2.2 => 2.4, etc) each 9 to 12 months is about right.
Ken
the article doesn't really go into this, so (with out trying to show off the fact that I was there) I will.
according to linus, he was very un happy with the "pain" that people went through upgrading from 1.2-2.0 and then from 2.0-2.2 . he wants to avoid this as much as possible, (also stating that people shouldn't "have" to upgrade, but realizing the unmitagated joy in doing so). also, there was the time issue, something like 1.5 years from 1.2-2.0 and then like 2.5 years for the next jump.
in the future, the plan as linus stated it, was to implement less "major" changes between code-freezes in order to get the newer stuff out there quicker. that's all.
A unified buffer cache is great for the whole range of linux systems.
Wow, you missed the Sun maneuver... They were going to introduce SunOS 5.7 (aka Solaris 2.7), but decided that they needed a bigger number; they changed the name to Solaris 7.
Windows 1.0 and 2.x were the runtime environments which came with early versions of Excel, IIRC.
Windows 3.0 was pretty bad and very flaky, but compared to naked dos, not bad.
Personally, i find the idea of date stamping a product not completely nuts. i mean, if you know that a box is running win95, but office 2000, then you can figure that the OS may need updating.
dave
That sounded much better coming from your mouth... er... fingers, than ZDNet. Basically, put a few more freezes in, with the goal of getting a smaller set of big things working. Better and sooner.
The way ZDNet put it, it started to sound like a commercial development. Which would suck (and be very unlike Linus and the whole kernel crew!)
I greatly respect Linus' ability to manage these things. I'd fold in 10 minutes :)
There was a Windows 2.0 too.
-- Ace
I mean, Linux _development_ isn't going to go any faster. Linus can't mandate that all the developers start working harder.
All this means is that the stable kernel cycle time will be shorter, meaning less features per cycle, but distros will be able to incorporate these new changes sooner. I think this is a good thing.
A user who wants the newest and hottest kernel can just use that, like always. The kernel patches will probably be released at the same rate as always, so the 'bleeding-edge' user will have the same number of compiles as before.
The enemies of Democracy are
Is Linus nuts? It's 1999 and he's still only releasing version 2.x? Look around, man! The Red Hat distro is up to version 6.0. SuSE is up to 6.1 (clearly, it's more up-to-date).
And Microsoft? Their development environments will all be 7.0 soon (clearly more up-to-date than any of those Linux products). Why, that's why MS renamed NT 5.0 to Windows 2000! Why buy NT 5.0 when I can have Red Hat 6.0 -- it's a bigger number, man!
For the sake of marketing, I propose a MASSIVE jump in kernel major numbers. Then all the distros can fall in line.
This fall, Linux 2.4 should be released as Linux 2001.0.0. Red Hat, SuSE, and everyone else can release with the same version and clear up all this confusion. Dev kernels can use the same system as now (2001.1.0, etc.)
/* Someone will take me seriously. Watch. It happens every time. Bunch of literalist geeks.... */
Save the whales. Feed the hungry. Free the mallocs.
I'm still on 2.0.X and don't have any plans to upgrade. Things are running well for me and all of my devices are supported.
Question: Has anyone stepped up and said they will take over maintenance of 2.0.X if Alan and Linus don't want to anymore?
They don't. Linux still uses partially invalid asm code which used to work on gcc 2.7.2, but fails with a better compiler such as egcs 1.1.x. The egcs team has decided to _not_ support the broken code from Linux.
This reminds of "the PSA, the Python Software Activity, which was originally formed in response to a thread on the Python newsgroup, which posed the semiserious question: "What would happen if Guidowas hit by a bus?" Guido van Rossum still manages most new developments in Python, but the PSA and Python's user-base help support the language, work on extensions, etc. Given Python's popularity, and the PSA infrastructure, bus attacks seem less threatening now; of course I can't speak for Guido..."
shamelessly stolen from "Programming Python" by Mark Lutz
So what about a "Linux Software Activity Group"?
We could use some better kernel support for some thread-related things like shared POSIX semaphores (SYSV semaphores don't count) and things, but we do already have kernel threads themselves.
We've had soft realtime since I don't know when, but certainly in 2.0... (I still run 2.0.36, and I'm the maintainer of some shell utilities for dealing with the realtime scheduler (check out rt-utils on Freshmeat); I should know that it's there). For hard realtime, we just need the rtLinux merge.
---
DNA just wants to be free...