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?
The best way to get (1) is to use Free Software. The best way to get (2) is to hire an appropriate number of experienced systems administrators and Free Software developers to your internal staff. Why? Well, if you go through a commercial support vendor, you'll have the same problems as with any other technical support - your trouble ticket has to work its way up the chain to the people who actually understand it, the people answering the phones usually have virtually no ability to understand the problem, and the back-and-forth is time-consuming. The cost, assuming you have a reasonably large installation, isn't going to be any less than the in-house contracts anyway. So is it worth the extra time to get back up to be able to "blame" somebody if something doesn't work? Not when you're losing money while a phone monkey at Joe's Linux Support asks you to repeat, for the third time, just what exactly isn't working with your SCSI controller.
However, let's think about the implied assumption for a minute. The implied assumption that you make is that the software is going to break in the first place. That well-tested, well-designed, well-implemented and well-integrated software is going to break after you deploy it to 90,000 cash registers. This assumption might not be valid. Yes, in general things tend to break. But, if Linux is the operating system, it probably won't be the cause of the breakage. Instead, the cause will be things like your POS code.
The same could hardly be said for Windows, with it's DLL Hell and inability to ever be the same twice after 1 week of users touching it. Further, Windows on a POS system will foster an illusion of competence which will encourage various attempts to break into the systems. You will have to spend gobs of money on software to lock the systems down to prevent "hax0rs", and even then it probably won't work (2600 delights in publishing exploits on POS systems and the like.)
So which is better: a system that doesn't break in the first place, or support to help you fix it after it does?
--
-- Slashdot sucks.
There are plenty of stories wherein open source software has quietly proven a success. Quietly? Sure. Home Depot may be on Linux, but IT is not percieved as a fundamental issue for Home Depot's financial success, things like Supply Chain Management (SCM) are. Of course, if their IT infrastructure fails, it will screw up their cutting-edge SCM, but financial analysts rarely drill that far down.
A good example is the rise of DEC. (The fall of DEC is an example of other things :-).
In the mid-80's, insurance giant Aetna bought out a small insurance company -- something they do all the time. In the course of their due diligence, they requested a roster of standard reports. The reports arrive two days later. The Aetna execs were flabbergasted. It took weeks for a team of RPG and COBOL programmers to coax similar reports from Aetna's computers. What kind of computers was this small company using? "We run on DEC machines running UNIX," they answered.
Before you knew it, DEC was the new star in corporate IT. IIRC, 1986 was the Year DEC Could Not Be Stopped. Linux has a lot of good buzz, but it hasn't crossed that perception barrier. What will it take? It will take someone betting on, and winning with, Open Source.
I'm running my ecommerce infrastructure using Linux, Apache, NetBSD, mod_php, Jakarta Tomcat and PostgreSQL. The only closed-source element is the JVM that runs Tomcat and I can replace that with Kaffe eventually. Have I bet my business on Open Source? Not really. I told a Sun and an Oracle rep just last Thursday that if Linux and PostgreSQL begin to break under stress, they could expect a call. I can switch to Solaris and Oracle in a weekend. Even though I have the source code, I have neither the time, the expertise or even the interest in developing Linux and PostgreSQL into a solution that can rival the power and stability of Oracle running on dual E6500's. I will, at the point where I need that, have the money to pay for them. Right now, I'm just one of thousands of businesses that is controlling their startup costs by building their initial infrastructure on Open Source. That's a plus, but it's not the testimonial Wall Street needs to see.
What needs to happen is a success story build on Linux or NetBSD that couldn't have happened using closed-source approaches. I don't know what that's going to be, but I'm sure it's on the horizon. If I do think of it, look for me on the cover of Forbes (I'll see if I can get Linus to stand behind me and grin appreciatively).
"Reasonable people adapt themselves to the world. Unreasonable people attempt to adapt the world to themselves. All progress, therefore, depends on unreasonable people." -George Bernard Shaw
You contract for support not for support of........? D'ya get it? In fact it's EASIER to support a Linux based system in a large corporate environment because (in theory) you would make any chang you need instead of swearing about some broken Windows crap that STILL hasn't been addressed for a year or so. You don't go an build, say, a huge datawarehouse and then throw your hands up if Windows or OS/390 or any other OS doesn't cooperate. You contract with whomever can get that job done. Do you honestly think that if you were a large Windows customer and even if you contracted with MS directly they would roll off a custom version just for you?
Compaq, IBM, and Dell all sell systems with Linux on them, and they stand behind their systems in terms of compatibility. You install a new device that is buggy on Linux, their support guys will help you, or they'll tell you it isn't officially supported hardware, and see if there are workarounds -- same as a MS tech will tell you about devices not on the HCL.
But if you get a POS system (touchscreen, cardreader, cash drawer) based on OS/2 or DOS or Java (don't know what they run under the Java) then just go ahead and slap linux on it and things break, what the heck is the vendor *supposed* to do? They don't know any more than you do about running Linux on the hardware, most likely *less*, since you're the one being the guinea pig.
On the other hand, if you purchase a POS system from a vendor that supports Linux and it doesn't work as advertised, then you need look no further than the vendor that sold you the system.
And for the mutants in the crowd with three hands, on that hand if you homebrewed this POS system, you can't hold anyone to support it but yourself. If you build your own car and it breaks down because you assembled it with parts that were never made to be fitted to each other, you don't have a car maker to hold responsible either.
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
Btw.. I'm calling for a unified packaging system for the unixes and it requires and first of all it requires a unified FHS. What efforts are being put into that out there?
I'm trying not to sound crass here, but if you were putting serious effort into your system, you'd know the answer better than anyone here. As an aside, I have many reasons to believe it's misguided to have your unified packaging system require a unified filesystem. First, you're the tail wagging the dog. Show that your system adds value. Redhat users have rpm, debian has apt, bsd has ports. You have to beat those or they have no reason to switch. Second, good luck getting solaris and slackware to see eye to eye.... or by "unixes" do you just mean linux? Lastly, I suspect your rigid filesystem standard would simply fall down in the face of complexities like a multi-architecture network. There is no One Right Way To Do It, especially when there's more than one "It".
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
His first action? "Well, let's get on the phone with the Apache people!" When I quietly informed him that there wasn't a specific "Apache people" to get on the phone with, he was utterly confused
A quick trip to www.apache.org would have put the lie to your answer. Apache is tightly managed by a group of developers, all of whom have names. You can even peruse the cvs logs to find the name of the developers who worked on that particular piece of code. You won't get telephone support, but you *can* send in apache bug reports, which are responded to. If that's not good enough, you can also purchase support contracts for apache from a number of companies. Tell me you did something other than throw up your hands?
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
90,000 POS terminals that can run on generic hardware, with hardware+licensing savings on the order of about $3,000 per cash register ~= $100M/yr in savings over a 3-year equipment life...
Three THOUSAND? Where the HELL did you pull that figure from? You don't exactly put Win2K Server on a POS box, much less buy a separate CD copy for each one.
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
Even if nobody else considers your problems worth looking at (slim chance,) since you have the source code, you're not at anybody's mercy waiting for an upgrade that might or might not fix the problem. You can hire a Unix programmer, consultant or fix it yourself.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
Last summer my company (30k employees) did a massive Win2k deployment. Then Bad Things (TM) began to happen, especially with Active Directory.
In a few days, Microsoft assembled a 20-people team (mostly developers) that came on-site, plus another couple of sizeable groups in the US and UK to support them.
The problems got fixed in about two weeks (I must commend the guys, they worked really hard).
> Yes, they can sue. But, pointing that finger won't make the problem go away.
You got that right.
I've worked for a place that used commercial (non-MS) software, and there was very much a resigned "maybe it will get fixed in the next release" attitude. And my employer was a Fortune 100 company that you might expect to have some clout with a vendor.
In once case I had to debug an application myself -- without the source code -- and then browbeat the vendor's engineer with my evidence in a conference call until he agreed to look at the code and verify it. (I did it by tweaking paramaters and plotting the result, and got a "sawblade" pattern where I should have got a 45 degree line, telling me a certain parameter was being held in too few bits, with consequent wraparound as it grew.)
The "who do you point at" myth is marketing, not reality. As others have already pointed out, with OSS you at least have a chance of fixing it yourself.
--
Sheesh, evil *and* a jerk. -- Jade
From IBM's latest annual report, percentage of revenue by category:
IBM is a HUGE support organisation. Sure, they do make more money from hardware than from support or from software (individually), but not much more. And look at the trend; it probably won't be long before Global Services surpasses Hardware.
Have a look at IBM's recent press releases. You'll see IBM mentioning Linux a fair bit.
It certainly looks like IBM's trying to position itself as a software and support company, with Linux as a not insignificant part of that strategy.
Enjoy your job, make lots of money, work within the law. Choose any two.
IBM recommends whatever they think will make them the most money. Right now it's probably easist for them to sell a machine with Windows on it. They're not going to say to their customers, "I know you think Windows is great but we think you'd like this Linux thing instead." If you see an ad by IBM selling Linux support and call them up, they'll be more than happy to sell that to you.
Enjoy your job, make lots of money, work within the law. Choose any two.
Slashdot is not a Linux support forum. Besides, since we both post below 2+, it is likely, that nobody watches;-)
>not 100% native mode:will probe irqs later
That is ok.
>ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
>ide0 at 0x14c0-0x14c7,0x14b6 on irq 11
It looks like you forgot to make the secondary harddisk (ide1) a slave. Check the jumpers on it.
Oh, watch your Windows partition; do have a backup ready, or at least at windows boot disk ready (with fdisk on it, in case you need to do a fdisk/mbr, if you place the bootmanager (lilo) in
the wrong place.)
Is IBM large enough for you?
As one responsible for mission critical systems, I've justified paying a large sum of money to get support for a commercial UNIX system (Data General, now EMC, for DG/UX).
This puppy, whenever it paniced, would send diag packets automatically to DG, they'd start analyzing the problem, create a patch, and ship it out to us. There's a great comfort in that.
We had one case where the box would panic for no good reason on boot. Software support couldn't figure it out, so hardware support came out and just started blindly swapping processors, memory, etc, and it still didn't stop it. Turned out to be a faulty VME slot backplane board. Fixing that fixed the problem.
The point is, I have a ton of problems to worry about already and I took great comfort in knowing that no matter what was the cause, THEY HAD TO FIX IT.
I haven't seen any Linux vendor support get there yet, and I certainly haven't seen that with Microsoft servers. If they fail, you're told to reboot and try again. If that doesn't work, the next "solution" is to re-install it. Will Microsoft custom-fix a patch for me if I'm seeing a problem? I don't think so. Maybe if the fault is being experienced by thousands of sites...
So, bottom line is, it really doesn't matter what the OS is or who makes it, it matters who the support vendor is and how well they support it. There is nothing that says that level of support couldn't be made available for Microsoft or Linux OSes. The advantage vendors like Sun, DG, HP, and IBM have is that they provide the hardware and the OS as well as the service contracts. When something fails miserably, they can tap all their internal units if needed to get it fixed. A Linux support vendor theoretically could do the same since they also have access to the source. A Windows support vendor, I just don't see how it works.
But I will soon enough. We just got a pair of DG Intel boxes and are loading Windows 2000 on them and getting DG service contract on them. I'm going to have first-hand experience comparing their support for Windows versus their own UNIX variant..
I happens with my company. I work for Charter Communications Inc. and we are a huge NT and Cisco shop and when we want a fix for a problem that's the fault of the vendor such as Microsoft, they give us a custom solution within hours of the problem. That's called Enterprise support.
First:
The question was not how badly other vendors support their products - it was how to get support for Linux in enterprise environments.
Second:
You comment was based on an EULA, an "End-User License Agreement". Was the question about end users? No, it was about enterprise. Microsoft and other provide a LOT of support for enterprises(sure, it costs, but it's available).
This are very different when you're a big business, especially when you're buying in volume. Having worked for Ontario Hydro, I know that many vendors fall over themselves trying to help the big companies. Once there was a problem, and we called our support number(which no other company had - it was ours), and MS had a tech out in two hours. She arrived at three AM, and had the problem fixed by eight AM.
Go get a life.
Dave
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
My employer is about 4,000 seats, 30+ NT servers and 80-ish Unix servers, and I've never heard of us being personally responsible for the generation of an actual OS code patch via complaint. (Of any OS; we've been through a good four Unixes and all the MS OS products.)
We're in the same "if many people complain, a patch will come in a matter of months" bin as Mom & Pop companies.
The real need for an OS patch is rare; the vast majority of support requirements are for parameters, tweaks, workarounds, etc...how you *ask* the OS to do something, not changes to what it does.
Direct vendor support is needed for that with closed products because only they can understand how it really responds to user stimuli. But with open products, "all"(?) you need is a really, really savvy consultant who knows the code down deep.
There's nothing magic about the support staff of vendors, they aren't god. They're working stiffs who mostly inherit code and can generally figure out problems and produce patches after they've been working with it a few years.
With open products, *anybody* can do this.
So the real question here, is "what's the market availability in really, really savvy Linux consultants"? Because anyone who is, can do anything for you that a vendor support team can do.
And any company serving 10,000 seats can definitely afford $100K/year plus to have such a consultant on retainer.
Big businesses like accountability, someone they can point a finger at and say 'Make it work'.
IBM, or RedHat, or VA Linux, or dozens of other companies will support linux and fix problems for you, allowing you to hold them accountable.
I still think this is a straw argument - You can CHOOSE anyone in the world, and they would have source code access that allows the fixing of ANY bug. That will NEVER work with a closed source vendor.
Actually you are wrong. The poster of the "Ask Slashdot" is asking about Support Contacts which a number of Linux vendors provide as opposed to Warranty which no software vendor provides whether it is Open or Closed source.
Enterprise support is usually provided by third parties as opposed to the actual OS vendor, for instance there is a sizable list of companies that provide support contracts for Microsoft software. Then again some companies like Sun provide their own enterprise support contracts which happens to be one of the largest support service providers in the industry.
As for the Ask Slashdot, here's a list of companies that provide Enterprise support.
- Caldera Systems, Inc.
- Red Hat
- Rebel.com
I'm sure there are a bunch of others but these are the ones I know off the top of my head.Grabel's Law
It is not, however, an enterprise class O/S. Want a kernel debugger? Well, there's a patch that might be up to date. Want to profile the kernel to debug the slowdowns in your 8-way profusion database server? Good luck if you don't have a kernel developer on your staff (and those are reasonably difficult for your average website to find and employ).
And Linus will never allow this kind of "cruft" into his kernel. His opinion is that there should be a high bar of standard for people who want to hack on his kernel. He's not going to make it any easier for very advanced system admins who want a kernel debugger, crash dump analysis and better ways out of the box to profile the kernel. (Read the linux-kernel mailing list if you'd like to -- Linus has said as much).
None of this goes over well with businesses, at least not for the Enterprise server market. It may be more than adequate for the desktop though (who cares about profiling a kernel sitting on a desktop?). So, if you'd really like to face reality, Linux is the Win98 of Unix OSen. And Linus is trying to keep his kernel that way. The only alternative is to fork the damn thing and its way overdue for Linux distros and companies like SGI and IBM that have some Linux investment to go ahead and do so.
try it, it won't. o it boots, but stability is not there. o microsquish will tell you it works, but sorry, after a number of different machines, all with different ram, all with differnt processors, all with different mobos, all built with legal m$ distribution. it doesn't work. o yes, and by the way, did i mention that windows me, windows 98 and windows 95 don't work with more than 511 megs of memory. if you believe everything they say, i guess you are being part of the problem, not part of the solution. its not fud its reality.
o yes, i went through all of the windoze knowledge base. one solution proposed was to have less than 512 megs of memory in your machine. quite a solution to the problem really, i think it would be most effective.
There is enterprise and there is enterprise. If you are Ford or Merk or some similar, even Billy will dance the jig for you. Money talks. Try to get the support you just mentioned if you are a 25 person enterprise or a 10 person enterprise. My usual experience is that you will get the go fly a kite response and be passed down to someone who can barely find the rest room on their best days. Supportability is a valid issue, but after running computers since the days of vacuum tubes, just putting up a good front isn't support, its dishonesty.
The OSS business model IS different from what you see in the old marketing books. Any economic theory makes assumptions, and when those assumptions fail, the theory fails. When something that is taken for granted (like the ability to sell the product, for example) is suddenly removed, you place a big fat '0' in front of one of the variables that previously had a rather important coefficient. Other variables with previously negligible coefficients start becoming very important, and thus you have a model that does not conform to the traditional ones in your old marketing textbook.
WARNING: there is a trojan on your
No, you can't order around people who are under no obligation to you. Neither can you order around Microsoft, Oracle, or a lot of other large vendors, unless you're quite the Big Business indeed. So how is this different from saying, "there no fix for the problem yet, but it's expected in the next service pack"?
A lot of Free and/or Open Source software seems to be less buggy than their commercial counterparts in the first place. And you have the choice to fix it yourself, or hire someone (perhaps the authors) to do so in a timely fashion. If neither of these factors satisfies you, or applies in your case, buy the commercial alternative. But don't delude yourself. As MacArthur said, "There is no security on this earth. There is only opportunity."
"The best we can hope for concerning the people at large is that they be properly armed." - Alexander Hamilton
Since the code is open source, when something does go wrong your staff can fix it. When was the last time you heard of a 90,000 seat MS-Deployment where the customer was able to tell the vendor "We've got an MS-Problem, and we'd like it fixed," only to hear the MS-Vendor say "Sure, we'll get our MS-Staff right on it!"
I can tell you right now everything that goes wrong will have to be handled by the in-house staff. They might just take care of it themselves, or perhaps they'll try to contact the developers themselves, but ultimately it's the in-house IT guys that have to handle it.
:) - and it benefits the companies too (and no, I'm not willing to explain how that is - post another "ask slashdot" question if you want to know).
Now considering that most enterprise Linux systems are running daemons such as Apache and SSH, I don't think it's a big problem. When something arises, they IT folks would just fix the way the programs run, and if they can't...well we can all hunt down the people in charge of Apache and SSH pretty darned fast.
Enterprise Linux systems, however, are also used as workstations and storage systems. For the storage system, all you need is to assign some lowly person and teach them the chmod and chown commands. For workstations, I'm going to assume that many partitions will be networked (/usr, etc.), and the company will have more IT people to linger around and fix up problems on the workstations. I'm not going to get into the details of shared systems, but it's most likely that you'll see it set up like that.
So to sum it all up, the open-source model will (and does) work in enterprises, especially the USS Enterprise
Want good Xmas music? Look for Manheim Steamroller!
SIG: HUP
To continue business operations, the software needs to get fixed as quickly as possible. And having the sources to the application gives a company the best chance of doing that as quickly as possible: they can contract out support, hire consultants, or develop the in-house expertise.
Besides, unlike hardware, software doesn't just usually wear out and go bad. Almost always, serious software problems are triggered by an insufficiently tested upgrade or by an untested change in business procedures. And as a stop-gap measure, it's usually feasible to undo whatever was done.
Problem size or volume can also get too large for software to handle. That's a specification, testing, and sizing problem, not a software bug, and closed-source vendors won't help with that either other than by selling more, more expensive software and hardware.
The main class of unexpected bugs that occur is security problems, and the record of open source software is considerably better of fixes than for proprietary, closed-source software. And with the closed-source software, nobody can even review the bug fix to make sure it doesn't cause more problems.
I used to work with a company that dealt with POS etc, mainly running on SCO. SCO are like any big company, pretty slow with getting fixes out. The companies that made the software that ran on top (POS, Inventory, stuff like that) were usually small companies dealing in specialised markets. While the software was proprietary, the main selling point was the support contract and they were usually pretty quick with fixes.
However they could only fix their own software. Probs with the OS had to go back to SCO.
How would they deal with Open Source? They would be much better off. Rather than having to run to SCO for fixes, they would be able to fully support the operating system as well as the software that runs on top.
--
enterfornone - logging in for a change
Let's see. Depending on who you want to sell on the issue, we certainly have the big boys. IBM , HP and quite likely Compaq (the TrueUnix/VMS folks, not the crappy box assemblers) can quite likely deliver expensive support and professional Linux services. Of course it's up to you to determine the quality. But you also have to do that when EDS is shipping 10 of their clones with bad haircuts to you.
Then there are specialized companies whose most prominent representation is probably Linuxcare.
Finally and - in my experience most importantly there are the distributers who base their business model basically on services. I had outstanding experiences with SuSE (American site) which guided me through struggles getting X up on my notebook. They made a very idealistic, determined and goal oriented impression and delivered far better support then what I've seen with companies that charge $1/4 million a year (and that was the free issue installation support). They run a professional services department and they have various support plans including 24/7 - and dedicated resource plans. Pricing looks quite reasonable.
I can't vouch for Red Hat, Mandrake , or Caldera, but at least Red Hat has a good reputation.
So, here we go. There's a lot around to chose from and compare. If the gentlemen in the suits insist on an IBMHPSUNDEC rubber stamp, here you go and you probably pay for it through your nose. Not that the distributers quite give away theire services, but from what I've seen there seems to be excellent value there.
ich bin der musikant
mit taschenrechner in der hand
kraftwerk
Now, the only way we are going to get such a large Linux company that the corps feel they can trust to fix their problems is if Red Hat, SuSE, Caldera, Corel etc become one. Divided, they are small and weak. Together they are strong. I see this fate as being inevitable, anyway. It is the due process of capitalism. I expect that in ten years, after a struggle between these companies involving bankruptcies, mergers and hostile takeovers there shall emerge one true Linux company, if you like a MS of the Linux world, without quite the same stifling power. Only then will corps be able to make large scale deployments of Linux with the proper assurance and support.
Debian will survive, of course. It shall remain the hobbyists distro. But the commercial companies will be (and are) at each others throats.
KTB:Lover, Poet, Artiste, Aesthete, Programmer.
KTB:Lover, Poet, Artiste, Aesthete, Programmer.
There is no
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.
--
- 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.<picardmaneuver> Actually, they just need to say 'Make it so.' </picardmaneuver>
"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
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.
-- Don't Tase me, bro!
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.
--
The unsig!
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.
Enjoy your job, make lots of money, work within the law. Choose any two.