Reliability: Unix and Linux beat Windows (heise online)

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).