Hi all,

Please don't take this the wrong way, I'm just curious. I'm wondering how thorough the slackware stable is tested before release. I'm new to slackware (but not UNIX/Linux), so I just don't know.

I'm in the process of evaluating slackware for server use (in a production environment), and I've noticed the package versions in slackware stable are *generally* more current than packages in Debian's stable, testing, unstable and experimental! We've been running Debian servers for years (very happy with it), but Debian does tend to have older packages. Too old.

We all know Debian has a sometimes painfully slow but thorough testing procedures, and you can be assured that once a package hits Debian stable, it is rock solid. I'm wondering if the same can be said about slackware stable?

I can give a (long) list of packages with versions if anyone is interested.

I'd like to learn more about slackware's testing procedures, history, release/patch success, problem severity and frequency, etc.

Thanks for reading

From my personal experience (using Slackware since 10.0) I would say that Slackware is very thoroughly tested. Stability and security are some of the many strengths of this OS. Once Slackware is set up I have never had it fail on me (unless there is a hardware failure or I've done something stupid).
Slackware is exhaustively tested by the developers and users when Slackware is in the current stage of development. Patrick Volkerding will only release Slackware to the stable branch when it meets his criteria for excellence.
Yes. Slackware is an excellent choice for a server.

Some of the Slackware devs are members here so I expect them to sound off shortly.

As for my experience, I have been using it since 8 was released. It is the most rock solid distro available. Pat will not include any bleeding edge packages like most of the other distros feel compelled to do.

BTW, I'm moving to Sarasota/Bradenton mid June. You belong to a LUG in Tampa/St Pete?

I'd like to learn more about that. Is the dev mailing list public and archived somewhere, so I can read past discussions? Also, I'm sure there are some mailing lists I should join for future discussions too.

That would be great! I hope they do join in and share their personal experiences too.

Hmmm, the one in tampa and sarasota are supposed to be pretty big, if I recall correctly, but they are a little far for me, so I never made it to one of those. My local one here (st pete) has been really small over the years. It's been almost two years since I checked it out, I should do so again.

Except some important, like openssl.

You can read the development as it happens on the intel current changelog.

http://www.slackware.com/changelog/current.php?cpu=i386

There is also a security mailing list you can subscribe to.

DOH!

I don't know how much testing does Slackware gets before packages gets included in the stable branch, but it seems logical that it's going to be less than Debian, because Slackware's dev team is tiny compared to Debian's. I'm not saying Slackware is more buggy than Debian stable, for me at least is the other way around, Slackware just works and it doesn't break

And one thing I really like about Slackware is that it's compiled from vanilla sources, I tend to think this is the magic that make Slackware rock solid :^)

First off we don't have a public dev mailing list sorry (or a private one for that matter :P ).

Yes the devel team is rather small and this is by design... the old "Too many cooks" applies here.
One advantage of this is that it's easy to know what everyone else is doing.

As for testing:

Everything is proved as working on the hardware available to us before it hits the current branch. From there we rely on reports from users that often use current on a daily basis. Current really is the testing phase for any release.

I personally find that the people putting things together are probably the worst test case for any product especially something as complex as a Linux distribution.
While we do check everything thoroughly there is bound to be some corner case or someone using something in an unexpected fashion that will cause a degree of breakage.
The hardware we have at our disposal is also limited so putting it "out there" is the best test it can have.

Current usually goes through it's beta stages where things are pretty much in a feature freeze before the rc's come along... this is the time for bug fixes/security updates only.

So to sum it up... every release is very well tested before it becomes stable and hits the mirrors.

I have a mail out that notifies people of any current updates and it has 300 odd people subscribed to it.... I'd have to assume that most of them are testing current along with many that track the changelog themselves.

wow it took forever to submit and double posted

Thanks mRgOBLIN, that does help, and makes good sense. I kind of like keeping the core group smaller, so everybody is playing in the same game. Having one quarterback is great too, keeps the project focused and moving forward.

It just dawned on me, the slackbuilds.org scripts are tested by other people, mostly community I'd imagine (compared to the Debian archives which are officially maintained by the devs). The slackbuild site says each script is tested, but I wonder to what extent. I'm sure the quality of scripts can vary radically, depending on who wrote it. So far, I've only tried a few, but I'm slowly getting a better feel for things.

I hope these don't appear to be stupid questions. I'm still learning the "slackers" way, but so far, I find it very appealing.

I have a little question
how many users can slackware serve at the same time if it is being used as a server??

Indeed :-)

Theoretically, everything in our repository is tested for proper function by the submitter, and proper packaging by the approver (the SBo admin), and we (speaking for SlackBuilds.org) often test for proper function too if it's within our expertise to do so (but lots of things simply aren't [1]). That's not to say that we're perfect, as we occasionally miss some stuff, but generally speaking, I think you'll find that the resulting packages are on par with what you'll get from any other distribution.

[1] As an example, I wrote and maintain the build script for blender. I can verify that the package is built correctly and that blender will actually run, but I have no idea if everything it's supposed to do works correctly. I don't have any experience in "blending" ;-) nor do I wish to obtain any -- I wrote the script simply because there were a quite a few people requesting it.

As many as the machine can handle. Most of the time the amount of users a server can handle is directly related to the hardware.

Example:

An old P2 500mhz, 256mb RAM could not handle as many as a Core 2 Quad and 8gb of RAM.
Also you Net connection changes the amount of people you can handle.