I have been trying out Scientific Linux 6 which is a clone of Red Hat Enterprise Linux. I don't know how to put this: there seems to be an awful lot going on. That is not meant as a criticism of SL, which is a very nice system, but from my very inexperienced point of view it seems that a lot of what Slackware does in a straightforward manner is needlessly complicated in Enterprise Linux.

I was wondering how many people here use Slackware in what could be called an enterprise setting, serving not tens but hundreds or thousands of users, as file servers, for example, or proxies. Is there something in the RHEL kernel that Slackware doesn't have, or is there anything else that limits Slackware technically? A limit on the amount of memory or the number of CPUs supported perhaps? I do understand Enterprise Linux has long-term paid support, and that changes made to newer kernels are backported, but other than that I can't really see much else that should prevent someone using Slackware on one of the world's supercomputers, for example. I see loads of these supercomputers running Enterprise Linux.

I'm just curious about this, and I hope I don't start any flame wars. I am unlikely ever to have to provision a server for hundreds of users or more, but I'd like to know why the Slackware kernel and userspace shouldn't be able to handle this scenario just as well as if not better than Enterprise Linux.

I'm interested in the responses you receive! I also would be grateful if you could itemize some of the things you thought excessive in SL6.

I absolutely do not want to give the impression this is a criticism of SL6. It's just my first impression of Enterprise Linux, which, if anything, reflects on RHEL, not SL.

I suppose the list of services running by default is one thing I noticed, but of course I was just trying SL out as a desktop user, and no doubt in the enterprise having these running by default might be expected? Another thing that surprised me was that most things seemed to be compiled statically into the kernel, not as modules, but I could be wrong about that.

What I was really trying to get at is, would Slackware as it stands, with a little customization of the kernel, suit as a drop-in replacement in an enterprise setting, prescinding from the issue of commercial support? Is there some magical, secret switch Enterprise Linux engineers can flick which Slackware users don't have access to? My impression is that all the important requirements are already there in Slackware to allow someone run it, for example, on one of the Top 500 supercomputers in the world. The kernel is the same, or is it? The filesystems are the same, or are they? And the amount of memory/number of CPUs supported on a 64-bit system is the same, or is it? A firewall is easy to switch on; Samba is easy to switch on; Squid is easy to set up. Chmod +x in /etc/rc.d/ does all that. So what else is there I am missing? What's to stop me advertising my 8GB Intel Core2Duo in the paper tomorrow as a supercomputer?

0 members found this post helpful.

I'd say it all comes down to support.

When getting any proprietary software they are usually supported on the Red Hat. Also, Red Hat has big team available to support you in any way when you need them (if paying for the support).
Nothing else comes to mind which makes enterprise distros different from regular distributions.

With Slackware you need to be able to install and manage each service by yourself. For example, you need to install Oracle database... ok, hit problem so you start to google it. Then you try few things before you get everything to work. Later you need to tune the database but Oracle tells that they don't support your distro and you need to figure out the settings on your own which takes time.

Enterprise distros might not be the most well behaving systems but they are predictable, well tested and supported for a long time which is something not commonly available for other distributions.

1 members found this post helpful.

The primary reasons that RHEL is used in big business:

1. Vendors - Many vendors of expensive products aimed at the enterprise only provide installers or packages for the enterprise distributions (mainly to make supporting the application as cheap as possible). For example, while Veritas NetBackup will install and work perfectly on Slackware, the installers are designed with only RHEL and SLES in mind. Anything else and you're on your own.

2. Support - Many large companies are not interested in having real experts on the payroll. They prefer to have people who are reasonably competent with the vendor's support channel as the backup for really serious/important issues.

3. Time - RHEL5 is RHEL5. Regardless of the patch levels and the backported upgrades, if something is written to work on RHEL5 is will work on RHEL5 right up to the time it is EOLd. Therefore in the example of the company I work for, the main infrastructure for the global compute infrastructure is based on one version of RHEL and that is stable and supported for many years. When there is sufficient reason to upgrade to the next release it is handled as a major project with the acceptance that many changes will be required.

4. Stability. RHEL is the definition of out of date. But the reason for that is because when something is old it's been tested and retested to death and it should be reasonably stable. Fedora is the blasting ground for leading edge testing and then once something is rock solid it will end up in RHEL.




Having said that, I massively prefer to run Slackware above all else and have done so in an enterprise as a desktop OS as well as in the core infrastructure. I had Slackware running everything from NetBackup to internal DNS & DHCP as well as VPN, databases, web servers etc. Even the core file servers were running Slack and serving files via NFS and CIFS to desktops and servers alike with fantastic performance even with multiple silicon chip simulations running data in and out at high speed.

