This may be a really silly question, but here goes.

At my workplace they are going to set up a virtual Linux server in VMware. The question from our IT manager is (as he has not done much Linux work), "Is Slackware server grade or should we go with something like Redhat or SuSE enterprise?"

Basically, is there anything crucial that distinguishes something labeled "Enterprise" from Slackware?

My feeling is that Slack should be perfectly suited for the task. It would only need to service a few simultaneous users.

Thanks for your thoughts.

Slackware is fine for a server. The main difference between normal and "Enterprise" distributions is that you can buy support for those distributions.

With a Redhat server you will have to pay a yearly subscription fee for OS patches - see https://www.redhat.com/apps/store/server/ for the subscription model and prices. Note that Redhat offers web and phone support in return, but you pay a lot extra for that service.

With Slackware you will get the patches for free, and those will keep comping for more years than you will get support for an "Enterprise distro". Free is nice, but if Slackware is used in a business, it would be nice to buy a Slackware subscription (40 dollar per Slackware release, with roughly one release per year).

Compare the cost per year!

Slackware is definitely server grade. Some big-business software (like Oracle database) will not work out of the box on Slackware since Slackware has not certified itself for that (costs for a certification are astronomical for a small distro) but otherwise you can trust any software or service to a Slackware machine.

Eric

2 members found this post helpful.

From a technical POV, Slackware will work fine. Users will see no difference between Slackware or Red Hat or whatever, so I'd suggest the decision be made based on cost and the ability of your IT guy to install and support it. RHEL is very good and does cost. But, you can get the same code, minus Red Hat branding, in CentOS 6.3. (centos.org) and still take advantage of the voluminous Red Hat online documentation.

I self-hosted my website on Slackware for four years.

Definitely server grade.

Most distros, when they offer "server" versions, mean that those versions do not install a GUI by default. "Enterprise" often means that there is a paid-support version. The underlying software is usually the same.

1 members found this post helpful.

I have used Slackware on servers in a production environment. It serves quite well in this role.

I have worked with nontrivial clusters of CentOS, RHEL, Debian, Ubuntu, and Slackware systems, and Slackware is hands-down the most stable of them all. To me stability is the most important thing in a server. A service which isn't there when you need it is not a useful service, no matter how advanced its features.

However, using Slackware in an enterprise setting is not without its caveats:

* Most sysadmins of enterprise infrastructure come from RedHat and Debian backgrounds, and may be confused by Slackware's differences (.rpm and .deb packages behave differently from .tgz/.tgx or sbo, and old-vs-new style rc files).

* There is no equivalent to kickstart/satellite for provisioning large (thousands of servers) clusters of Slackware machines: http://www.redhat.com/products/enter...rhn-satellite/ ... If you are deploying a small number of servers (less than a hundred), or if you are able to roll your own PXE-install solution which serves the company's needs, then this may be a non-issue.

* While there are tools for Slackware equivalent to apt-get and yum, they are not installed by default (slapt-get for official packages, sbopkg for ancillary packages). Enterprise IT often codify strict processes for installing new software, which assumes that a standard package is available via such tools. Install slapt-get (and perhaps symlink it to apt-get) and this may be a non-issue (though if your company develops software in perl, sysadmins might grumble about having to use /usr/bin/cpan instead of official distribution packages of perl modules -- slapt-get and sbopkg do not provide these, afaik).

* Software developers and web developers who are deploying to these servers may complain about the latest-greatest-whatever not being available. Slackware's stability is due in large part to a limited set of official packages, and limiting those packages to stable software releases. If developers can be told "this is what you have, and you must work with it", then this may be a non-issue. But if developers have more clout with management than you do, they can have your boss tell you to reverse your decision.


You may notice that most of these are social and political issues, and not technical issues. Truth be told, social and political issues are often more important than technical issues in an enterprise environment.

There have been times in my career when I was able to choose which OS a cluster's servers would run, and I have wanted to use Slackware, but I chose Debian or CentOS instead for political reasons. For instance, at archive.org, everyone was excited about Debian, and the senior sysadmin had even ported much of our software to Debian on his own time. I was the only member of the team with any Slackware experience. I could have tried to impose Slackware on them, and faced an uphill battle trying to get them to accept that decision, or I could have taken advantage of the excitement and experience they already had, and gotten them on-board from day one by choosing Debian. I chose Debian. It worked pretty well.

