Slashdot Mirror
Linux Support For The Enterprise?
[CRiMSON] asks: "Does the open source model support big business? When those 90,000 POS terminals have a problem, who do they turn to? It's hard to tell your manager, that 'there no fix for the problem yet, but it's expected in the next pre-patch release.' Big businesses like accountability, someone they can point a finger at and say 'Make it work'. For Linux would you have to point to many people... Or in some way could one hold Linus responsible?" There are companies that offer support for Linux and there are several other options where, if accounting is a must, you can get it. Support can be purchased with the system, either separately or included in the contract, or you can hire in-house IT staff to make any necessary modifications that you require. What companies out there offer Enterprise-Level Support for Linux and do any of you readers out there have any experiences you would like to share?
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!
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.
****Gfx Scrollbar Special case hit!!*****
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.
n /magic-cauldron.html
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
...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/) 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.
--
- Alfred Perlstein - Programmer and Administrator, Wintelcom.
The LCARS e-theme would help with interoperability at the UI level at least.
"don't fall into the fallacy of believing that Perl can solve social problems. Maybe Perl 6 can, but that's a ways off"
- 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.
The Norton Anthology of English Literature, 4th Ed., Vol 2
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.
The Norton Anthology of English Literature, 4th Ed., Vol 2
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.
The Norton Anthology of English Literature, 4th Ed., Vol 2
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.
___
___
If you think big enough, you'll never have to do it.
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.
___
___
If you think big enough, you'll never have to do it.
[I would have moderated Blade's post 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) 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.
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.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
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.
There's more to it than this.
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.
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].'?????????????
KLAATU, BORADA, NIh*ahem*
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.
Sig is taking a break!
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.
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.
War is necrophilia.
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.
War is necrophilia.
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
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...
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:
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
Do you have ESP?
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!
-bugg
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,
--[rosso bright]--
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.
meh.
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.
Old truckers never die, they just get a new peterbilt
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
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 (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 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.
"that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
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.
...we won't see exploding consoles anymore, due to the stability of linux? :)
"Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it." -- Linus Torvalds
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.
Yep, I never spell check.
More incorrect spellings can be found he
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.
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.
________
Does anyone actually have a Java program designed to control air traffic, or for the operation of a nuclear facility?
Hey brother, which world are you living in???? I just can't understand from where you have the perception that major software companies can deliver custom solutions at finger point ? This just doesn't happen!
The opposite way is quite more likelly, the software vendors will probably ask you to change the way your company works or recommend a version upgrade of your system, which will require more hardware and new changes...
In the Linux word you at least have the chance to try. If the company who priovides you support isn't good enough you can always look for someone else or do it in-house.
You have two choices, you can blame the vendor and not get anywhere, or you can fix the problems yourself, and take resposibility for the problems. A lot of companies can't handle #2, so they take the 'easy' (for their careers) route of blaming vendors for all of their problems...
Think outside the... Hey, where'd the friggin' box go?
...the machines in questions were Singers instead of PoS terminals. That way, he could point and say, "Make it sew."
God, I suck. Mod me down, please.
Why do users with IDs under 100,000 or over 700,000 usually have the most worthwhile comments?
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...
I think they can afford to pay for qualified staff out of that!
Support cost would be very low, too. Unlike a corporate LAN with individual desktops configured to the tastes and whims of each user, cash registers are "black boxes". They can make their own "HD Linux" distro, do a broadcast-push to each store using DirectPC, and mass-install/upgrgrade all registers over the LAN using kickstart (or just boot the register off the server using network-IPL).
And, because the cash registers are doing relatively simple stuff, there's no need for sophisticated high-end support for the end-station. 99% of the problems in the field will be hardware. (This assumes, I think safely, that HD will rigorously test their software and OS configuration before sending it out to the entire company...) Of course, I'd still want a Sun Enterprise server with 24x7 Gold support in my datacenters, and one workgroup server with Silver support in each of my store. But the cash registers? Eh, they're almost a dime-a-dozen.
Granted, I may have been overly optimistic about the cost saving... So, let's say they save only $20/machine on licensing, and $280/machine on hardware... That's still $10M/yr...
Well, yes, if you want spiffy looking/small-form-factor POS terminals with integrated swipe readers and touch-screen LCD, they are not cheap... And you'd certainly want to use such a machine in high-end retail locations...
But inside a HomeDepot? I think they can use a low-cost desktop to run their POS station. Probably around $800 for the PC and $2,200 for the remaining equipment...
Using standard prices from a POS equipment supplier that I just pulled out of Yahoo! POS-terminal equipment, totaling ~$2,200:
How many licenses do you have to forgo paying for to save enough money to hire a "team to to support it"?
Well lets just assume for a minute that you keep your staff the same size. Now instead you start hiring admins with programming experience. Now support contracts are going to be about the same cost. But now when the admin is getting core dumps and the like he can start fixing the problem himself. Obvisiously support calls will still have to be made but overall the number of support calls will be reduced.
Now since most admins have programming experience the increase in cost is not going be more than 2k a person assuming you already hire compentent admins.
--- Justin Dearing http://www.justaprogrammer.net/ We're just programmers.
I actually ran into this at work yesterday. A Java developer was using Apache to prepare a demo for a client. He ran into an issue with Apache, and we had some trouble figuring out the solutions. Although we did figure it out, for a few minutes it seemed like there wasn't an answer. 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. Next he wanted the distributer... and completely didn't understand the concept of Apache being free, open source, and open developed.
It does pose an interesting problem. Although in my experience it's been easier to find a solution for an open-source software, companies are very used to purchasing contracts. As more and more IT professionals get on the "open-source bandwagon" companies are having to readjust their policies and thought processes towards supporting and understanding the software that they use, rather than the Commercial-Off-The-Shelf approach.
So when "real money" is at stake, like it was here, how do you explain to the management the benefits of free, available code? Does it actually save money in the end? After all, to a company man-hours are the most expensive portion; investing time in a developer to learn and rewrite the code giving him a problem is, to them, far more expensive than buying a software contract from the local support company. Unfortunately, they frequently don't understand the difficulty of working with a closed source base and trying to add functionality to a product it wasn't designed to handle.
You could always use a service like QuestionExchange.com. You can hire out their experts. They can provide support and culpability.
----- go to www.questionexchange.com.
Sometimes management just strikes me as plain idiotic. (The rest of the time, it's only stupid.) What difference does it make if you have someone to point to, if, when you point, they just shrug their shoulders? How many times has Microsoft been made aware of a major problem and dragged their feet fixing it... or claimed it was a 'feature'? How many companies do you know of that have successfully sued Microsoft for one of their products failing to perform?
It seems like it isn't that they need someone to point a finger at... it's that they are afraid to take any kind of risk or do things even the slightest bit different than they've been done in the past. It has always worked that way and probably always will. As long as the less intelligent and risk-averse continue to be promoted to prevent them from doing any harm in the trenches... things will stay the same.
Portable versions of Firefox, GIMP, LibreOffice, etc
You have read to many marketing and distribution books and lived too little life.
Keep in mind those books were primarily written before the open source revolution or the authors had no feeling with this underground development and philosophies took ground and saw themselves find way into the hearts of many more.
Do not forget the other unixes either.
You can not make such a projection based on a merely business point of view, it will be flawed as it does lack perspectives to other higly influental areas which indirectly forms the future.
That your remark has been given 2+ score shows hordes of non-thinking individuals making up a flooding mass.
'Not yet' to the extent given in the example is worth rethinking. Because if the kernel and the rest of the system already now can deliver the functions needed, it will be an investment with an outcome impressing any banker, and some savings, you can make up investing in hiring or contributing to general og specifically related development, which can provide you more flexible, optimized, usable solutions that will enhance your structure and solidify your business structure.
You shall see..
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?
Final comment: ..Linux is to be found 6 feet under..
The day linux become 1 company, you will learn that
...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.'
Doesn't Microsoft do this every 6 months with Service Packs?
Not making the mainstream?
Failing to gain total world domination?
Linux won't go anywhere even if it doesn't replace Windows.
Those who have not worked or experienced the enterprise environment will not understand the question. In the enterprise environment, bugs are political issues, not technical issues. If you can say "Well, Microsoft said..." the CIO can go and hammer on Microsoft to get it fixed. This makes everyone happy: the tech doesn't have to deal with the problem, the CIO gets to abuse a big-ass vendor, and MS keeps the large revenue stream from the ELA. Ta-da!
The linux world believes it understands do-it-yourself support. However, when you're paying for support already, why the heck should your guys do the work? Politically, it's easier to blame a vendor than your own guys.
One other point, forgotten in the discussion, is linux provides no way to actually UPDATE 90,000 POS systems at once. Tivoli Enterprise runs on Linux, but I'm not sure what products are supported.
--- only for the squeamish
-
Expensive support is available from various companies for Linux and Windows.
- With cheap support for Windows you have a problem. Half the time you find a fix on the Microsoft page, but it isn't "fully regression tested" so you get nothing. The last service pack from NT is already nearly a year old (though I saw some "presp7" tags in some kb articles a few weeks back)
- With linux you will have to wait from time
to time with the smaller problems, but really annoying stuff you could either try to fix yourself, or hire somebody who can on *per incident* basis
- Also instead of the waiting for RedHat/SUSE/whatever-fix, you also have to possibility to alert the community directly, and speed up the process of getting it fixed.
Short Microsoft support is no picknick eitherthat third hand- it's called the gripping hand. Read The Mote In God's Eye.
knee-jerk? check. post? check. okay, time to read the article.
Anyone can pick up the code and fix it. Would MS allow you to fix thier code. No you are at thier mercy as to if or when they'd fix it. Not that MS is going out of business or anything, but what if Redmond dissappeared into a black hole. Linus could be hit by a truck but the code marches on. By having all the sources you can hire anyone qualified to modify, fix, enhance the software. Under the traditional model you are at the mercy of whoever holds the sources.
Most big comercial applications have their fair share of bugs, and it is very rare that they will fix them for you in the current release (the notable exception i know of being Oracle who once offered to supply an immediate fix for a bug I found in a company I was working for at the time). If you find a bug your best bet is to generally goto the web-site, check their bug lists and hope someone has a workaround for you to use. Then you can put your code back the way it was supposed to be when the next release is available.
The same holds true for linux, if you find a bug you try and find documentation on it and any workarounds. If you want to fix it yourself fine (though I dont see many peoples bosses agreeing to test a change to a linux kernel for a bug fix one of their in house developers made, let alone undertake to support that version of the kernel on an ongoing basis). So you hack around the bug the same as you do anything else. Luckily most linux apps have a higher turnaround than commercial apps so often the bug fix will be available quicker.
I would say however that the lack of a stable java vm and things like application servers is a bigger consideration for a lot of large enterprise jobs since a lot of big companys want an EJB solution these days.
Slashdot: Proof that a million monkeys at a million typewriters can create a masterpiece
Exactly, There are thousands of people worldwide that would be willing to get a paycheck to do something they love. With FreeBSD you could hire some of the core group. jail is a prime example of this
Would you like to pet my Penguin? The Linux Pimp
--It's Pimptastic!--
Do you have a HPT366 ide controller. It's part of the chipset on Abit BE6 etc.
Try here - HPT366 Linux mini howto
--
--
Mecworks BLOG
As for accountability, blame can be an important part of the process. Not so that one can "neener neener" someone else, but rather to gather the kind of useful data that improve the way source is built. For example: On an open source project, say the Linux kernel, you have a few dozen core developers. If you knew that one was introducing 90% of the defects, wouldn't you want to change the review process or the developers to prevent this?
As far as the "phone jockey" asking for the 3rd time for some information, How about this: "If you would just give me the answer to the question I have now asked 3 times I wouldn't have to ask it again." Most people have no idea what it sounds like at the other end.
Oh, one last thing, using your example, if a SCSI device is failing, what's to blame, the HBA, The device, another device on the same chain, the driver, the OS, the application, or the user? 99 times out of a hundred, it's the last one in the list, not the first...
Just because you write code, doesn't mean your an engineer. Unless you also drive a train...
I thought it ran on LCARS. (Library Comuter and Retrival System), At least the Enterprise D and E do.
This all comes back to the Open Source Business Model.
The current Open Source Business Model is not geared toward selling Linux, or selling Software. Redhat wouldn`t make much money, if that were the case. Its about selling support and upgrade services. That part is at least covered for large businesses that wish to use Linux as a standard. They can buy a support contract with thier software, which is how the Open Source Business Model is working right now.
Besides, most large businesses have IT staff on hand, or on call, that can come in and troubleshoot any problems. Most of whom hang out in usenet, which brings a practical use for usenet tech support.
No pleasure, no rapture, no exquisite sin greater.
The classic IBM statement was:
Believe me, if they could make sales without hardware or software they'd love to. Since selling support and services is a way to make sales without all that nasty engineering staff, they love it.The computers on the Enterprise are probably already running Linux.
Would you like to touch my monkey?
This is a bad article from the simple fact that when these large companies (I have dealt with a few before) will spend a large amount of money, or have there systems running so many critical systems they have there own internal Techs put it through a ton of different procedures, just checking for failure points. You miss the point of Open Source, the kernel with its failures and its glories are totally open to all to see, therefore any point of failure has already been documented, and if you are lucky can either be patched quickly, or the patch is already there. SuSE, Redhat, Slackware all can make any patches to the kernel without having to wait for Linus to authorize it. The only caveat is that the patch you make is readily available at no cost to the public. To be an official part of the Kernel it does have to go through Linus. Whats so hard about that? The kernel itself is only a small part of the distro, its the core. The rest maybe distrobution specific. Trust me too, that SuSE, Redhat whoever would try and fix whatever is broke in a much faster time than is suggested by the article. Finally, the most interesting part of this is that they are using SuSE based machines. What really begs the questions is, who is the number 1 distrobution in reality? Take sales out of the equation, but what distro's are techs using most?
"Any connection between your reality and mine is purely coincidental." -Slashdot
"Generic Hardware?"... We've installed a few POS systems and small-footprint, touch-screen POS systems are anything but generic! Thermal printers and credit card swipes are NOT cheap. Small LCD-based POS terminals (typically AMD K-6 processors with 6+ serial ports and whatnot) run $3000 for 'off-brands' and upwards of $5000 for IBM or NCR... Saving $70 for Win9x or $150 for WinNT might be nice for 90,000 terminals but it certainly isn't $3,000 per terminal!
take the space out before annual
a/s/l here. Sorry, adding domain tags to your s
Out board Ide controller recognization failed. six different kernel compilations and give up. 36 hours is way to long to load an OS. I like linux but this is FUCKING RIDICULOUS!
a/s/l here. Sorry, adding domain tags to your s
Four hours and twenty minutes ago I posted this little gem 'SOS'. I figured that Slashdot may be a good place to get a quick answer considering the inflow of Linux users trafficking the know how.
I got the above error messages (the ones in the post this replies to) after running a rh7.0 install on a 3gig drive. Created an 80 meg swap partition. It rides on the same ide cable as a win/fat32 drive. It starts to boot, both in text and graphic mode but halts at the above messages. Any clues???
I am not a veteran Linux user. Never would claim to be. But I do have a question that I'd like to find an answer to, so I may become a convert.
I know you are not tech support, but when a person wants a real answer from some one they KNOW knows the answers to, who would they come to?
It would be a great day in Slashdot history to add a section of realtime message posting that had a few of the crack team of Linux folks pumping out a coupla' answer through out the course of the day.
a/s/l here. Sorry, adding domain tags to your s
Very IN-formative
a/s/l here. Sorry, adding domain tags to your s
???
not 100% native mode:will probe irqs later
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide0 at 0x14c0-0x14c7,0x14b6 on irq 11
???
a/s/l here. Sorry, adding domain tags to your s
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'm not saying that the community should sacrifice its ideals though, just that it will need to grow up a little, if you like.
KTB:Lover, Poet, Artiste, Aesthete, Programmer.
KTB:Lover, Poet, Artiste, Aesthete, Programmer.
There is no
If you think the Open Source revolution makes one whit of difference to business practice you are utterly mistaken. Business practice has been fundamentally the same since Adam Smith.
I can bet you that the CO of Red Hat has sleepless nights worrying his market share and threats from SuSE, Corel, and the rest. The motivations are the same, the tactics are the same, the fears are the same.
As I say in another post, it's no use saying that Linux works and the OSS business model works and expecting the real world to come knocking at your door. Linux has to change to fit the world, not the other way around, if it is to be successful. Anything else is arrogance and wishful thinking.
Companies expect support. They expect their problems to be fixed for them. It's no use saying:"But you can fix it yourself" - you have to give them the support, right or wrong.
Of course, that is exactly what Red Hat, SuSE and the rest are doing; they are in the real worls of commerce. But can they support large 100k unit installs? I doubt it, and so do they, I would think. So if they want a piece of that action, they are going to have to grow. How do you do that? By taking away market share from your competitors, taking over your competitors, etc. I would say the unification of the Linux Distro commerce world is inevitable.
KTB:Lover, Poet, Artiste, Aesthete, Programmer.
KTB:Lover, Poet, Artiste, Aesthete, Programmer.
There is no
KTB:Lover, Poet, Artiste, Aesthete, Programmer.
KTB:Lover, Poet, Artiste, Aesthete, Programmer.
There is no
True, there is someone to blame if you buy at M$, IBM, Sun et al.
...
but
- does complaining fix your problem ?
- do you have any guarantees anyone cares ?
Just use the source - or hire someone to do it for you - and you CAN squash the bug and nobody can stop you from doing it.
Just tell your boss "the EULA doesn't allow reverse engineering, and they ignore our reports - we are out of luck"
guess who now provides enterprise-level support for "linux & open source"? their professional services people are actually quite good @ getting fixes pushed through the devel cycle . . . though their support packages *do* cost a bit. :)
Everyone's always talking about how with open source software there's nobody to call, nobody to hold responsible.
Sounds like a valid objection, I guess, except in the real world.
I was an IT manager in an organization large enough to make Microsoft ask "how high?" when we told them to jump (30K machines at our particular site). I could get real live engineers (not support techs) to call me back the same day, which is better support than most people would ever dream of getting from them.
Useless.
From time to time, we would uncover bugs in NT and associated products. We'd work with the MS people, who would disappear and come back in 3 or 4 weeks with a patch, generally accompanied by annoying workarounds, that would stop the crashing or other bug manifestations. The patch would wind up in the next service patch or hotfix or whatever, weeks to months later.
On the other hand, when we had problems with open source software, we'd put a team on it and more often than not, fix it that same night. Then, depending on our confidence in the fix, we'd release it to the community, so everyone else could benefit straight away.
The difference was night and day. It was far more cost-effective to devote some programmer-power to actually fixing the problems, than to deal with lost productivity or stalled projects for weeks. And our benefit was a win for everyone else as well.
In my current situation, a much smaller organization, we're almost entirely open-source, and I'd never go back.
"Patriotism is your conviction that this country is superior to all other countries because you were born in it." -- GBS
"IBM recommends Windows 2000 Professional for business" -- Every IBM PC hardware advert.
Actually, that probably is how Microsoft treats 90,000 seat customers. However if you are some pidding small fry with only 9,000 seats, forget about it.
Oracle provides enterprise level database system. With the help of Java, Oracle database can run on all major linux distros, including Debian GNU/Linux, though I only support Redhat.
Most people dislike Java, scold Oracle. However, they fail to realize that Enterprise computing is about proprietary.
Progress on Java in Linux is too slow. Mainly due to the fact that Linux zealots hate Java, hate anything non-GPL. Oracle's success in porting to Linux tells us that Java is a bridge between Enterprise computing and Linux.
Please don't compare Java with other languages like C++, C#. People use Java not because of its superiority in all aspect, in fact it's not. It's the high portability impressive.
The best way to get (1) is to use Free Software. The best way to get (2) is to hire an appropriate number of experienced systems administrators and Free Software developers to your internal staff. Why? Well, if you go through a commercial support vendor, you'll have the same problems as with any other technical support - your trouble ticket has to work its way up the chain to the people who actually understand it, the people answering the phones usually have virtually no ability to understand the problem, and the back-and-forth is time-consuming. The cost, assuming you have a reasonably large installation, isn't going to be any less than the in-house contracts anyway. So is it worth the extra time to get back up to be able to "blame" somebody if something doesn't work? Not when you're losing money while a phone monkey at Joe's Linux Support asks you to repeat, for the third time, just what exactly isn't working with your SCSI controller.
However, let's think about the implied assumption for a minute. The implied assumption that you make is that the software is going to break in the first place. That well-tested, well-designed, well-implemented and well-integrated software is going to break after you deploy it to 90,000 cash registers. This assumption might not be valid. Yes, in general things tend to break. But, if Linux is the operating system, it probably won't be the cause of the breakage. Instead, the cause will be things like your POS code.
The same could hardly be said for Windows, with it's DLL Hell and inability to ever be the same twice after 1 week of users touching it. Further, Windows on a POS system will foster an illusion of competence which will encourage various attempts to break into the systems. You will have to spend gobs of money on software to lock the systems down to prevent "hax0rs", and even then it probably won't work (2600 delights in publishing exploits on POS systems and the like.)
So which is better: a system that doesn't break in the first place, or support to help you fix it after it does?
--
-- Slashdot sucks.
There are plenty of stories wherein open source software has quietly proven a success. Quietly? Sure. Home Depot may be on Linux, but IT is not percieved as a fundamental issue for Home Depot's financial success, things like Supply Chain Management (SCM) are. Of course, if their IT infrastructure fails, it will screw up their cutting-edge SCM, but financial analysts rarely drill that far down.
A good example is the rise of DEC. (The fall of DEC is an example of other things :-).
In the mid-80's, insurance giant Aetna bought out a small insurance company -- something they do all the time. In the course of their due diligence, they requested a roster of standard reports. The reports arrive two days later. The Aetna execs were flabbergasted. It took weeks for a team of RPG and COBOL programmers to coax similar reports from Aetna's computers. What kind of computers was this small company using? "We run on DEC machines running UNIX," they answered.
Before you knew it, DEC was the new star in corporate IT. IIRC, 1986 was the Year DEC Could Not Be Stopped. Linux has a lot of good buzz, but it hasn't crossed that perception barrier. What will it take? It will take someone betting on, and winning with, Open Source.
I'm running my ecommerce infrastructure using Linux, Apache, NetBSD, mod_php, Jakarta Tomcat and PostgreSQL. The only closed-source element is the JVM that runs Tomcat and I can replace that with Kaffe eventually. Have I bet my business on Open Source? Not really. I told a Sun and an Oracle rep just last Thursday that if Linux and PostgreSQL begin to break under stress, they could expect a call. I can switch to Solaris and Oracle in a weekend. Even though I have the source code, I have neither the time, the expertise or even the interest in developing Linux and PostgreSQL into a solution that can rival the power and stability of Oracle running on dual E6500's. I will, at the point where I need that, have the money to pay for them. Right now, I'm just one of thousands of businesses that is controlling their startup costs by building their initial infrastructure on Open Source. That's a plus, but it's not the testimonial Wall Street needs to see.
What needs to happen is a success story build on Linux or NetBSD that couldn't have happened using closed-source approaches. I don't know what that's going to be, but I'm sure it's on the horizon. If I do think of it, look for me on the cover of Forbes (I'll see if I can get Linus to stand behind me and grin appreciatively).
"Reasonable people adapt themselves to the world. Unreasonable people attempt to adapt the world to themselves. All progress, therefore, depends on unreasonable people." -George Bernard Shaw
You contract for support not for support of........? D'ya get it? In fact it's EASIER to support a Linux based system in a large corporate environment because (in theory) you would make any chang you need instead of swearing about some broken Windows crap that STILL hasn't been addressed for a year or so. You don't go an build, say, a huge datawarehouse and then throw your hands up if Windows or OS/390 or any other OS doesn't cooperate. You contract with whomever can get that job done. Do you honestly think that if you were a large Windows customer and even if you contracted with MS directly they would roll off a custom version just for you?
Compaq, IBM, and Dell all sell systems with Linux on them, and they stand behind their systems in terms of compatibility. You install a new device that is buggy on Linux, their support guys will help you, or they'll tell you it isn't officially supported hardware, and see if there are workarounds -- same as a MS tech will tell you about devices not on the HCL.
But if you get a POS system (touchscreen, cardreader, cash drawer) based on OS/2 or DOS or Java (don't know what they run under the Java) then just go ahead and slap linux on it and things break, what the heck is the vendor *supposed* to do? They don't know any more than you do about running Linux on the hardware, most likely *less*, since you're the one being the guinea pig.
On the other hand, if you purchase a POS system from a vendor that supports Linux and it doesn't work as advertised, then you need look no further than the vendor that sold you the system.
And for the mutants in the crowd with three hands, on that hand if you homebrewed this POS system, you can't hold anyone to support it but yourself. If you build your own car and it breaks down because you assembled it with parts that were never made to be fitted to each other, you don't have a car maker to hold responsible either.
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
Btw.. I'm calling for a unified packaging system for the unixes and it requires and first of all it requires a unified FHS. What efforts are being put into that out there?
I'm trying not to sound crass here, but if you were putting serious effort into your system, you'd know the answer better than anyone here. As an aside, I have many reasons to believe it's misguided to have your unified packaging system require a unified filesystem. First, you're the tail wagging the dog. Show that your system adds value. Redhat users have rpm, debian has apt, bsd has ports. You have to beat those or they have no reason to switch. Second, good luck getting solaris and slackware to see eye to eye.... or by "unixes" do you just mean linux? Lastly, I suspect your rigid filesystem standard would simply fall down in the face of complexities like a multi-architecture network. There is no One Right Way To Do It, especially when there's more than one "It".
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
90,000 POS terminals that can run on generic hardware, with hardware+licensing savings on the order of about $3,000 per cash register ~= $100M/yr in savings over a 3-year equipment life...
Three THOUSAND? Where the HELL did you pull that figure from? You don't exactly put Win2K Server on a POS box, much less buy a separate CD copy for each one.
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
Even if nobody else considers your problems worth looking at (slim chance,) since you have the source code, you're not at anybody's mercy waiting for an upgrade that might or might not fix the problem. You can hire a Unix programmer, consultant or fix it yourself.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
Last summer my company (30k employees) did a massive Win2k deployment. Then Bad Things (TM) began to happen, especially with Active Directory.
In a few days, Microsoft assembled a 20-people team (mostly developers) that came on-site, plus another couple of sizeable groups in the US and UK to support them.
The problems got fixed in about two weeks (I must commend the guys, they worked really hard).
From IBM's latest annual report, percentage of revenue by category:
IBM is a HUGE support organisation. Sure, they do make more money from hardware than from support or from software (individually), but not much more. And look at the trend; it probably won't be long before Global Services surpasses Hardware.
Have a look at IBM's recent press releases. You'll see IBM mentioning Linux a fair bit.
It certainly looks like IBM's trying to position itself as a software and support company, with Linux as a not insignificant part of that strategy.
Enjoy your job, make lots of money, work within the law. Choose any two.
IBM recommends whatever they think will make them the most money. Right now it's probably easist for them to sell a machine with Windows on it. They're not going to say to their customers, "I know you think Windows is great but we think you'd like this Linux thing instead." If you see an ad by IBM selling Linux support and call them up, they'll be more than happy to sell that to you.
Enjoy your job, make lots of money, work within the law. Choose any two.
Is IBM large enough for you?
As one responsible for mission critical systems, I've justified paying a large sum of money to get support for a commercial UNIX system (Data General, now EMC, for DG/UX).
This puppy, whenever it paniced, would send diag packets automatically to DG, they'd start analyzing the problem, create a patch, and ship it out to us. There's a great comfort in that.
We had one case where the box would panic for no good reason on boot. Software support couldn't figure it out, so hardware support came out and just started blindly swapping processors, memory, etc, and it still didn't stop it. Turned out to be a faulty VME slot backplane board. Fixing that fixed the problem.
The point is, I have a ton of problems to worry about already and I took great comfort in knowing that no matter what was the cause, THEY HAD TO FIX IT.
I haven't seen any Linux vendor support get there yet, and I certainly haven't seen that with Microsoft servers. If they fail, you're told to reboot and try again. If that doesn't work, the next "solution" is to re-install it. Will Microsoft custom-fix a patch for me if I'm seeing a problem? I don't think so. Maybe if the fault is being experienced by thousands of sites...
So, bottom line is, it really doesn't matter what the OS is or who makes it, it matters who the support vendor is and how well they support it. There is nothing that says that level of support couldn't be made available for Microsoft or Linux OSes. The advantage vendors like Sun, DG, HP, and IBM have is that they provide the hardware and the OS as well as the service contracts. When something fails miserably, they can tap all their internal units if needed to get it fixed. A Linux support vendor theoretically could do the same since they also have access to the source. A Windows support vendor, I just don't see how it works.
But I will soon enough. We just got a pair of DG Intel boxes and are loading Windows 2000 on them and getting DG service contract on them. I'm going to have first-hand experience comparing their support for Windows versus their own UNIX variant..
First:
The question was not how badly other vendors support their products - it was how to get support for Linux in enterprise environments.
Second:
You comment was based on an EULA, an "End-User License Agreement". Was the question about end users? No, it was about enterprise. Microsoft and other provide a LOT of support for enterprises(sure, it costs, but it's available).
This are very different when you're a big business, especially when you're buying in volume. Having worked for Ontario Hydro, I know that many vendors fall over themselves trying to help the big companies. Once there was a problem, and we called our support number(which no other company had - it was ours), and MS had a tech out in two hours. She arrived at three AM, and had the problem fixed by eight AM.
Go get a life.
Dave
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
My employer is about 4,000 seats, 30+ NT servers and 80-ish Unix servers, and I've never heard of us being personally responsible for the generation of an actual OS code patch via complaint. (Of any OS; we've been through a good four Unixes and all the MS OS products.)
We're in the same "if many people complain, a patch will come in a matter of months" bin as Mom & Pop companies.
The real need for an OS patch is rare; the vast majority of support requirements are for parameters, tweaks, workarounds, etc...how you *ask* the OS to do something, not changes to what it does.
Direct vendor support is needed for that with closed products because only they can understand how it really responds to user stimuli. But with open products, "all"(?) you need is a really, really savvy consultant who knows the code down deep.
There's nothing magic about the support staff of vendors, they aren't god. They're working stiffs who mostly inherit code and can generally figure out problems and produce patches after they've been working with it a few years.
With open products, *anybody* can do this.
So the real question here, is "what's the market availability in really, really savvy Linux consultants"? Because anyone who is, can do anything for you that a vendor support team can do.
And any company serving 10,000 seats can definitely afford $100K/year plus to have such a consultant on retainer.
Big businesses like accountability, someone they can point a finger at and say 'Make it work'.
IBM, or RedHat, or VA Linux, or dozens of other companies will support linux and fix problems for you, allowing you to hold them accountable.
I still think this is a straw argument - You can CHOOSE anyone in the world, and they would have source code access that allows the fixing of ANY bug. That will NEVER work with a closed source vendor.
Actually you are wrong. The poster of the "Ask Slashdot" is asking about Support Contacts which a number of Linux vendors provide as opposed to Warranty which no software vendor provides whether it is Open or Closed source.
Enterprise support is usually provided by third parties as opposed to the actual OS vendor, for instance there is a sizable list of companies that provide support contracts for Microsoft software. Then again some companies like Sun provide their own enterprise support contracts which happens to be one of the largest support service providers in the industry.
As for the Ask Slashdot, here's a list of companies that provide Enterprise support.
- Caldera Systems, Inc.
- Red Hat
- Rebel.com
I'm sure there are a bunch of others but these are the ones I know off the top of my head.Grabel's Law
It is not, however, an enterprise class O/S. Want a kernel debugger? Well, there's a patch that might be up to date. Want to profile the kernel to debug the slowdowns in your 8-way profusion database server? Good luck if you don't have a kernel developer on your staff (and those are reasonably difficult for your average website to find and employ).
And Linus will never allow this kind of "cruft" into his kernel. His opinion is that there should be a high bar of standard for people who want to hack on his kernel. He's not going to make it any easier for very advanced system admins who want a kernel debugger, crash dump analysis and better ways out of the box to profile the kernel. (Read the linux-kernel mailing list if you'd like to -- Linus has said as much).
None of this goes over well with businesses, at least not for the Enterprise server market. It may be more than adequate for the desktop though (who cares about profiling a kernel sitting on a desktop?). So, if you'd really like to face reality, Linux is the Win98 of Unix OSen. And Linus is trying to keep his kernel that way. The only alternative is to fork the damn thing and its way overdue for Linux distros and companies like SGI and IBM that have some Linux investment to go ahead and do so.
try it, it won't. o it boots, but stability is not there. o microsquish will tell you it works, but sorry, after a number of different machines, all with different ram, all with differnt processors, all with different mobos, all built with legal m$ distribution. it doesn't work. o yes, and by the way, did i mention that windows me, windows 98 and windows 95 don't work with more than 511 megs of memory. if you believe everything they say, i guess you are being part of the problem, not part of the solution. its not fud its reality.
o yes, i went through all of the windoze knowledge base. one solution proposed was to have less than 512 megs of memory in your machine. quite a solution to the problem really, i think it would be most effective.
There is enterprise and there is enterprise. If you are Ford or Merk or some similar, even Billy will dance the jig for you. Money talks. Try to get the support you just mentioned if you are a 25 person enterprise or a 10 person enterprise. My usual experience is that you will get the go fly a kite response and be passed down to someone who can barely find the rest room on their best days. Supportability is a valid issue, but after running computers since the days of vacuum tubes, just putting up a good front isn't support, its dishonesty.
The OSS business model IS different from what you see in the old marketing books. Any economic theory makes assumptions, and when those assumptions fail, the theory fails. When something that is taken for granted (like the ability to sell the product, for example) is suddenly removed, you place a big fat '0' in front of one of the variables that previously had a rather important coefficient. Other variables with previously negligible coefficients start becoming very important, and thus you have a model that does not conform to the traditional ones in your old marketing textbook.
WARNING: there is a trojan on your
No, you can't order around people who are under no obligation to you. Neither can you order around Microsoft, Oracle, or a lot of other large vendors, unless you're quite the Big Business indeed. So how is this different from saying, "there no fix for the problem yet, but it's expected in the next service pack"?
A lot of Free and/or Open Source software seems to be less buggy than their commercial counterparts in the first place. And you have the choice to fix it yourself, or hire someone (perhaps the authors) to do so in a timely fashion. If neither of these factors satisfies you, or applies in your case, buy the commercial alternative. But don't delude yourself. As MacArthur said, "There is no security on this earth. There is only opportunity."
"The best we can hope for concerning the people at large is that they be properly armed." - Alexander Hamilton
Since the code is open source, when something does go wrong your staff can fix it. When was the last time you heard of a 90,000 seat MS-Deployment where the customer was able to tell the vendor "We've got an MS-Problem, and we'd like it fixed," only to hear the MS-Vendor say "Sure, we'll get our MS-Staff right on it!"
I can tell you right now everything that goes wrong will have to be handled by the in-house staff. They might just take care of it themselves, or perhaps they'll try to contact the developers themselves, but ultimately it's the in-house IT guys that have to handle it.
:) - and it benefits the companies too (and no, I'm not willing to explain how that is - post another "ask slashdot" question if you want to know).
Now considering that most enterprise Linux systems are running daemons such as Apache and SSH, I don't think it's a big problem. When something arises, they IT folks would just fix the way the programs run, and if they can't...well we can all hunt down the people in charge of Apache and SSH pretty darned fast.
Enterprise Linux systems, however, are also used as workstations and storage systems. For the storage system, all you need is to assign some lowly person and teach them the chmod and chown commands. For workstations, I'm going to assume that many partitions will be networked (/usr, etc.), and the company will have more IT people to linger around and fix up problems on the workstations. I'm not going to get into the details of shared systems, but it's most likely that you'll see it set up like that.
So to sum it all up, the open-source model will (and does) work in enterprises, especially the USS Enterprise
Want good Xmas music? Look for Manheim Steamroller!
SIG: HUP
To continue business operations, the software needs to get fixed as quickly as possible. And having the sources to the application gives a company the best chance of doing that as quickly as possible: they can contract out support, hire consultants, or develop the in-house expertise.
Besides, unlike hardware, software doesn't just usually wear out and go bad. Almost always, serious software problems are triggered by an insufficiently tested upgrade or by an untested change in business procedures. And as a stop-gap measure, it's usually feasible to undo whatever was done.
Problem size or volume can also get too large for software to handle. That's a specification, testing, and sizing problem, not a software bug, and closed-source vendors won't help with that either other than by selling more, more expensive software and hardware.
The main class of unexpected bugs that occur is security problems, and the record of open source software is considerably better of fixes than for proprietary, closed-source software. And with the closed-source software, nobody can even review the bug fix to make sure it doesn't cause more problems.
I used to work with a company that dealt with POS etc, mainly running on SCO. SCO are like any big company, pretty slow with getting fixes out. The companies that made the software that ran on top (POS, Inventory, stuff like that) were usually small companies dealing in specialised markets. While the software was proprietary, the main selling point was the support contract and they were usually pretty quick with fixes.
However they could only fix their own software. Probs with the OS had to go back to SCO.
How would they deal with Open Source? They would be much better off. Rather than having to run to SCO for fixes, they would be able to fully support the operating system as well as the software that runs on top.
--
enterfornone - logging in for a change
Let's see. Depending on who you want to sell on the issue, we certainly have the big boys. IBM , HP and quite likely Compaq (the TrueUnix/VMS folks, not the crappy box assemblers) can quite likely deliver expensive support and professional Linux services. Of course it's up to you to determine the quality. But you also have to do that when EDS is shipping 10 of their clones with bad haircuts to you.
Then there are specialized companies whose most prominent representation is probably Linuxcare.
Finally and - in my experience most importantly there are the distributers who base their business model basically on services. I had outstanding experiences with SuSE (American site) which guided me through struggles getting X up on my notebook. They made a very idealistic, determined and goal oriented impression and delivered far better support then what I've seen with companies that charge $1/4 million a year (and that was the free issue installation support). They run a professional services department and they have various support plans including 24/7 - and dedicated resource plans. Pricing looks quite reasonable.
I can't vouch for Red Hat, Mandrake , or Caldera, but at least Red Hat has a good reputation.
So, here we go. There's a lot around to chose from and compare. If the gentlemen in the suits insist on an IBMHPSUNDEC rubber stamp, here you go and you probably pay for it through your nose. Not that the distributers quite give away theire services, but from what I've seen there seems to be excellent value there.
ich bin der musikant
mit taschenrechner in der hand
kraftwerk
Now, the only way we are going to get such a large Linux company that the corps feel they can trust to fix their problems is if Red Hat, SuSE, Caldera, Corel etc become one. Divided, they are small and weak. Together they are strong. I see this fate as being inevitable, anyway. It is the due process of capitalism. I expect that in ten years, after a struggle between these companies involving bankruptcies, mergers and hostile takeovers there shall emerge one true Linux company, if you like a MS of the Linux world, without quite the same stifling power. Only then will corps be able to make large scale deployments of Linux with the proper assurance and support.
Debian will survive, of course. It shall remain the hobbyists distro. But the commercial companies will be (and are) at each others throats.
KTB:Lover, Poet, Artiste, Aesthete, Programmer.
KTB:Lover, Poet, Artiste, Aesthete, Programmer.
There is no
It was a pretty good group of people, but only half of them were capable enough to debug something "from scratch"; the other half would look up your problem in the database, roughly the ancient equivalent of what every vendor gives you gratis over the net nowadays, and if it wasn't there they would either escalate, dispatch hardware or local support, or wander the cube halls asking the more savvy people what to do.
People were well-supported under these conditions if they had problems that were RTFM, or known bugs, or hand-holding for odd and difficult things like really had fscks or restores from unknown backups.
I'm sure these are the sorts of problems that every Linux vendor can also offer these days. But what if your problem was a real bug that your enterprise depended upon?
Well, those problems would be escalated to "engineering", the group that did kernel and such support for our versions of Unix. And those problems took *ages* to get anything back. Especially in an age where the company was trying to get rid of the burden ofsupporting the customers with old hardware that had been sold before the merger of Burroughs and Sperry. The BSD customers were largely out of luck. The people reporting problems on modern levels of software that was still being developed were the only really lucky ones, as their problem might get some attention. Otherwise, the level of interest in truly solving a serious problem was very low indeed.
And if a bug was not reproduceable, and didn't come with a ton of information and core dumps and whatnot, forget it.
Linux is different in two ways. Firstly, and most obviously, with the source code available, there is a really good chance that you can either fix problems yourself or find/hire someone who can fix problems for you. But secondly, and more importantly, Linux encourages a different attitude towards IT. It invokes the primal call of the hacker. It encourages the involvement of a different sort of employee.
Under old corporate Unixii, sysadmins *had* to call support. It was S.O.P. because support was the only place to turn to for the problem database, for patches (this was pre-Internet and patches weren't made publically available), for finding out whether a problem was previously known.
Now, with the source available, with known problems advertised to the world, with patches mirrored on 30 different servers, with hundreds of places to turn to for help, there are no excuses. The chances are much greater that a sysadmin can locate a solution or workaround. The same code running in the enterprise is also running in 12 million other boxes.
Furthermore, the online communities did not exist in the corportate unixii world, and for the most part they *still* don't exist. Find other people interested in helping you figure out an error message in HP-UX? I wouldn't even know where to turn. Find a weird error message in Linux? Chances are a net search will find it, and in five minutes you'll know whether it's a rare problem or a common one, and if it's common, in five more minutes it'll be fixed.
Bottom line: the "rules" for support have radically changed -- for the better. The quality of support from the teeming masses of Linux users is as high if not higher than the old corporate support. The type of people attracted to running and using Linux is better.
Lastly, in an enterprise situation, and especially in the case of POS terminals, one is unlikely to suddenly run into a problem that will "shut down" the enterprise. POS terminals will run the same code over and over. Enterprises will run systems in advance of putting them into place; new problems will crop up when they run into resource limits, but these are problems that everyone has run into -- things like, what happens when you run out of swap, what happens if you try to configure a file system larger than the last one, etc.
Otherwise, the typical support calls of "What happens if I can't read my backup tape?" and "Why does my system crash when I plug my serial cable into line voltage?" will be handled by the vendors, just as they always have been.
--
- What is your escuse soldier?
- No excuse sir.
as the only possible answer just doesn't fly anymore. Anyway, when it comes to Microsquish bugs, I demand a recount. Windoze Me doesn't even work with more than 512 megs of memory.<picardmaneuver> Actually, they just need to say 'Make it so.' </picardmaneuver>
"It's hard to tell your manager, that 'there no fix for the problem yet, but it's expected in the next pre-patch release.' Big businesses like accountability, someone they can point a finger at and say 'Make it work'."
Has anyone ever managed to hold a major software house accountable for _anything_? Microsoft, IBM, any of the big (or small) ERP vendors? I haven't seen it happen in 15 years of software support. My former employer had a super-double platinum support contract, and about 25 million USD a year in business, with a software vendor you know very well, and we NEVER managed to pin them down and force them to fix ANY of the bugs we found - some of them quite serious.
[Having previewed this, I will make one exception: Novell tends to stand behind its products more than other vendors]
As to whether you can support Linux et al, that's another question, but I hope no one is thinking they can force a commercial software house to stand behind anything. Not to even mention UMCITA.
sPh
And just who did Ebay "point their finger at" when they had all those troubles? They blamed Sun, but that didn't get them back online immediately. And in the end, Sun said it was Ebay's fault because Ebay didn't apply patches provided by Sun.
The bottom line is that you've got to have your own staff to support your machines. The whole "I can blame the vendor" approach is nonsense considering the EULAs and court decisions not holding vendors responsible.
-- Don't Tase me, bro!
This is the classic "who do I sue when Linux blows up?" fallacy. Who do you sue when Windows NT blows up, taking out half of your enterprise? Answer: it ain't Microsoft. By agreeing to their EULA, you agreed to hold them harmless, and gave up any right you might have had to sue them.
--
The unsig!
I'm quite sure that a decision to widely deploy Linux, like Home Depot's decision, was not made by some tech under about three levels of management. When you're talking about a deployment of that size, you carefully weigh all of the options before going ahead. I'm sure Home Depot looked at licensing costs, expected support response times, support contracts, hardware requirements, etc. before going ahead with their Linux deployment.
The article mentions Red Hat; Home Depot may have a support contract with them. If they don't, or if Red Hat disappears, there are others to turn to for support. Home Depot's IT group is probably a respectable size; they could hire an in-house Linux developer for support if desired.
What do you do if your POS system is running on a proprietary, closed operating system and you come across an OS bug? If you're big enough, you might have a support contract for your OS and perhaps you will get support, but otherwise you're basically out of luck. Even with a support contract, if the company goes under or fails to provide support in a timely manner, you have nobody else to turn to.
Enjoy your job, make lots of money, work within the law. Choose any two.