LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   Why is Slackware so stable? (https://www.linuxquestions.org/questions/slackware-14/why-is-slackware-so-stable-832421/)

spoovy 09-15-2010 07:01 PM

Why is Slackware so stable?
 
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?

Jeebizz 09-15-2010 07:33 PM

Quote:

Originally Posted by spoovy (Post 4098805)
Newbie question here I suppose, but -

Slackware seems to be often compared to RHEL or Debian Stable in terms of stability.

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.


Quote:

Originally Posted by spoovy (Post 4098805)

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?

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. :p

Perceptor 09-15-2010 07:41 PM

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 :D ).
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. :D

BrZ 09-15-2010 07:43 PM

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

lostzinzthought 09-15-2010 07:52 PM

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. :)

lazardo 09-15-2010 08:53 PM

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,

dugan 09-16-2010 01:17 AM

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.

H_TeXMeX_H 09-16-2010 04:06 AM

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 :)

spoovy 09-16-2010 04:45 AM

Thanks all, very comprehensive!

GazL 09-16-2010 04:59 AM

Quote:

Originally Posted by Jeebizz (Post 4098818)
Only WELL TESTED packages included, not just packages included that are 'labeled' as stable.

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. ;)

H_TeXMeX_H 09-16-2010 06:16 AM

Quote:

Originally Posted by GazL (Post 4099235)
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. ;)

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.

willysr 09-16-2010 07:14 AM

Quote:

Originally Posted by GazL (Post 4099235)
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.

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.

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.

hitest 09-16-2010 08:02 AM

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!

tronayne 09-16-2010 08:05 AM

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.

GazL 09-16-2010 08:26 AM

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.

hughetorrance 09-16-2010 08:51 AM

GazL I think Pat could do a better job of keeping up with kernel updates, I reckon Pat et al do too much, without the head start they give me I would still be wandering distro land... LOL

ps Slackware feels like coming home after a long journey.

spoovy 09-16-2010 12:35 PM

Quote:

Originally Posted by GazL (Post 4099235)
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. ;)

I wasn't aware of that I promise! I'm not a troll :)

GazL 09-16-2010 12:37 PM

lol. Don't worry. I don't think anyone took you for one. :)

spoovy 09-16-2010 12:39 PM

Quote:

Originally Posted by hitest (Post 4099398)
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!

Surely all these points apply equally to RHEL and Debian as well?


I get it though now thanks. I wasn't aware of the amount of work the big distros do on so many upstream packages, so it makes sense that during the long testing cycle they are largely testing their own patches/modifications rather than testing the upstream product.

nortonlui 09-16-2010 03:11 PM

I agree with Gazl about this thread

look,

http://www.ocert.org/advisories/ocert-2010-001.html ( wget flaws )

GazL 09-16-2010 04:03 PM

I'm not sure how that relates to the points I was making (other than being another case emphasising that distros are at the mercy of upstream providers), but it's interesting non the less. Anyone downloading stuff with any tool really shouldn't be doing it directly to their home directory anyway specifically because of the risk of malicious file overwriting in this way. The same thing is also true of extracting files from tar archives.

If I download files, it'll be to either a subdirectory in /tmp or /home/user/downloads which will mitigate this type of vulnerability. I don't think this one is anything to get over excited about as long as you follow best practice.

dugan 09-18-2010 01:31 PM

Another reason is that each version of Slackware starts from a well-tested base: the previous version of Slackware.

This works better than, say, starting from a snapshot of Debian Unstable in whatever state it's in.

Jeebizz 09-18-2010 04:00 PM

Isn't Ubuntu based off Debian-unstable? :D *runs for cover*


All times are GMT -5. The time now is 04:19 AM.