Linux Support For The Enterprise? 152
[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?
Picard maneuver actually works! (Score:1)
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!
Re:Fix the problem, not the blame (Score:1)
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.
commodization of support (Score:1)
Re:My experience (Score:1)
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-cauldro
-Derek
Re: Why this is really important... (Score:1)
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
FreeBSD has enterprise support. (Score:1)
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.
--
UI Standardisation... (Score:1)
Linux Support for the Enterprise (Score:1)
- 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.
Re:I would say 'not yet' (Score:1)
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.
Re:I would say 'not yet' (Score:1)
Re:Ebay example (Score:1)
___
exactly! (Score:1)
___
Shunning Linux to avoid responsibility (Score:1)
[I would have moderated Blade's post [slashdot.org] as(+3, Flamebait Deluxe). It is irresistible!]
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.
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.
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.
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.
Fine for 30k employees, Try 30 employees. (Score:1)
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.
Have you tried to point the finger? (Score:1)
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.
Re:Fix the problem, not the blame (Score:1)
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.
Standardize (Score:1)
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.
Re:Standardize (Score:1)
"The Question Is Moot" with host, Jesse Jackson. (Score:1)
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].'?????????????
Re:I would say 'not yet' (Score:1)
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.
Re:I would say 'not yet' (Score:1)
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.
Enterprise Commuting (Score:1)
Re:I would say 'not yet' (Score:1)
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]
Re:SOS (Score:1)
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.
Has anybody ever sued Bill Gates? (Score:1)
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.
Re:Fixed in the next realease - blame game (Score:1)
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.
Other options (Score:1)
Re:What on earth are you talking about? (Score:1)
Dave
Re:Ebay example (Score:1)
Dave
Re:Why this is really important... (Score:1)
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...
Someone please pick up the needle.... (Score:1)
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:
Re:Fixed in the next realease (like Windoze maybe? (Score:1)
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.
Linux support (Score:1)
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'm sure you could find someone with enough work (Score:1)
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!
Re:Hire the support (Score:1)
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,
Enterprise Support Experiences (Score:1)
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.
closed source != responsible (Score:1)
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.
read this... (Score:1)
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.
yeah, who anyway.. (Score:1)
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.
YOU provide Enterprise support (Score:1)
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]
Re:INFO (Score:1)
freaking perverts...
Re:Now pricing a cluster and told NT over Linux (Score:1)
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.
Now pricing a cluster and told NT over Linux (Score:1)
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.
Hire the support (Score:1)
The example sited is a great one. You could develop 90,000 units that are identical. This would help making problems easier to solve.
Support Accountability == On-site support (Score:1)
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
support? (Score:1)
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.
Software as service (Score:1)
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.
Re:Interesting problem (Score:1)
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
Enterprise Support (Score:1)
Re:Why are there enterprise questions here? (Score:1)
Re:Now pricing a cluster and told NT over Linux (Score:1)
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.
Re:Now pricing a cluster and told NT over Linux (Score:1)
http://www.redhat.com/products/software/linux/eeo
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.
Re:Picard maneuver actually works! (Score:1)
Does that mean... (Score:1)
Why are there enterprise questions here? (Score:1)
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.
Pointing does nothing. (Score:1)
Enterprise Level Support (Score:1)
Self sufficiency is the whole point... (Score:1)
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.
Fix the problem, not the blame (Score:2)
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.
One other comment (Score:2)
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?
--
Open Source Reality vs. Business Reality (Score:2)
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).
Re:Fixed in the next realease (like Windoze maybe? (Score:2)
Stop smoking drain cleaner (Score:2)
so use certified solutions (Score:2)
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.
--
Re:I would say 'not yet' (Score:2)
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".
--
Re:Interesting problem (Score:2)
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?
--
Re:Support? We don't need no steenkin' support! (Score:2)
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.
--
With Linux, you have the source code. (Score:2)
Re:Fix the problem, not the blame (Score:2)
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.
My company's experience with Microsoft (Score:2)
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).
Re:Pointing does nothing. (Score:2)
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.
--
Re:I would say 'not yet' (Score:2)
From IBM's latest annual report, percentage of revenue by category:
IBM is a HUGE support organisation. Sure, they do make more money from hardware than from support or from software (individually), but not much more. And look at the trend; it probably won't be long before Global Services surpasses Hardware.
Have a look at IBM's recent press releases [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.
Re:I would say 'not yet' (Score:2)
Re:SOS (Score:2)
>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.)
Re:I would say 'not yet' (Score:2)
Is IBM [ibm.com] large enough for you?
Why this is really important... (Score:2)
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..
Re:What on earth are you talking about? (Score:2)
Re:Ever read a EULA? (Score:2)
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.)
What size of "enterprise" you talking about? (Score:2)
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.
Accountability (Score:2)
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.
Support Contracts Aren't Warranty (Score:2)
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.
- Caldera Systems, Inc. [calderasystems.com]
- Red Hat [redhat.com]
- 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
Holding Linus Responsible... (Score:2)
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.
Re:Fixed in the next realease (like Windoze maybe? (Score:2)
Re:Fixed in the next realease (like Windoze maybe? (Score:2)
Re:Ever read a EULA? (Score:2)
Re:I would say 'not yet' (Score:2)
Again? (Score:2)
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."
Re:Ebay example (Score:2)
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!"
As a sys-admin... (Score:2)
Now considering that most enterprise Linux systems are running daemons such as Apache and SSH, I don't think it's a big problem. When something arises, they IT folks would just fix the way the programs run, and if they can't...well we can all hunt down the people in charge of Apache and SSH pretty darned fast.
Enterprise Linux systems, however, are also used as workstations and storage systems. For the storage system, all you need is to assign some lowly person and teach them the chmod and chown commands. For workstations, I'm going to assume that many partitions will be networked (/usr, etc.), and the company will have more IT people to linger around and fix up problems on the workstations. I'm not going to get into the details of shared systems, but it's most likely that you'll see it set up like that.
So to sum it all up, the open-source model will (and does) work in enterprises, especially the USS Enterprise
Want good Xmas music? Look for Manheim Steamroller!
finger pointing and suits won't help the company (Score:2)
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)
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)
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)
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)
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)
- 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)
<picardmaneuver> Actually, they just need to say 'Make it so.' </picardmaneuver>
Obtaining support from commercial vendors (???) (Score:5)
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)
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)
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)
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.