It's all circumstantial. Do what you think is best given your circumstances.

9 members found this post helpful.

+1 for that. I've spent the last few months working entirely on Debian and RHEL, due to 1) clients requesting Linux training on Debian and 2) geophysical calculation software being only certified on RHEL. Only a few days ago have I found some time to put my hands back on a pet project of mine on Slackware, and it's a breath of fresh air. It's like riding my old 1000cc BMW (no-bullshit two cylinders, KISS principle, lots of good vibes) after some time on your average japanese sports cycle enhanced to death with malfunctioning ABS, CBS and various other electronic assistants.

Thanks for the great information. I would like to follow-up on two posts.

First, to Alien_Bob, great idea about a subscription. I mentioned it to the IT manager and he had no problem with that. Also, as far as I know, there are no plans to run things like Oracle on this. The one commercial product that will eventually find its way there will be SAS. I have been using SAS on my own Slackware installations with no issues, so I'm not concerned about that one.

Second, to ttk, you gave some great advice for OS choice in a bigger environment. In our case, this will be the only Linux server around and is being set up for a small number of users with particular needs. The IT folk have little experience with Linux and have no distro preferences. I am the in-house Linux expert (although I'm not IT myself) and I have been told that I will have some admin rights. But after things are running, Slackware requires very little care and feeding, which is a plus.

Thanks again to all. I don't post often, but when I do, I never fail to get useful and helpful responses.

Kind of keep in mind that servers don't have to worry about too much -- typically don't have a keyboard, monitor or mouse (you get into it on your LAN with SSH) -- just sit there mumbling to itself and do what it's intended to.

It might be a data base server, MySQL, PostgreSQL, Informix (yup, Informix), Oracle, whatever. It might be a mail server. It might be a math cruncher. It might be a Bugzilla server (which would mean data base and mail). Doesn't really matter -- what does matter is stability and reliability; these babies need to run for months, 24/7.

My own machines run like that. The only time they get rebooted is when a security patch is applied (no such thing as, you know, Patch Tuesday). They're all Slackware, have been for years and they've been running for years (well, one quit when a capacitor went bad on the motherboard; got that that fixed and it's been sitting in a closet running for almost a year since).

I spend, what, about $300 for a box, $40-ish for Slackware, insist that it not have fancy-schmancy graphics or audio cards in it (who need graphics or surround sound on a headless server, one asks), install Slackware, configure the network (fixed-IP only), set up NTP, set up Apache, configure whatever I'm doing with it (like MySQL something), set up a back up scheme and that's that. What used to cost thousands or hundreds of thousands for (well) under $500 -- including roughly an hour it takes me to go from raw iron to fully functional.

And then I don't mess with it until a security patch is announced -- you're smart to subscribe to the security mailing list at http://www.slackware.com/lists/. Spin the patch(es) out to all of 'em and that's that, back in business in ten minutes or less.

I've arranged my disk drive partitions so that I can do a "clean" install when a new release of Slackware comes along. The "system" side (the distribution software) is isolated in two partitions (the root and swap partitions) and everything else is in separate partitions. Trick is, when you're installing Slackware, that you can add partitions without formatting them (really simple, that), so /opt, /usr/local, /var/lib/mysql, /var/lib/virtual (where I put virtual machines) and so on are untouched. No reloading hundreds of gigabytes worth of data bases and other stuff. Works for me. I do recompile all the add-on software (which I force into the /usr/local tree) but that's just start a bunch of SlackBuilds and go get some coffee.

Is that an Enterprise approach?

Well, I had to come up with a simple, easy-to-manage way of keeping things up-to-date and that's what I came up with. I also had to come up with a distribution that was as close as possible to System V for compatibility and ease of transition between different hardware and operating systems (Slackware drops into a Solaris -- which is essentially System V -- shop with only a few essential differences; With X86 Linux we're dealing with PC architecture to which Sun boxes do not even come close. Slackware serves that purpose nicely, it's close enough to System V that you can hardly tell the difference in addition to being rock solid and dependable as all get-out. I came up from Honeywell GECOS to System 3 to System V to Solaris to Slackware (never did like BSD or BSD-based systems) and haven't looked back [or been temped to switch]).

What you're really looking for is simplicity, stability, dependability and long-term support. You're not looking for the latest and greatest hairy-edge goodies and nonsense, you want to turn it on, set it up and forget about it. You get that with Slackware.

Hope this helps some.

2 members found this post helpful.

OMG! It must be a living hell working there!

I setup and run 4 Slackware 13.37 64 servers where I work on various machines. These servers serve our corporation globally, not just locally. I have been running them since 2007 (started with 12.1). Never had a problem that couldn't be solved quickly. In fact this year I just replaced an old Debian server with Slackware.

The problem with Debian (at least in this case) is that it is installed by first installing a core, then you only install the software you need. This is advertised as a benefit. That is all well and fine when things are working; however, when there is an issue, you may NOT have the application installed that you need to fix the box and you may not be able install the app due to the problem. That's what happened to me. So I prefer the default Slackware install of everything, even for a server, because downtime is more important than some minor performance that nobody but you is going to notice.

I too can't stand it when I hear managers who really know little about Linux trying to pick a direction for what I do with out asking first. Recently there was talk of "standardizing" on a Linux distro for the whole company. My position was that that was a bad idea because different distributions are better at certain things than others. And we have alot of people doing alot of different things. For example Slackware is probably not the best choice if you're going to be doing multi-media work. On the other hand Ubuntu is probably not the best choice for critical system because Ubuntu is designed for user friendliness and as such the answers to technical questions in Ubuntu forums is not as forthcoming as in Slackware forums.

This is just my opinion from my own experiences so don't anyone get twisted about it. :-)

2 members found this post helpful.

Having run a performance characterization lab for advanced NAS server development, all of the infrastructure, test/load generation and data acquisition machines were either Slamd64 or Slackware in side the lab (company edict was RHEL).

The choice was simple since Slackware kernel and apps are built from source as released by the developers rather than something that has been heavily modified, often in multiple iterations by different teams ala debian -> ubuntu_flavorX.

Tracing down subtle kernel+network+RAID configuration nuances in the product AND in the lab test servers was interesting enough without trying to unravel what bleeding edge RedHat-ism was influencing behavior.

Besides that, the illusion that a "paid subscription" will get timely support for anything but trivial issues is absurd given the level of complexity and speed with which issues need to get resolved in a product development environment.

Cheers,

I would just add that, while servers tend to demand little attention from day to day while they are happy and working properly, the Powers-That-Be will demand an immediate response when, inevitably, a server stops working properly.

If the support for a Slackware server comes from a non-IT guy who happens to be a Linux buff, then that pressure is going to fall on him, whether he wants it or not. It might also affect the opportunities he has at the business because management might find it cheaper to freeze him in place rather then train the IT crew appropriately.

Having been one of the Powers-That-Be at a shop, and having seen business stop because servers went down, my *strong* recommendation is that the choice of a server OS not be based on the skills or enthusiasm of one employee for one Linux distribution, regardless of the attributes of either the employee or the OS.

All contemporary Linux distributions will, in fact, provide essentially the same level of technical performance. The choice should be made, then, based on the willingness to pay for the level of support and maintenance deemed necessary. It's a bit of a gamble, either way. A business might luck out by going with in-house amateur support. But, what happens if the server crashes while that amateur is away on a 3-week vacation?

Buying support from RHEL or another vendor (you can buy Debian support, for example) might see a business never having a need to call the vendor. On the other hand, they might. I came to see that kind of cost as insurance. We couldn't afford to bring the business to a halt if the servers crashed.

Thousands of businesses rely on paid support contracts, with RHEL or otherwise. They do it for good reasons, not because they have been duped by fast-talking guys in suits.

I'd agree in principle with an earlier comment that easy problems can often be fixed in house for "free" without paying for support, but that assumes a business keeps full-time IT staff on the rolls. It also assumes that your IT staff has a realistic idea of its own capabilities and is honest about that with management. Businesses get burned when an IT guy says "I can handle that" and then cannot.

Serious, major, and confusing problems are harder to fix, period. My position was we should pay a vendor to provide that support because we had no need to keep IT people with that skill set on salary.

These are good points in general. In our case, the server is not in a mission-critical position. The IT person responsible does have some Linux experience also, so problems won't fall square on my shoulders.

The primary point was 'development environment', not 'typical IT environment'.

Cheers,