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.
"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.)
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.
limit coredumpsize 0 Thats how you keep the toilet from clogging
What is SAP? A Google search yields a company that sells business products, but there doesn't seem to be anything related to a point-of-sale system or workstation software. Is it an electronics design software?
Colin Dean Go a year without DRM
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.
what a load of crap.in all my years admining linux systems i have never seen ANYTHING even remotely close to a windows blue screen style crash. a user land process cannot blow away the system like that under linux. the only way this would happen is 1. bad hardware 2. idiots playing with kernel settings they shouldn't be.
either way none of this reflects on linux's stablity at all, just on the skill of the admin running it.
want another hint this is a case of a total retard running the system? "2 weeks to install sap on redhat"
even the most stable system will go bad with an idiot in charge.
If you mod me down, I will become more powerful than you can imagine....
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.
"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
"touch" the power button to turn it back on after it crashes.
Poor documentation, poor standards across distros, and obscure undocumented dependencies.
Yeah, this is a general problem with common modern programming languages. Dealing with dependencies is just hard since we've had a reuse model that is largely based on saving disk space by having one copy of a function.
Today, I'm convinced we need a system where every version of every library is stored and programs are able to use whatever version they have been tested against.
Yes, because we totally believe that you came up with that arguement on your own. "Total cost of ownership" is a natural concept which simply develops in natural language, like swear words based around bodily functions.
It's been a long time.
From TFA , a quote from RedHat support regarding Crest...
"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.
These Crest guy's didn't even have the ability to use support properly.
and
"We run Linux on our web server"
The entire company has 1 webserver? Unless he was missquoted this guy doesn't have a clue what his IT department should be doing.
Nuff said.
The person giving the references in this article did not seem to be the long time UNIX user he claims to be.
first: He put his experience with Linux into a windows context, suggesting that he is in fact an experienced windows administrator.
second: he did not understand automatic updates. A feature which is and has been available on many linux distro's for quite some time, and a feature which is quite prevalent in UNIX especially from IBM
third: Red Hat Linux (even enterprise class) does not have a very restrictive hardware requirement, and the odds are pretty good that they would have needed to do the same hardware upgrades to run whatever windows system they eventually moved to.
fourth: Anyone who is an experienced administrator knows that the core operating systems are tremendously stable, be it windows or Linux, or UNIX, and that the instabilities in any system will be introduced by drivers needed for operation of application specific hardware (for example a custom cash register based peripheral or some such). This tells me that they had just such a piece of equipment in their systems, and that the vendor of this hardware did not supply working drivers. Further, I would conjecture that said supplier probably had a long standing windows driver, and had ported the drivers to the linux platform specifically at the request of this client. The result is what you would expect: a first generation driver which fails intermittently.
-=Geoskd
www.geoskd.com
I wish I had a good sig, but all the good ones are copyrighted
I hate those *false* links that redirect to a registration page. Even if it's free, do they imagine anyone is going to fill those long forms for every page they visit.
Fortunately, the bugmenot bookmarklet did the trick.
About the story : so we have *one* situation where a problem happenned between SAP and linux. That kind of conflicts happens all the time in IT. Either you solve it or you change one component.
In both cases, drawing general conclusions on the abandonned product is common but unfair and a sign of lower qualifiquations.
Men are born ignorant, not stupid; they are made stupid by education. Bertrand Russel
You're the troll, not the trolls.
it's actually more difficult to properly admin a Windows box well
I find 00 buckshot works quite well.
Seriously though, IIS runs really poorly on Linux too. Insist on such combinations and you get what you deserve. Did anyone investigate SAP before spending two weeks trying to get it running? I also find it quite hard to believe that they were getting crashes every week or so. Although I avoid RedHat...
The it person came in for the change and had a background of SAP on AIX.
RTFA or shut up.
Men are born ignorant, not stupid; they are made stupid by education. Bertrand Russel
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
Only an absolute moron would admit to that. You have idiots working for you fire them immediately! With absolutely no experience with any unix/linux system and very little windows experience, I setup a mail server, webserver and started creating a website for a company. I did that back in 1996 with RedHat 5 & a Linux for Dummies Book. Linux has come a long way since then. If they can't figure out how to install a modern linux distro in less than 4 hours, you should not be let near any computer ever! I could build a PC clone system from parts and install Fedora Core 4 configure it with apache, mysql, ftp and secure it before lunch. I've done it several times at work.
*Every* major distribution has a full package manager that does dependency installation for you - automatically!
Even if you want to install something that isn't packaged for your distribution, you can still install the dependencies with the package manager, and what they depend on recursively will also be installed.
Oh, you can update everything on your system with one command, too.
Things have vastly improved since the days of manually tracking down software. Well, in Linux they have.
Bob's phone sales in Milwaukee has decided that Nokia is better than Motorola. And Viadork Systems has decided that Toyotas are better than Mazdas. Seriously, though, since when is this news?
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.
Unless I missed something, red hat cerified engineers came in and configured the box. The guy had previously ran SAP under AIX (which is not linux by any means). The rest of the time it was under control of the regular admin whether it be an AIX guy or Windows guy. Red Hat Australia support asked if they could run a diagnostic test, but the customer never got back to them. I don't care what that article stated, what they are claiming just doesn't happen. It was either a faulty piece of hardware despite what IBM stated, or a faulty admin and no people are pointing fingers in other directions. The only other thing would be if they were running a custom kernel. This is not linux's fault, if the same exact thing happened under Windows, I'd also be claiming that this series of events is most likely wrongly being correlated to the OS.
Regards,
Steve
I have installed systems for customers of mine that had to be reliable. We have run into our share of problems on both Windows and Linux. However, our experience is that *when used in the right areas* Linux is easier to troubleshoot and maintain. Sometimes braindead applications cause high CPU load meaninglessly, but I have never seen this bring down a Linux system.
Case in point. The most unreliable system I ever installed was a Linux server for a small retail management installation (2 registers, one server that was supposedly fault tolerant, etc). Well, we ran into two problems. The first was that the application was sitting on top of PostgreSQL and was trying to do an outer join between a very large table and two empty tables. Since PostgreSQL assumes that zero-length tables are really say 10 pages in size, it was doing a nested loop join against two empty tables every time the new invoice window would be opened, meaning that the registers were full, the 20 seconds or so was not only slowing the business down but also causing the server to be under very high load most of the time. No problems from that aside from poor performance. We did, however, hack the application to make it stop such braindead behavior.
However, a few weeks after we were able to fix this problem, we started getting database server errors (most commonly corrupted hash table messages). These were intermittant, but usually occurred at about the same time every day if they occurred at all. Turned out to be hardware failure of course.
In neither of these cases were the problems the fault of Linux. One was a correctable hardware failure and the other was a correctable softrware error. OTOH, I am not brave enough to try to run SAP on Linux.
LedgerSMB: Open source Accounting/ERP
the problem today with gazillions of copies of the same library isn't that they waste disk space -- it's that they each present an independent pathway for security failure.
Yeah, this is another difficult problem. How do you ensure that security updates are applied.
If you have something better than a linear versioning system, then you can distiguish between security updates and other sorts of updates. I still think you need a system where you have multiple versions of libraries that are functionally different. I think it's just a fact of life of software development. Libraries aren't going to just stagnat.
Also, if you notice that everyone is like "well they are using SAP, so they should be using Windows duh!" But if someone posted an "Ask Slashdot" and said "Were is installing a SAP solution, do we pick Linux or Windows". They would probably laughed at for even considering Windows.
Saying Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders.
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.
Who would choose to use a distribution called "Unreliable Linux"?
If you're rebooting because of patches that often, you're running the wrong OS.
The only reason to reboot a 'nix system is if you're patching the kernel. We've got systems (bastion systems that do email filtering, very stripped down) that have uptimes coming up on two years. Yes, the applications and services have been upgraded and/or patched a few times, but the (linux) kernel hasn't needed it, and it's still going strong. (Heck, we even discovered one crazy process that leaked about a meg of memory a day -- a cron job to restart it every month took care of that until we got an update.)
-- Alastair
"Most problems with Linux on the desktop are problems with X."
I couldn't disagree more. There are usability issues, documentation problems, missing features, etc. None of this is caused by X. I have seen _zero_ evidence that X11 is in any way a problem. The protocol is great, and I think we'd be nuts to ditch such a powerful, network transparent facility. As a developer, I'm not fond of the Xlib APIs, but there's work to replace Xlib now. The XFree86/XOrg implementation of the server could be better built so that it was in many small parts - but that's only a problem for people doing lots of low-level distro hacking, and for distributors. Again, there's progress to modularize it anyway.
X11 is not slow. Some X11 drivers are slow, but that's a driver issue and changing the window system will still leave you with crap drivers. For that, you need people who really understand the guts of the hardware, and you need good documentation. I should note that my system is *extremely* snappy under X11. In general, I find decent ATi and NVidia cards get very good results. If you're talking about 3D, that's in my view quite separate - but again, comes down to driver support and no documentation from vendors.
Nothing in X11 makes apps that use X11 ugly. Seriously. It's *WAY* too low level. Your complaint is most likely with the toolkits, themes, etc. If not, I'd be interested to know what in X11 you think causes the problem.
I'll certainly give you the points on X11 configuration and maintainance. I personally find it pretty painless, but then I have good hardware. I also find X11 to be very stable, though there have been times in the past I've sworn rather loudly about it (usually due to bad drivers or hardware).
The VT system could work a lot better, and I'm looking forward with enthusiasm to the move of much of the frame-buffer programming back to the kernel where it belongs. That should help solve a number of irritations.
I suspect you may have hit the reliability nail on the head if you're talking about rebuilding Xorg/XFree86, fontconfig, etc. If not done very carefully and with a good knowledge of the system, you'll quite possibly break things here. In particular, you need to be 100% sure that your new versions are ABI-compatible, unless you isolate them and only use apps you built against them with them. Your comment suggests that you do not, since Fontconfig has nothing to do with font rendering, and if there's anything you should be rebuilding (but you don't actually generally need to) it's freetype.
Of course, I find I get extremely good quality fonts anyway, so I can't say I've ever felt the need. Fonts under Linux used to be horrific - eye searing examples of pure horror. This has, in my view, been entirely resolved by recent freetype libraries and the ditching of X core fonts in favour of client-side rendering.
I personally find X11 one of the most attractive things about Linux. There are some issues with the implementation, but the power and flexibility of the protocol is not something I'd want to give up. I do agree that it could use some more work, but I'm unwilling to whine about it when I lack the time, skills, and motivation to do it myself. I personally think the current X work is important, and it looks like it'll lead toward more radical enhancements once the more basic issues with the codebase are addressed.
In recent years, I've never seen a Windows server crash, and the last time I saw a Linux server crash it was due to failed ram. They're both generally as stable as the hardware, drivers, and other software you use them with.
I have had much more patch downtime on Windows because it has to restart (usually minutes) while on Linux only the services usually need restarting (usually less than a second), but even then we install patches during off-hours, and most patches are really optional.
We run mostly Linux servers, but some server software (our ERP for instance) is only supported on Windows. In this case I suspect it'll run on Linux, but I'd rather run it on a configuration that's supported, tested, and recommended by the developer. So we bought a Windows server just to run this one piece of software, the most expensive server we've ever bought, but less than 1/10th as expensive as the software itself. In this case our decision of which operating system to use had nothing to do with which operating system was better.
Patching is done every quarter (3 months) and the patches available are applied after evaluation and testing. Just because you don't reboot after every patch does not imply you will have years of uptime. I have been supporting Linux for many years and not a year has gone by that a kernel patch didn't come out that required installation for one reason or another. Patches don't only fix security issues, they some times are used to improve performance and stability in certain enviroments.
Patching in general and especially kernel patches are more important in "high-availability" systems.
This patching does not mean you are taking the entire enviroment down though. Doesn't everyone run there "high-availability" systems in clusters? You simply take one node down at a time and patch.
How often do you patch your systems?
I *know* this guy is not an admin. He is MIS, at best. *Huge* difference. This guy gets paid to write reports and macros for applications for whatever software this businesses uses, clearly SAP, not to install or administer servers.
I mean, just listen to him. He outsources everything. He seriously believes all operating systems are the same. He complains about having to spend two days a month updating and testing. Then he goes on to include this work in an increased "total cost of ownership" for Linux, completely ignoring the fact that it's his job and he's being paid whether he does it or not. He doesn't know the difference between an application failure (core dump) and an OS failure (panic/oops). And, to top it all off, he thinks autopatching is a great feature.
Lots of "small" (multi-million dollar) businesses make the mistake this one has: they think they can get away with having just one "admin" who is really MIS, who spends all of his time dealing with the business side of things rather than the computing side. To maintain the illusion that this is a workable combination, they switch everything to Windows and spend almost as much on licensing and consultants as they would on a competent admin. Then they wonder why their customers' credit card numbers mysteriously show up on the 'net.
News flash to all the "small" businesses out there: well-maintained computer infrastructure can replace 50% of your employees. Skimping on IT personnel is a stupid, stupid mistake. You can afford to have *both* a proper IT guy and a report-writing business grad. Despite their misleading marketing, Microsoft software is not a substitute for a qualified admin.
"I assumed blithely that there were no elves out there in the darkness"
Everyone knows the Apple Store, one of the largest online stores, runs on.. oh, wait.
We do know that Macs are useless for clustering and could never be used to build a supercomputer.
I know, old ideas die hard.
Read the EFF's Fair Use FAQ
This thread seems especially pointless, even for /. -- there is not enough information to infer anything at all. There is no such product as "SAP", so no one could have installed "SAP" on Win32, Linux or any other OS. There is, however, an SAP AG that is a vendor of an imense suite of ERP products.
I am currently involved in an SAP Netweaver '04 implementation at one of the largest SAP customers in the SF Bay area. I have to admit that I have no experience with SAP software on a Linux platform -- my experience is with ERP 2004/Netweaver 2004 on Wintel and Solaris. Even so, I think I am accurate in stating that any significant part of the suite that you install on either of these platforms would not be useful in just a few hours. You probably won't have finished installing the base components, the patches, the service packs and the relevant business packages until towards the end of the first day. And then you still would not have even begun the lengthy task of configuring all the backend architecture to play together. And keep in mind, this is NOT a single server business solution, even for the smallest SMB customer!
So, what exactly does it mean if someone claims to have "SAP running" on a box in a couple of hours? It sounds kind of like a mail server with no network interface -- runs like a champ for months on end, no problems!
Maybe I'm missing some deeper insight, but this so-called "news" tells me nothing about SAP, Linux, Windows or Crest Electronics. Nada. Zilch. Click the back button and keep scrolling folks, there's nothing to see here.
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.
I also deal with this shit all the time. Find me a MCSE that understands any real OS and I'll show you a salesman.
Unix? What's that? Microsoft invented the IntarWeb! Ack.. die you stupid fuckers.
when you have your servers up in 2 weeks instead of two might cost some dough .... but stability costs less at the end ...
...
...
.. if you have 24hr support sitting on a reset button windows might be OK, if a reboot costs you heavy dollars and long distance calls and several minutes of services down you should choose 2 weeks install and no reboots..
when your servers on windows will blue screen at the middle of the production day that wiwill most likely cost a lot more on the long term in productivity loss and people sitting in their offices not being able to access resources
yes i can install windows box in 30 minutes with webserver, however i have bsd boxes running 365days+ with dns/apache restart and having a good sleep while my non windows machines run is just cheaper me than having a blue screened server for 8 hours and loose customers or receive pages to "fix that crap" in the middle of the night
of course your mileage might vary
just a note: how can an installation of a software last 2 weeks vs 2days ? Same software ? I know sometimes clicking a defult config together takes less time than building a config file (text) from a bad template/example but 2 weeks ?
God created all that in 1 week! (including basics for SAP and Linux in a way) -OK He knows more than us I guess
this is a server we're talking about, it's not supposed to have a gui ;P
sum.zero
that we are going to find out that the baby's daddy is really PeopleSoft?
I mod everyone down who says "I'll get modded down for this." I hate to disappoint.
thats says it all in a nutshell i think. he's a retard.
If you mod me down, I will become more powerful than you can imagine....
If you have an MCSE certification it doesn't automatically make you competent to administer a Windows network.
I've had MCSEs call on me for help with simple networking problems.
I find that many qualified people just forget what they've learned. I even have the same people calling me up every once in a while, with the same questions, purely because they keep making the same mistakes.
It may just be coincidence, but, I find that the most incompetent MCSEs are those who go out of their way to tell you they're an MCSE. They seem to use it as an excuse for their incompetence - like saying "Well, I was smart once!"
: )
Linux/Open Source/Anti Microsoft News
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.
So in other words, hardware fault that they never bothered to trace. What's the bet the Windows system was on fresh hardware?
I run a 2-core HT Xeon system @ work, it looks like a 4-way CPU. This is great for finding race condition bugs in my software -and other peoples.
my core troublespot appears to be cups, which will spin at 100% of a CPU within a few hours of starting. So I have to restart cups every morning. This is so, irritating. I suppose i could just get cron to reset it for me, but still.
Whereas on windows, I havent had to reboot my laptop since, what, yesterday, when the clipboard stopped working. I didnt even know the clipboard could stop working, but no, you can suddenly stop being able to cut and paste. Trust me to be the one to find out.
I've installed SAP r/3 on Solaris and Linux... never a problem. Yes it's complex, but hey - that's what's fun about being a sysadmin! One thing to keep in mind folks is that it's a GIANT fucking database - tons and tons of tables. And like all databases, you have to care for it and feed it.
That means watching memory usage, extents, indices, disk controller utilization, network interface utilization, swap space, processor load, and on and on and on.... And trend it all out... then monitor some more - when you see the problem, you fix it. Sometimes that leads to other problems that get exposed as you move up the line - but when it's all done the system rocks...
I know this because I've built HUGE systems used by thousands of agents every day... they run on Sun E10000 boxes, E4000's, HP K-class boxes and so on... If you're installing SAP and you can't handle the diagnostics - get the fuck out of the computer room and go back to asking if you'd like fries with that...
I read the article and thought that the guy had a bunch of dingos for admins...
And he isn't the least, tiniest bit a paid shill to spread patented MS-FUD!
No, sirree. But you never saw a better recipe for a flame-war on Slashdot. How should we do this one? Doom-style? NeverWinter-style? Quake3Arena-deathmatch?
Why does your linux server ever need to be under "heavy load"? Aren't Linux boxes supposed to be cheap to set up so you can have yourself a nice Linux cluster and balance the load so you are never running above 50% or something like that? If you buy a cheap server - and run it near 100% all the time - then you deserve to have problems! Dude. Upgrade your hardware.
Horns are really just a broken halo.
This is a problem I have noticed with Linux many times. On the whole, Linux is incredibly rock solid. But there are rare instances where specific combinations of Linux software and hardware will cause crazy problems. For example, at one time there was a problem with APIC in the kernel. If you had an nforce2 motherboard and a kernel with APIC enabled it would freeze up semi-randomly. 99% of people did not have this combination, so it wasn't a problem for them. But for the 1% of people who did, how were they supposed to figure it out? Only if they are very involved in a Linux community would they discover this.
Another problem I had was with the combination of Ubuntu, Nforce2 IGP, the NVidia driver and not having DDR Dual-Channel enabled. This combination brought about frequent freezing. But who could know without good googling skills that this combination was the cause of the freezing?
I'm willing to bet that this guy had one of these weird combinatory problems. It just goes to show that the Linux testing procedure is not 100%. But switching to Windows when this happens is basically just claiming ignorance instead of figuring out why it's crashing and fixing it.
The GeekNights podcast is going strong. Listen!
Crest Electronics IT department deemed incompentent, laughing stock of industry.
The difference between Canada and the USA is that in Canada healthcare is a right and gun ownership is a privilege.
I understand the love for Linux (or rather hate of MS). To each his own. However, in this situation it is a common problem that companies are having with Linux. 2 weeks to configure and deploy. Come on, that's ridiculous. This guy had a business need and needed to get the job done. If you can't understand that, then you'll be unemployed 6 months after convincing management to make the switch to linux and you still haven't gotten the entire enterprise up and running. Also, and read this slowly so that you don't pass out: LINUX CRASHED.. Now, the hardware was blamed and then the administrator. What's next, code fairies???
It seems like the admin never really wanted to be on Linux in the first place and his knowledge of Linux is highly lacking. The fact that he knew nothing more to describe his problem than "blue screen of death" shows which OS he wanted in the begining.
I've had ongoing issues like that before of random crashes spaced weeks apart (userland software problem, not OS problem). I worked with the vendor very hard and we got the issue resolved over the period of a few months. Some suggested we switch to windows. Myself and my contact at the software vendor didn't think it was a good idea. In fact, it wouldn't have been a good idea, because there was a corruption in the data itself that was crashing it. An OS switch would have been loads of time and effort, just to have the problem still be there.
The fact that he never even returned Red Hat's calls leads me to believe he really didn't want the problem fixed. He wanted to make Linux look as bad as possible to his superiors so he could switch to what he really wanted. I doubt the whole operating system crashed. A misconfigured SAP was probably crashing and he was too incompetant to be able to tell the difference.
Also, what lameass autopatches on a mission critical server? That's such an incredibly bad idea. I'm sure all Red Hat's patches are of the highest quality, but if downtime could be a problem at all, take 20 minutes out of your day to look over the patches and make sure none will conflict with your particular setup. There's no replacement for human intervention if it's that important.
Ultimately I highly doubt the problems are rooted in Red Hat or SAP. They are rooted in a stubborn admin who didn't know what he's doing on Linux and found it easier to blame everyone else.
If an officer ever threatens to taze you, say you have a pacemaker.
What he's saying isn't so far fetched:
SAP "Supported configuration" is such and such version of Redhat Linux at a very specific patch level. I.E. This specific sub-release of glibc and the kernel that Redhat has published. If you let up2date or rhn automatically update the server, we won't support you because we've only tested at this certain level.
Now why that's ANY different than Windows updating itself is beyond me BUT I have a feeling that since he mentioned installing a Windows SUS, that SAP will support automatic Windows updates, as long as you control the update server. FYI, you can also do that with a Redhat Satellite Server but it costs money whereas Windows SUS does not (other than the cost of another server license).
One of the problems that we've seen with RHN updates is that older versions of packages are not available if a new one comes out. This has caused us problems in the past with our TSM server.
Case in point:
IBM in thier infinite wisdom decided that the Tape Library driver would not only check for the specific version of the kernel RPM but also check for the specific subrelease! I.E. kernel-smp-2.4.9-48.i386.rpm was supported but kernel-smp-2.4.9-65.i386.rpm was NOT. This drove us batshit because we went to install a new TSM server and we had two kernel choices, keep the one on the install media which had known bugs or upgrade via RHN to the newest kernel that had the performance bug squashed. Meanwhile the driver was only available for a release somewhere in between those two and RHN wasn't making it available for download anymore. The RPM installer for the driver (which was only available in RPM) refused to install if you didn't have the specific subrelease! The only way around it was a little rpm2tgz magic and remain "unsupported" until IBM saw fit to release a version of the driver for that kernel.
What ended up happening was that a NEWER kernel was released shortly after that. IBM built to THAT kernel instead of the one we had so we were forced to do a kernel upgrade just to install the driver.
Now having said all that, I can understand why this guy might have had to deal with that if SAP were a hardware vendor but they aren't. As MANY people have mentioned before in this thread, the problem really lies with SAP and the fact that the product will only be "supported" at very specific levels of certain Redhat packages.
The only real choice is to make sure you download each and every package that get mentioned in the errata from RHN when it's announced and then wait for SAP to announce which combination is newly supported and upgrade at that time. If you don't then you may be SOL because a package could be superceded in RHN and you won't even be able to get that package again.
"Fighting the underpants gnomes since 1998!" "Bruce Schneier knows the state of schroedinger's cat"
Comment removed based on user account deletion