2.4 isn't really that stable compared to 2.6 though. 2.6 is inherently more stable, and as for crashes/panics, they don't occur any more than in 2.4. The only thing that isn't stable is a driver api, but even so, 2.6 still has support for more hardware and more binary drivers than 2.4 does.

Most of the "stability" issues with 2.6 lie in things like the Nvidia drivers, and even they work perfectly with 2.6 now. 2.6 is not, however, stable in that it is actually a moving platform, but as of 2.6.16, it's stable in that sense too.

(Besides, i'd rather use a kernel updated once every month than a kernel that hasn't recieved any updates in 7 months, even if the 7 month old kernel is "stable".)

2.4 being more stable than 2.6 is nothing more than a myth. An incorrect myth at that. 2.4 and 2.6 are both pretty unstable, at least compared to other Unix OS's.

I know that it doesn't count as an argument, but my experience has been the opposite, 2.6 crashes, panics and oopses more often than 2.4.


OTOH, 2.4 was developed with 2.5 available for those who know that Linux has always been about fun (I had a Linus quote about this, but can't seem to find it anywhere) and knew that adding features is way funnier than hunting bugs, this also meant that 2.4 suffered less radical changes than 2.5 and subsequently, 2.6, which hasn't got a 2.7 branch (and probably it will not have one in a huge bunch of years). This helped 2.4 being more stable (less changes = less new code = less chances of having new bugs AND more chances of having old code revised for bugs). This hasn't happened with 2.6, though.

2.6 development cycle nowadays has a two-weeks window to accept big changes (which usually are new features), after every version release there's a huge amount of these patches wanting to enter the Morton's tree (which is basically a 6-12 months ahead version of Linus' tree).

This space of time in which new features are accepted came up (IIRC it was Linus who enforced this) because new features where being added between release candidates and stability (in both senses) was suffering from it.

This window was added with the release of 2.6.13 (it was a decision made at the 2005 Linux Kernel Developer's Summit). After the two weeks have gone through, only small changes and bug/security fixes are accepted.

I have to say that if it weren't because of this two-weeks space of time, the 2.6 kernel line would be much more unstable. But that doesn't make it stable (in both senses), several of the new features added to the 2.6 kernel would instead go to a 2.7 branch if it existed, leaving 2.6 more than enough time to iron out most of the bugs and stabilize the APIs.

Now, a guy called Adrian Bunk said that he'll keep manteinance of the 2.6.16.x branch, even after the 2.6.18.x version which is when Greg K. and Chris W. stop supporting the 2.6.n-2.x series. (There's a faq here:
http://lkml.org/lkml/2005/12/3/55)

This will bring a similar situation as with 2.4 and 2.5, being 2.6.16.x a stable kernel (in both senses, since Bunk will backport bug/security fixes and he will NOT backport API changes and new features) and 2.6.17+ a funnier (I mean testing) kernel branch.

Nvidia drivers work perfectly with 2.6? I have yet to see a Nvidia driver which works somewhere near "good". They are crashy/buggy as hell (even under Windows and it has a stable (as in non-moving) ABI).


Yes, that's why Pat is going to stick with 2.6.16.x for a while now, and that's probably what we'll see as default kernel in Slack 11.1/12 (I really don't think we'll see it with Slack 11)

I totally disagree there, I have found that 2.4 kernels ARE more stable than 2.6 (in both meanings).
I agree, though, that the design of 2.6 (AFAIUnderstand it) should be more stable (as in the no-crashes meaning) than 2.4.

I also agree here. Fortunately, Linux (the kernel) is free (as in beer), and that gives it a special edge over Unix: The stability/price ratio is way more high than Unix because price is near zero.

They work fine for me, although I'm still using a patched version of 1.0-7676. The later releases don't scale properly for me for some reason. I play a lot of games, and need to be able to easily switch from 1280x1024 to 300x240, and any other resolution in between. The 7676 release does this very well.
Funny, that. I always thought that 2.4 was a huge step backwards from 2.2. Under 2.2, I could multi-task properly. Music didn't stop playing for anything. When I "upgraded" to 2.4 on the same hardware, the first thing I noticed was that music would stop playing with any decent level of disk activity. Or even when compiling a kernel. I can do all those things again under 2.6 without my mp3 player stopping. Even if I'm doing it all at the same time.

I just don't understand why Linus keeps allowing new features into a stable branch. New drivers are fine, but I reckon stuff like that new 'splice' thingamy should be reserved for the next development branch. Maybe I'm over simplifying things a tad, but stable branches should only receive bugfixes and driver updates.

When I was using 2.4.x I had to keep three versions of the Nvidia driver to try to find one that would actually run at all. Each new kernel would work with a different driver. Recent releases did not work with 2.4 and my MX440 card

No problems with the 2.6.16.x kernels

Personally I don't have any bad experiences with stability when it comes to newer 2.6.x kernels. On various servers the only reboots that were required were after installing security updated kernels. There are usually tens or over a hundred days in between without any instabilities. And even if a machine would hit upon a nasty bug, there is a good chance that the watchdog timer will catch it and will reboot the server. But again, no such thing has happened on the servers that I maintain on 2.6 (I have switched with 2.6.9).

On the desktop side 2.6 works great. Much better performance, more and newer drivers. No complaints there.


I was under the impression that the implicit assumption was that distributors would do the final stabilization. E.g. Red Hat picked 2.6.9 as their enterprise kernel, and add patches for bugs along the way. Obviously, this won't work for Slackware and some other distributions that do not have the personell to maintain their own kernel branches. This is where the $SUCKER and future Bunk branches fit in well. I had my reservations at the beginning of the 2.6 cycle, but I have to say that I like the current methodology better. Before 2.6, even kernel versions were often a bit stale and old (in other words out of line with current technologies) and uneven kernel versions were modern, but completely unstable. So, we were all working with old kernels for two years, and then there was a huge jump, getting stale again, huge jump, etc. Right now the development proces is faily linear and predictable.

Right. So why did they start the 2.6.x.y branches?

This only started after people asked for a more stable vanilla 2.6.x over and over. And even after Linus decided that having 2.6.x.y kernels would be ok he noted:

Source: http://kerneltrap.org/node/4800

Now current changelog has a 2.6.16.21 kernel in testing. This was never on kernel.org, which is already at 2.6.17.1 so the 2.6.16 stable fork has now happened.
Where to find a changelog for this kernel?

You will find it here:

http://www.kernel.org/pub/linux/kernel/v2.6/

Thanks, we are at 2.6.16.22 now.
Most of the fixes are non-i386, but there are nfs and jfs fixes in there

I just noticed the 2.6.16.22 today when I mirrored -current.

I'm starting to wonder when Pat will start to accept 2.6 kernels as 'stable'...

The point is that he has gone off down the 2.6.16.>20 "stable" fork of the 2.6 kernel instead of following the 2.6.17 path with new features

In my opinion Pat could benefit from making a "Slackware branch" distro forum, where experiences could be shared. For example Slackware (and Pat himself) could benefit from discussions with Jean-Philippe Guillemin, who administers the Zenwalk distro (which has been using 2.6 kernel from the beginning). The work going on there could quickly mature some thoughts about UDEV for example.

Pat has other considerations (especially if he wants back compatibility with 2.4 systems UDEV setup - I would say it's close to impossible), I acknowledge that, but the discussions alone would speed up the whole process (laying out potential risks and such).

Just my 2 cents.

Best regards,
Claus

I just tried Zenwalk 2.6 and was impressed. But the OS does not natively use the 2.6.x kernel. If you look, Zenwalk uses 2.4.32 linux headers. Another check is the file /var/log/Xorg.0.log which at the top will tell you that xorg was compiled with the 2.4.32 kernel. So basically the system was built with the 2.4.32 kernel and the 2.6.x kernel was added later and not truly integrated into the OS.

A full shift to the 2.6 kernel is going to affect a lot of packages.
One day Pat is going to have to bite the bullet.
I think that there will be so few developers using and interested in 2.4.33 that 2.4.34 never happens and it becomes a relic.
Look at 2.2.26 - last updated over two years ago