G
gnaynit
http://blogs.zdnet.com/Murphy/?p=3D473
if (Windows Rules) then (Linux fails)
Posted by Paul Murphy @ 3:39 am
Part of the problem with the documentation and identification issues I talked about=
last week - and will talk about more later - is that it is very hard to separate informat=
ion from disinformation.
Disinformation comes in three major forms:
1. innocent mistakes;
2. intentional disinformation (aka FUD); and,
3. (self) delusion.
Delusions are easily the most dangerous of these. In the IT context the most common de=
lusion is simply that what we know is right in general or applicable to some specific i=
ssue when, in reality, it isn't. We know, and we act accordingly - with frequently cat=
astrophic results.
FUD, taken as the art of spreading fear, uncertainty, and doubt, is at its most danger=
ous when it plays on existing certainties to reinforce delusion.
A recent report by Security Innovation comparing Windows and Linux seems to fall squ=
arely into that category.
Reader "Mired in Zealand" brought this thing to my attention late last week and both D=
ana Blankenhorn and I decided to respond via our askbloggie column. We asked George O=
u to speak for Microsoft on this one, but we haven't heard from him yet. Both Dana and I w=
ill, however, be filing our comments on the askbloggie site later today.
Meanwhile, here's my contribution to that debunking.
=E2=80=94-
Does Windows Rule?
Here's the reader request:
I rec'd this email newsletter today, and I found it very interesting, and admittedly=
down right controversial. As a Windows guy, even I was having some trouble believing=
that Windows is such the slam-dunk winner that it's purported to be over Linux. What a=
re your 2 cents? I'd love to see a blog entry on this. This is of particular interest to m=
y IT shop since we're contemplating a move from our z/OS environment to possibly a Lin=
ux environment. =
=
From: WindowsITPro Update
[mailto:[email protected]]
Sent: Tuesday, November 22, 2005 2:19 PM
To: Mired in Zealand
Subject: Microsoft vs Linux 2005: It's All About Reliability
by Paul Thurrott, News Editor, (e-mail address removed) =E2=80=A6
OSS proponents have been pushing the supposed security, reliability, and durabili=
ty advantages of Linux over Windows for years now. My gut feeling has always been that=
were Linux installed in as many production environments as Windows, it would fall ap=
art as much or more, albeit in different ways. What's lacking, of course, is evidence=
.. Whereas Microsoft has sponsored study after study to examine the competitive adva=
ntages of Windows and Linux, the cozy relationships between the software giant and t=
he companies making these studies always made the results less than believable.
Last week, however, I think we reached a turning point in understanding how Linux and=
Windows differ in the real world. Yes, yet another study is involved, and yes, Micros=
oft commissioned this one as well. However, the company that performed the study, Se=
curity Innovation, is highly regarded for its independence and methodology. In thi=
s study, "Reliability: Analysing Solution Uptime as Business Needs Change", [URL a=
dded - murph] Security Innovation examines the real-world reliability of Windows a=
nd Linux, not abstract and often pointless statistics such as uptime.
=E2=80=A6
As part of the study, sets of experienced Windows and Linux systems administrators w=
ere given control of e-commerce environments based on their respective systems. Th=
e Windows environments were based on Windows 2000, then upgraded to Windows Server 2=
003 and any applicable hotfixes and security patches during the simulated year of th=
e study. The Linux environments began life with Novell SuSE Linux Enterprise Server=
8 and were upgraded to SuSE 9 and any applicable updates. Both groups of administrato=
rs had to configure and maintain the systems over time, introduce new functionality=
to the e-commerce application over time (including personalisation, dynamic sear=
ch, and list-targeting features), and perform the major OS version upgrades. Secur=
ity Innovation examined the performance of the administrators, noting how long the=
y took to execute each task.
At a high level, the Windows systems were dramatically more reliable than the Linux s=
ystems. On average, patching Linux took six times longer than patching Windows, and=
there were almost five times as many patches to apply on Linux (187) as there were on Wi=
ndows (39). More important, perhaps, the Linux systems suffered from 14 "critical b=
reakages," software dependency failures in which software simply stopped working=
on those systems. Windows had no dependency failures.
Sounds compelling doesn't it? I thought so, in fact I thought both this newsletter an=
d the Reliability study it reports on were among the best things of this kind I've seen=
.. On the other hand there's a challenge to the Linux community here we'd be fools to ign=
ore.
As step one, lets look closely at what the underlying study actually says. Paul Thurr=
ott, the newsletter writer quoted above, captured its central argument very well: i=
t's about comparing what happens when you put both Linux and Windows into a productio=
n environment and then upgrade both the OS and the applications suite over the period=
of year.
In fact, however, Security Innovation didn't actually do this. Instead they simula=
ted this by compressing all activity into an unknown period -whether days or weeks th=
ey don't say.
During that period three people hired as experienced Linux administrators and thre=
e Windows people were each given responsibility for a machine and asked to:
1. apply security and recommended patches on a simulated monthly release basis;
2. upgrade the e-commerce application with new functionality at the end of each simu=
lated quarter (i.e. change it to meet changing business requirements); and,
3. upgrade the core OS from SuSe 8.0 to 9.0 and from Windows 2000 server to Windows 2003=
/XP server at the end of the simulated year.
Here's part of Security Innovation's summary of what came out of this:
* Two of the three Linux administrators were unable to meet all business requirement=
s within the time constraints of the study; in contrast, all three Windows administr=
ators met all business requirements
* on average the three Linux administrators were about 70% slower than their Windows=
counterparts to fulfill business objectives. This was in part driven by more system=
failures experienced by the Linux administrators (14 compared to 0 for the Windows a=
dministrators) and a greater number of patches that needed to be applied to the Linux=
systems (in total, 187 compared to 39 for Windows).
* The only Linux administrator who was successful in meeting all requirements insta=
lled components and component versions that were not directly supported by the vend=
or (and in some cases custom compiled) that effectively put his system into an unsupp=
orted configuration. While the configuration did meet functionality requirement=
s, the administrator is now "on his own" to resolve potential future system failures=
.. It has also increased the IT administrative burden given that any future patches to=
the unsupported components would now have to be gathered from alternate sources and=
in some cases edited at the source code level and recompiled. On the Windows front, th=
e system was maintained by components provided either from Microsoft or from the 3rd=
party component vendor and all configurations were within the boundary of support.=
Not exactly good news for Linux is it?
And then again, maybe a closer look is required before we draw conclusions.
The first problem is that they don't say which patches they applied. In the period giv=
en, July 1st 2004 to June 30th 2005, Novell apparently released 237 patches, not 187.=
They also don't say which e-commerce application they used, or which third party upg=
rades were implemented, so we don't know how many patches applied specifically to th=
ose elements of the overall configuration.
Thus the numbers they give suggest they applied some subset of the patches issued by N=
ovell, but they don't tell us which ones. Here's the first five letters worth of an alp=
habetical listing of what Novell's 237 patches applied to:
a2ps: Converts ASCII Text into PostScript
aaa_base: SuSE Linux base package
acl: Commands for Manipulating POSIX Access Control Lists
acpid: Executes Actions at ACPI Events
apache2-mod_python: Python module for the Apache 2 web server
arts: Modular software synthesiser
arts-devel: Include Files and Libraries mandatory for Development.
aspell: A Free and Open Source spell checker
aspell-devel: Include Files and Libraries Mandatory for Development
bison: The GNU Parser Generator
bootsplash-theme-SuSE: Default SuSE Bootsplash Theme
bootsplash-theme-SuSE-Home: Default SuSE Linux Enterprise Server Bootsplash Th=
eme
bzip2: A program for compressing files
cadaver: Command-line WebDAV client for Unix
coreutils: GNU Core Utilities
cups: The Common UNIX Printing System
cups-client: CUPS Client Programs
cups-devel: development environment for CUPS
cups-libs: libraries for CUPS
curl-devel: header files and libraries for curl development
cvs: Concurrent Versions System
cyrus-imapd: An IMAP/POP Mailserver
cyrus-sasl: Implementation of Cyrus SASL API
cyrus-sasl-devel: Cyrus SASL API implmentation, Libraries and Header files
dhcp-server: ISC DHCP Server
drbd: Distributed Replicated Block Device
dvd+rw-tools: A Collection of Tools for Mastering DVD+RW/+R Media
emacs: GNU Emacs Base Package
enscript: An ASCII to PostScript(tm) Converter
evolution: The Integrated GNOME Mail, Calendar, and Addressbook Suite
evolution-devel: Include Files and Libraries mandatory for Development.
exim: The Exim mail transfer agent, a replacement for sendmail
ez-ipupdate: A small utility for updating dynamic DNS service =
A lot of these are marked as security updates, but almost all of the software they appl=
y to has no place in an e-commerce configuration. With Windows servers you install ev=
erything you're licensed to because the dependencies are largely unknown, with Lin=
ux you install what you need -because what isn't there doesn't have vulnerabiliites=
, use resources, or require patching.
In other words, knowledgeable Linux people configuring and running those servers m=
ight have had to install perhaps five or six Linux related patches during the year - no=
thing like 187, and none with recursive dependency tails of the kind that got two out o=
f the three testees in trouble.
The second problem is something the author doesn't mention at all: "management" has=
clearly told these administrators to apply the patches directly to the "production=
" systems. In real life many people do this with Windows, but you don't do this with Lin=
ux. With any Unix you duplicate your production environment on the sysadmin's works=
tation and debug any processes to be applied to production there before proceeding.=
They don't say why they didn't do this, but a reasonable speculation is that there wer=
e two reasons: the simulation would have imposed unrealistic calendar time constra=
ints, and, probably more importantly, this isn't the Windows way, and they did every=
thing the Windows way.
The third set of problems arises because of the way they handled the e-commerce appli=
cation upgrades.
Again, there's a shortage of critical information in the report: they don't tell us w=
hich e-commerce application they started with, and they don't tell us which third pa=
rty upgrades they installed. Instead we get this about the quarterly application up=
grades:
These feature enhancements will be simulated by adding best-of-breed third party c=
omponents to the system that meet new requirements. In the running ecommerce exampl=
e, this could mean adding a new shopping cart component or an add-in data mining tool.=
In many cases there will be multiple 3rd party products that satisfy functional requ=
irements. Our selection among these alternatives will be made strictly based on lar=
gest market share among enterprise customers.
=E2=80=A6
During the experimental trials, 3rd party best-of-breed components were chose to s=
atisfy the needs of the solution. Our criteria for selection of components were:
* Support on both Windows and Linux
* Strong and established base of enterprise customers
In other words, the game was to add components chosen on the basis of market share and a=
vailability for both Windows and Linux. That sounds fair, but they sabotaged it from=
the gitgo by choosing quite dissimilar starting points:
S1 [the starting point] is a basic ecommerce application running on the Windows Serv=
er 2000 operating system, written in ASP, hosted by IIS using the SQL Server 2000 data=
base that is operating on June1st, 2004. Similarly, we define S1 on the Linux side to b=
e a basic ecommerce application running on Novell SuSE Linux Enterprise Server 8, wr=
itten in PHP, hosted by Apache using the MySQL database engine. =
The problem with this is that the requirement that component upgrades run on both Win=
dows and Linux looks like it's intended to level the playing field but has the opposit=
e effect - taking the best open source applications out of consideration because the=
se might run on Windows but not with ASP and SQL-Server, and limiting the number of ven=
dors on the Windows side to one.
As a result the Windows administrators were merely asked to load new modules "from th=
e 3rd party component vendor" (P3, note singular) while the Linux administrators we=
re expected to integrate dissimilar bits and pieces taken from multiple incompatib=
le sources.
Let me be clear about this: the right thing to do would have been to do on Linux what the W=
indows market structure apparently forced them to do on Windows: take a single vendo=
r integrated solution known to contain all the components needed for the end product=
, partially install it, and then upgrade it "quarterly."
But that's not what they did: instead the Windows people were asked to load pre-integ=
rated modules while the Linux administrators faced integration and interfacing pr=
oblems on unrelated code bundles.
Amazingly enough, one of them succeeded in keeping his machine "in production" all t=
he way through!
In stage magic the emphasis is always on distraction - get the audience focused on wha=
t the pretty girl isn't wearing and nobody will notice the lighting change behind the=
magician. This works in paid advocacy studies too - get everyone focused on a known an=
d widely shared pain like upgrade dependencies in non core toolsets and few will noti=
ce that you're crippling Linux by applying Windows methods (install everything) an=
d Windows management ideas (interface most popular of breed components) where they=
don't fit.
Looking at this you might think it would be reasonable to describe the result as class=
ic Microsoft anti-Linux FUD - a lie from one end to the other. However, there are a coup=
le of reasons for thinking that maybe this isn't so.
In the first place there are lots of people who actually try to run Linux in just this wa=
y and presumably get just these results. They're getting, of course, just what they d=
eserve - but this is the biggest problem in business computing: managers and adminis=
trators whose certainties about running systems drawn from one environment get app=
lied to another to create what the authors rightly call "IT pain."
See this report in that context and what we have is a positive story in which one of thre=
e guys hired for their claimed Linux expertise and given wildly inappropriate opera=
ting instructions manages to pull it off.
As I've said many times, it's not Linux or its applications that are at fault when this=
happens: the problems documented in the study are largely the result of applying Win=
dows expertise to Linux - something I see people do almost every day, and something "M=
ired in Zealand" will be seeing a version of at first hand if his organization transit=
ions from zOS to Linux without a lot of retraining, rethinking, and re-staffing firs=
t.
The second reason not to dismiss this study as mere FUD is subtler. The fact that this c=
ompany calls itself "Security Innovation" but works with Windows suggests some int=
ernal conflict has to exist - and the structure of much of the report leads to a "wild su=
rmise" as to what one of those might be about.
Read it carefully and you'll see that most of the verbiage is cast as you'd expect to se=
e it in a proposal to Microsoft to do this study, not as you'd expect to see it in a report=
about the outcome of the study. Thus the construction: "we will [do something]" occu=
rs at least 65 times in the report. For example:
For each failure we will do a root cause analysis to determine its source. These causa=
l factors will be written up and documented in our analysis. Specifically, we will ca=
pture metrics around dependency failures, version demand conflicts and other pote=
ntial sources of failure. =
Hence the "wild surmise:" these guys might well have set out to settle an internal arg=
ument by doing exactly what they report, exactly as they report it - only to call Micro=
soft for funding and publicity when their mistakes on the Linux side seemed to give Wi=
ndows such a huge lead in performance and reliability.
In other words it's possible to see this report as wrong on all counts, and not only cre=
dit the authors with a legitimate attempt to come to grips with a real problem but feel=
sorry for them because what they ended up, in all innocence, writing a case study on ho=
w not to deploy Linux.
=E2=80=94=E2=80=93
As I said above, FUD is at its most dangerous when it supports and reinforces delusion=
.. In my opinion that's what happened here: with these people getting just about every=
thing about running Linux wrong, finding what they hoped to find not as the result of a=
ny actual Linux/Windows differences but as a result of their own delusions about sys=
tems management, and then using Microsoft's money and press access as a means of spre=
ading those delusions to others.
if (Windows Rules) then (Linux fails)
Posted by Paul Murphy @ 3:39 am
Part of the problem with the documentation and identification issues I talked about=
last week - and will talk about more later - is that it is very hard to separate informat=
ion from disinformation.
Disinformation comes in three major forms:
1. innocent mistakes;
2. intentional disinformation (aka FUD); and,
3. (self) delusion.
Delusions are easily the most dangerous of these. In the IT context the most common de=
lusion is simply that what we know is right in general or applicable to some specific i=
ssue when, in reality, it isn't. We know, and we act accordingly - with frequently cat=
astrophic results.
FUD, taken as the art of spreading fear, uncertainty, and doubt, is at its most danger=
ous when it plays on existing certainties to reinforce delusion.
A recent report by Security Innovation comparing Windows and Linux seems to fall squ=
arely into that category.
Reader "Mired in Zealand" brought this thing to my attention late last week and both D=
ana Blankenhorn and I decided to respond via our askbloggie column. We asked George O=
u to speak for Microsoft on this one, but we haven't heard from him yet. Both Dana and I w=
ill, however, be filing our comments on the askbloggie site later today.
Meanwhile, here's my contribution to that debunking.
=E2=80=94-
Does Windows Rule?
Here's the reader request:
I rec'd this email newsletter today, and I found it very interesting, and admittedly=
down right controversial. As a Windows guy, even I was having some trouble believing=
that Windows is such the slam-dunk winner that it's purported to be over Linux. What a=
re your 2 cents? I'd love to see a blog entry on this. This is of particular interest to m=
y IT shop since we're contemplating a move from our z/OS environment to possibly a Lin=
ux environment. =
=
From: WindowsITPro Update
[mailto:[email protected]]
Sent: Tuesday, November 22, 2005 2:19 PM
To: Mired in Zealand
Subject: Microsoft vs Linux 2005: It's All About Reliability
by Paul Thurrott, News Editor, (e-mail address removed) =E2=80=A6
OSS proponents have been pushing the supposed security, reliability, and durabili=
ty advantages of Linux over Windows for years now. My gut feeling has always been that=
were Linux installed in as many production environments as Windows, it would fall ap=
art as much or more, albeit in different ways. What's lacking, of course, is evidence=
.. Whereas Microsoft has sponsored study after study to examine the competitive adva=
ntages of Windows and Linux, the cozy relationships between the software giant and t=
he companies making these studies always made the results less than believable.
Last week, however, I think we reached a turning point in understanding how Linux and=
Windows differ in the real world. Yes, yet another study is involved, and yes, Micros=
oft commissioned this one as well. However, the company that performed the study, Se=
curity Innovation, is highly regarded for its independence and methodology. In thi=
s study, "Reliability: Analysing Solution Uptime as Business Needs Change", [URL a=
dded - murph] Security Innovation examines the real-world reliability of Windows a=
nd Linux, not abstract and often pointless statistics such as uptime.
=E2=80=A6
As part of the study, sets of experienced Windows and Linux systems administrators w=
ere given control of e-commerce environments based on their respective systems. Th=
e Windows environments were based on Windows 2000, then upgraded to Windows Server 2=
003 and any applicable hotfixes and security patches during the simulated year of th=
e study. The Linux environments began life with Novell SuSE Linux Enterprise Server=
8 and were upgraded to SuSE 9 and any applicable updates. Both groups of administrato=
rs had to configure and maintain the systems over time, introduce new functionality=
to the e-commerce application over time (including personalisation, dynamic sear=
ch, and list-targeting features), and perform the major OS version upgrades. Secur=
ity Innovation examined the performance of the administrators, noting how long the=
y took to execute each task.
At a high level, the Windows systems were dramatically more reliable than the Linux s=
ystems. On average, patching Linux took six times longer than patching Windows, and=
there were almost five times as many patches to apply on Linux (187) as there were on Wi=
ndows (39). More important, perhaps, the Linux systems suffered from 14 "critical b=
reakages," software dependency failures in which software simply stopped working=
on those systems. Windows had no dependency failures.
Sounds compelling doesn't it? I thought so, in fact I thought both this newsletter an=
d the Reliability study it reports on were among the best things of this kind I've seen=
.. On the other hand there's a challenge to the Linux community here we'd be fools to ign=
ore.
As step one, lets look closely at what the underlying study actually says. Paul Thurr=
ott, the newsletter writer quoted above, captured its central argument very well: i=
t's about comparing what happens when you put both Linux and Windows into a productio=
n environment and then upgrade both the OS and the applications suite over the period=
of year.
In fact, however, Security Innovation didn't actually do this. Instead they simula=
ted this by compressing all activity into an unknown period -whether days or weeks th=
ey don't say.
During that period three people hired as experienced Linux administrators and thre=
e Windows people were each given responsibility for a machine and asked to:
1. apply security and recommended patches on a simulated monthly release basis;
2. upgrade the e-commerce application with new functionality at the end of each simu=
lated quarter (i.e. change it to meet changing business requirements); and,
3. upgrade the core OS from SuSe 8.0 to 9.0 and from Windows 2000 server to Windows 2003=
/XP server at the end of the simulated year.
Here's part of Security Innovation's summary of what came out of this:
* Two of the three Linux administrators were unable to meet all business requirement=
s within the time constraints of the study; in contrast, all three Windows administr=
ators met all business requirements
* on average the three Linux administrators were about 70% slower than their Windows=
counterparts to fulfill business objectives. This was in part driven by more system=
failures experienced by the Linux administrators (14 compared to 0 for the Windows a=
dministrators) and a greater number of patches that needed to be applied to the Linux=
systems (in total, 187 compared to 39 for Windows).
* The only Linux administrator who was successful in meeting all requirements insta=
lled components and component versions that were not directly supported by the vend=
or (and in some cases custom compiled) that effectively put his system into an unsupp=
orted configuration. While the configuration did meet functionality requirement=
s, the administrator is now "on his own" to resolve potential future system failures=
.. It has also increased the IT administrative burden given that any future patches to=
the unsupported components would now have to be gathered from alternate sources and=
in some cases edited at the source code level and recompiled. On the Windows front, th=
e system was maintained by components provided either from Microsoft or from the 3rd=
party component vendor and all configurations were within the boundary of support.=
Not exactly good news for Linux is it?
And then again, maybe a closer look is required before we draw conclusions.
The first problem is that they don't say which patches they applied. In the period giv=
en, July 1st 2004 to June 30th 2005, Novell apparently released 237 patches, not 187.=
They also don't say which e-commerce application they used, or which third party upg=
rades were implemented, so we don't know how many patches applied specifically to th=
ose elements of the overall configuration.
Thus the numbers they give suggest they applied some subset of the patches issued by N=
ovell, but they don't tell us which ones. Here's the first five letters worth of an alp=
habetical listing of what Novell's 237 patches applied to:
a2ps: Converts ASCII Text into PostScript
aaa_base: SuSE Linux base package
acl: Commands for Manipulating POSIX Access Control Lists
acpid: Executes Actions at ACPI Events
apache2-mod_python: Python module for the Apache 2 web server
arts: Modular software synthesiser
arts-devel: Include Files and Libraries mandatory for Development.
aspell: A Free and Open Source spell checker
aspell-devel: Include Files and Libraries Mandatory for Development
bison: The GNU Parser Generator
bootsplash-theme-SuSE: Default SuSE Bootsplash Theme
bootsplash-theme-SuSE-Home: Default SuSE Linux Enterprise Server Bootsplash Th=
eme
bzip2: A program for compressing files
cadaver: Command-line WebDAV client for Unix
coreutils: GNU Core Utilities
cups: The Common UNIX Printing System
cups-client: CUPS Client Programs
cups-devel: development environment for CUPS
cups-libs: libraries for CUPS
curl-devel: header files and libraries for curl development
cvs: Concurrent Versions System
cyrus-imapd: An IMAP/POP Mailserver
cyrus-sasl: Implementation of Cyrus SASL API
cyrus-sasl-devel: Cyrus SASL API implmentation, Libraries and Header files
dhcp-server: ISC DHCP Server
drbd: Distributed Replicated Block Device
dvd+rw-tools: A Collection of Tools for Mastering DVD+RW/+R Media
emacs: GNU Emacs Base Package
enscript: An ASCII to PostScript(tm) Converter
evolution: The Integrated GNOME Mail, Calendar, and Addressbook Suite
evolution-devel: Include Files and Libraries mandatory for Development.
exim: The Exim mail transfer agent, a replacement for sendmail
ez-ipupdate: A small utility for updating dynamic DNS service =
A lot of these are marked as security updates, but almost all of the software they appl=
y to has no place in an e-commerce configuration. With Windows servers you install ev=
erything you're licensed to because the dependencies are largely unknown, with Lin=
ux you install what you need -because what isn't there doesn't have vulnerabiliites=
, use resources, or require patching.
In other words, knowledgeable Linux people configuring and running those servers m=
ight have had to install perhaps five or six Linux related patches during the year - no=
thing like 187, and none with recursive dependency tails of the kind that got two out o=
f the three testees in trouble.
The second problem is something the author doesn't mention at all: "management" has=
clearly told these administrators to apply the patches directly to the "production=
" systems. In real life many people do this with Windows, but you don't do this with Lin=
ux. With any Unix you duplicate your production environment on the sysadmin's works=
tation and debug any processes to be applied to production there before proceeding.=
They don't say why they didn't do this, but a reasonable speculation is that there wer=
e two reasons: the simulation would have imposed unrealistic calendar time constra=
ints, and, probably more importantly, this isn't the Windows way, and they did every=
thing the Windows way.
The third set of problems arises because of the way they handled the e-commerce appli=
cation upgrades.
Again, there's a shortage of critical information in the report: they don't tell us w=
hich e-commerce application they started with, and they don't tell us which third pa=
rty upgrades they installed. Instead we get this about the quarterly application up=
grades:
These feature enhancements will be simulated by adding best-of-breed third party c=
omponents to the system that meet new requirements. In the running ecommerce exampl=
e, this could mean adding a new shopping cart component or an add-in data mining tool.=
In many cases there will be multiple 3rd party products that satisfy functional requ=
irements. Our selection among these alternatives will be made strictly based on lar=
gest market share among enterprise customers.
=E2=80=A6
During the experimental trials, 3rd party best-of-breed components were chose to s=
atisfy the needs of the solution. Our criteria for selection of components were:
* Support on both Windows and Linux
* Strong and established base of enterprise customers
In other words, the game was to add components chosen on the basis of market share and a=
vailability for both Windows and Linux. That sounds fair, but they sabotaged it from=
the gitgo by choosing quite dissimilar starting points:
S1 [the starting point] is a basic ecommerce application running on the Windows Serv=
er 2000 operating system, written in ASP, hosted by IIS using the SQL Server 2000 data=
base that is operating on June1st, 2004. Similarly, we define S1 on the Linux side to b=
e a basic ecommerce application running on Novell SuSE Linux Enterprise Server 8, wr=
itten in PHP, hosted by Apache using the MySQL database engine. =
The problem with this is that the requirement that component upgrades run on both Win=
dows and Linux looks like it's intended to level the playing field but has the opposit=
e effect - taking the best open source applications out of consideration because the=
se might run on Windows but not with ASP and SQL-Server, and limiting the number of ven=
dors on the Windows side to one.
As a result the Windows administrators were merely asked to load new modules "from th=
e 3rd party component vendor" (P3, note singular) while the Linux administrators we=
re expected to integrate dissimilar bits and pieces taken from multiple incompatib=
le sources.
Let me be clear about this: the right thing to do would have been to do on Linux what the W=
indows market structure apparently forced them to do on Windows: take a single vendo=
r integrated solution known to contain all the components needed for the end product=
, partially install it, and then upgrade it "quarterly."
But that's not what they did: instead the Windows people were asked to load pre-integ=
rated modules while the Linux administrators faced integration and interfacing pr=
oblems on unrelated code bundles.
Amazingly enough, one of them succeeded in keeping his machine "in production" all t=
he way through!
In stage magic the emphasis is always on distraction - get the audience focused on wha=
t the pretty girl isn't wearing and nobody will notice the lighting change behind the=
magician. This works in paid advocacy studies too - get everyone focused on a known an=
d widely shared pain like upgrade dependencies in non core toolsets and few will noti=
ce that you're crippling Linux by applying Windows methods (install everything) an=
d Windows management ideas (interface most popular of breed components) where they=
don't fit.
Looking at this you might think it would be reasonable to describe the result as class=
ic Microsoft anti-Linux FUD - a lie from one end to the other. However, there are a coup=
le of reasons for thinking that maybe this isn't so.
In the first place there are lots of people who actually try to run Linux in just this wa=
y and presumably get just these results. They're getting, of course, just what they d=
eserve - but this is the biggest problem in business computing: managers and adminis=
trators whose certainties about running systems drawn from one environment get app=
lied to another to create what the authors rightly call "IT pain."
See this report in that context and what we have is a positive story in which one of thre=
e guys hired for their claimed Linux expertise and given wildly inappropriate opera=
ting instructions manages to pull it off.
As I've said many times, it's not Linux or its applications that are at fault when this=
happens: the problems documented in the study are largely the result of applying Win=
dows expertise to Linux - something I see people do almost every day, and something "M=
ired in Zealand" will be seeing a version of at first hand if his organization transit=
ions from zOS to Linux without a lot of retraining, rethinking, and re-staffing firs=
t.
The second reason not to dismiss this study as mere FUD is subtler. The fact that this c=
ompany calls itself "Security Innovation" but works with Windows suggests some int=
ernal conflict has to exist - and the structure of much of the report leads to a "wild su=
rmise" as to what one of those might be about.
Read it carefully and you'll see that most of the verbiage is cast as you'd expect to se=
e it in a proposal to Microsoft to do this study, not as you'd expect to see it in a report=
about the outcome of the study. Thus the construction: "we will [do something]" occu=
rs at least 65 times in the report. For example:
For each failure we will do a root cause analysis to determine its source. These causa=
l factors will be written up and documented in our analysis. Specifically, we will ca=
pture metrics around dependency failures, version demand conflicts and other pote=
ntial sources of failure. =
Hence the "wild surmise:" these guys might well have set out to settle an internal arg=
ument by doing exactly what they report, exactly as they report it - only to call Micro=
soft for funding and publicity when their mistakes on the Linux side seemed to give Wi=
ndows such a huge lead in performance and reliability.
In other words it's possible to see this report as wrong on all counts, and not only cre=
dit the authors with a legitimate attempt to come to grips with a real problem but feel=
sorry for them because what they ended up, in all innocence, writing a case study on ho=
w not to deploy Linux.
=E2=80=94=E2=80=93
As I said above, FUD is at its most dangerous when it supports and reinforces delusion=
.. In my opinion that's what happened here: with these people getting just about every=
thing about running Linux wrong, finding what they hoped to find not as the result of a=
ny actual Linux/Windows differences but as a result of their own delusions about sys=
tems management, and then using Microsoft's money and press access as a means of spre=
ading those delusions to others.