Slashdot Mirror


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?

42 of 152 comments (clear)

  1. Fix the problem, not the blame by The+Man · · Score: 2
    Who gives a rat's ass whose fault a problem is? Assigning blame doesn't get it fixed any faster. Yes, it's nice to be able to tell your boss that the problem is an OS bug or an app bug or in some way a bug that wasn't your fault. But that still doesn't fix it. To get your operation back up and running as quickly as possible, you need two things:
    1. The source to the faulty software, and
    2. A person or small team with good debugging skills and knowledge of the software you use

    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.

    1. Re:Fix the problem, not the blame by swb · · Score: 2

      Well, think of it this way - do problems get fixed faster (in the complete absence of such an inhouse team) using Free or binary-only software?

      Depends on the problems, I guess. I've had problems in the past with OSS software that were fairly site specific and trying to get the attention of OSS developers is hard enough; unless you're on the "A" list of Open Source gurus a lot of the time you get totally ignored or you get "fix the source yourself".

      The value of pay software (and I'll readily admit, it often means paying beyond just purchase price) is that when it doesn't work the obligation to fix it is well understood by both sides. The obligation to fix open source software just isn't there except for more obvious bugs in larger, more high-profile projects.

      My overall solution is to generally stay comfortably away from the bleeding edge. The bugs are generally gone and the solutions usually pretty well known. The only downside to this is that high level interoperability and modern drivers often hover closer to the bleeding edge than I'd care for.

  2. One other comment by Amphigory · · Score: 2
    I see others have covered the standard "support doesn't help" and "you can't sue anyway" responses.

    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.
  3. Open Source Reality vs. Business Reality by the+red+pen · · Score: 2
    As many posters have noted, the short answer to this question is "yes" Open Source OS's are viable in the enterprise environment (and more so every day).

    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).

  4. Re:Fixed in the next realease (like Windoze maybe? by Malor · · Score: 2

    "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

  5. Stop smoking drain cleaner by gelfling · · Score: 2

    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?

  6. so use certified solutions by scrytch · · Score: 2

    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.
  7. Re:I would say 'not yet' by scrytch · · Score: 2

    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.
  8. Re:Interesting problem by scrytch · · Score: 2

    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.
  9. Re:Support? We don't need no steenkin' support! by scrytch · · Score: 2

    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.
  10. With Linux, you have the source code. by crovira · · Score: 2

    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.
  11. My company's experience with Microsoft by kinkie · · Score: 2

    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).

    --
    /kinkie
  12. Re:Pointing does nothing. by Black+Parrot · · Score: 2

    > 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
  13. Re:I would say 'not yet' by mistered · · Score: 2
    IBM shall always primarily be a hardware company.

    From IBM's latest annual report, percentage of revenue by category:

    ............... 1999 1998 1997
    ____________________________________________
    Hardware....... 42.3 43.4 46.7
    Global Services 36.7 35.4 32.1
    Software....... 14.5 14.5 14.2

    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.
  14. Re:I would say 'not yet' by mistered · · Score: 2

    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.
  15. Re:SOS by Peter+H.S. · · Score: 2

    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.)

  16. Re:I would say 'not yet' by chazR · · Score: 2
    We shall never see nationwide installations of Linux in the 10k + range until there is a very large Linux company.



    Is IBM large enough for you?

  17. Why this is really important... by weave · · Score: 2
    First off, Linux isn't there yet, and neither is Microsoft. Hear me out please...

    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..

  18. Re:What on earth are you talking about? by CmdData · · Score: 2

    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.

  19. Re:Ever read a EULA? by dbarclay10 · · Score: 2

    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.)
  20. What size of "enterprise" you talking about? by rbrander · · Score: 2
    As others have said, certainly no minor customer of MS,Sun, or Oracle is actually going to get them to examine source code, write a patch, and send it to you. That's strictly for places with 10,000 seats and up.

    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.

  21. Accountability by blakestah · · Score: 2

    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.

  22. Support Contracts Aren't Warranty by Carnage4Life · · Score: 2
    This is the classic "who do I sue when Linux blows up?" fallacy.

    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.
    1. Caldera Systems, Inc.
    2. Red Hat
    3. 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
  23. Holding Linus Responsible... by lamontg · · Score: 2
    Its actually pretty much impossible to get Linus to do something that he doesn't want to. Linus has control over the Linux source and has a singular vision. And largely Linus is a software developer who cares about engineering the core of the O/S to be fast and efficient and teaching himself O/S design as he goes along. Linux really is Linus' summer project run out of control.

    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.

  24. Re:Fixed in the next realease (like Windoze maybe? by HiyaPower · · Score: 2

    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.

  25. Re:Fixed in the next realease (like Windoze maybe? by HiyaPower · · Score: 2

    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.

  26. Re:Ever read a EULA? by HiyaPower · · Score: 2

    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.

  27. Re:I would say 'not yet' by ca1v1n · · Score: 2

    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.

  28. Again? by Skald · · Score: 2
    Come on! The "Whom do we sue?" line of FUD is a particularly tired one. You must make choices in life, and none of them are safe.

    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

  29. Re:Ebay example by nick_danger · · Score: 2
    The bottom line is that you've got to have your own staff to support your machines.

    [And for a 90,000 seat deployment, you're a fool if you don't have your own staff to support it]

    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!"

  30. As a sys-admin... by autocracy · · Score: 2

    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.

    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 :) - 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).

    Want good Xmas music? Look for Manheim Steamroller!

    --
    SIG: HUP
  31. finger pointing and suits won't help the company by q000921 · · Score: 2
    While it may be nice for a mid-level manager to be able to point the finger for a software problem and for the company to be able to blame a vendor when the stock holders get annoyed, none of that helps the company's business. It doesn't recover any significant damages (EULA/UCITA...), and it won't get the software fixed.

    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.

  32. My experience by enterfornone · · Score: 3

    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
  33. Ready? You bet by CaptainZapp · · Score: 3
    Being in consulting for quite some time and being inevitably part-time abused for support issues I've seen both sides of the medal. I truely believe Linux support at this time is as good as it gets.

    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

  34. I would say 'not yet' by Kiss+the+Blade · · Score: 3
    The Linux model is not a good vehicle for big business because the usenet model of support only works for a couple of dozen computers. We shall never see nationwide installations of Linux in the 10k + range until there is a very large Linux company.

    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

  35. Turn to the vendor? Not as useful as you think by Tony+Shepps · · Score: 4
    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.
    --

  36. Fixed in the next realease (like Windoze maybe?) by HiyaPower · · Score: 4
    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.
  37. For the Enterprise? by Brian+Kendig · · Score: 5
    ... someone they can point a finger at and say 'Make it work'.

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

  38. Obtaining support from commercial vendors (???) by sphealey · · Score: 5

    "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

  39. Ebay example by Col.+Klink+(retired) · · Score: 5

    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!

  40. Ever read a EULA? by jcostom · · Score: 5
    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.
    --

    --

    The unsig!
  41. Turn to yourself for fixes. by mistered · · Score: 5
    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.

    --
    Enjoy your job, make lots of money, work within the law. Choose any two.