Linux, OpenBSD, Windows Server Comparison:
Stability and Reliability Summary
Miscellaneous Reliability Issues
Occasionally on the open source systems, I've encountered
problems that are at first mysterious. These have always been
traced to a system change, where the relationship is hard to see
at first, but obvious once it's finally figured out. The UNIX
problems have always been the result of something I've done.
I've never seen anything on any UNIX like systems, that resembles
some of the bizarre NT changes, that take hours or days to solve.
Index server failing
when a virtual web site is added (never solved --
MMC losing IIS configuration
data (quick fix but no solution),
two days down waiting for
hardware repair because good backups and similar hardware is
not sufficient (NT requires identical hardware for a successful
core system functions lost
after a UPS initiated orderly shutdown (fixed but no NT error
messages or log entries).
Last but not least, my NT server experienced a
complete system failure
following the installation of a security patch with no user choices or
options. I subsequenly determined that a bad memory chip, installed at
the same time as the patch, was almost certainly the actual trigger.
Still NT self destructed in the presence of defective hardware where
Linux only behaved unreliably and OpenBSD displayed useful error
messages that immediately lead to identifying and correcting the
underlying problem. The NT changes have been spontaneous, or an
unexpected by product of an install or change that should in no way
have been related to the problem.
Compare the handful of possible system crashes or networking
irregularities on several UNIX like systems, over a year and a half,
to far more frequent Windows system crashes and lockups on two
machines. I was just learning the UNIX like systems but had three
years experience with NT. The Windows problems are not frequent the
way that pre NT Windows desktop failures may be, but not so infrequent
that there is any surprise when they occur. Once placed into a
"production" setting, the UNIX like systems exhibited almost total
reliability. The NT server had nearly 70 reboots during the time the
Linux server went 336 days without one. While I had it, I spent more
time troubleshooting the NT server, by far, than all my UNIX like
systems combined. Following the last NT failure, and knowing that I
would not be migrating to the next Windows server version, the system
simply wasn't worth the effort to restore again.
Stability and Reliability Summary
Though my personal experience might suggest otherwise, I believe
that over all, OpenBSD is somewhat more stable than Linux, but
not by such an amount that I can put any specific figure on it.
Comparing the OpenBSD and Linux with NT, I'd rank the UNIX like
systems together and rate NT a very distant third. My gut
feeling is that the difference is something like two orders of
magnitude when looking at the core of the system and system
crashes with a plausible range somewhere between one and three
orders of magnitude. In other words, looking at resistance to
kernel crashes, I'd think NT is ten to one thousand times less
stable. NT simply isn't very good at isolating itself from
either system or user processes that are buggy. Moving to more
peripheral parts of the operating systems, I'd expect the
differences to be somewhat less.
Nearly everyone seems to agree that Windows 2000 is more stable
than NT and that NT is a lot more stable than Windows 98.
Microsoft's own figures put clear limits on how much more stable
Windows 2000 it is than NT. If NT were only marginally more
stable than 98 the upper limit would be 13 times. If these
figures have any real meaning, I'd guess the actual difference is
something between a third more stable and three times more
stable. From an NT user's perspective, Windows 2000 may look
significantly more stable than NT but from any UNIX user's
perspective, both Windows systems look very unstable.
I say "if these figures have any real meaning" because if you
have enough resources to really test both hardware and software
compatibly, and to keep reasonably simple and unchanging server
configurations, NT can be made quite stable, though still not a
match for UNIX systems. Windows 2000 should be better. If you
don't have those kinds of resources and conditions, then luck
seems to play a large role in how stable any particular Windows
system is, and this is meant to apply to the entire Window's
Generally, the more complex the system configuration, the more
active processes running and the higher disk, CPU, and memory use
is, the more likely the system is to experience crashes or
bizarre behavior. To some extent this is true of any system, but
it seems much worse with Windows systems. UNIX systems seem
to run naturally with 100% CPU use for extended periods of time.
With NT servers I've been responsible for, CPU use reaching and
staying at 100%, was always cause for concern. If significant
paging activity were also present, I'd be mentally if not literally,
"crossing my fingers."
With the Windows family, unstable behavior is most likely to
occur following any system change, including installs or
seemingly trivial configuration changes. There does not seem to
be any way to predict or anticipate unusual behavior, and the
changes made, are likely to have no discernable relationship to
the observed problems.
Microsoft has acknowledged the reliability problems inherent in
Windows, with a "System Restore" feature that debuted in ME and is
now included in XP. An eWeek review (no longer available)
of the final XP release said "System Restore
enables users or help desk personnel to return systems to a
workable state in the wake of a harmful application installation
or other destabilizing event." I could not imagine using a
phrase like "harmful application installation or other
destabilizing event" in conjunction with any UNIX system.
Why did Microsoft deliberately choose to build a system with
these reliability issues when competing systems did not have
similar issues? The answer is spelled "M O N O P O L Y". If you
don't understand this answer then read the legal opinions in the
v. Microsoft. In particular, the
of Fact" under the "District Court Filings," lower on the
page is relevant. If a Microsoft technical decision that
otherwise makes no sense, makes it harder to port a Windows
application to a different operating system, you may begin to
understand Microsoft's motivation. Not surprisingly, Microsoft's
approach to the problem is not to fix the underlying cause (the
registry), but add a new feature, which presumably tracks system
changes, and allows the system to be rolled back to a previous
date. Do you like complexity?
Top of Page -
Copyright © 2000 - 2014 by George Shaffer. This material may be
distributed only subject to the terms and conditions set forth in
These terms are subject to change. Distribution is subject to
the current terms, or at the choice of the distributor, those
in an earlier, digitally signed electronic copy of
http://GeodSoft.com/terms.htm (or cgi-bin/terms.pl) from the
time of the distribution. Distribution of substantively modified
versions of GeodSoft content is prohibited without the explicit written
permission of George Shaffer. Distribution of the work or derivatives
of the work, in whole or in part, for commercial purposes is prohibited
unless prior written permission is obtained from George Shaffer.
Distribution in accordance with these terms, for unrestricted and
uncompensated public access, non profit, or internal company use is