Thursday, November 17, 2005
Opinion: New Linux study suggests fundamental Microsoft creditability problems
Wait, this isn't news, is it???
http://www.linux-watch.com/news/NS6557933549.html
[edit]
I've gone and read some of the study in question now. Not too impressive.
First is all the commentary about "Out of support" packages on SLES 8, while SLES 9 is available (and with those packages that are out of support in SLES 8!!!). Hmm! Maybe the applications that required those out of support packages were written towards distributions of SLES 9's vintage. Rather than upgrade 1-2 packages "out of support", I would expect a competent administrator to upgrade to SLES 9 or find an application compatible with SLES 8.
Rather, 3rd party extensions/products were chosen that operated both on Linux and Windows. Though of course, the specific application isn't disclosed, nor were the versions of those 3rd party products discussed.
Second, again with the "Out of support" packages. The report indicates that two of three of the SLES (*ahem*) administrators completely broke their servers while trying to upgrade glibc. I have to question the competence of the admins they selected. No backups? No knowledge of how to deal with this type of issue at all? Why were "third party extensions" to their "custom" ecommerce platform selected that weren't compatible with the existing platform?
The footnote at the bottom of page 3 is telling in this regard. Tallying non-version-specific "Windows" experience vs. non-version-specific "Linux" experience and having some version-specific requirements as well doesn't quite add up. What would the Windows administrators be getting experience in if not Windows 2000 or 2003?
Third, there is a mention of one of the Microsoft admins calling "Third party product support". Didn't the SLES administrators have similar options available?
Fourth, the number of patches installed, and the conveniently "monthly" patch cycle. Convenient, as Microsoft has a monthly patch release cycle. And the "number" of patches is questionable, as every patch not rated "optional" was installed. This entirely ignores whether the patch was to a component actually in use. SLES has all services disabled by default, and needn't automatically launch GUI software either.
SLES's patches included upgrades and patches to things like Acrobat Reader, which, given the methodology, would not have been patched on MS's enterprise solutions. The number of patches was higher for SLES because the vendor supports virtually all of the software on the machine.
Given the way modern linux distributions handle patch management, this isn't much of a burden. Requiring that _all_ patches be applied, presumably even to packages that were only installed to need patching, isn't a sensible approach. If it isn't needed, don't install it. If it isn't installed, don't patch it.
Some interesting charts, from Secunia:
SLES 8:
http://secunia.com/product/1171/
SLES 9:
http://secunia.com/product/4118/
Windows 2000:
http://secunia.com/product/20/
Windows 2003:
http://secunia.com/product/1174/
Pffft.
http://www.linux-watch.com/news/NS6557933549.html
[edit]
I've gone and read some of the study in question now. Not too impressive.
First is all the commentary about "Out of support" packages on SLES 8, while SLES 9 is available (and with those packages that are out of support in SLES 8!!!). Hmm! Maybe the applications that required those out of support packages were written towards distributions of SLES 9's vintage. Rather than upgrade 1-2 packages "out of support", I would expect a competent administrator to upgrade to SLES 9 or find an application compatible with SLES 8.
Rather, 3rd party extensions/products were chosen that operated both on Linux and Windows. Though of course, the specific application isn't disclosed, nor were the versions of those 3rd party products discussed.
Second, again with the "Out of support" packages. The report indicates that two of three of the SLES (*ahem*) administrators completely broke their servers while trying to upgrade glibc. I have to question the competence of the admins they selected. No backups? No knowledge of how to deal with this type of issue at all? Why were "third party extensions" to their "custom" ecommerce platform selected that weren't compatible with the existing platform?
The footnote at the bottom of page 3 is telling in this regard. Tallying non-version-specific "Windows" experience vs. non-version-specific "Linux" experience and having some version-specific requirements as well doesn't quite add up. What would the Windows administrators be getting experience in if not Windows 2000 or 2003?
Third, there is a mention of one of the Microsoft admins calling "Third party product support". Didn't the SLES administrators have similar options available?
Fourth, the number of patches installed, and the conveniently "monthly" patch cycle. Convenient, as Microsoft has a monthly patch release cycle. And the "number" of patches is questionable, as every patch not rated "optional" was installed. This entirely ignores whether the patch was to a component actually in use. SLES has all services disabled by default, and needn't automatically launch GUI software either.
SLES's patches included upgrades and patches to things like Acrobat Reader, which, given the methodology, would not have been patched on MS's enterprise solutions. The number of patches was higher for SLES because the vendor supports virtually all of the software on the machine.
Given the way modern linux distributions handle patch management, this isn't much of a burden. Requiring that _all_ patches be applied, presumably even to packages that were only installed to need patching, isn't a sensible approach. If it isn't needed, don't install it. If it isn't installed, don't patch it.
Some interesting charts, from Secunia:
SLES 8:
http://secunia.com/product/1171/
SLES 9:
http://secunia.com/product/4118/
Windows 2000:
http://secunia.com/product/20/
Windows 2003:
http://secunia.com/product/1174/
Pffft.
# posted by Sam @ 11:17 PM | 
