Reliability: Unix and Linux beat Windows (heise online)

Because people using Debian don't care enough about redundant power supply?

Seriously, it seems silly to analyse downtime by OS without addressing the differences in the
hardware configuration.

over the last few months I've had a rash of hiccups (failover then fail back) on boxes that
appear to be related to 447 days of uptime. I had about a hundred systems hit this.

you know, I really should upgrade more frequently ;-)

Unix variants in general have extremely low downtime requirements compared to pc operating
systems. Same goes for linux in my experience. Linux servers with hundreds of days uptime are
the norm here -

plemlp01: /home/jjs
(tty/dev/pts/0): bash: 113 > ruptime -t
plemlp05      up 611+06:38,     0 users,  load 0.02, 0.02, 0.00
plemlp04      up 611+06:31,     3 users,  load 0.08, 0.05, 0.01
plemlp03      up 611+06:16,     1 user,   load 0.00, 0.00, 0.00
plifsp05      up 607+00:23,     0 users,  load 0.02, 0.05, 0.05
plemlp01      up 607+00:04,     0 users,  load 0.11, 0.08, 0.08
plemlp02      up 607+00:00,     0 users,  load 0.52, 0.39, 0.35
plemlp01: /home/jjs
(tty/dev/pts/0): bash: 114 > cat /etc/SuSE-release
SUSE Linux Enterprise Server 10 (i586)
VERSION = 10

But this is nothing new - I had a couple of busy production mail/dns servers back near the
turn of the millenium which were up for over 2 years - but that was on the 2.2.17 kernel, and
uptime would wrap around at 497 days. No problems whatsoever in the performance, they kept
running for hundreds more days til we brought them down for hardware upgrades.

At any rate I'm glad the mainstream "IT pundits" are catching on.

Any uptime above a couple of weeks is a proof for poor system administration: Either, no
updates are done, or reboot is not tested after a changes.

So you tell us that (1) you didn't apply kernel security updates and (2) you didn't test (at
appropriate maintenance windows) that your system changes (i.e., security updates, config
changes) will not endanger reboot functionality, thus severly increasing the risk associated
with these systems. And you're even proud of it. Gosh, I don't even know where to start.

Excuse me if I'm too frank for you, but: if I would find you at one of my customer's sites as
a sysadmin, the first thing that I would try to do is to cause revocation of your sysadmin
priviledges, as you're obviously a security and risk hazard. (With the shown unprofessional
mindset, you probably wouldn't work at my company in the first place.)

Any properly run data center will reboot its servers in regular and scheduled intervals. This
doesn't mean that user service is interrupted, that's what HA is for. (I design data centers
and processes around them for a living. And I have seen enough sh*t hitting the fan and have
been called too often inmidst a night to a customer's site to know why such reboot processes
are necessary, for *all* operating systems.)

The answer should be the people using those systems. 
For what I read around Internet and my own friends, Debian administrators tend to be more
hackish than Ubuntu's or other distro. 
So they tend to have more resources solving problems but on the other hand they may prefer
their own methods over what the distro have ( or what the distro doesn't have and they
implement).
As everybody is wrong sometimes, they will make the system fail more often that people that
just use what the distro provides that at least has been tested by someone else than yourself.

Don't get me wrong, even if those systems have a couple more bugs they have to address, some
of them are pure art in what they are achieving.

Microsoft has historically been concerned about corner cases with changes to core system
software or its configuration†, so they nearly always trigger a reboot on updates or major
config changes.

Unix (and thus Linux) has historically assumed that the operator knows what they're doing, and
will choose to reboot if its appropriate.

This bites both ways, you can get mysterious problems which resolve when you reboot your Unix
server, only for you to realise days, weeks or even years later that the cause was a daemon
still using configuration from a file that had been updated and just not re-read.

Meanwhile your Windows administrator cousin finds that despite her best efforts she's losing
an hour a month to reboots for changes that would most likely have caused zero downtime in
Linux.

† This is a self-fulfilling prophecy of course. Having decided that it's OK to handle such
changes only by rebooting, more and more of the system software comes to rely on this
behavior, and so when Microsoft did try to respond to feedback about "too many reboots" it
struggled to do anything about them. In particular the inability to replace a file while it is
open, combined with the requirement for many core services to hold open files they are using,
results in Windows needing an entire boot-time subsystem dedicated to replacing such files
while there's still a chance, and of course anything which uses this subsystem requires a
reboot...

Windows reliability is getting much better - in the Win95 days I wrote an uptime script
showing my Win95 laptop had an average uptime of 11 hours, including times when I was asleep!
My WinXP laptop is now much less likely to lock up (mis-rendering fonts and becoming unusable)
now that it has 2 GB RAM - was 1 GB, but Windows Process Explorer / Task Manager consistent
mis-reports that it has plenty of RAM when in fact it is struggling (some RAM usage must be
un-reported)...  So having more than adequate hardware is important to Windows - by contrast,
home Linux boxes with 96, 192 or 512 MB RAM run Linux with GUI apps very reliably and never
crash, and very rarely lock up.

On server admin skills, you're right about many Windows admins, I think, in that they never
need to learn so much, but in larger organisations the best admins have to master registry
hacks, patch update management, and many other very technical areas, in order to keep a large
number of Windows systems working.  

Generally, I think it's a lot more effort to keep a desktop or server box running with Windows
than with Linux (what with antivirus, antispyware, anti-rootkit, defragging, Windows updates
[which sometimes takes 100% CPU) - however, it can be more effort to get Linux working with
recent video cards and WiFi adapters.

Large IT depts have a big challenge in testing the various Windows patches before rolling them
out to all desktops/servers, because these patches often break things in unpredictable ways,
particularly for mission-critical apps - hence there's a multi-week "patch lag" between patch
release by MS and rollout by IT, leaving systems more vulnerable.  This means the IT dept has
to invest in more centralised security - there are systems that sit on the network and
dynamically block exploit attempts specific to MS patches that are released but not yet
applied, for example.  I can't see this patch-lag issue happening with Linux - the updates I
get from Ubuntu simply work (with the odd exception such as the broken xorg update a while
back) and I'm sure Debian stable is far better at this.

The end result is that my Windows laptop (managed by the IT dept mostly) is quite reliable,
but due to patch-lag is quite vulnerable for many weeks to vulnerabilities in Flash, MS
Office, etc that are remotely exploitable and therefore rated 'highly critical' by Secunia
(see http://secunia.com -they have a great free vulnerability scanning tool if you have to use
Windows).

> Uptime 300+ day tell us only that the machine is leaved unmaintained and vulnerable...

Such uptime tells only that the kernel was not updated. It does not mean that the rest of the
system was not properly maintained. If a vulnerability in the kernel can not be exploited over
a network connection, a decision to skip updating the kernel is very reasonable if the system
is a file or web server with no local user accounts.