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.""
"the machine would basically, putting it in Windows terms, core dump or blue screen at random"
whereas you can expect windows to core dump periodically and predictably.
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.)
It may be true in some cases that Windows runs more stable than linux. I have seen some flakeyness on more bleeding edge distros, X11 crashing, apps crashing. One of my boxes, I have troubled hardware support for my Promise SATA controller and large data transfers would cause system lockups all the time. Supposedly this is fixed in kernel 2.6.12. But I'm running Windows XP on that machine so I don't really know. But really, XP stablity isn't all it's cracked up to be. I have to reboot often (~once a week). Things just slow down and get really sluggish after ~ 2 weeks, or less.
But hardware/driver issues aside, I don't believe Windows can be more stable than linux. If you don't have to run Windows for some specific compatibility/software requirement. Linux can be a far superior experience.
Qualified admins are never cheap.
I've never hired a dog that was an MCSE.
I did hire an elephant once. He remembered everything and worked for peanuts. We never had a second problem with a computer if he troubleshot the first one. Amazing what a good stomp will do to a system.
Coding Blog
I've known many, many, many people who swear by Linux's reliability and uptime. When I look at their load usage, it's alway like "0.01, 0.01, 0.02" or some such low usage box. Chances are, if they are running SAP, that box is loaded. Or overloaded. And then, things can sometimes get more dicey. A device driver that works okay under low-load is fine, but then when the commands are stacking up it barfs. Or some hardware that's been only marginally fast enough is exposed as underperforming (especailly hard drives and FSB). Performance degrades quicker than expected very often, and resources can easily become exhausted. I love Linux, but often people who swear by it have never seen the pain of a truly heavily loaded Linux box. It's much better now that a lot of sweat has gone into the scheduler.
When a program dumps core, it means that the program did something that it wasn't supposed to do (like try to read memory that isn't valid) and the operating system has (correctly), stop the program's execution, and to make life easier on developers, copied the program state into a handy file so that the problem can be debugged. No other programs on your system will be harmed by this one malfunctioning program.
When Windows blue screens, it means *the operating system* has done something it wasn't supposed to do (like try to read memory that isn't valid) and the operating system bails. Often, it will return execution to the next instruction and hope things will be okay. It almost certainly isn't. You're basically screwed.
The equivalent in Linux is an Oops. They don't happen that often on production systems. A crappy properitary program doing things it's not supposed to is *not* a Linux problem nor an Open Source problem. It's SAP's problem.
This is a testimonal about the crappiness of SAP and nothing more. They obviously didn't do enough testing on Linux.
"The Best Run Businesses Run SAP" is a true statement... SAP says it over and over again. What they're really stating is that only the best run businesses can survive a SAP implementation, the rest run out of money or patience, or worse, end up being driven out of business by the enormous cost and disruption it causes. SAP has a HORRIBLE track record on linux. They claim support for linux and other non-MS platforms, but that's only for their core products. Everything outside of CRM and R3 is riddled with technotes and disclaimers about needing MSSQL and WINDOWS. They don't really write cross-platform systems, they just make claims and back them up with fine-print disclaimers.
I just left a company that was $10M and 2 years behind on their "$2M" SAP implementation. It's a joke. Once SAP gets their foot in the door, they flood your company with incompetent consultants and rebuild your business around SAP-approved procedures and architecture. At the end of this clusterfuck you end up WAY over budget and desperately looking for a scape goat. Clearly Crest Electronics chose Linux.
SAP products require patch after patch, and take MONTHS to really install. We had a team of engineers working around the clock (literally) for 5 months to get our base systems set up to SAP specs. Even then we would receive "mystery" patches, frequently resulting in system crashes as they weren't designed to work with other patches. Bottom line - SAP is the problem. They churn out highly unstable software and have armies of consultants who will sweep problems like this under the carpet or find something else to blame.
Blue screen is a Windows thing but core dump is not.
Crest Electronics is trialling Microsoft's Windows Server Update Service, which allows automatic patching for the operating system and other Microsoft software on servers and desktop machines across a corporate network. Its benefits are one of the key reasons why Mr Horton stands by his decision to switch from Linux to Windows.
"We run Linux on our web server and for an accounting package with great success and we do use the auto-patching in those environments,"
I work in a Windows shop but we don't do automatic patching. We don't patch until we've done extensive testing on our own to make sure it works in our environment first. SUS/WUSS/whatever is great in the sense that it allows you to control how patches to your Windows workstations are distributed. You can change the workstations' auto-update behavior so they only update from your SUS servers, etc. But the automatic update thing, from what I've heard, is rarely used in a production environment. In fact, Microsoft gives you a considerable amount of control over its behavior, probably because in recognition of the dangers of auto updating in a production environment.
Mr Horton disagrees: "It might be fine for things like security patches, which don't impact SAP certification rules but with some patches you still actually have to check the release levels and then check against the SAP site. Otherwise SAP might ask you to roll back to the previous version before they will support it."
Give me a break! The same thing happens in the Windows environment. It took Bloomberg and our other vendors a while before they supported Windows XP SP2. When SP2 first came out, a lot of vendors blamed SP2 for problems that may or may not have been SP2's fault. It took Windows vendors a while to adpot SP2 as well.
In any case, the whole patching issue he takes with Linux seems absurd. Just a few days ago, I think our server guys patched their cluster with a Microsoft service pack. Now the cluster refuses to fail over properly. Patching in a production environment is ALWAYS a big headache if you want to do it right. Unfortunately for our server guys, we don't have a spare cluster sitting around for them to test patches on like they normally do with other servers.
EvilCON - Made Famous by
If neither one cuts it, get FreeBSD. (Hey, don't forget about us!)
It's a German company that sells quite rather a lot of software. Whole large businesses run on it, and a cheap installation starts in seven figures and goes up from there. It's a serious suite of software. Check "SAP Specialist" in your favourite job search engine and check the rates they're getting for clue 2. They're big, as in first-page-of-Hitchhiker's-Guide big.
Do not mock my vision of impractical footwear
from TFA: "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.
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
Yeah, please don't hurt the feelings of both of us!
But, seriously, BSD > any Linux flavor > Microsoft's sorry-excuse-for-an-OS.
The BSDs don't have the fragmentation that Linux has. If anyone asks me what is my OS, I say simply "FreeBSD". By that I qualify my package management, my system boot scripts, where my conf files are, how the system works. "Linux", on the other hand, can mean a bunch of things: maybe the kernel, maybe one of those hundreds of distros, each with its own idea of package management, file placement, system configuration, or boot method. Of course, they are all Linux, they all run roughly the same software (Apache is Apache no matter in which Linux distro you run it), but the details, the little differences, do hurt Linux (okay, Stallman, GNU/Linux, as you wish) by making it into a moving target for support and maintenance.
Back on topic, that Linux machine must have had some hardware flaw. Bad memory comes to mind...
Stupidity is an equal opportunity striker.
Fellow slashdotter Bill Dog
That's if you're lucky, normally they'd throw a chair at you.
Wow, this is just so uninformed. SAP is just as easy to install on Linux (for those that know Linux) as it is to install on Windows (for those that know Windows). SAP development started on Unix. It is more mature there - always has been. SAP's Linux product comes from the same codebase as it's Unix product. Windows is not the same codebase. You tell me which you think is more "mature". I've been running SAP on Unix for 10 years now, and on Linux for over 3 years now. Never a single issue that wasn't already documented somewhere.
Who would choose to use a distribution called "Unreliable Linux"?
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.
Sorry but that's one of the dumbest things I've read in a while.
You're noting that the name "Linux" covers a broad range of things, and comparing it to the name "FreeBSD" which refers to one thing. You're then trying to say that "the BSDs don't have the fragmentation that Linux has". I call bullshit. Your example proves nothing remotely near that. It proves that FreeBSD isn't fragment, but then neither is the Debian project's distribution.
If I say "I run BSD" then there at least 3 different systems I could be running. Would you then say that "the BSDs have fragmentation just like Linux does"?
Inversely, if I say "I run Debian" then "I qualify my package management, my system boot scripts, where my conf files are, how the system works".
Sorry, I'm not normally this harsh, but what was your point again? If you try to compare Linux to FreeBSD then yes Linux will appear more fragmented. But how about we compare FreeBSD to Debian shall we? Apples to apples? Does your argument that it "damages" Debian still hold?
At one job, a few years ago, I installed a small, simple SAP program, SAPRouter. It was basically a program that would route net connections over a modem into a foreign network. I don't remember the details very well, because it has been six or seven years, but some of the stuff I definitely do recall. My memory of cursing, intensely, for DAYS is clear and bright. SAPRouter was among the stupidest pieces of software I've ever been forced to work with.
It was just bizarre. Out in left field.... way, way out. They implemented an entire routing protocol, kind of like IP, but very poorly. It was completely unrelated to any other form of routing I've seen.
From what I remember, you had to install the router software on a PC that had a modem. That was going to do the call out. (VPN wasn't common at the time, you had to use a modem for a network backdoor.) But then you had to configure the client to talk to that PC over the network... and you also, if I remember correctly, had to tell it about every hop it had to take in the foreign system.
In other words, it would be like having to manually configure your PC with every hop between you and Slashdot before you could read web pages. And if one of the hops changed, well, too bad. No Web for you.
There was more, too, lots more, but I have lost the details. All I remember is that it was problem after problem after problem for DAYS. And this is relatively simple software.
The documentation was horrible too. It made no sense at all. (which shouldn't be that surprising, really, since the program made no sense either.) SAP was kind of bleeding edge in one regard, and provided fairly complete Web documentation. Sadly, instant access helped clarity not a whit. I ended up taking three or four days and making repeated calls to SAP to get the stupid thing working. It felt like I was trying to push my head through a cheese grater. I'm not an idiot... I was learning IP routing at the time, and I can assure you, it was _trivial_ in comparison.
In some ways(the bad ones), SAPRouter reminded me of learning Netware for the first time. Netware was full of weirdnesses that didn't make sense at first. But after you'd been working with a given feature for awhile, nearly always there was an 'aha!' Netware had a payoff for the struggle... you'd finally see why they had modeled a given problem the way they had, and it was inevitably elegant, powerful, and aesthetic all at once. It was hard to figure out their context, but once you did, their solutions made beautiful sense. They thought out problems incredibly thoroughly, and solved them completely.
SAPRouter wasn't like that. It felt like, well... like a bureaucracy that's very sure of its own brilliance. They reimplemented, badly, what IP was already doing. It was grossly inferior, complex when it didn't need to be. Once I understood their context, and why they solved the problem how they did, my conclusion was that they were idiots. It felt like something designed by people who had *no idea* what routing is or how it should work.
To be fair, it was nicely stable once it was up. I didn't have to fool with it anymore after it was (finally) running.
Basically.... don't be so serenely certain these admins are idiots. The reason you're good at figuring this stuff out is because smarter people than you (or me) took the time to make it (relatively) easy. They chose good models and clean implementations, so the programs are fairly easy to configure and use. You being good at building solutions from open source stuff is partially your brainpower, but the lion's share of the credit goes to the original designers. You had an easy time of it because, for the most part, the software is fairly easy. It could have been far, far worse.
It could have been SAP.
I'm a *nix (FreeBSD & Solaris preferred, but Linux too) admin, but in this circumstance I would have switched to Windows too. TCO is really more important than ephemeral "but you can fix it yourself" claims. Especially since, if you RTFM, they can't - they can't get support unless they are running a certified operating system. So they can't tweak it, they can't just automate their patches - it's an admin's nightmare! Good on him for switching to the OS that works. Sorry, RedHat.
;)
Right tool for the right job. Most of the time I think Unix is the better tool, but sometimes you don't need a swiss army knife. Sometimes you need a hammer. Windows is a very effective hammer