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.""
...we will see what you have to say about hidden costs and core dumps.
Anyone that says that Linux will beat out Windows in every situation is a fool.
Choose the product that best suits your needs. If Linux doesn't cut it, get Windows. If Windows doesn't cut it, get Linux.
It costs money to hire qualified admins, Windows or Linux.
Obviously, your admins were not qualified to administer a Linux server like this. If it took them two weeks to get software installed and running like that, I'd fire them right away. Even if it is SAP, a complex piece of software. Just because you got it up and running in 2 days on Windows doesn't mean it was done right, or done securely.
I wish he would have given us more information regarding the problems he ran into. I'm talking about system specs, the name and version of the Linux distro used, and more information regarding the software they apparently had so much trouble installing.
When problems do happen, the open source community is notorious for getting them fixed very quickly. If he were to provide us, the community, with more details about the problems he encountered, I just know they could be solved for him and potentially for many other users in a similar boat.
Cyric Zndovzny at your service.
This whole article is useless without really saying what the crash was. You could have the most rock solid stable server in the world, and it won't mean much if the applications you're hosting are buggy and badly implemented. It would be nice to know to EXACTLY what crashes he was getting and why. Not just "Uhh, there were core dumps and blue screens, but with a linux blue instead of microsoft blue." I think this would be a great opportunity for an Ask Slashdot poll. Maybe he'd even post some of the core dumps.
That the decision to go Linux was made by his predecessor.
Looks like 'new manager' syndrome to me...
Quidquid Latine dictum sit, altum videtur (anything said in Latin sounds important)
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.
whereas you can expect windows to core dump periodically and predictably
You know, I've had that happen enough to care about - years ago, with older copies of NT, running on flaky/overheated/bad-sectored hardware. But I run things like SQL, or file services, or IIS under 2000/2003... and have machines that cook along without me doing anything month after month after month. No BSDs, etc. Yes, patch = boot, and that's a few moments of taking a machine out of a cluster for a minute... but not because the machine hangs while doing anything routine. For that matter, not even when I'm doing something non-routine.
This whole "Windows just crashes all the time" stuff, especially on the server side, is pretty much FUD. Bad RAM and drives can piss off Linux, too. Flaky commercial third-party apps can gum up any OS. But I sure don't have anything like the problems that so many people love to rant about - and even though I only have a running sample of a few dozen specific machines that I actually consistently lay hands on every week, you'd think that the mythical "predictably, always crashing" Windows server would rear its ugly head at some point. But it doesn't. The FUD's an anachronism.
Don't disappoint your bird dog. Go to the range.
You're the troll, not the trolls.
Do you observe that lately if someone puts Windows instead of Linux is news.
Just like: a dog bites a man is not news, but a man bites a dog is. That's telling.
"It is our choices, Harry, that show what we truly are, far more than our abilities." -- Prof. Dumbledore
for example, if you only have one copy of zlib on your system, and it's managed by the OS vendor (up2date, apt, or similar), then you only have one copy of zlib that can be exploited, and you only have to worry about applying your vendor's updates to keep all of your zlib activity patched.
if you have 80 copies of zlib, each one shipped by a different application that uses the library, you've got a frigging mess on your hands, and you've probably got no hope of patching them all if there's a security bug.
what we need is more centralization of libraries, not the wild-west free-for-all that would result from what you're advocating.
*nix usually gets a better reputation because corporations haven't had much opportunity to hire the off-the-street administrator with a degree in law and a certificate saying they can setup a server. That's changing and, as such, you'll start to hear more and more stories about *nix migrations gone bad and the like.
Of course, the major difference is that MS is just now learning to try and lock down their machines by default and force the user to unlock what they want to use. This makes the bad Windows admin have a higher likelihood of failure because they start with a bad setup and have try to fix things, instead of starting with good setup and trying to make things work with it.
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.
This argument is brilliant.
User A: I used SAP and had lots of problems and it didn't work and the consultants took lots of money and re-engineered everything around their system. SAP is always crap.
User B: I've used SAP for years and had no problems. You must be the problem. Never mind that I know nothing about your situation or your dealings with SAP I'm going to call you a liar and say SAP is wonderful.
Neither of you are being reasonable, but man, pass the popcorn! This is entertaining! Just like Jerry Springer.
These posts express my own personal views, not those of my employer
I'm definitely a windows boffin but have tinkered with Linux. My experience with both are the same, the kernel's are rock solid in both products these days and with the RIGHT device drivers. The only time you see kernel level crashes is when there are hardware issues usually as a result of buggy device drivers, or faulty hardware.
The thing I find with linux is that you invariably find hardware vendors drag their feet on the linux drivers as it's far more important to get the windows drivers to market (due to the market's size). I'm no expert but I have found unless your machine's config is pretty vanilla Linux can be really hard to work with. Rate me a troll, maybe I don't know what I'm talking about, but I just find windows with it's hardware auto-detection and out of the box support really kicks ass over linux.
Of course these problems aren't an issue with Apple and OS X as things are shipped as one complete package ready to work. If they wanted unix, maybe they should have gone apple....