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.""
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.
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.
If neither one cuts it, get FreeBSD. (Hey, don't forget about us!)
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.
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
*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.
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.
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