There's absolutely no reason you can't use Slackware so long as you know what you're doing and the applications you want to run will run on Slackware.

From a technical perspective anything RHEL can run on Slack should be able to run on. While there's a lot of custom development in RHEL the base kernel is just a standard kernel. Any specific drivers needed for high-end hardware are available to slack if they're available to RHEL. If drivers are proprietary then if there's a RHEL RPM you can install it into Slack and away you go.



Having said THAT there is one place that Slackware massively falls down in terms of an enterprise architecture and that is the lack of PAM. The lack of PAM doesn't mean you can't do some things but it does make them a lot more difficult. For example, something as simple as authenticating system users against Active Directory or another LDAP database is quite a lot of hassle without PAM. I left my users authenticating from a NIS server because that's something Slack is perfectly designed to do - if Slack had had PAM a few versions ago I would have moved authentication to LDAP and removed the NIS server entirely but while possible it just wasn't feasible.


I've run out of useful things to say without a definitive conclusion so I will just say Slack is always 100% my preference for every task of any size - but there are a few (VERY few) times when it's just not the right way to go - and most of the time that's because of authentication, vendor support or a combination of both.

9 members found this post helpful.

When it comes to the large enterprise, there's just too much risk in going with a mission-critical application on Slackware.

1) The OS needs to have 24x7 support professionals available.
2) The application needs to have been thoroughly tested by the vendor on the OS and platform of choice, and fully supported by them.

Only your enterprise Linux distributors are going to offer that level of support, and because that's where their customers are going, that's also where the application vendors will go. It doesn't make any sense for vendors to exhaustively test against every flavor of Linux, so they'll go with the popular ones among their customer base, and stop there.

And once a shop has RHEL or SLES in house, they're not going to bother with Slackware for some of their minor apps, because standardization on one particular flavor saves a lot of time and money.

1 members found this post helpful.

Thank you! Something like the PAM information, i.e., a *technical* limitation, is exactly what I was looking for. If we prescind from the support issue and the availability of software issue, there's nothing else! Amazing really. It was the list of the top 500 supercomputers in the world that got me thinking. Hard to believe this little old desktop runs something so powerful! Thank you.

0 members found this post helpful.

And one other thing that's going to drive big business selections for Linux... support for hardware platforms other than x86. If a Linux distro is being supported on PowerPC and SystemZ, that exposes a lot more enterprise customers. Right now, that list stops at RHEL and SLES.

In fact, if you're looking at that list of supercomputers and wondering why SL isn't on it... there's your reason right there.

0 members found this post helpful.

This is massively dependant upon the application and the available skills. I spent years running not just mission-critical, but business-critical applications on Slackware. The problem comes when you spend more on an application than on your whole infrastructure. For example, when it comes to EDA tool vendors like Cadence and Mentor. When one application costs a six figure sum, it makes sense to make sure your infrastructure conforms precisely to the support specification of the vendor.

For less expensive software, again using NetBackup as an example, you only need to test and prove that what you implement will work as you need it to. Because NetBackup is available for pretty much every platform under the sun, you know that the likelihood of "flavour-specific" linux issues is likely to be low since the application is basically the same whether it's running on AIX, Solaris, RHEL or SLES. As long as you can correctly install it, connect to any needed peripherals and confirm backup and restore works as expected you don't need to care what the OS is as long as you know your own OS. When you do need to raise a support ticket you tell the vendor you are using the OS for which your installer package was built and translate any responses accordingly.

This is *only* if you have the skills to handle your own OS. You cannot give someone who only knows RHEL a Slackware box and tell them to handle the apps on it. But if you know Slackware intimately or you have a good familiarity with multiple different types of distro then you are better off using the one that you think is best for the job.

All of these decisions need to be made appropriately when testing. If, during testing you determine that there are enough issues with a particular piece of software that it needs to be run on the supported distro, you install a server with that distro and run it there or run a Virtual copy of that OS if that's what floats your boat - it doesn't mean anything else in your infrastructure has to run it - only the servers that depend on or are depended upon by the application's own code.

