Words to live by....

I do, however, use -current on two of my boxes for day-to-day use. I also 'update' those same boxes every few days when -current changes. At this point, -current is very close to 11, so I don't feel as 'ooky' using it as I would have had it been about 6 months ago.

As far as 'fresh' install goes, you can install -current as an upgrade, which is not a fresh install. If you need it fresh, make the iso's and install like you would 10.2

But Slackware-current is surprisingly stable. I barely had any problems with it so far (Except for an OpenSSL version mismatch). And with Slackware 11.0 imminent, I reckon Slackware-current should be pretty much perfect by now.

-A

But once slackware 11 is released, current will be broken in weeks.

true, since Pat wants to upgrade a lot of things that was listed in his TODO list and he waits until 11.0 comes out since he doesn't want to break the stability of 11.0. He'd rather wait until it's released.

Here is his words in his current changelog long time ago (Mon Jun 19 00:28:53 CDT 2006 about Xorg)

The 2.6.16 and 2.6.17 kernels in the latest changelog are two steps out of date, not including a critical /proc fix.
Looks like there will be more changes before 11.0

Please define "broken" in this context.

The only real way to break any Linux distro is to completely botch a glibc upgrade. Everything else (including kernel-related problems) can be reasonably easily fixed.

There'll be nothing between -current and 11 that can't be fixed with upgradepkg. I'll eat my own hair if I'm wrong.
Anyone like to hazard a guess as to why Pat thinks 2.6 is still too unstable to become Slack's default kernel?

the point is that after releasing 11.0, patrick will have the freedom to make all kinds of changes (including glibc), without having to worry about stability... hence, it's normal to expect things might be broken all over the place after 11.0 is released - nothing wrong with that - it's the nature of -current...

there's no guessing, he explained it very clearly in the changelog... besides, it's not like you can't use the 2.6 in extra, which WILL BE FULLY SUPPORTED by patrick... so we have the best of both worlds: those who want the stability of 2.4 can have it, and those who want the modern features of 2.6 can have that too... BOTH will be provided, and BOTH will be supported, but it makes sense to make the most stable one the default... in 11.1, things will be different...

D'oh!!!

Yes. You're right. Sorry, I completely misread liquidtenmilion's comment.

I agree that current will be broken soon after 11 is released, but I don't think it'll take weeks.

2.6 is stable in operation. The problem is that many eyes are looking at it and finding and fixing bugs. Another group are adding potentially broken improvements.

2.4 is not getting improvements and not many people are hunting bugs. This does not mean that they are not there.

You're probably right, I just suspect that pat will spend a few weeks releasing a few patches for 11.0 before he shifts his attention to upgrading, mangling, and then re-stabilizing current.

which is beside the point, as far as stability is concerned... stability is determined by looking at changelogs and source code, not by how well the kernel "operates"... this is a technical linux forum - if there's anybody that should refrain from using media definitions for things - it's us...

that's not really a problem... besides, the 2.6.16.y tree is specifically made to be a stable tree... that means the focus is on bugfixes, not adding "potentially broken improvements"... this is the reason 2.6.16.y is in /extra (and supported) while 2.6.17.y is in /testing (and likely not supported)...

WRONG. even though the focus by most devs is on 2.6, 2.4 is still getting a decent amount of maintenance, under the leadershop of Marcelo Tosatti... just look at the changelog for 2.4.33-rc2... the small amount of "improvements" made to the 2.4 code is precisely why it's more stable than 2.6...

What exactly IS your definition of stable? The political definition or the technical definition? For me, stability means not crashing, and working exactly as it is supposed to every time, not simply "doesn't get that many changes anymore."

If that were the case, then technically linux 2.2 is the most stable of them all right now. But those of us who have used it would tell you otherwise.

yes, that is precisely the media definition of stability... it's a situtation akin to the the media definition of "hacker"... it means something to the media, and something else to the linux community... the original definition of stability can be found in any dictionary: http://wordnet.princeton.edu/perl/webwn?s=stability - it refers to the amount of change and variations you have to put up with...

yeah... but making tons of changes to the code will greatly reduce the possibilities of that happening...

well, it's about keeping the changes to a *minimum* - to keep the users free of any unnecessary variations... for example: let's say i install debian stable... i expect it to work the same way until the end of it's support cycle... this includes having non-critical bugs _remain_, because "i've probably worked-around those bugs, and i do NOT expect some package update to force me to make further changes to my system... i only want changes/patches if not having them means i will suffer from security vulnerabilities..."

of course, it's not the same with slackware, as patrick doesn't have the resources to stabilize a kernel specially for slackware, like the debian team does... but still, that's why it's great that a stable 2.6.16.y tree was created by the kernel people themselves, as it allows distribution maintainers like patrick to provide decent support for a very modern kernel, without requiring slackware users to put-up with all kinds of changes and variations when they do upgrades...

either way, real slackers compile their own kernels anyways, so it really doesn't matter to them what patrick does with the distro's kernel...

Well, in my experience, 2.2 was always better than 2.4 in terms of operational stability. The only downside was that you had to apply patches to the source code to get support for filesystems other than ext2. Other than that, 2.2 was a great kernel with great support for the hardware available at the time.

"Upgrading" from 2.2.17 to 2.4.0 was like taking a giant step backwards for me. IMO, 2.4 didn't come into it's own until 2.4.10.