Slashdot Mirror
Unreliable Linux Dumped from Crest Electronics
nri writes "The Age writes, Linux misses Windows of opportunity. Crest Electronics chose a Linux operating system, then seven months on, the company chose to abandon it for Windows.
Mr Horton says. ".. the machine would basically, putting it in Windows terms, core dump or blue screen at random. It would run for weeks or so and then just bang, it would stop....I fully support Linux but if I had to make the decision again I'd pick Windows. A big reason is the fact Windows was up and running in two hours at all the right patch levels. The installation of SAP took two days on Windows, the installation on Linux Red Hat took two weeks. The total cost of ownership is actually lower in this case than with Linux because of the hidden costs of the support.""
Odd that the Windows terminology for the blue screen of death now seems to be the standard term for a computer crashing. Or maybe that's not so odd.
(please don't mod this as funny, I am very serious here.)
RTFA. Redhat EL 3. IBM servers (OK, but which kind?) The whole article smells fishy to me.
* 2 weeks to install to SAP standards? Hmm. How about 1 day to install Linux, and the rest is setting up SAP and testing? 2 days to install on Windows? How much testing was included there, eh?
* "Software updates had to be manually installed to ensure SAP certification." So that's like, rpm -Uvh the_update.rpm. The HORROR!
* "We asked the customer to do a diagnostic test and the customer never responded, so it was impossible for us to address the issue," Mr McLaren says. Most folks who are serious about making it work would probably get back to them when having these problems. Almost sounds like some geek personalities were the problem, not Linux.
RedHat, IBM and SAP are all cool about running this setup - but the IT department of this consumer electronics distribution company can't handle it effectively? I think I can see where the problem is...
The cynic in me suspects they got a VERY good deal from MS for publicising this move.
Forget thrust, drag, lift and weight. Airplanes fly because of money.
What amazes me is that they had IBM hardware and RedHat Engineers working on this and it still didn't work. I've installed Linux servers for 10 years and rarely have experienced such problems. Usually it was the hardware or my screw up at the center of it all.
:-D
Besides the reference they were running IBM hardware, I wonder what their configuration was. That's the tough part of these kind of articles. Very little information and a conclusion. Sure it was IBM certified hardware and it was ruled out as the problem. Perhaps the RedHat engineers simply screwed up. Not like that couldn't happen
"We asked the customer to do a diagnostic test and the customer never responded, so it was impossible for us to address the issue," Mr McLaren says.
I wonder why they never bothered to respond to RedHat. If it was important then they would have worked with the Vendor. I'd like to see someone work with ANY Operating System and ignore their vendors help. With these tidbits of information, it's difficult to take such a conclusion seriously.
Has Comcast disconnected your Internet account? Same here. You can read about it at http://comcastissue.blogspot.com
That's very true. SAP is a very complicated application and it takes an extreme amount of patience both to install it and to keep it working correctly. In other words it takes an administrator who knows how to interpret the SAP documentation and then follow that documentation in a very, very precise manner. I've installed SAP Enterprise on RedHat 2.1 more than a couple of times. The RedHat portion of the installation is so easy that I cannot imagine how anyone could screw it up. It's really the steps following the RedHat installation where an administrator can get into trouble. This includes memory settings and some really crucial environment variable additions in the system profile. Get one of these wrong and a SAP installation will quickly turn into a major headache. But if the instructions from SAP are followed step by step, then the whole process can be done in about 6 to 12 hours (depending on the speed of the machine). We currently have 5 SAP systems running on RedHat Advanced server 2.1 and I cannot ever remember an outtage that was related to an issue at the OS level. It has been a rock-solid stable set of systems that require little intervention. The SAP documentation is so stupidly complicated that one literally has to spend days reading it before attempting an installation. If these admins tried to shortcut that process, then obviously made a mistake. Thanks, - J. Haynes Helena, MT
Chances are, if they are running SAP, that box is loaded. Or overloaded. And then, things can sometimes get more dicey.
I've run busy mail servers hosting about 6,000 email addresses. I've seen a server run with a load average between 2.0 and 20.0, 24x7 for WEEKS ON END without any complaints. A full megabit of traffic, 24x7, just for EMAIL...
I've seen millions of website hits per month, month after month, year after year. No complaints, reliability simply excellent. And, I've seen this using Linux kernel 2.2, 2.4, and 2.6.
Sorry, pal. Maybe it's true for some other slashweenies, but in my experience, the reliability of Linux IS truly legendary, and is why I've standardized on Linux anywhere I can possibly use it.
Heck, when I'm putting together a new, high-capacity system, one of the first things I do is load a series of "torture tests" and run them. I put the server through its paces, running with a load average between 5.0 and 10.0, compiling the kernel or PHP in a loop, copying files, reading large files into memory and clearing memory out, while stressing whatever service the server will be using. (EG: if it's a mail server, while all the above is running, I have a script sending 10,000-20,000 emails per hour to 25 pseudo-accounts, while another script POPs them all to the bit bucket. If it's a web server, I have 10-20 wget shell scripts beating the webserver continuously)
Hour after hour, for a week or so.
A few disclaimers:
1) I make sure all the components for a high-capacity server (esp. the chipset & NIC) are on the RedHat compatability list.
2) When I'm buying hardware for a cheapie embedded server, I try to buy hardware that's been on the market for at least 6 months or so.
With this formula, I've had nothing but stellar results!
I have no problem with your religion until you decide it's reason to deprive others of the truth.
I live in Brisbane, and the area where Crest is situated is renowned for power supply problems - only the best UPS's will help. I'll bet that the guys who "fixed" the problems with WINDOWS supplied a new UPS with their gear.
Is it just me, or does this sound like an ad?
"I fully support Linux but if I had to make the decision again I'd pick Windows. A big reason is the fact Windows was up and running in two hours at all the right patch levels. The installation of SAP took two days on Windows, the installation on Linux Red Hat took two weeks. The total cost of ownership is actually lower in this case than with Linux because of the hidden costs of the support."
I feel like I'm reading a Microsoft brochure. And keep in mind that I *like* Windows as a desktop OS, for the most part.
I'll second al broccoli's response - the parent post is talking absolute crap.
I, we - the team I work in, have recently finished a migration of SAP4.6 on windows to SAP4.7 on solaris. The windows installation was formerly the largest single installation of SAP on windows in western europe, and it had severe scaling and support problems.
I also know from some years back, this having been discussed in an interview I attended, that Unilever, who before they switched held the crown for the largest installation of SAP on windows, switched to Digital UNIX (before it was Tru64) for exactly the same reason.
SAP on any OS has a hefty hardware requirement list. In addition, to my mind, they make some stupid recommendations about memory. Viz - for our setup we have multiple V440 and V490 suns with 16GB memory, and SAP want (and, on some servers, having hit this problem, *need*) THREE or FOUR TIMES that in swap. I would have suggested either less databases on each machine, or more memory (not sure if 16GB is the physical limit for V440/490) or just bigger machines, but then it's not my job to spec these things.
Anyway, having vast quantities of swap actively used as working memory may have contributed to the instability of a SAP system on linux, if as someone suggested that VM on linux is currently not as good as it could be.