Newbie question here I suppose, but -

Slackware seems to be often compared to RHEL or Debian Stable in terms of stability. But, as I understand it, these other distros go through huge amounts of testing from a very wide user base in order to reach their stable releases - both taking years to reach that point (Debian Squeeze is how many years in the wings, and RHEL 6 even longer?).

Slackware on the other hand seems (to me - and I accept I am obviously wrong in some respect) to be more of a small-scale distro, run by a very small team, yet still has new releases regularly, with up-to-date software. So how can it be as stable? I realise the package base is smaller, but is this the only reason?

Slackware being compared to RHEL? Thats a new one for me. I wouldn't be surprised that it might be compared with Debian though, since it is only younger than Slackware by a few months only.


There are a few factors as to why Slackware is so rock solid.


Vanilla kernel
Only WELL TESTED packages included, not just packages included that are 'labeled' as stable.
Not trying to make the system complex


Those are just a few, and I'm sure others can include more reasons.

1 members found this post helpful.

Slackware focuses on _simplicity_ in accordance with the KISS principle; is almost entirely "vanilla" (no patching, while Debian developers, for example, heavily modify their packages) and does not include unstable software (if something needs to be patched, it's likely that it's not ready to be included into current). Slackware requires some manual work from the user, but the result is totally worth it: absolute control over the system and the beforementioned stability. Most other distros try to automate this and that but let's be honest: until a working AI is developed, the OS would not be able to take care of itself (automatic dependency resolution etc ).
I also like the Slackware release cycle: new releases are announced when they're ready. So far I haven't had any install trouble with any of them since 12.0. And speaking of versions, Pat still produces security upgrades for the older ones back to 8.1. I don't think there are many distros with such support.

Edit: Jeebizz has posted while I was writing this and I'm not surprised at the coincidences of some of our arguments.

Perhaps it's not the size, but the quality of the team...

2 members found this post helpful.

This is just from my own experience and opinion, not necessarily based on pesky things like fact, or reality... just warning you ahead of time.

Slackware is very simple - the stability comes in part at least, because there few distro-specific customizations and patches, most software is barely changed from upstream, it's all tested and managed to make sure it works properly, it doesn't make many assumptions - there are few GUI config/admin tools, for example, which can cause problems when you try to mix them with configuration file tweaks and such. There isn't as much official software - no massive official repository of 20,000+ programs or anything, so there's not as much to keep track of, in slackware, YOU manage most packages, not the slackware team.
Also; I believe the relatively small team actually helps it's stability - the team behind it is large enough )and more importantly: Skilled enough!) to create an amazing OS [proven by the slackware distribution itself], but not so big that they can't keep track of whats going on.

I think the biggest factor is that it leaves a lot up to the end user - they don't try to make everything handle itself, YOU manage your packages, YOU play around with config files, YOU make all the users and directories, etc.
Automated processes are nice, when they work, but making them work every time is very difficult, and they're prone to breaking.
with slackware, it's as reliable as YOU make it.

Red Hat in particular has a fairly large engineering team that makes source and configuration changes in the kernel and many of the more complex applications and subsystem components. This allows them to take earlier/more unstable snapshots and create a supportable release.

But.

It also makes for the possibility of dependency hell, dependence on RH packages over source (especially for software not available as a package) and of course, redhat-isms that sometimes get in the way of non-redhat code (ala RH9 threading).

I'll take stable, tested, unmodified source packaged with intelligence any day.

Cheers,

Because it's a simpler distribution and there's less to test. It doesn't have a highly customized desktop that tries to integrate everything, as many desktop distros do. It doesn't give you its own system administration tools, like Defoma or Yast, and then configure its packages to use them.

It also releases "when it's done" instead of sticking to a release schedule. That helps a lot.

I agree with all of the above.

vanilla kernel - probably the most important factor, other distros tend the patch the **** out of the poor kernel, and this may cause problems, especially since the people that release the patches don't always know what they are doing.

packages - not only well tested, but are only updated for security fixes, unlike other distros that just update for the heck of it.

no package manager (with dependency resolution) - it only complicates things, just try using Fedora, Ubuntu, RHEL, and you will see.

no GUI complication - these other distros often rely heavily on GUI config tools, but you have no idea how often they fail to work properly and mess things up.

no release schedule - things aren't just shoved out the door (like several Fedora releases and I'm sure many other distros have done)

Pat V and the team - last but not least, and probably one of the most important factors

Thanks all, very comprehensive!

That's simply not true. Take a look at shadow, which is a pretty important package to have working correctly: here and here

