Comment Huh? (Score 1) 960
Several things in that "article" jumped out at me right off. I usually read things like that two or three times to find the spin points and to think about whats being said while not being said. Given that, here are a few things that caught my attention on the first pass, and bug me even more the second time I read the article...
First, this: "Despite using a version of Linux certified by SAP and SAP-certified IBM servers, stability issues and the complexities of keeping Linux up to date and secure. . ."
I have run various flavors of Linux since I first downloaded an old version of Slackware off a local BBS way back when. Another post mentioned something that I agree with. I do soemtimes forget exactly how or why I configured something on my linux machines at home and at work because I configure them and they run. Period. I dont have to touch them again. My windows machine however, usually requires a reinstall every 18 months or so. Sometimes for an upgrade, and sometimes because it just stops working right. I dont know. Admittedly, I am not a windows person. Also, I can say, having supported end users and corporate customers on Red Hat Linux, administered RH machines, tested them professionally, and so forth, that the vast majority of stability issues I find fit into two groups. A: Issues with the OS. This almost always occurs, however, when I am testing beta releases. Almost never happens with a released version of RHEL, or even SLES. B: Hardware. Either bad hardware (usually attributed to a failing hard disk, a BIOS issue with a piece of hardware or a piece of ECC RAM that starts throwing double bit errors). Beyond that, I hardly ever see a stability issue with any linux that was not caused directly by me because of something I tweaked too much, or some piece of software that I installed that had issues that have nothing to do with the underlying OS.
The next thing that jumped out at me was this: "Crest's IT manager, Anthony Horton, oversaw the deployment of SAP on Linux in November 2004, after inheriting the decision when he took the job. Having previously run SAP on AIX - IBM's version of Unix - Horton was comfortable with deploying such a mission-critical application on Linux."
So what they are saying then, is that the IT manager DID NOT CHOOSE LINUX. He came into his job AFTER the decision was made and had been initiated. It does not take a project management genius to know that switching owners mid-stream during a major project is a Very Bad Thing[tm] in most cases. Also, since he "inheirited" the project, he had no real investment in it to begin with. His own statements later on point to him being a Windows guy. Kinda like those people who dislike minorities, but try to qualify themselves by saying "I have friends, but..." And running SAP on AIX makes it comfortable DEPLOYING SAP on Linux? Linux ain't Unix. Thats like saying I ran XX software on Windows, so I am completely comfortable running XX on MacOS because they both have point-and-click GUIs. Moron.
He then says he called contractors to install RHEL and ensure it was SAP compliant??? Umm, if he was so comfortable with it, why did they farm out the installation? Installing RHEL 3 is NOT difficult. I do it several times a day on test machines of all flavors. Its NOT DIFFICULT. If they cant even install the OS themselves, complaining later on about the "Difficulty" of keeping it up do date is superfluous. Another analogy: My car wont start. Did you put gas in the tank? Gas? You have to put gas in it?
The next complaint is that it took two full weeks to get everything set so that SAP would support the box and the software. Then only two days for Windows. Ummm.. duh. The hard work (ensuring supported hardware and components) was already done when they initially set up the RHEL box. Unless they just chucked the server out the door and configured a brand new one for the Windows install, which I really doubt, they didnt have to do even 1/4 of the work during the Windows install that they did when they did the Linux install. It had ALREADY BEEN DONE.
" It would run for weeks or so and then just bang, it would stop."
Ummm... hello memory leak. Can you hear me?? Memory Leak... or bad RAM... Either way, just the little bit stated here points to a very likely cause. RHEL 3 has run solidly on all sorts of machines in all sorts of corporate and industrial settings for a good while now. I have a real hard time believing that there is something that wrong with RHEL 3 that would cause catastrophic failure that hadn't alreay been found at this point.
""The thing that had me scratching my head was this particular hardware is pretty standard and it's actually already certified with IBM on this Linux kernel."
Another silly statement. There is a BIG difference between certified with IBM on this kernel and certified by Red Hat on this hardware. In most cases, unless the hardware vendor gets actual Red Hat Ready certification for $hardware, they have done some sort of compatiblity testing, but thats about it. There is usually a big difference between the two.
"Aside from the stability issue in this particular case, Mr Horton also found the total cost of ownership included soft costs such as the hard work required to keep Linux up and running. Software updates had to be manually installed to ensure SAP certification."
What I really found funny with this is that he bitches about the manual installation of patches... ummm.. but he has no problem with using autoupdate on Windows?? I dont recall having any hard work keeping a Red Hat server up and running. My workstation has Red Hat 9 on it (I know, I know) and it usually has a 6 month uptime before I reboot it. I dont even have to reboot it when I do. I just do it as a part of routine. My server at home runs RHEL 4 and has only been rebooted once in a year. And that was because I wanted to use a smaller kernel I had custom compiled with firewire support. And when I was an admin, I spent about 85% of my time keeping the windows servers functioning, and only about 5% of the time keeping the linux servers running. The rest of my time was doing website maintanence and other mundane tasks like spam filter writing and such...
I could go on, but I am at work and need to start doing something productive for the day, but just that first bit of the article speaks for itself. The whole thing boils down to this: An IT Manager who didnt know anything about the project initially takes it over mid-stream. He seems to think that running SAP on AIX is the same thing as building a new box from scratch and installing Linux on it to run SAP. They were so incompetent that instead of having their IT staff, which tried oh so hard to make it work, had to farm out the entire thing from the beginning to outside contractors. If they couldn't even do the base OS install, they certainly wouldnt have had much luck maintaining it afterwards. They couldnt possibly do auto updates through RHN on the SAP box with Red Hat, but have no problem doing so with windows, when windows updates are KNOWN to break software severely (Hello, Update 2 Calling...). The whole thing smells like a case of "We run Windows. We heard this linux thing was easier. Umm... Linux doesnt run like windows. We dont understand. We go back to Windows now."...
First, this: "Despite using a version of Linux certified by SAP and SAP-certified IBM servers, stability issues and the complexities of keeping Linux up to date and secure. .
I have run various flavors of Linux since I first downloaded an old version of Slackware off a local BBS way back when. Another post mentioned something that I agree with. I do soemtimes forget exactly how or why I configured something on my linux machines at home and at work because I configure them and they run. Period. I dont have to touch them again. My windows machine however, usually requires a reinstall every 18 months or so. Sometimes for an upgrade, and sometimes because it just stops working right. I dont know. Admittedly, I am not a windows person. Also, I can say, having supported end users and corporate customers on Red Hat Linux, administered RH machines, tested them professionally, and so forth, that the vast majority of stability issues I find fit into two groups. A: Issues with the OS. This almost always occurs, however, when I am testing beta releases. Almost never happens with a released version of RHEL, or even SLES. B: Hardware. Either bad hardware (usually attributed to a failing hard disk, a BIOS issue with a piece of hardware or a piece of ECC RAM that starts throwing double bit errors). Beyond that, I hardly ever see a stability issue with any linux that was not caused directly by me because of something I tweaked too much, or some piece of software that I installed that had issues that have nothing to do with the underlying OS.
The next thing that jumped out at me was this: "Crest's IT manager, Anthony Horton, oversaw the deployment of SAP on Linux in November 2004, after inheriting the decision when he took the job. Having previously run SAP on AIX - IBM's version of Unix - Horton was comfortable with deploying such a mission-critical application on Linux."
So what they are saying then, is that the IT manager DID NOT CHOOSE LINUX. He came into his job AFTER the decision was made and had been initiated. It does not take a project management genius to know that switching owners mid-stream during a major project is a Very Bad Thing[tm] in most cases. Also, since he "inheirited" the project, he had no real investment in it to begin with. His own statements later on point to him being a Windows guy. Kinda like those people who dislike minorities, but try to qualify themselves by saying "I have friends, but..." And running SAP on AIX makes it comfortable DEPLOYING SAP on Linux? Linux ain't Unix. Thats like saying I ran XX software on Windows, so I am completely comfortable running XX on MacOS because they both have point-and-click GUIs. Moron.
He then says he called contractors to install RHEL and ensure it was SAP compliant??? Umm, if he was so comfortable with it, why did they farm out the installation? Installing RHEL 3 is NOT difficult. I do it several times a day on test machines of all flavors. Its NOT DIFFICULT. If they cant even install the OS themselves, complaining later on about the "Difficulty" of keeping it up do date is superfluous. Another analogy: My car wont start. Did you put gas in the tank? Gas? You have to put gas in it?
The next complaint is that it took two full weeks to get everything set so that SAP would support the box and the software. Then only two days for Windows. Ummm.. duh. The hard work (ensuring supported hardware and components) was already done when they initially set up the RHEL box. Unless they just chucked the server out the door and configured a brand new one for the Windows install, which I really doubt, they didnt have to do even 1/4 of the work during the Windows install that they did when they did the Linux install. It had ALREADY BEEN DONE.
" It would run for weeks or so and then just bang, it would stop."
Ummm... hello memory leak. Can you hear me?? Memory Leak... or bad RAM... Either way, just the little bit stated here points to a very likely cause. RHEL 3 has run solidly on all sorts of machines in all sorts of corporate and industrial settings for a good while now. I have a real hard time believing that there is something that wrong with RHEL 3 that would cause catastrophic failure that hadn't alreay been found at this point.
""The thing that had me scratching my head was this particular hardware is pretty standard and it's actually already certified with IBM on this Linux kernel."
Another silly statement. There is a BIG difference between certified with IBM on this kernel and certified by Red Hat on this hardware. In most cases, unless the hardware vendor gets actual Red Hat Ready certification for $hardware, they have done some sort of compatiblity testing, but thats about it. There is usually a big difference between the two.
"Aside from the stability issue in this particular case, Mr Horton also found the total cost of ownership included soft costs such as the hard work required to keep Linux up and running. Software updates had to be manually installed to ensure SAP certification."
What I really found funny with this is that he bitches about the manual installation of patches... ummm.. but he has no problem with using autoupdate on Windows?? I dont recall having any hard work keeping a Red Hat server up and running. My workstation has Red Hat 9 on it (I know, I know) and it usually has a 6 month uptime before I reboot it. I dont even have to reboot it when I do. I just do it as a part of routine. My server at home runs RHEL 4 and has only been rebooted once in a year. And that was because I wanted to use a smaller kernel I had custom compiled with firewire support. And when I was an admin, I spent about 85% of my time keeping the windows servers functioning, and only about 5% of the time keeping the linux servers running. The rest of my time was doing website maintanence and other mundane tasks like spam filter writing and such...
I could go on, but I am at work and need to start doing something productive for the day, but just that first bit of the article speaks for itself. The whole thing boils down to this: An IT Manager who didnt know anything about the project initially takes it over mid-stream. He seems to think that running SAP on AIX is the same thing as building a new box from scratch and installing Linux on it to run SAP. They were so incompetent that instead of having their IT staff, which tried oh so hard to make it work, had to farm out the entire thing from the beginning to outside contractors. If they couldn't even do the base OS install, they certainly wouldnt have had much luck maintaining it afterwards. They couldnt possibly do auto updates through RHN on the SAP box with Red Hat, but have no problem doing so with windows, when windows updates are KNOWN to break software severely (Hello, Update 2 Calling...). The whole thing smells like a case of "We run Windows. We heard this linux thing was easier. Umm... Linux doesnt run like windows. We dont understand. We go back to Windows now."...
