Linux Support For The Enterprise?

[CRiMSON] asks: "Does the open source model support big business? When those 90,000 POS terminals have a problem, who do they turn to? It's hard to tell your manager, that 'there no fix for the problem yet, but it's expected in the next pre-patch release.' Big businesses like accountability, someone they can point a finger at and say 'Make it work'. For Linux would you have to point to many people... Or in some way could one hold Linus responsible?" There are companies that offer support for Linux and there are several other options where, if accounting is a must, you can get it. Support can be purchased with the system, either separately or included in the contract, or you can hire in-house IT staff to make any necessary modifications that you require. What companies out there offer Enterprise-Level Support for Linux and do any of you readers out there have any experiences you would like to share?

Comments

Turn to the vendor? Not as useful as you think

[Tony Shepps]

From 1992-1994 I worked in high-level Unix tech support for Unisys. during most of that time we supported 7 different architectures and 7*n different version of *nix, both AT&T & BSD flavors.

It was a pretty good group of people, but only half of them were capable enough to debug something "from scratch"; the other half would look up your problem in the database, roughly the ancient equivalent of what every vendor gives you gratis over the net nowadays, and if it wasn't there they would either escalate, dispatch hardware or local support, or wander the cube halls asking the more savvy people what to do.

People were well-supported under these conditions if they had problems that were RTFM, or known bugs, or hand-holding for odd and difficult things like really had fscks or restores from unknown backups.

I'm sure these are the sorts of problems that every Linux vendor can also offer these days. But what if your problem was a real bug that your enterprise depended upon?

Well, those problems would be escalated to "engineering", the group that did kernel and such support for our versions of Unix. And those problems took *ages* to get anything back. Especially in an age where the company was trying to get rid of the burden ofsupporting the customers with old hardware that had been sold before the merger of Burroughs and Sperry. The BSD customers were largely out of luck. The people reporting problems on modern levels of software that was still being developed were the only really lucky ones, as their problem might get some attention. Otherwise, the level of interest in truly solving a serious problem was very low indeed.

And if a bug was not reproduceable, and didn't come with a ton of information and core dumps and whatnot, forget it.

Linux is different in two ways. Firstly, and most obviously, with the source code available, there is a really good chance that you can either fix problems yourself or find/hire someone who can fix problems for you. But secondly, and more importantly, Linux encourages a different attitude towards IT. It invokes the primal call of the hacker. It encourages the involvement of a different sort of employee.