One thing I want to make clear is that, in my view at least, "enterprise software" and "mission-critical" software do not refer only to software such as NetBackup and Cadence etc. Basic file storage is just as critical. So is DNS. So is the software you support your clients with. While you *can* go out and spend ridiculous sums on customised software and the associated necessary support programmes, in many cases a Free/Open Source option is just as suited to your needs but, again, so long as you have the skills on the payroll to handle them. So when my company needed an enterprise grade support ticketing system, I put in Request Tracker. When it needed to authenticate against LDAP and MySQL, I took what was available and wrote an authentication module for it (which was released back to the community). When a VPN replacement was required I put in place OpenVPN. It was not only free, but it was faster, more secure and more reliable than the proprietary system it replaced.

So yes, my company paid for my time to do all of these things, but out of the salary of one man they got a complete infrastructure that cost them a one-digit percentage of a normal IT budget for a company of the same size, with no additional risks. Everything I put in place was tested to my satisfaction. Mission-critical systems ran on redundant hardware and were backed up appropriately; and because of the way the infrastructure was put together (i.e. very simply) the entire building could explode, but within a week (assuming being given hardware replacement budget and the off-site tape backups) I'd have everything back up and running again.

No-one should ever make the assumption that because a lot of money is involved, or because a business is of a certain size, that the only way to organise an IT system is to throw money at specialist companies, support organisations and applications. You have to make a choice. Spend your money on an external company and hope that they are capable of doing what they're contracted for (more often than not they actually aren't, but very carefully tiptoe over SLAs), or spend your money on recruiting some well trained sysadmins who really know what they're doing and let them get on with the job they love. If any of them prove not to be capable, then they can be replaced. The ever-present problem is knowing who to hire and it scares a lot of companies - but if they'd only stop focussing on head-count numbers and concentrate on hiring the right people not just whoever the agencies send that have a vaguely appropriate CV they might really have a chance to succeed.


Y'know what, I think I'm done ranting now

1 members found this post helpful.

zordrak: I think you missed one of the points I made, though. Once you have spent a fortune on a piece of proprietary software that commands you to use RHEL or SLES in order to support it, you've already justified having one of those enterprise flavors in house.

And once you've already paid for a support contract with RedHat or Novell... why wouldn't you go ahead and use that same flavor elsewhere? Once you've entered into a support agreement, it doesn't cost you any more to run your DNS or file server on RHEL than it costs you to run them on Slackware. But now you can call RedHat if you have a production outage and need help. Also, you can standardize your maintenance processes, which will save a lot of man-hours.

So if you can build an entire enterprise on Slackware, more power to you. But as soon as you have one critical system where the vendor only supports you on RHEL or SLES, Slackware no longer makes any sense.

0 members found this post helpful.

I would have thought a support contract doesn't give you free rein to install RHEL on any number of machines in the company? Surely they place a limit on the number of CPUs?

0 members found this post helpful.

Nope. That's server licensing, which doesn't exist in a GPL world. Support is a whole other animal. RedHat and Novell make their money from their enterprise customers through support contracts, and through subscription-based software updates.

It's the second thing that could trip you up. In the Novell world, all you need to do is stand up a single update server and register it with Novell to get access to their online repos. That one update server will proxy all your other SuSE environments, so they never know (or care) how many servers you're updating. But here's where they can get you... if you try to run SLES and SLED, those are two different sets of repos, and require two different subscriptions. Or, if you're running SLES on SystemZ, and you wanted to stand up another SLES on x86, again, different repos, different susbscription. Someone else would have to weigh in on RedHat, but I believe they operate the same way.

In this case, it might make more economic sense to run Slackware on x86 and SLES on Z, but it depends on what you're running on it. Those subscriptions aren't very expensive.

Reminder: PAM is available in Slackware-13.37, you'll find it in /extra/source

There is no pre-built package but it's only a 'cd /slackware-13.37/extra/source/pam && ./pam.Slackbuild' away

1 members found this post helpful.

I have NO idea how I did not know about that! Thank you! I will investigate when I get the chance. Having said that implementing a system that uses it I would guess would involve rebuilding a lot of other bits and bobs to configure them for PAM due to them being built without it for Slack. Interesting times though.


WRT SL00b's comment about once you have one RHEL box you might as well make the rest RHEL too, I thoroughly disagree. I would much rather have a Slack infrastructure and one RHEL box as an exception for a specific purpose than make my infrastructure a nightmare to live with because of one application I manage.

Also, last time I had a support contract with RHEL it *was* charged per machine/host and the version of RHEL you buy (e.g. how much you spend) determines certain limitations on what you can use it on/for.

Guys, don't forget also that RHEL has some of the best GUI/console administration tools also...Although many will not agree on GUI tools as heavy resource consumers, the truth is that these tools make companies hire average experts as IT admins...