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!
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.
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?"
-- 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)
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
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.
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.
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
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
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.
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?