Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Linux Business

Linux Support For The Enterprise? 152

Posted by Cliff from the where-can-you-go-for-'accountability' dept.
[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?
This discussion has been archived. No new comments can be posted.

Linux Support for the Enterprise? More

Linux Support for the Enterprise?

Comments Filter:

  • Picard maneuver actually works! (Score:1)

    by Anonymous Coward
    Believe it or not, but that actually works.

    I manage a group of 10 techies who from time to time come to me with their problems and solutions. In the beginning I had to tell them: "No, don't give me problems. Give me solutions", but now they've learnt not to approach me unless they've got a solution at hand.

    After hearing them out, I usually say: "Make it so" and get back to playing Solitaire in my office.

    The best part is that if everything works out ok, I get the credit for making the decision, but if it doesn't I can blame all failures on them for providing me with bad information. Great!

  • Many smaller businesses can barely afford an in-house guy who can setup Windows.

    If you can't afford a technical staff (of size appropriate to the size of your infrastructure) to manage your systems then you cannot afford the systems. TCO was a buzzword, but the concept is 100% sound - the maintenance and administration costs are part of the machines and are not optional.

    If an inhouse open-source programming team is considered essential then I guess I can't use open source.

    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? It's a legitimate question; I suspect it strongly depends on the specifics of the software in question. There are very responsive and very unresponsive maintainers in both camps. So I don't really think the maintenance team is necessary, especially for smaller firms. It's only necessary if your organization can't stand any down time at all. And I suspect that anybody in that position can afford a maintainer or two. Bear in mind that if you go with a proprietary solution you're likely looking at high service contract costs there as well. So I think overall you misinterpreted my assessment; we weren't really talking about smaller companies here anyway.

  • It continues to amaze me that people worry about support for free software. Consider Windows: ultimately, there is only one vendor to get bug fixes, kernel enhancements, etc. from. In the Linux realm, nobody has a monopoly on support. There is a free market, and you can pick the support level that you want.
  • I listened to ESR talk about selling "Open Source" to the organization and that was exactly one of his main points. When you buy from a third party they usually have a contractual responsibility to support the product. But on the flip side, YOUR COMPANY IS HELD HOSTAGE to that third party for bug fixes and support. And we all know that tech companies NEVER go out of business, right? Using Free Software, on the other hand, leaves you many more options, as mentioned by the previous poster.

    So when the next PHB makes a big deal about some vendor having "support", turn around and ask him why he wants the company held hostage to a third party for mission critical software.

    The motivation for the GNU project started when RMS wanted to fix and enhance a printer driver but he was denied access to the source code. So he, and some of the worlds most compotent computer engineers, had to live with it until the vendor made the changes. It happens.

    Don't be fooled with grandiose promises of support. I think we all know what a frustrating experience it can be trying to get "support" for something. While it is true that money talks and the more money your company has invested in the support contract the better service you'll get, it is also true that the more money you invest in the project the less you can afford to not have in house control over the internals.

    For an interesting essay on the economics of "Open Source" software read ESR's "The Magic Cauldron".

    http://www.tuxedo.org/~esr/writings/magic-cauldron /magic-cauldron.html [tuxedo.org]

    -Derek
  • ...Data General, now EMC,...

    ... what will they be tommorrow? Next year? Will they always be around? If not, will you have enough warning to migrate your mission critical system to something else? Probably.

    The point is, you're dependent on DG. They may have great support now, but will they always? Don't get to comfortable while your mission critical stuff is 100% dependent on a third party for support.

    -Derek

  • The FreeBSD Project (http://www.FreeBSD.org/ [freebsd.org]) has at least 20 kernel programmers who usually jump at the chance to work with small and large companies to address bugs and scalability issues with FreeBSD.

    We've worked with Hotmail, Yahoo and many more. Since each committer has access and the ability to modify the system, companies that choose to contact a FreeBSD developer can sometimes have thier fix in the base system in a matter of hours.

    Most will do it for free, but all probably would appreciate some sort of hardware or beer donation.

    --

  • The LCARS [themes.org] e-theme would help with interoperability at the UI level at least.
  • Retail is a nice space for support, in general, because it tends to be a replicated site environment (aka branch automation). Like banks and companies with lots of branch offices, these sites tend to be largely the same. This makes support much easier, since you're effectively support one (or a few) configurations of hardware. Retailers, as a general rule, are cheap^H^H^H^H^H thrifty. That means staying on the same platform for as long as they can get away with it. The cost savings in using Linux can be applied in several ways:
    • Better, more reliable hardware
    • Enterprise support contracts from 3rd parties
    • Hiring internal support people
    • Training for your in-house developers/admins, etc.
    The latter two can be especially positive. I recommend that companies request training as part of the support agreements, so that they can handle the small stuff internally.

    I'll mention that I work for a large (Fortune 500) retailer who has had a support contract for over a year with a Linux distribution company located on the East Coast near several universities known for good basketball, and I've had excellent support from them so far, though, admittedly, we haven't had any real problems so far.

    I'll also mention that in past years I have had a bug in a *nix flavor that severely impacted my company's ability to do business - such that there are things that we *really* pay attention to in support contracts, such as explicit problem escalation chains, problem acknowledgement times, etc.

  • Not true, at all. Look at the list of companies that the distributions are currently handling for support. Look at the list of companies that other support companies such as Linuxcare is handling. These guys are helping IBM, Motorola... BIG companies. Ask them about the retailers that they are supporting NOW.

    You are confusing the number of computers with the complexity of support. Retail (in particular) is a much easier problem in many respects than desktop support, in that it tends to be a very controlled environment. Retailers, as a general rule, don't let employees change the machines running in their stores, especially their servers.

    Finally, who said anything about a usenet model of support? I pay for Linux support and I have a single named contact; anyway, getting the answer from the net is the support company's problem (should it fall to that, and I sincerely doubt it will), not mine.

  • That's funny.... when I had my support person out to my site, which he is required as part my support contract to do twice a year, he didn't appear to be a pimply faced guy. Wrong again, troll.
  • I don't know if it was in fact due to CPUs, but Sun had had patches available for 6 month prior to the incident. The incompetent sysadmin(s) never bothered to install them.
    ___
  • There was a story on /. about this. A large manufacturing company deployed some software that didn't work and caused them millions of dollars in damages. They took the software company to court, but lost -- the court upheld the EULA. Now wait till UCITA gets passed. Accountability will not even be a question, since it is explicitly disclaimed in EULA.
    ___

  • [I would have moderated Blade's post [slashdot.org] as(+3, Flamebait Deluxe). It is irresistible!]

    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.

    The problem is not the model of support, as you allege, but the priorities of management. You may be correct in suggesting that more companies would consider deploying Linux if there were a dominant distribution with "stifling power", but this just means that IT managers are concerned about the wrong things. IT departments ought ideally to exist for the purpose of creating and maintaining their organization's IT infrastructure (regardless of whether these arise from vendor ineptitude or unorthodox requirements in the organization) -- and not for the purpose of coordinating foreign intervention (i.e., yelling at vendors and hiring consultants) when problems arise.

    A small development team can still hope to craft a custom GNU/Linux system with long-term value that addresses the organization's needs precisely because GNU/Linux development is fragmented (which means that sources remain accessible in every respect) and because there is not a dominant player (which means that the evolution of the system is still reasonably transparent). Consider, for example, the Linux deployment by Lans Carstensen's team at the Dreamworks animation studio.

    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.

    If a company with expansive resources such as you seem to advocate should emerge, it could (according to Eric Raymond's analysis [tuxedo.org]) assert effective ownership of parts of GNU/Linux simply becoming the maintainer or primary developer of those parts. Consider, for example, the case of Red Hat, who keep various Linux, GCC, and GNOME developers on payroll. If such a company then chose to release new versions of free software only in conjunction with a new distribution (thus diminishing availability, accessibility) and without coordinating its efforts with other developers (thus diminishing transparency of the evolution of the software), the aforementioned virtues of GNU/Linux would be in doubt (regardless of whether the company did this maliciously) and many would find good reason to choose a different platform.

    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.

    Gosh, I hope you are wrong about there being only one "Linux company" but I know you are wrong to claim that such a company would be less stifling. And, now, repeat after me: diversity, distributedness, and transparency are good. :) A single, almighty "Linux company" is not likely to give you any of those things.

    Only then will corps be able to make large scale deployments of Linux with the proper assurance and support.

    The fact that some people think that Linux is a poor choice because it is fragmented is a good indication of just how perverse the mainstream IT perspective is. I hope I live to see the day in which avoiding responsibility gives way to meeting requirements as the modus operandi of technology managers in every company.

  • The size of the contract determines the response time. My employers are no different from anmybody else in that respect. Its not the squeakyness of the wheel, its the size of the wheel.

    Its called market responsiveness and if you're a small fry, your problems keep getting pushed to the end of the queue until it gets relegated to the next release. If your problem was crucial to you, you might have ceased to exist before the software publisher ever get around to it.
  • I used to work for a large regional bank, the then Portland, Oregon based US Bank. In the branch system alone we had 600+ locations each with a server and between four and tweleve workstations. In the back office we had thousands more desktop and server PCs all purchased from two of the Teir 1 PC vendor.

    What happened when the preferred PC desktop vendor changed their keyboard BIOS and broke an in house application? (The keyboard no longer reported shift/alt/ctrl status of F11 and F12.)

    1) They denied that anything changed.
    2) They requested that we send the program we used to read keystrokes.
    3) They then asked us to send one of the computers. It seems that the support lab didn't have any workstations that new.
    4) They reported that their computer worked the same and clones and another tier 1 vendor.

    My reply at this point was "We haven't been spending over a million on year for the last four years on clones or your competitor. We've spent the money with you. You changed the behavior of your hardware and we are requesting that you maintain compatibility - correct behaviour at that - with the millions of dollars of computers we have purchased in the past and intend to purchase in the future."

    I then went to our sales rep with this story. He doubled checked with the tech support people. Then he pushed through getting our issue escalated to engineering. They had a patch for us a week later.

    All in all this process took about three months.

    Someone to point a finger at? Get a Grip! What color is the sky in your reality? If you sincerely believe that purchasing from a major manufacturer has a benefit because you can lean on them you have a bright future in management. Major manufacturers will stonewall even their largest customers. Getting past the support channel to the engineering channel is a nightmare. You are much better off with open source - where you can fix it yourself or deal with reasonable human beings that take pride in what they do and don't hide behind layers of beauracy.

    Sorry about the rant. This is a pet peeve.

  • Who gives a rat's ass whose fault a problem is?

    Nontechnical management?

    A business of 500-1000 people that doesn't have the resources to keep and pay a full-time programmer with the ability to make serious modification and debugging of kernel/driver source code. And when you're planning a major infrastructure system you don't just get to go out and spend money. You have to develop a plan and present it to management. One of the first things MY management asks is "What do we do when it doesn't work right?"

    The best way to get (2) is to hire an appropriate number of experienced systems administrators and Free Software developers to your internal staff.

    I agree its the best way, but its not a possibility for most businesses. Many smaller businesses can barely afford an in-house guy who can setup Windows. If an inhouse open-source programming team is considered essential then I guess I can't use open source.
  • It's really the only way to get something like this to work. Windows has made it to where it is becouse I can go to any Winbox and know that there is a registry in the \windows directory. I know that hitting the "start" button will bring up the menu, etc.

    With Linux, I can roll out and maintain (with a team) an enterprise of RedHat boxen. I can keep it going for years. Then I decide to leave that company and go elsewhere. The next place I go has an enterprise of Debian boxen. Well, now I have to spend time learning how the Debian system works. The basics are all the same, true, but the specifics are different. And then what about the previous admin? Did he document all the little things that he modified to get things working?

    The flexibility of Linux is it's greatest strength and it's greatest weakness. If the major distributors can get together and come up with basic standards, if Gnome and KDE can bring us consistant menu options, and we (the user base) can stop bashing each others distros, I think we have something that we can move into enterprise wide situations.
  • You miss the point of what I was saying. I am not saying that I roll out RedHat then change to Debian. I mean that if I roll out RedHat at my current empolyer, then change jobs to a place that uses Debian. That is when the lack of standards comes into play.

  • Some person who likes being abused wrote:
    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.'

    That is just too stupid for words. What's the matter with that given people all the time tell their managers 'there's no fix for the problem yet, but it's expected in the next service pack.' OR 'there's no fix for the problem yet, but it's expected in the next [insert patch method of favorite OS here].'?????????????

  • You can't necessarily get free support but you can hire any competent software developer or company and they can fix it because they have the source and some level of support from the internet.


    If you buy something from a closed source vendor and they decide it's not in their interest to sort out your problem, you have no alternative ay any price.

  • Although IBM supports Linux, it is not really a Linux company. It is not publicising greatly its Linux capacity, probably because it does not have that great a Linux capacity anyway.

    IBM has placed full page ads in USA Today advertising Linux. On top of that they want Linux to run on every type of hardware they provide. I'd say that IBM is pretty firmly committed behind Linux, I can only imagine they have a decent capacity, and they certainly do seem to be publicizing it.
  • Commuting to the Enterprise involves catching an arrestor cable, and a catapult launch in the evening.
  • If you've got 90,000 computers (or 900) you're not going to depend on Usenet. You hire some in-house staff, and you also buy a support contract so you also have access to a wider pool of expertise.

    I've used many operating systems. With SCO Xenix and Microsoft Windows, all you could do was report a bug and hope they eventually fixed it. With CDC Kronos and Linux, you at least have the source and have the option to throw resources at the problem and try to fix it yourself (whether the "resources" are in-house or external). [Well, with Xenix you also could work around some non-OS system problems by replacing system programs such as getty]

  • ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
    Looks normal for first IDE controller.
    Should also show:
    hda: whatever is the master
    hdb: whatever is the slave

    ide0 at 0x14c0-0x14c7,0x14b6 on irq 11
    Looks VERY STRANGE.
    Expect something like
    ide1 at 0x170-0x177,0x376 on irq 15
    Use Windows to see what the hardware is.

  • If Bill Gates is not responsible for supporting windows why should Linus? Has anybody ever sued Microsoft for faulty software? did they win? Has anybody ever sued MS for lame support? Did they win?

    Will microsoft come over to my business like it came over to yours well considering that they don't even return calls I'd say no.

    If you are large company you can get support for anything.
  • Unix has a slew of tools to update thousands of PCs. You can start here to start on the free ones. Of course CA, IBM etc also have proprietary ones too. There are also a bunch of tools like network shell which allow you to write perl scripts to manipulate millions of machines if you got the time and bandwidth. Unix has always been in the forefront of distibuted and remote management.

    If you are large company MS will let you yell at them but you gotta be HUGE. Anything under 10K employees and MS will screw you blind if you try to mess with it. Go ahead Mr CIO and yell at MS you'll see how fast a legal team from MS will decend on you to audit your licenses.
  • Probably the best and most natural solution is to have at least one *nix guru on staff (or at least on call). I'm sure there are tons of qualified people out there who are looking for this exact job, plus it would probably be cheaper than going to another business for support.
  • MS isn't giving you code level patches to the OS in just a few hours, and probably not even any at all. What they will do, is offer a workaround, or stopgap, until the next service pack or revision.

    Dave
  • The eBay issue was due to Sun CPUs in the E10k that drives the backend, not software. It was hard to reproduce, that's why they had such a hard time finding it.

    Dave
  • Points all well taken and I agree. That's why I moved to Intel-based servers which I can always re-format and lay down whatever I want on them. The other big piece is the SAN technology.

    Even worse case, they go out of business (EMC is making money hand over fist though), there will always be a resellers market. By the time this might get to a point where it's a concern, they'll be something much better out there...

    I can't worry about who goes out of business or gets bought out. Looking back to the mid-80s, who would have ever guessed that some new just-an-IBM-PC-clone company (Compaq) would buy out the world's second largest (at the time) computer company (Digital) (and get their class A block in the process :).

    In reality, all of this could be done in-house using spare parts and internal knowledge. But in the real world where each additional employee holds future liabilities to a firm, often contractual money expenditures are preferred while internal staff get diverted to work on the stupid pet projects of someone else internally...

  • ...off this broken record.

    I used to work as a sysadmin and now run an ASP service, here's some thoughts from the trenches:

    1. Just because you have a support contract for closed source doesn't mean things will get fixed. It means you can call the vendor and ask for help, and they may or may not prioritize a fix. Mostly, these support contracts are only good for having them explain stuff YOU don't understand, or help you work a problem that's particular to YOUR configuration.

    2. Just because you have a support contract doesn't make things get fixed faster. I once found a DNS resolver bug in the HP-UX kernel which I could have fixed in 20 minutes given the source (it was one of those where the problem is totally obvious from the behvaiour), but it took three weeks to escalate it through HP's official support system and get a patch. Eventually, I got the developer on the end of the line and explained it to him, and it was fixed in 3 minutes. This was as a large enerprise customer, and I wouldn't characterise it as a bad support experience, it's just the way the world works.

    There is a bug in Word 97 (original and SR-1) whereby it doesn't use the standard filename handling library which the rest of MS-Office does and therefore can mess up UNC filenames which map to NFS or Novell IPX mounts. I was (I believe) one of the first customers to report this in the context of NFS, once again as a corporate client with 10k+ Windows dekstops, and although the level 1 people didn't find it in their database (it was listed as a Novell-specific issue) the support response from MS was excellent (escalated to Redmond in a couple of days) - they eventually gave me a workaround using a (then) undocumented registry setting. Had I had the source, I could have just browsed through and seen the code to use that setting, easy fix, no code to write.

    Eventually, of course, we solved the problem permanently by switching from NFS on the Windows side to Samba on the server side.

    3. Just because you have a support contract doesn't mean you have someone to sue. Look at the number of successful lawsuits against software vendors / support vendors for bugs. There are almost none. The only thing the support people are required to do is make a reasonable effort, and sometimes, that doesn't run to fixing the particular bug that upsets your installation and no-one else's (if it was a more widespread problem, they'd have caught it in QA).

    4. The best support, for open or closed source products, comes from your peers - other sysadmins at other shops who are customers of the same vendor.

    Even at the client level, where does the bulk of hours spent on Windows 98 support come from? Not from MS or Dell; it comes from neighbours, friends, nephews, etc. That's part of the secret to MS's success, they have over 10m unpaid part-time support people in the USA alone.

    If you have any in house expertise at all, open source is far preferable, because you have the ultimate resort of debugging it / fixing it yourself. In all the time I have been using them in a business environment, I have never patched a single line of code in either Linux or FreeBSD's kernels, but I have in many applications, both proprietary (where I have obtained source as part of the license agreement) and pulbic domain open source.

    In the proprietary case, I have rarely had time to work a bug myself, but I have had vendors provide me with 3 or 4 line patches over the phone which I could simply apply myself and then run make, much more expedient than a patch or point release.

    In our ASP production environment, the only infrastructure pieces we DON'T have source code to are the back end DB platform (Solaris and Oracle). They are both products which are very mature and stable, and we're not pushing the envelope of either system, so I have little fear. We are OTOH pushing the envelope with Apache JServ, and I have taken the opportunity to rummage in the source on more than one occasion to understand what's under the hood, though I have yet to touch it myself.

    In summary:

    • The theory that you'll end up patching source yourself is pretty thin, but you may well end up looking at it, and it can be damn useful.

    • Just as with software, free informal support like Usenet and mailing lists is often more useful than the kind you pay big $$$ for.

    • The quality of support at a pragmatic level depends more on the popularity of the product than it's development and licensing model. A fix is a fix whether it comes from Usenet or a vendor.

    • The sole difference between open and closed source from a support perspective is that you have the added benefit in the former case of having the source; the idea that closed source is somehow better supported because there is a formalised corporate structure around ownership of the IP is totally nuts.

  • Kiss the Blade wrote:
    You appear to be asking for the impossible. If Linux is to be successful, it will have to change to fit the pressures of the real world, nomatter how flawed the real world is. You appear to be asking for the real world to change its ways to fit Linux. Such an arrogant attitude will only cause Linux's downfall.

    The Linux community needs to ask "Why is Microsoft so successful?" and then try to emulate those aspects of Microsofts business strategies that do so.

    I suppose that 20 years ago, you would have been spouting nonsense about asking why IBM was so successful and suggesting that companies like Microsoft attempt to do business the way they did because asking the real world to change was too arrogant an attitude.

    However, the fact of the matter is that the "real world" did change its practices to match the way that Microsoft expected them to do business and they did so because some companies perceived that it was to their advantage to change and those that did not had trouble competing until they, too, adopted those changes.

    Lest you think that was the only time that business practices fundamentally changed as a result of changes in computing technology, the "real world" had changed it's practices about 20 years before that when computers were first introduced to business on a large scale. When the elder Mr. Watson predicted a total world market of a handful of computers, that prediction was based on the assumption that the "real world" would not make changes to the way they did business. It didn't work out that way, now, did it?

    Change happens. The "Linux Community" isn't asking anything of the real world. Instead, it's suggesting that, with some changes to the way they think of computing, people in the real world can get more from their information resources than they do by using an older model. This is what the younger Mr. Watson did with IBM in the 50's and ISV's like Lotus and Microsoft did in the 80's and, historically, it isn't a bad thing to suggest. If, of course, what you're suggesting is truly a better way of doing business.

    Adam Smith may have talked about great fundamental truths of economics, but it's tough to see how Wealth of Nations says that Linux needs to have a big company doing telephone tech support in order to continue to exist.

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

    The irony is that Linux is probably the only system out there where you can actually get some accountability, all because we have the source.

    I've worked with plenty of large software packages from large companies in the past (Ingres, Sybase, Oracle, VMS, various proprietary Unices) and I can say without doubt that the supposed accountability of large software companies is a bad joke. It doesn't exist. I've heard plenty of "that bug is fixed in the next version" out of big companies. I've had plenty of times that tech support very simply couldn't fix the problem. I've had times when they wouldn't admit there was a problem.

    I was up all night with tech support from one major rdbms company on the phone trying to fix a problem, told them to go to bed at 6:00AM and fixed it myself in 4 hours. This isn't unusual. When I was using Ingres heavily years and years ago, I had access to a full support contract with the company, yet most of my "support" came from the newsgroup.

    What does "accountability" really mean? Most of the time you buy software on that scale, you have to sign the license agreement (not a shrinkwrap joke license) that says the software isn't guaranteed to work, there are no warranties, and you agree to indemnify the software company in case of loss. Where in the hell is their "accountability" in that?

    With open source/Free software, you can actually hire someone (like me) who is a "buck stops here" person. I'm confident that if there was a nasty show-stopper bug in Linux or any other piece of software that I use and support, I could either fix it myself or find someone who can. Ironically, the only time I've had trouble is when using older software versions.

    I'm tired of people acting like we have to defend the use of Free software. It's high time that we turn that around and make the other side defend the use of costly proprietary software that comes with no source code, poor support, and a license that removes all accountability from the publisher.

    Michael

  • I know that you can purchase either BSD/OS or FreeBSD from BSDi with support; and customers use both (especially the former, as it's been offered by BSDi [then BSDI] longer) in areas that need even better uptime than cash registers.

    It's easy to find someone to offer you support, but you will need a big name for trust. LinuxCare, LinuxOne, RedHat, I'm sure one of them could offer you what you need. Shop around!

  • That's very true!
    Especially if you are a small bussiness, you are bound to have trouble with support ppl:

    "it doesn't work"
    "yeah, that must be because your implementation sucks"
    "ok, tell me how i could've done it otherwise!"
    "well, we have a complementing product xyz, ..."

  • If someone working for me advanced this argument ie "I want a way to avoid taking responsibility", I would fire them.

    In fifteen years of working in enterprises, I found very few companies actually provide any worthwhile support. IBM is one, but it is one of few. You can get Linux support from IBM I believe.

    Otherwise it is just the usual "retry, reboot, reinstall, upgrade" routine. This is not just from tinpot outfits either. Everyone knows what Microsoft support is like, but they are not unusual in this regard.

    The typical support organisation consists of a call centre staffed by people following scripts, plus a large number of marketing types. Actual people who can help solve your problem are thin on the ground in many cases.

    I am not exaggerating. MSFT spent more money marketing Windows 95 than developing it. Progress Corp spends 250% as much on marketing as on product development.

    Often when you find a problem, the vendor will put out a doc change, saying that you shouldn't do whatever triggered the bug, or in other ways say it is expected behaviour. Then they redefine your bug as an enhancement request. Or they do what MSFT did with multilevel numbering in MS Word 97. Remove the feature and pretend it never existed (I am not talking about multilevel heading numbers).

    Another thing they do is ask 'Is patch X on'. If not, even though it does not look like your problem, the ball is back in your court. Another good ploy is to ask for impossible amounts of diagnostic information. "Delete records from the database until the problem goes away and then send us a dump of that record", for example.

    For hearing this nonsense, you are paying through the nose for a 'support' contract.

    The other thing they do is have very tight upgrade requirements. Older versions are not supported and you are *really* on your own, unless you keep to a breakneck and very expensive upgrade schedule. Up the upgrade creek without the source code, in fact. Upgrading is not a simple matter. You may have a large number of products with complex version interdependencies and OS and hardware dependencies. Sometimes you can't get there from here.

    In a live situation it is almost always up to you to find a workaround or bypass. Stop using certain features, reboot every x hours, simplify the system, filter out errors that cause the software to choke, hone your recovery procedures. Swap out hardware until you find the bad component.

    I have been in the situation more than once where closed source vendors tell you "We can't [or won't] fix it and we won't let you fix it" (by giving you the source code). What do you do then? In my experience someone within the organisation carries the blame. VPs are very uninterested in hearing that xxx Corporation (NASDAQ XXX) is to blame. They want *you* to fix it *now*.

    More than one closed source vendor has gone bankrupt. Then you find they forgot to send the source to the escrow agency. Or they just lose the source code without going bankrupt. Then you get to reverse engineer the file formats, which is tedious after the first few times.

    If they don't go bankrupt they get taken over. Then they jack up the maintenance costs by 375%, or the previously strategic product becomes unsupported, you are frog marched to the Gigantic Software Corporation's often inferior product suite, and all your investment in training and product is wasted. You can't read your old files any more.

    Some things to look for in a support organisation:

    1. A searchable bug and knowledge base.
    2. Access to techos, as opposed to Marketing people. Job titles can help but you need to speak to them.
    3. Knowledgeable, experienced technical support people
    4. Technical support people who are not snowed under. Find out the numbers.
    5. A number you can call at any time and they will answer and be able to get someone to help.
    6. Clear definitions of problem categories and levels and specific service levels for a) restoration of service and b) provision of a fix for the problem for the various categories.

    User groups are very important. Often you will be told "Noone else has this problem so it must be due to something you are doing wrong". Often this is a lie. The vendor must not be able to censor your mailing lists.
  • Let's face reality on this one, as a consultant of enough years I can tell you without equivocation that a closed source solution does not guarentee you can point to them and say "fix it".

    Before you implement ANY system of significant size you test it, you test it, and you test it. You discover through this testing whether the product will do what you want it to. In the case of an open source or closed source project if the functionality and reliability aren't there, you look for another solution.

    I am currently in the process of rolling out a fairly recently released network management tool and have discovered a couple problems our lab and pilot program didn't uncover. Does this mean that the company who I bought it from is going to turn around and fix it for me right now? Most likely, no. Their response is simply "we have reported this issue to engineering" and I'll be forced to wait for a patch, fix, or update. The same holds true for open source. However, I have a much better chance of speaking with the development team under an open source project than I will by calling technical support.
  • Try reading a relatively new Open Source book mentioned in /. recently, "Embracing Insanity". The author quite ably addresses issues concering OS in business including much of the question raised.

    Briefly, with the source open it is much more likely than an employee or a consultant, or some contributor to the project can/will tune/fix the software many times faster and more to the business' specifications than any closed source vendor is likely to respond. With OS the help/support number is the Internet and the development community at large. Best of all, this community is much less vulnerable to simply going away or turning in a direction adverse to the business with the business having no recourse at all after that.

    Also, more and more organizations are providing OS/Linux support services to business. Unlike in the closed source proprietary world, you can pick and choose between service vendors instead of being at the mercy of a single software vendor.

    In short, the problem is largely getting management past its old-style thinking and planning, getting them to see the much more important silver lining in not having their old single "who you gonna call" criteria satisfied.

    Similar points are made in the book about other things that management will need to get used to with OS that violate current assumptions.
  • And if those 90k terminals are running any other thing, what do you say? There's no fix yet, but the next version of windows which should be out sometime in the next 5 years should fix the problem...

    This is a question that in todays software environment simply doesn't have an answer.

    The "who do i sue" question is always nobody, regardless of what model produced the software.
  • 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.'

    Gimme a break - what you should be telling your manager is: "Look here's the problem, and because we have the source, I'll have it working again in a couple hours, and the whole world will have my fix in the next release."

    *I* provide Enterprise-level support for Linux, and you can too. Your boss is NOT beholden to the vendor with Linux - anyone can fix it!

    Tim at LinuxTampa.com [linuxtampa.com]

  • Goatsex be lurking there - DONT CLICK!

    freaking perverts...

  • Thank you very much for your comment. Unfortunately the eeoracle link you provided ends up with a Slashdot error page as if it was discarded by the management..

    And I found no mention of Oracle9i being available for Linux, though perhaps it exists somewhere. 9i has some new clustering and failover capabilities over 8i it seems.

    Hewlett-Packard is providing discount hardware to the startup as part of a special program they have in Japan for selected startups.

    The only good news is that we may end up having it hosted at the provider where the SE went! Thanks for your help.
  • Hope this is not too far off topic.

    I'm a private developer and am also managing a project which is about to purchase a cluster for a venture that expects a great need to scale. But the chief SE (who seems knowledgeable and likes Linux.. but just left the company) thought we should put Windows 2000, instead of Linux, on the HP cluster we are getting. The system will be mainly Apache for the web server and BEA WebLogic for the J2EE app server.

    The main reasons were that Oracle does not guarantee its Linux version, and that while there is clustering for Linux (I had made up a list of info including LVS, Linux-HA, and Convolvo/Kimberlite to consider), database clustering is not ready yet for Linux. While we are probably starting much smaller, his target was a highly redundant system from two routers down to two DB servers for no single point of failure. He said since Solaris is not recommended for HP (the hardware vendor is already set) and Oracle is needed to work well spreading a db across a number of machines, we should go for Win2k. And he is actually a Linux advocate.

    This is not so much a question about human support as a question about the "ready for enterprise scale" and Oracle-related posts here. I suspect the 5 nines redundancy is really more than we need for the project (an online business venture which could grow fast), but would like to recommend Linux for future projects where possible and wonder if it is ready in this area, and where there may be more information about impelementation with case studies. And is it really true that db cluster support is shaky on Linux, and that Oracle doesn't support Linux. It seems believable, but Oracle was pushing Linux pretty hard last time I checked and inability to support multiple database servers would be a problem for them. I'd like to know if there are other database vendors, or other clustering solutions, that would make it safer to host databases on linux.
  • Use the money you save on software liscenses to hire a team to support it. They could be involved in directly fixing any problems found. I would also have them be involved in setup, configuration, and testing of the units.

    The example sited is a great one. You could develop 90,000 units that are identical. This would help making problems easier to solve.
  • I personally work for a company, Linuxgruven [linuxgruven.com] (www.linuxgruven.com) that offers Enterprise Linux Support around the United States. From what our clients have expressed, one thing that makes a difference and helps provide accountability to the management is being able to provide on-site support in a timely manner. Not every Linux support company can do that. A number of our clients have large clusters (>100 nodes) and they want someone on-site ASAP, meaning hours not days. With more than a hundred people spread throughout the country, we make this a reality.

    Also, any company should evaluate a product (i.e. Linux) based on what it can do today and the near term future. If the company that put in those 90,000 POS systems promised them something Linux won't be able to do until kernel 2.6/3.0, then that company is at fault. Unrealistic expectations from ill-used products usually can not be corrected in the support realm. They move to the software development area, where hacking can create what the customer needs. A great example is ImageStream [imagestream-is.com] building enterprise class Linux-based routers.

    I am not solely trying to advocate Linuxgruven but would recommend to IT managers out there to look for this in ANY SUPPORT COMPANY, whether its Linux, Cisco, Microsoft, or any other infrastructure component.

    Neoflux
    email me at matthew@SPAM-sucks.porterhome.com
    remove the SPAM-sucks part
  • Big businesses like accountability, someone they can point a finger at and say 'Make it work'.

    I don't have a copy handy, but every EULA I've ever seen conatains langauge to the effect that "this software is not warranted for suitability for any task". So, unless you pay extra and negotiate carefully, you're on your own even if you pay for proprietary software.
  • You'll go to some agency - web based 'natch - and say "We have problem X and will spend Y to have it fixed by Z." Your s/w agent meets with those of the hackers and one gets selected (somehow) to do the work (or none if you aren't paying enough). Because everyone has access to the infrastructure's source they are in a position to be able to fix problems (if capable, which is why you pay) and a nice, big, fat service market builds itself. To some extent its already happening but the base needs to be a little bigger to support more than the big name OSS celebs.

    One of the benefits of the open-source model is that this marketplace can develop. With proprietary systems you are limited to getting support from the vendor or those blessed by the vendor. You are limited by their schedule and reasoning. If they don't want third parties being able to fix things and want to lock the customer into obtaining things from just them it is all too easy to do.

    And just like non-OSS software if you spend enough you get support. If you need a fix or mod to something you pay someone to do it. Or wait till it get's fixed by some other means. Just the same as with non-OSS but it probably costs less to get OSS modified than special attention from a vendor. And With more accessibility to source the costs should come down however the expertise is what you're paying for. Ever consider how long it takes someone to become adept with the workings of a large program? It's a significant investment in time from usually relatively useful people. This is one of the mistakes non-software people make when thinking about OSS. Just having the code doesn't make it useful, you need to understand it.

  • So when "real money" is at stake, like it was here, how do you explain to the management the benefits of free, available code?

    so what's the problem here? if you're going to get Apache for the enterprise, be sure you get a support contract along with it. for big-business "cheap" is not the driving factor for buying software (and it shouldn't be either). maybe that's why you use BSD or Linux on your home firewall, but big-business will like it for other reasons

    instead of pushing the "cheap" aspect, you should push that you have access to the code! the reason open source works so well is that when there is a problem, you can fix it yourself. big-business will have the resources to make changes to the code, and in the end, it becomes a lot more resource-efficient, and you get exactly what you want, without having to wait for the vendor.

    so if you're going to use Apache (or whatever) in the enterprise, by all means, buy the support contract from somebody out there! then there's the "Apache people" to call, and your business will reap the real rewards of using open sourced software.

    and as a bonus these big companies will effectively make open source profitable, open source will continue, and the rest of us can reap the rewards as well! everybody's happy (well, except maybe Microsoft).

    - j

  • There are several companies out there that offer Linux support. Some companies, like LinuxCare, offer first tier support for desktops and small shops, while others offer second and third tier support. Mission Critical Linux, RedHat, VA Linux, just to name a few, offer enterprise-level support ranging from installation to custom kernel engineering, along with 7/24 support. The old argument agains using Linux in the enterprise was a lack of support and accountability. These days, there is an abundance of support options out there, and the arguments are no longer valid.
  • Good point. I think the answer is:
    1. People posting enterprise questions to /. are just curious about their peers' opinions. The poster is probably not in a position to affect these kinds of decisions.
    2. In the ensuing hubbub, a certain portion of 'enterprise mindset' will trickle down to the /. masses. This can only be a good thing. If awareness of high-end requirements spreads, more software might be written that meets the needs of high-end users.
  • How depressing. I wonder if Red Hat Enterprise Edition for Oracle [slashdot.org] would be applicable? I think that given the context, you may have little choice.
    But why was the hardware platform selected before the OS? I'd say the mainstream recommendation is Solaris/SPARC. Windows, like Linux, is a red-headed stepchild to Oracle, though they won't say that.
    I'm afraid Linux is totally indefensible as an enterprise DB platform for now. It doesn't even show up at tpc [tpc.org].
    I'm sorry to say I predict a lot of pain with your Win2K servers. Maybe the key to keeping them stable is not running any unnecessary apps or scripts on them - use an external Linux box for all cleanup and monitoring tasks. If you experience the growth you're expecting, you'll wish you'd thrown these machines in the dumpster and bought Suns.
  • Sorry about the link. I have no idea what happened. It should have been:
    http://www.redhat.com/products/software/linux/eeor acle/ [redhat.com].
    Is there any chance that HP would help you out with some of their Unix servers? They make a fairly broad range of really solid (but expensive) servers running HP-UX on their PA-RISC chips. Not as much bang for the buck as Intel, but more peace of mind.
  • Bah, that's not what the "Picard Maneuver" refers to. The Picard Maneuver is the act of pulling your shirt/vest down just a tad whenever you stood up. Picard did it quite a fair amount due to his short shirt and tight pants.

  • ...we won't see exploding consoles anymore, due to the stability of linux? :)
  • Why do people post questions to Ask Slashdot on enterprise scale problems? Comeon, what network architect, manager, administrator, whatever, is really going to expect to use good, qualified feedback on slashdot?

    How many people here have even sent a byte of data on an enterprise network? Probably a very small percentage. Lots of people talk out of their ass too.

    There are newsgroups where a higher concentration of experienced, qualified personal are located. Use that. Slashdot is for linux activists, and I know the quality of activist advice.
  • Yes, they can sue. But, pointing that finger won't make the problem go away. At least with open source software, you can develop a solution on your own if the timeline of other developers isn't as fast as you require. With closed source, you have to wait until they even acknowledge there is a problem.
  • A number of "BIG" support companies are starting to offer Enterprise level support for Linux now. Companies like Hewlett Packard offer the same level of support that they do for HP-UX and Windows... They have developers at the back end of things available to make fixes as well. The only issues are that #1 it is just as expensive as all other OS support agreements for the Enterprise level, and #2 They are still building up their internal infrastructure to provide this support, so in these initial stages things do not always run as smoothly as they should. Still, if an Enterprise wants someone to point their finger at and hold responsible, this is the way to go.
  • Why does someone else always have to fix it? Vendors and support contractors are usually no better at fixing things than in house people, especially at the enterprise level, where there are usually highly trained, smart poeple in the IT department. In fact, these IT departments are often bigger and potentially better equipped than the companies or divisions supplying enterprise software. The folks in these IT departments are usually of a higher caliber than tech support drones, plus they're intimately familiar with the particular deployment (and moreso if they wrote it themselves). So most big companies are better off being self sufficient. Support is expensive, and often useless. Hiring smart people who can handle whatever problem might come up is a better deal.

    Another thing to consider is that big companies could develop their own software, then sell it to others as well. They could grow the software development dept. into a new division, which could be sold off later at a profit.

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

  • 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?

    --

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

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

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

    --
  • 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?

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



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

    --
  • 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 [yahoo.com]. 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.

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

  • We shall never see nationwide installations of Linux in the 10k + range until there is a very large Linux company.



    Is IBM [ibm.com] large enough for you?

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

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

  • 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.
  • 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 [microsoft.com] that provide support contracts for Microsoft software. Then again some companies like Sun provide their own enterprise support contracts [sun.com] which happens to be one of the largest [sun.com] 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. [calderasystems.com]
    2. Red Hat [redhat.com]
    3. Rebel.com [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
  • 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.

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

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

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

  • My experience (Score:3)

    by enterfornone ( 7400 ) <anonymouscoward@enterfornone.com> on Saturday December 09, 2000 @06:49AM (#570489) Homepage Journal
    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.

  • Ready? You bet (Score:3)

    by CaptainZapp ( 182233 ) on Saturday December 09, 2000 @08:14AM (#570490) Homepage
    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 [ibm.com], HP [hp.com] and quite likely Compaq [compaq.com] (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 [linuxcare.com].

    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 [www.suse.de] (American site) [suse.com] 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 [www.redhat], Mandrake [mandrake.com], or Caldera [caldera.com], 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.

  • I would say 'not yet' (Score:3)

    by Kiss the Blade ( 238661 ) on Saturday December 09, 2000 @06:52AM (#570491) Journal
    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.

  • Turn to the vendor? Not as useful as you think (Score:4)

    by Tony Shepps ( 333 ) on Saturday December 09, 2000 @09:30AM (#570492)
    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?) (Score:4)

    by HiyaPower ( 131263 ) on Saturday December 09, 2000 @06:58AM (#570493)
    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? (Score:5)

    by Brian Kendig ( 1959 ) on Saturday December 09, 2000 @06:47AM (#570494)
    ... 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 (???) (Score:5)

    by sphealey ( 2855 ) on Saturday December 09, 2000 @10:42AM (#570495)
    "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 (Score:5)

    by Col. Klink (retired) ( 11632 ) on Saturday December 09, 2000 @07:04AM (#570496)
    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? (Score:5)

    by jcostom ( 14735 ) on Saturday December 09, 2000 @07:03AM (#570497) Homepage
    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. (Score:5)

    by mistered ( 28404 ) on Saturday December 09, 2000 @07:06AM (#570498)
    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.

Slashdot Top Deals

An authority is a person who can tell you more about something than you really care to know.

Close