Under old corporate Unixii, sysadmins *had* to call support. It was S.O.P. because support was the only place to turn to for the problem database, for patches (this was pre-Internet and patches weren't made publically available), for finding out whether a problem was previously known.

Now, with the source available, with known problems advertised to the world, with patches mirrored on 30 different servers, with hundreds of places to turn to for help, there are no excuses. The chances are much greater that a sysadmin can locate a solution or workaround. The same code running in the enterprise is also running in 12 million other boxes.

Furthermore, the online communities did not exist in the corportate unixii world, and for the most part they *still* don't exist. Find other people interested in helping you figure out an error message in HP-UX? I wouldn't even know where to turn. Find a weird error message in Linux? Chances are a net search will find it, and in five minutes you'll know whether it's a rare problem or a common one, and if it's common, in five more minutes it'll be fixed.

Bottom line: the "rules" for support have radically changed -- for the better. The quality of support from the teeming masses of Linux users is as high if not higher than the old corporate support. The type of people attracted to running and using Linux is better.

Lastly, in an enterprise situation, and especially in the case of POS terminals, one is unlikely to suddenly run into a problem that will "shut down" the enterprise. POS terminals will run the same code over and over. Enterprises will run systems in advance of putting them into place; new problems will crop up when they run into resource limits, but these are problems that everyone has run into -- things like, what happens when you run out of swap, what happens if you try to configure a file system larger than the last one, etc.

Otherwise, the typical support calls of "What happens if I can't read my backup tape?" and "Why does my system crash when I plug my serial cable into line voltage?" will be handled by the vendors, just as they always have been.
--

Fixed in the next realease (like Windoze maybe?)

[HiyaPower]

Although responsibility is actually a valid issue, I get a bit tired of the "Well nobody is responsible for Open Source, therefore we will have to use Closed Source" arguments. At least in the Open Source model, you have 1/2 a chance to find and fix the bug yourself (after all You were responsible for choosing this weren't you?), rather than putting a bug report into some Microserf someplace and hoping that there may be an answer sometime. Personally, I hold my management responsible for their choices. Unfortunately moral cowardice is rather rampant these days and the fact the Marine mentality of:

• What is your escuse soldier?
• No excuse sir.

as the only possible answer just doesn't fly anymore. Anyway, when it comes to Microsquish bugs, I demand a recount. Windoze Me doesn't even work with more than 512 megs of memory.

For the Enterprise?

[Brian Kendig]

... someone they can point a finger at and say 'Make it work'.

<picardmaneuver> Actually, they just need to say 'Make it so.' </picardmaneuver>

Obtaining support from commercial vendors (???)

[sphealey]

"It's hard to tell your manager, that 'there no fix for the problem yet, but it's expected in the next pre-patch release.' Big businesses like accountability, someone they can point a finger at and say 'Make it work'."

Has anyone ever managed to hold a major software house accountable for _anything_? Microsoft, IBM, any of the big (or small) ERP vendors? I haven't seen it happen in 15 years of software support. My former employer had a super-double platinum support contract, and about 25 million USD a year in business, with a software vendor you know very well, and we NEVER managed to pin them down and force them to fix ANY of the bugs we found - some of them quite serious.

[Having previewed this, I will make one exception: Novell tends to stand behind its products more than other vendors]

As to whether you can support Linux et al, that's another question, but I hope no one is thinking they can force a commercial software house to stand behind anything. Not to even mention UMCITA.

sPh

Ebay example

[Col. Klink (retired)]

And just who did Ebay "point their finger at" when they had all those troubles? They blamed Sun, but that didn't get them back online immediately. And in the end, Sun said it was Ebay's fault because Ebay didn't apply patches provided by Sun.

The bottom line is that you've got to have your own staff to support your machines. The whole "I can blame the vendor" approach is nonsense considering the EULAs and court decisions not holding vendors responsible.

Ever read a EULA?

[jcostom]

Have you ever read the EULAs of OS vendors? Let's use Microsoft as the example. Under the terms of their EULA, the software has no warranty at all. They make no claims about fitness for a specific purpose.

This is the classic "who do I sue when Linux blows up?" fallacy. Who do you sue when Windows NT blows up, taking out half of your enterprise? Answer: it ain't Microsoft. By agreeing to their EULA, you agreed to hold them harmless, and gave up any right you might have had to sue them.
--

Turn to yourself for fixes.

[mistered]

It's hard to tell your manager, that 'there no fix for the problem yet, but it's expected in the next pre-patch release.'

I'm quite sure that a decision to widely deploy Linux, like Home Depot's decision, was not made by some tech under about three levels of management. When you're talking about a deployment of that size, you carefully weigh all of the options before going ahead. I'm sure Home Depot looked at licensing costs, expected support response times, support contracts, hardware requirements, etc. before going ahead with their Linux deployment.

The article mentions Red Hat; Home Depot may have a support contract with them. If they don't, or if Red Hat disappears, there are others to turn to for support. Home Depot's IT group is probably a respectable size; they could hire an in-house Linux developer for support if desired.

What do you do if your POS system is running on a proprietary, closed operating system and you come across an OS bug? If you're big enough, you might have a support contract for your OS and perhaps you will get support, but otherwise you're basically out of luck. Even with a support contract, if the company goes under or fails to provide support in a timely manner, you have nobody else to turn to.