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
>Swap File System for /tmp
Solaris only needs this because its own
filesystem is so inept -- ext2 has been
demonstrated to be plenty fast enough (and
comparable in performance to Sun's swapfs)
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.
Windows is already at version 98! Obviously it is a much more mature product than a simple version 2.2 product! Wait until version 2000 comes out next year... it will be MUCH more stable and have many thousands more features than any OS that exists today has. We need LinuxOS 4, then Linux 2.3, then Linux 2.4, then Linux 2.5, Linux 2.5.1, Linux 2.6, and then of course, the next logical version number would be Linux 7. ;-) (this is all tongue in cheek of course so calm down :-)
Time to upgrade my Linux 1.2.8 kernel based system! This is awesome! Next you're going to tell me there is SMP support! Woohoo!
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.
He probably means security updates?
(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.
Where do you think all the users are coming from for Linux's exponential growth?
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.
Yeah ! even solaris jumped from 2.6 to 7.0 !
Why not do the same ?!
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
It's also MUCH more stable after it's been locked up by any of the numerous DOS bugs that have been fixed in the last 300 kernel versions. ;-)
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
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
Even though the 2.3 kernel has been around for only 1 month, 5 _major_ features have been added already: A) waitqueues (used by all kernel subsystems) have been rewritten to get simpler and scale better on SMP. B) the new waitqueues enabled to implement 'wake-one' semantics for accept(): the 'thundering herd' Apache problem mentioned is thus 100% solved. C) David Miller (the main Linux networking guru, working for Red Hat) has rewritten the networking code to scale as good as it gets on SMP - this was apparently a major rewrite of the networking code. D) the pre-2.3.7 kernel has extensive NFS client-side changes written by David Miller - he mentioned on linux-kernel that these changes if finished will improve Linux NFS-write and read performance alot. D) The pre-2.3.7 kernel appears to have very 'daring' changes to the page-cache and ext2-fs, the changelog says that the buffer-cache and page-cache has been 'unified' so that data is only cached once, and that all file IO is parallel and
constrained by the 'big kernel lock' anymore. Has anyone here tried 2.3 on a big SMP box? The development pace of 2.3 is really high, apparently with a _HUGE_ focus on SMP scalability. I bet that the 2.3 kernel if stabilized will blow NT away in even the most unfair benchmark setups! Kudos to everybody involved, especially to David Miller and Linus!
> Redhat 5.2 and Redhat 6.0 aren't that much
> different. The installer is different, the
> packages have been updated, but this is not
> really something to warrant a whole revision.
> yes, the kernel went up to 2.2.5 or whatever,
> but that doesn't make it a completely Revised
> Redhat release.
The debut of Gnome as the main desktop environment, the inclusion of KDE, a 2.2 series kernel (first new kernel series in 2 1/2 years), the final stages of switch to egcs, the switch to glibc2.1 (first major update in over 2 years), etc, etc.
These are not minor differences.
Likewise, 4.x to 5.x marked the change from libc5 to glibc, which in itself was a MAJOR change.
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?
Easily solved--stealing from another company we now have Linux99.06.16. Current stable version will always be Linux3.1, bleeding edge LinuxNT, current development Linux98. Next major upgrade Linux2000 (due out Sept.).
Oh lighten up.
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.
Will PnP cards be supported? This is long over due. FreeBSD already has a PnP driver! I don't want to use the crufty isapnp anymore.
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
moving from 2.0 to 2.2 of the kernel isn't exactly as involved as moving from libc5 to glibc2. Only a select few programs have to be upgraded- and they (along with where to get them) are conveniently listed in the 2.2 documentation. Redhat 5.2 even has upgrade RPMs available to get your system 2.2 ready
-- 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.
a) If the symbolic link/directory
b) Untar the kernel source under
c) As root, cd to
d) Run 'make xconfig' (if in X, 'make menuconfig' if in console) and select the stuff you want in your kernel, making copious use of the help text. Generally this consists of telling it what hardware and features you have and want. (a safe bet is generally to either not compile it or compile it as a module if you aren't sure)
e) If on Debian, install kernel-package and run 'make-kpkg buildpackage' then install the resulting deb. Otherwise, run: "make bzimage && make modules && make modules_install && make install'
f) The only tricky bit -- edit
image=/boot/vmlinuz-[new_version_number]
and then re-running LILO. What you need to do may depend on your system though. Making a boot floppy first is fine if you aren't sure :-)
Daniel
Right now we have a ready replacement for Linux.
Alan. Great guy.
But what if they both die? Do we have an obvious
third person?
I know it wont be ESR or the GNU guy (mental block).
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
HP were demoing their port at Linux Expo, into user space, on a simulator (obviously). They had built it with egcs (kernel messages said so). VA had nothing on show, and HPs marketing guy floating around their stand said it was their work and had no VA code in it.
Journalling FS extensions, boucoup VM system changes (mostly efficiency things, like merging the page cache with the buffer cache to prevent an extra copy), 4GB of RAM support for x86(finally), large file support, better demand-mode paging (which is how programs are loaded incrementally, instead of with a WHUMP, a big deal for servers forking off lots of processes) and whatever minor fixes get put in (quotas, fast NFS-3 support, which will be back-ported around 2.2.14, etc)
> 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
Can we ever expect Merced support? If so, when? Intel has already released the insruction sets. I think if linux is to work on any computers manufactured in 2000, Merced support is nessisary. In what kernel will this be available? Who's working on it?
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.
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.
Does anyone know what new features are set to
appear in 2.4? Kernel threads? Real time services? Anything worth salivating over?
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.
Don't get me started on Meagersoft. "We'll build a new OS and call it... VERSION 3! No, no, better yet: 3.1! The perfect way to bypass the point-oh bugs... mu-ha-ha-ha-ha!"
Knowing how to count is obviously for sissies.
A unified buffer cache is great for the whole range of linux systems.
Actually, all these features sound pretty cool. But they only affect people with big budgets who can buy the type of hardware that this stuff shines on! I'd rather see the kludginess of our graphics system finally get cleaned up (programs have to handle sharing of graphics resources themselves unless you're using fbdev..the kernel should be mediating this)
Daniel
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.
This is an excellent example of what you were describing. Anyone know if it's going to make it into 2.4?
Daniel
AC said: Don't get me started on Meagersoft. "We'll build a new OS and call it... VERSION 3! No, no, better yet: 3.1! The perfect way to bypass the point-oh bugs... mu-ha-ha-ha-ha!"
I'm assuming you're speaking of Windows 3.1
Well....
Actually, there _was_ a Win 3.0. I know because I actually saw it a while back, and somewhere around the storeroom here at work is an _upgrade_ kit for Win3.1 from 3.0
But inflated version numbers still strike me as stupid, ie Solaris 2.7 == 7.0
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?
tug-tug
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"?
Small devices, especially handhelds have crucial memory and power requirements.
For example, on the PalmPilot, there is a very
small amount of actual ram that can be used
(64k), the rest is slower ram that cannot
be used as dynamically, but instead, more like
a database.
Secondly, besides the ram shortage, these devices
must sleep as much as possible to conserve battery life.
The PalmPilot batteries last incredibly long because when the user isn't touching the screen,
and the system isn't animating anything, the
CPU is dormant.
If you play a Chess app on the Palm, you'll notice your batteries drain alot faster because
of the CPU running so much.
A much more suitable OS for small devices is
those from the embedded/real-time space. Those
OS's that don't demand memory protection,
processes, or even the concept of kernel and user space.
To me, running Linux on a handheld is as big as a mistake as running Windows on a handheld. It's the same problem I have with people porting "traditional apps" to the Pilot. They just aren't designed from the pen-small-screen paradigm.
Rather than trying to use Linux as a universal hammer, the OS should fit the device. A handheld
device needs a minimalistic OS, and doesn't need
a kernel based system.
Linux on small devices is a nifty idea, but I think it's a stupid one. Just like "Linux on the Commodore 64"
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...