Now both those issues are upstream problems and I find it very poor that shadow-4.1.4.2 has been left that way by its developers for over a year with the fixes only to be found in the svn trunk! (would it have hurt to bring out a 4.1.4.3 bugfix release while they work on new features in 4.1.5?). And those are only two of the issues fixed in trunk. I'm running a custom shadow pkg with no less than 5 patches from trunk applied to it. (I just pulled down the ones that looked to fix the worst problems, I probably missed some.)

There's also the udev/dev-mapper/cryptsetup issue that was causing luks devices to be given real (duplicate) device nodes in /dev/mapper rather than symlinks. (I fixed that locally by upgrading udev, lvm and cryptsetup). Again all upstream and not Pat's fault.

Then there's the slackware kernel: still at 2.6.33.4 despite upstream telling everyone that they must update and especially so since the 33 branch is now a dead branch.

In contrast to Slackware, debian, redhat and suse have kernel security teams that will back-port important security updates to older kernels once they are no-longer receiving official maintenance. Sometimes they'll even patch before upstream get around to it.

Please don't take any of this as Slack-hate, it's not my intent and despite issues like this, Slackware is still my distro of choice. I think Pat could do a better job of keeping up with kernel updates, but that's the only thing I'd criticise, and it is easily remedied locally with a custom kernel build.


Slackware's vanillaness is a two-edged sword, it leaves you at the mercy of upstream. Mostly this is a good thing, but occasionally it's not as the examples I gave above show.

IMO, some of the distro's try and do/change too much or be too clever, and that can cause stability issues. Slackware, through necessity (i.e. the very small team/resource pool they have) do too little, but it's easier to fill the holes in slackware than it is to undo the mistakes and over-engineering in the more complex distros.

To me, Slackware is sort of a half-way house between LFS and a full distro, and that's exactly what I'm looking for.

Well that's my view on it anyway.


P.S. It's a bit ironic someone posting a "Isn't slackware stable' post the day after a sudo update breaks /var on everyones system.

4 members found this post helpful.

Huh ? I don't use sudo and haven't heard of this, is this on slackware ?

EDIT: I found the thread, I somehow missed it.

If you follow the Ubuntu/Debian model by back-porting features from newer kernel, it would require a lot of efforts and at the end, you will end up rebooting your system to have the updated kernel, which is not the situation that everyone need since they may need 24/7 running system.

Besides, new kernel doesn't mean that it's always better. Sometimes there's too much risk of backporting new features to the current kernel. Slackware chooses the most stable kernel when it's gets released (after heavily testing by the team) and as always, it's the users who should maintain the system, not Slackware teams. If you need to compile your own custom kernel, then it's your job to do that.

I am running a custom kernel ever since i successfully compiled my first kernel few years ago. Default kernel only being used for first installation.

1 members found this post helpful.

In Slackware there is no rush to get a release out the door, there is no pre-set time table. Each stable release of Slackware is announced when it is ready. Each stable release of Slackware is thoroughly battle-tested. This is why Slackware deservedly has the reputation of being rock-solid.
Slackware is number 1 in my book!

Consider the thousands of developers that created Windows Vista then compare the result with, well, frankly, pretty much any Linux distribution but specifically with Slackware; that's the benefit of a few folks that know what they're doing and do nothing gracefully (meaning: no screwing around with things that ain't broken).

Consider, too, the amount of "upgrades" with, oh, Ubuntu versus Slackware (I tried it, didn't like being bombarded with Windows-like upgrades seemingly every day [well, not literally every day, but too blasted often], blew away Ubuntu and just happily have gone on with Slackware).

Consider, also, how many Slackware logos you see embedded in software -- what? None? Ooh, now that's nice.

And, finally, consider that Slackware machines just sit there doing their thing for weeks, months, and in some reported cases, years with zero problems. That, to my way of thinking, is the definition of stable.

Hope this helps some.

Not rebooting is a moot point. If you care about a secure kernel then at present you're going to have to apply security updates and reboot. There's no two ways about it, though the likes of ksplice may become workable solution in the future.

I don't agree with back-porting new features, but if you're going to stick with a specific kernel.org branch like slackware tends to do, what happens when upstream stop providing security updates? To remain secure you need to either follow all the latest kernel updates, or maintain your own kernel and back-port any important security/reliability updates. Slackware does neither.

13.1 uses 2.6.33.4 which branch has already been abandoned/unmaintained upstream.
12.2 uses 2.6.27.31 but 2.6.27 is already up to 2.6.27.53. That's a significant difference.

If you treat Slackware as a 'starting point' and take on management of this sort of thing yourself then it's not a problem, but it's important understand this is how slackware works. It's not like Redhat/CentOS, SUSE or debian where the distro team look after everything for you.