Windows Servers Beat Linux Servers
RobbeR49 writes "Windows Server 2003 was recently compared against Linux and Unix variants in a survey by the Yankee Group, with Windows having a higher annual uptime than Linux. Unix was the big winner, however, beating both Windows and Linux in annual uptime. From the article: 'Red Hat Enterprise Linux, and Linux distributions from "niche" open source vendors, are offline more and longer than either Windows or Unix competitors, the survey said. The reason: the scarcity of Linux and open source documentation.' Yankee Group is claiming no bias in the survey as they were not sponsored by any particular OS vendor."
Lets look at last years survey being debunked in a business week analysis. ('cause I'm sure not a damn thing's changed since last year's study).
The biggest criticism of the study is this:
Only people running w2k3 AND linux were allowed to respond. Hmmmmmn, so how many MS shops with an evaluation linux server (installed by their clueless MSCE) were included in this "survey"
Yankee group can claim no bias all they like - but I am sick of Laura DiDio fud being posted here (Oh she of 'SCO's claims are justified after looking at the source' fame).
Call this ad-hominem if you like, but if someone pushes a POV year in, year out, you tend to dismiss them.
There are shills on slashdot. Apparently, I'm one of them.
That means that Red Hat Linux has to have at least 1,461 hours of annual downtime, which is 60 days. (This is so that it would then have no more 5,844 hours of annual uptime, in order to allow 20% more of that to fit into one year at 365.25 days.)
I don't think so.
I hate writers who don't understand math.
I have run both windows servers and linux servers over the last 10 years and my experience is higher uptime with linux servers. Windows machines deal poorly with memory leaking apps and need rebooting for every service pack or required update. I only need to restart specific processes with linux when there is a justified upgrade.
Our Windows 2003 TS servers have a much longer uptime than our Linux servers that are accessed from our lab. Simply because fewer people choose to use the Windows service....
Why does Slashdot continue to even acknowledge 'studies' performed by the Yankee Group? You think we would have learned our lesson by now...
Hard evidence of collusion may be lacking, but it's still patently obvious that Laura DiDio is a Microsoft shill.
Past experience should be enough to show this, but just in case it's not clear enough yet, here's a snippet of TFA:
Translation: "We don't know how to support Linux, so it's Linux's fault."
Also from TFA:
I'll bet they did...when you turn out such a ridiculously skewed 'study', you pretty much have to make certain everyone knows how 'unbiased' it is.
____
~ |rip/\/\aster /\/\onkey
We'll see lots of defensiveness over this study in the comments, although if the conclusions were different, it would be cheered. Why not accept it and fix the documentation issue?
"Sufferin' succotash."
Another article claiming my OS is better than yours, another article with virtually no information, and the information therein is off-the-scale incomprehensible and inconsistent.
Here's a casual observation: the article says, "
" Later in the article, this: " Let's just say a Linux server has 24 hours of downtime a year (higher than the "survey" says). That leaves 364 days of uptime in a year, 365 days in a leap year.Implied in the article then, a Windows 2003 server would have to be "up" approximately 20% more to satisfy the "claim". Now, I am not a calendar "expert", but I'm having a difficult time believing that Windows 2003 server is up an average of 364 * 1.2, or 436.8 days a year. If it is, I'm buying.
Also from the article: "..., But standard Red Hat Enterprise Linux, and Linux distributions from "niche" open source vendors, are offline more and longer than either Windows or Unix competitors, the survey said. The reason: the scarcity of Linux and open source documentation...."
First, this is a survey, it hardly points to data that support this survey, in my book a no-no when trying to prove a point. Secondly, assuming there's truthiness in this, my inference from the previous paragraph is, "Red Hat would be a little easier to set up and use if it had better documentation..."
Three to five down events per year totaling 10 to 19 hours of downtime per year? I'm not SuperAdmin, but NONE of my servers are ever down for that long or that often. Who are they letting run these boxes? What are they doing? Taking the machine into single user mode and recompiling the kernel before rebooting them or something?
Oolite: Elite-like game. For Mac, Linux and Windows
How does documentation affect the uptime of a server?
You need documentation to make changes, not to leave the server alone.
If you're making changes you're not measuring the reliability of the OS/software, you're measuring software and admin performance.
So where would *BSD fall in. Along with Linux because of the clueless people rebooting it because they don't understand /etc/init.d, or along with UNIX because (I'm linux user myself) BSD users actually do seem a bit on the more experianced side of the fence.
Is it 20% more uptime? Or is it 20% less downtime? There's a very, very big difference there -- two months of downtime is pretty severe, and if you have that, you have some serious problems. From the reverse perspective, three nines of uptime allows for nearly nine hours of downtime per year. If that downtime is reduced by 20%, that's nice, but not really noticeable for most users.
You can never go home again... but I guess you can shop there.
A more informative Summary of the 2006 Survey
First and foremost, the whole nature of the design of Unix/Linux provides a means by which software systems can be updated without any service outage. You cannot do this with any version of Windows. Most Windows-based patches and upgrades require a system reboot, which is downtime. Most unix-based upgrades merely require a quick stop/start/HUP of the services. If their main claim is that updating system components is the basis for downtime, they're smoking crack. Maybe their methodology for testing involved taking the entire system down while they upgraded? Unix doesn't require such drastic measures - Windows probably does, as you probably can't update a running service. By design, Windows is exponentially more prone to downtime in the process of patches and upgrades. It's virtually impossible for them to compare the two OSes on this issue and not be dramatically manipulating the test methods to create bogus results that are in no way reflective of how sysadmins patch and manage their server resources. I call BULLSHIT.
I have unix servers right now with uptime measured in YEARS. There are no Windows boxes that can make that claim. Period. I've had outages on occasion due to DDOS or system probes that caused a process to terminate over the years, but I've never had any type of wholesale outage that you'd typically get with most Windows installations. Does anyone have any details on the methodology of the testing? It's obviously bogus.
We have a WinXP Pro box that's been up over a year ...
Another box that's Win2k pro that's been up almost 2...
The one app they run is heavily used (dispatch for a 911 center).
= Grow a brain...
http://www.businessweek.com/the_thread/techbeat/ar chives/2005/04/the_truth_about_1.htmln ux/story/0,10801,82070,00.html ... "The courts are going to ultimately have to prove this, but based on what I'm seeing ... I think there is a basis that SCO has a credible case," DiDio said. "This is not a nuisance case."
s /videos/didio_video.wvx
http://www.computerworld.com/softwaretopics/os/li
Laura DiDio, an analyst at The Yankee Group in Boston, said she was shown two or three samples of the allegedly copied Linux code, and it appeared to her that the sections were a "copy and paste" match of the SCO Unix code that she was shown in comparison.
DiDio and the other analysts were able to view the code only under a nondisclosure agreement,
Watch the "expert" Laura Didio on video from a credible source:
http://www.microsoft.com/windowsserversystem/fact
Enjoy her!
*lol*
How come I never get any of these "impartial surveys"? I have racks and racks of RHEL Linux servers that I only reboot when:
a. a machine suffers a hardware failure (fairly rare) or
b. there's a kernel update that impacts security
In the case of (b), I apply the updated rpms and reboot which normally results in a downtime of approximately 60 seconds for that server. This might happen a few times a year (single digits).
For our small number of Windows 2003 server boxes, it seems that each "windows update" cycle recommends a restart. We'll call that a once a month reboot when Microsoft gets around to releasing their monthly cleanup. Total server downtime is maybe 2-3 minutes (windows takes a bit longer to reboot on the identical hardware used with our Linux machines).
So while I *could* say that our windows servers are down XYZ percent more than our Linux servers, in terms of actual downtime, both platforms are about the same, with Linux seemingly holding a small edge in my experience.
Cheers,
I don't know about uptime, but I used to be a Linux-Only person when it came to servers. After recently falling into a job where I have had to administer Windows servers, I'll admit they are slick...... I picked up workiing with them a hell of a lot easier then I would have a Linux server (if I was new to it). Good LAN support features, ISA, Exchange, license management, fairly easy remote user/computer maintenance..... I'm probably going to give it a shot for my next home server once I get the parts. Although the software is costly if you want to learn it as a hobby (I'm getting it for my home server through MSDNAA).
In undeveloped countries, the consumer controls the market. In capitalist America, the market controls you.
"Red Hat Enterprise Linux, and Linux distributions from "niche" open source vendors, are offline more and longer than either Windows or Unix competitors, the survey said. The reason: the scarcity of Linux and open source documentation."
Hmm, thats odd. Linux documentation has always been in great abundance. It's getting information about how OS interals worked that caused me the biggest OS to Application head-aches. (Both Unix and Windows)
On a broader note, said Yankee analyst Laura DiDio
Ohhhhhh, I see. Laura DiDio had her nasty little Microsoft-lead hand in this survey.
That would be about 304 days, as 20% of 304 is 60.8 (304+60.8=364.8). The 20% must be taken as 20% of the RedHat uptime, not the Windows.
But yeah, that's way too low for RedHat.
According to Netcraft, they have a whopping 4 days since last reboot: http://uptime.netcraft.com/up/graph?site=www.yanke egroup.com/
They also go with the bulletproof reliability of MS IIs
Power tends to corrupt, and absolute power corrupts absolutely.
What the hell kind of shops/businesses/people are they surveying? People that have their servers running for a couple of days a year??
"According to the Yankee Group's annual server reliability survey . . . Windows 2003 Server, in fact, led the popular Red Hat Enterprise Linux with nearly 20 percent more annual uptime."
I would think that most businesses want to have their servers up 24/7/365 minus a few hours of scheduled reboots and upgrades, and unless something breaks or crashes. So, assume a Windows 2003 server had PERFECT uptime record for the year.
365/1.2 = 304.17. So, in order for Windows to beat Linux with 20% more uptime, they're trying to say that a server running RHEL is down more than SIXTY DAYS a year? My BS meter just crashed.
See, I know far too little about system administration. If I were to try to run a Linux server without help, it would be down all the time. If _I_ wanted a server, I'd pay someone a service feel to maintain it for me, and it would be up all the time.
So, it seems to me that ON AVERAGE, Linux servers would be down more than others, because so many people would be trying to admin themselves. The lack of documentation would definitely be a problem. (Actually, there's plenty of documentation. FINDING it is the problem. I don't know enough to come up with the right Google search terms! And posting to usenet is hit or miss.)
The question is what the uptime is like for Linux distros where you're paying out the ass for support (like you would for Windows or UNIX anyway). That's got to be such a small portion of Linux servers that it's not dragging the percentages up.
The real metric should be UPTIME / ($$ spent on support).
Be careful about those divides by zero.
See for yourself:o soft.comx .com
http://uptime.netcraft.com/up/graph?site=www.micr
http://uptime.netcraft.com/up/graph?site=www.linu
I can easily clone a production server and walk it through the upgrade process
apt-get dist-upgrade
It is truly awesome. You can test and re-test the entire process every time they release a bug fix for any of the packages you'll be using. (Yeah, you can do it with gentoo, also.)
I am not surprised. Documentation of many open source projects (including linux) is often very poorly written and/or not maintained. Being a good code writer does not necessarily translate into being a good documentation writer. Major software companies hire whole teams of doc writers, and the results are (many times) much better than those that come with OS projects. This has been one of my fundamental points in the never ending discussion of things that are hindering wide spread adoption of OS solutions.
My
Debian Sarge x86: 63 days, 19:43
Debian Sarge PPC: 61 days, 12 min
OS X 10.4 PPC: 51 days, 1:02
NetBSD m68k: 107 days, 37 mins
So, if you want the highest uptime, use NetBSD on a 25MHz 68040. Further, I contend that my study is at least as believable as the article cited in the submission.
MacBook Pro. Worst name since the Bicycle
I happen to be a Linux developer myself, and other than my own inherent bias towards my own system, I'd have to say that there are a few good reasons I never believe this junk:
Uptime isn't everything, especially as far as security patches are concerned. Sure, the site can run for years on end, but does it have the latest security fixes, especially for low-level kernel and other system stuff that often requires a reboot to finish?
The distribution does matter, at least in my own opinion. Red Hat might be one of the big names, but it's only one of many distributions – and a lot of them, especially ones based on Slackware Linux such as my own, tend to be considerably more stable and reliable (I may be wrong here, but I've used both systems, so I have at least some experience). So don't blame every Linux system just for Red Hat's problems.
History repeats itself, as a lot of previous posts have shown – they always make these extraordinary claims about Windows vs. Linux, but it's always the same people, and they're always proved wrong in the end. Since everyone else has already made this point, I'm just going to leave this one alone, and continue to the next:
UPTIME ISN'T EVERYTHING! I've already said it once, but uptime is only one of many different statistics as far as this type of thing's concerned. Sure, it's important that servers stay running as long as possible, but honestly, there are other important factors to consider as well – I'd rather have a Linux system that's occassionally offline than a Windows one that's always on, because (a) the Linux system would likely do what I need it to with far less work, at least in my opinion; (b) the Linux system would likely be much more secure against outside threats than the Windows one; and (c) face it, I'm biased, and so's everyone else who does this type of thing.
Just remember, there are three types of lies: Lies, damn lies, and statistics. I don't think we really need to say anything else. Q.E.D.
Creative misinterpretation is your friend.
I wrote a Microsoft-funded white paper last year with the assistance of two subject matter experts - a Microsoft expert and a linux expert, both certified veterans of their fields. The goal was to compare the processes required to set up and administer various services in Windows 2003 Enterprise vs. Red Hat's and SuSE's boxed enterprise server NOSes. Because the white paper was intended for internal use only, we had 100% control over what services would be tested, how to evaluate them, and how to present our findings. We didn't evaluate uptime per se, but I feel my comments are relevant since installation and maintenance contribute to server and client downtime, ergo, uptime.
We compared many factors including user management, authentication, "ghosting" new machines remotely, remote application installs, file sharing, delegating authority to subordinate administrators, and much much more. The Windows and Linux guys would work on a "lab" side by side, often peeking over to see how the other was doing. At the end of each lab we'd all have a discussion about the number of steps, any problems, company and community support, the ease/frustration factor, and how it went overall. We wrote about all these factors and rated them on 10-point scales per lab, and condensed those into one comprehensive graph showing overall ease-of-use of each NOS.
Long story short, Windows came out on top by a huge margin in every field - ease, usability, intuitiveness, support, everything. In fact, the only topic where Linux came even close to Windows was in community support, and even that was only 50% of Windows' score. At the end of the project the Linux expert garnered a lot of respect for Windows and quashed most of his prejudices. Needless to say, MS soon compiled our white paper into marketing materials and stuck them on http://www.microsoft.com/getthefacts (but it's been replaced by more recent studies).
I was a little disappointed that we couldn't expand the scope of the test to put stuff like Apache and Squid and mySQL through the paces, but the topic was enterprise administration, not publishing live services. I also would have liked to have tested custom installs of other linux flavours like Debian or Slackware, but neither product had a specific enterprise distribution.
So don't be too quick to label all pro-Windows studies BS or FUD or other ignorant catch-all acronyms. I personally was funded by MS to spearhead an impartial study, and MS management had a genuine interest in improving their products. I can't speak for the study in TFA, but my own was conducted with nothing but integrity and truthfulness.
Uh, I can't remember the last time I had to patch my linux kernel due to a security issue. Maybe there was an occasion in the last year, but that is unlikely. That is the only thing in linux that requires a reboot.
As far as the other stuff you mention goes - none of that requires substantial downtime. Sure, if you're making an application change you might need to work out what dependencies need to be updated, but it isn't like you're going to do that while production is down.
If you're running a server that you care enough about to bother reading uptime surveys, then you're not going to make any changes to it until you've performed the change in an identical test environment following a documented procedure, and have tested the change to ensure the system works. Then you just follow the same procedure again in production and it will work there as well. And running a different OS isn't going to make a difference in your application update plans, except possibly for stuff like package-manager utilities or other tools to manage your apps. On linux you'd actually have more support for this stuff - if you need to have good control over your production server with some app not supported by the OS vendor then you're better off making your own RPM for it.
If you generally upgrade applications by fiddling with the production server until it works, then you're really not the target audience for server uptime reports. That kind of stuff will kill uptime on any server.
It's probably more a case of MCSEs that don't grok the concepts of Linux and how it is documented. The survey was supposedly limited to just shops that run both Windows and Linux. That means you are likely dealing with a bunch of MCSEs that have been working with Windows for over a decade and have only in the past couple years been given Linux to also administer. If such a survey were limited to shops that had been running both systems for an equal period of time and have people on staff who are specialists in each system and have equivalent levels of experience (for example the Windows admin has 10 years Windows experience and the Linux admin has 10 years Linux experience and both have been working at this particular shop for 4 years, which has been running both Windows and Linux for the past 6 years), then I think it might be able to show the true differences and similarities. But I don't think this is anything Ms. Didio is capable of doing.
now we need to go OSS in diesel cars
I don't give a rip about uptime per se. What I care about is being able to reboot on my terms..and sadly...Windows usualy sets those terms.
I know that zealots from both sides will indulge in the opportunity for some bashing and grandstanding, which is fun and I enjoy a good smack-down as much as the next Slashdotter, but I just wanted to inject a little reality check. This study doesn't mean anything about OS quality. Numbers always lie, and even if you're not trying to make them lie, they're sometimes useless anyway, as in this case.
Linux has a different user base than Windows and UNIX. So the fact that 20% of the responses to the survey show higher Windows uptime doesn't mean that for the same usage patterns Windows is higher quality. To show that, you'd need to compare only sites with very narrowly targeted usage patterns which differ (as much as possible) only by their choice of operating system. This study didn't even attempt that, so making any claim whatsoever about the relative quality of operating systems based on this data is fallacious.
Instead, this study CAN shed some insight on the type of people running different OS's, and their type of usage.
Since UNIX had the highest uptimes, you might conjecture that conservative people run UNIX. Or you might guess that since UNIX market share is currently eroding in favor of Linux and Windows servers, UNIX servers are more heavily weighted towards older, established systems that aren't in early development stages as much as the up-and-coming OS's.
Conversely, since Linux had the lowest uptime, you might guess that Linux has a higher percentage of fresh new applications running on it.
(Note that I'm not saying that there's conclusive evidence of these guesses here. I'm just saying that when considered together with other data, these are the kinds of conclusions you'd be able to draw from this sort of statistic).
"Linux distributions .. are offline more [because of] the scarcity of Linux and open source documentation"
.. "That's not a place I want to be." - Laura DiDio Aug 2003
Even assuming that were true how does a lack of paper cause an OS to bork?
And how does a lack of paper cause the OS to stay offline longer?
Is it because it is sulking?
How was the data collect the data?
What was the methodology used?
Where are the figures?
What criteria was used in selecting the participents?
How is a marketing firm or Ms. DiDio for that matter, suitably qualified to comment on OS security? Finally are these people really the unbiased commentators they claim?
"Windows servers recover 30% faster from security attacks than Linux servers" Laura DiDio July 2005
"Indemnification is a serious, potentially costly issue for enterprises" - Laura DiDio Oct 2004
"For the time being, she said, Linux has an apparent advantage simply by virtue of a lower level of connectivity" - Laura DiDio April 2004
"hype notwithstanding, Linux's technical merits while first-rate, are equivalent but not superior to Unix and Windows Server 2003," - Laura DiDio Mar 2004
"This has the potential to turn into a twentieth century witch hunt," "There is a visceral anti-Microsoft sentiment in Europe." - Laura DiDio Sep 2003
"The entire Linux community is saying to customers, 'You're on your own,'"
davecb5620@gmail.com
Google is where we all go for answers these days.
I think it's interesting that MS sells a lot of software (Office, for example) that has less-than-great documentation, and that this is also a complaint people have with OSS. Currently there's a market for commercial documentation for both types of software--my local Borders has lots of books on both Linux and Windows Server. But eventually I expect that OSS documentation will improve to the point where it's better than what is provided in proprietary software, since there are people both willing and able to contribute to the documentation effort in OSS.
True story: I was once offered a full-time job where the owner of the company essentially told me he was looking to hire a Microsoft Office expert to provide office suite "consulting" to his staff. I didn't take it (as a technical writer, I want to actually write) but it said a lot about the state of usability and documentation for Office.
Interested in a Flash-based MAME front end? Visit mame.danzbb.com
This is the postfix gateway, external web server, dns server, etc for our little (1000 employee) company:
root[loki:/]# w
10:57am up 1030 day(s), 21:27, 1 user, load average: 0.05, 0.02, 0.04
This happens to be a Solaris 9 system. It has never crashed. Actually, over the past 5 years we have had 1 software related bug take down one of our solaris systems (multipathing bug in the FC drivers when used with active/passive disk arrays). This is based on an environment with 40+ solaris based servers (running a wide variety of services, this is not a '40 identical servers shop')
The best our windows boxes can manage is 6 months (and that is if we skip a few of the security patches).
I can guarantee that during the past 3 years, every single one of our windows systems (60+ servers) has had an issue that is core OS software related (not counting the security related ones). Kernel memory leaks are the most popular (file server reboot every 115 days or it will freeze up). Security worms are another fun one, but kinda rare today compared to the good old days.
Others have already commented on the lack of clarity, the need to read between the lines, the absence of the most elementary numbers and facts about this "study" (as in: how many respondents, how recruited, how many rejected and why, how was uptime defined and measured, what were the uptime numbers, (contingency table by OS this year, contingency table by OS previous year)).
If any students read this, let me take this opportunity to warn you. Submit a "report" like this to any serious faculty and look forward to an F grade. Unless you're a "Communications Major" obviously, in which case you'll be complimented on the flow of your prose.).
I'm guessing here of course, but I think that the real study was conducted and written by someone totally different, and miss Didio got the write the "teaser": i.e. the part that you can release without divulging any real information that you would otherwise be required to pay for.
Raise your hand if you have read any documentation included with any software you purchased in the past five years. Anyone? Anyone?
Okay then- raise your hand if you know that there are 600-odd page gorilla Linux reference books out there which may provide documentation should you need it that will be 100x better than anything included with the software.
Raise your hand if you know where to seek help, such as #linuxhelp and #linux on EFNet.
Case in point. Why not put a properly run linux server against a properly run Windows server- that is what it comes down to. A trained, professional, and experienced admin who has learnt the software they are running and know it well, in a specific purpose. Put Linux as a fileserver against Windows as a fileserver with any optimizations possible and equivalent configurations that are agreed upon beforehand. Put Linux versus Windows as a Web server with a knowledgable admin. This `good at neither` system doesn`t work!
-M
when you see the word 'Linux', drink!
Because individually those bugs might not allow remote root, but in clever combination they would? Or perhaps there's also a hidden issue which wasn't widely known that the patch also fixes?
Also, you don't need to reboot Windows as much; often times you are told to because of a file lock, but you could easily unlock the file by stopping services which are using it at the time.
There are very very few servers in the world that need 100% uptime; if your server is that critical, why isn't there a fallback server you can rely on to bring the orginal down?
There really isn't any excuse not to patch, unless you want to leave yourself open.
I notice you never answered the question though; perhaps there is a security patch which you've not applied?
I'd probably have uptime like that on an old home server I have sitting in a closet somewhere, unfortunately it reboots every time the power goes out and the UPS drains.
There ought to be some kind of metric for "software uptime," i.e. the delta between the uptime of your actual services (HTTP, SSH, whatever) and the uptime of the building's mains power / network connectivity, etc. I'm pretty sure quite a few servers I've worked on would be at 100%, or close to it.
Otherwise, any time I start seeing surveys like this, I start to wonder about how they've tried to normalize the variations in hardware setups, connection reliability, power service reliability, etc. I could probably get more uptime if I had a bigger UPS and paid for a better internet line, but it's not that important to me; I suspect even datacenter users eventually have to make a determination of how much they want to spend for that last "9" to the far right of the decimal place, and not everyone's decisions are going to be the same.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
In debian based distro land, you upgrade everything on the fly. You need not reboot. You need not disconnecting from an ssh session to update ssh. Only security problems in the kernel need a reboot... so linux potential uptime = time since latest kernel hole require a reboot, and actual uptime IMHO is 99% or more of that.
In acronym land, you call BS on TFA, BTW.
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
Yes, Windows is better documented... That is, if you are looking for really shallow documentation. For both Linux and Windows, you are way better off by buying a few good books. The GUI documentation of Linux is pretty worryingly bad, but if you go deeper, it gets better. With Windows, it's just the other way around. Even MSDN is pretty bad and (maybe more importantly) one sided. And, if you are trying to watch it on the machine you are working on, prepare for a reboot; MSDN requires the latest Internet Explorer most of the time. I do not expect .NET to improve this situation, with Java application servers you can just unzip the stuff in a folder and run (as with the VM).
I generally find that whenever Linux is being attacked, it is only through a model with serious logical fallacies that are carefully covered over by seemingly innocent mistakes. In reality these are carefully engineered FUDs designed to sound valid to most common people but failing under any serious scrutiny.
I can conclude from these quotes that the author may feel that Window's point and click interface should somehow justify its inefficiencies compared to Linux. However, Linux's lack of point-and-click gui tools is very old news that got washed away several years ago when tools like Mandrake's free setup tools for Red Hat and SuSE's YAST came about. And besides, it is better to have to learn to setup systems using text config files and then have it run problem free for a year, than to point and click for a day and end up with a system that needs constant attention just to be kept running.
Red Hat released a purely security related kernel update on 2006/05/24:
https://rhn.redhat.com/errata/RHSA-2006-0493.html
I would be very surprised if your kernel did not have known security issues that you are unaware of. Whether or not the various security issues apply to your environment is another question.
robert
For the record, I've been using linux on servers and for my desktop for years.
Documentation for big projects (apache, squid, etc) is usually easy to find. However, when you start running between versions and other isssues, suddenly the waters become a bit murky. Google is often friendly, but lately I've been lucky to find docs in english let along for the version(s) of software I'm using.
I've also been taking my LPI (my employer's idea). It's a freaking linux certification/exam and has no official documentation, other than a general overview of topics. That's right, no course materials, nothing. Even as an experienced linux user/admin I generally don't memorize the dozen different ways to do something, and then find that the one I didn't know is on the exam (which you can't study beforehand, because no documentation).
Sites like TLDP et al are very useful, but a more comprehensive set of documentation (and more up-to-date documentation coming with the software packages) would certainly be a useful thing.
On the Windows side of things, Win2k3 server performs the best, most outages due to forced reboots from patching/hot fixing. Win2k servers follow closely behind. Both are about .04% behind the Linux and HP-UX boxes for uptime, and much further behind when it comes to the CPU running at 100% for an extended period of time doing whatever Windows servers decide to do overnight (Nagios classified as 'unavailable').
This 'study' is utter dreck. It's flawed from the get-go, and people have to be careful believing what they read. If you are an IT professional, I highly recommend you speak with peers who have some serious experience with Linux before you proceed with any deployment/changeover/rollout. Depending on what your needs are, you might be pleasantly surprised!
On Windows it is impossible to delete or replace a file which is in use (e.g. a shared library). The same applies for directories. Thus for any meaningful upgrade you need to restart the applications and often the OS _before_ you can do anything with their files. There are complicated mechanisms for keeping track of files that need to be deleted/replaced after a reboot. It appears that recently they have added yet another even more complicated feature to avoid reboots: http://www.eweek.com/article2/0,1895,1895276,00.as p
Such complicated techniques for a basic thing like an upgrade make me very nervous. What happens if something goes wrong with the extensive bookkeeping in the middle of the upgrade ?
There are always some study that says one OS is better than another. Most often the study is funded by one of the OS groups. That doesn't it necessarily make it useless. What makes them useless is when the details of the study are not released.
These studies present themselves as scientific but they are not. In true science, the data and the methodologies are presented for scrutiny. There could be issues with either or both that would harm the results. True science involves skepticism.
Remember a few years ago when some cult claimed that they cloned a human baby. The first reaction was "Can we see and test the baby's DNA?" When the answer was no, the majority of scientists dismissed their claims outright. The minority reserved judgement until there was actual proof.
Until I can look at the study, I'm not going to believe it. Since no one paid for the study, the Yankee Group does not have any restrictions unless they mean to profit by selling the study.
Well, there's spam egg sausage and spam, that's not got much spam in it.
There is no use. With no real information, this study is crap. It is just throwing more FUD on the pile. One of my favorite bits: I love that Linux is refered to as a less mature operating system. "Yankee Group determined a significant portion of this outage time is attributed to the scarcity of Linux and open source documentation compared to the more mature, established operating systems."
In some ways (support for 3D graphics HW, sound), Linux is not as developed as Windows or MAC, mostly due to proprietary vs open driver issues. In many other ways (portability, support for older/slower HW, virtualization, load sharing across machines, security, customization), Linux has far greater maturity.
UNIX is a totally different issue, but the Linux vs UNIX comparison is moot as far as I am concerned. For the most part, the kernels are the only fixed-in-stone aspects of these OS's. Some things don't exist in the Linux kernel, others don't exist in proprietary UNIX kernels. Choose your poison based on what you need.
In the end, the list of features unavailable in Linux is short and inconsequential when compared to the list of features unavailable in Windows or Sun/AIX/etc. OpenMosix, Xen, and User Mode Linux alone should be enough to overwhelm the Linux downside of making sure you buy a video card from a manufacturer who isn't an ass.
Just to round out my arguement: the other measure of maturity is time-based. Windows NT (follow-on from ideas developed in other versions of windows) was first released in July 1993. Linux (follow-on from ideas developed in UNIX and minix) was first released in August 1991.
Don't save Windows XP! http://www.petitiononline.com/jjw1xp/petition.html
The assertions are ridiculous on the face of it, obviously prepared by someone with an agenda, and not even a bit subtle.
As an IT professional, I can tell you that if any of our linux servers were to go down, there would be people screaming bloody murder all over the place within a few moments. Downtime is unacceptable for infrastructure services, and linux has performed flawlessly for the fortune 100 company where I am employed.
I think as other posters have noted, the key piece of information that was unwittingly leaked, was that the survey was only open to windoze shops, and most likely included some mcse's linux test boxes in the downtime data figues. That's really the only thing that makes sense, as downtime simply wouldn't be tolerated in a normal production environment.
Anyone who is works with linux professionally and is aware of the fact that it's been running 24x7 for years at amazon.com and other firms such as my own employer, will find it quite odd to read about all this extended downtime and the nonsensical reasons given for it.
This is just pure FUD.
Uptime is something I see as completely meaningless, the longer the uptime just means the longer the machine wasn't rebooted that's all. Why would a sys admin reboot? After a major update or a new kernel or even after serious patches.
In the world of linux, there's constant improvements, enhancements and security patches in the kernel and in the server software. I think the gap is more to do with Linux Sys admins being more active in maintaining their boxes compared to the windows sys admins.
If windows 2K/2003 servers do have longer uptimes than that to me is just scary, it means those sys admins aren't applying security patches regularly.
My 2 cents.
"If a show of teeth is not enough, bite
I have to reboot Windows2K3 jsut about everytime an update is avaliable from Microsoft. I started using the system only a few months ago.
I have not had a reboot of the Linux system we use here in well over a year, (448 days to be exact) even though I have updrad applications and applied many patches.
--fatboy
According to various articles scattered around the net, the Unix flavors included Solaris, HP-UX, etc. But, I have seen no references to NetBSD or FreeBSD as a Unix that was evaluated.
While boxes are boxes and OSs are OSs, the application that the server is running needs to be factored in. There are many cases where a BSD server may be a better choice than Linux or Windows just as there are cases where Linux or Windows may be the better choice. I found it interesting that I can find no reference to a BSD Unix in any of the links to the study.
So, since this study has so many unanswered questions relating to function, measurement criteria (what is considered downtime?), application, hardware, etc., the survey is pretty much worthless.
Box+OS is a tool and I use the right tool for the job. One size does not fit all solutions.
Banjo - The more I know about Windoze, the more I love *nix
With Debian, grab deborphan and debfoster and you can weed out un-needed packages quickly and easily.
"deborphan" compares the dependencies of each package so you can see packages that are installed that nothing else needs. Delete the ones that you don't need.
"debfoster" shows what all the dependencies are for a particular app. For example, Apache can have all kinds of packages it is dependent upon. If you want to get rid of that app, you can also quickly purge all the packages that were installed as dependencies for that app.
Once you've got the machine stripped down to the basics, just check all the files in the non-home/non-data/non-log directories to make sure that they each belong to a package. Or that you know why you put them there.
It runs sweet.
It runs clean.
It runs exactly what you want.
Nothing more/nothing less.
Which makes patching the box soooooooooo much easier. And it means that you have fewer potential security holes because you're running fewer apps.
As far as TFM it's qualifications draw my suspision. Did they include "devices" running linux as well or just full blown rigs? I can tell you *nix based appliances (unless they're really bad) have very few problems, and don't typically require the constant reboots for system updates that drives down your 99.99..999999 uptime.
Whatever happened to limiting exploitable processes? Windows method of protecting the services is all based around their firewall. Ever try and configure a windows box to run slimmed down? It's a pain in the ass. How about hardened? Good luck, apply the NIST standard lockdown SecPol to a 2k3 box and you'll see what I mean.
Take a *BSD/Trustix(+SELINUX)/Debian(+SELINUX) box install with 3 services AND a firewall in a 100meg footprint, and call it a day. Windows can't compete with the kinda uptime you get out of a stripped down OS. Oh they try with XP-Embedded and the likes but it's certainly not within the same realm of ease to create and deploy the OS that the *nixes give you. Not to mention, how many times have you had to troubleshoot a problem in Windows that ended up being caused by some unrelated service? I can tell you from my experience, it doesn't happen very often on a machine running single digit numbers of services.
On top of which they nicely avoided shops smart enough not to run Windows devices in their nocs, who probably have much better trained staff on the unix hardware and would throw their numbers with nearly 0 downtime figures. How many untrained people new to unix reboot when they could have just restarted a service? etc. This whole thing smells fishy.
You probably should not read the DiDio-bashing going on over at Slashdot today, but I do see what I believe is an error in the presentation of the data in the press release http://www.yankeegroup.com/public/news_releases/ne ws_release_detail.jsp?ID=PressReleases/news.server reliabilitysurvey.DiDio.htm.
The specific statement, "with nearly 20% more annual uptime" is I believe factually not supported by your numbers. Do you mean that Windows has 20% LESS DOWNTIME than RHEL?
"on average, individual corporate Linux, Windows and Unix servers experience three to five failures per server per year, resulting in 10.0 to 19.5 hours of annual downtime for each server."
If RHEL had 19.5 hours of downtime, and WIndows had 15 hours of downtime, this would be 20% less downtime. 5 hours less downtime per year is actually real data and would be useful to the press release.
On the other hand, 20% more annual uptime would actually result in RHEL being down nearly 61 DAYS per year assuming Windows is up 100.000%.Note: 60.8333 days = 365 - (365/1.2)
----------- The report may be correct. The press release is most certainly in error.
"Windows 2003 Server, in fact, led the popular Red Hat Enterprise Linux with nearly 20 percent more annual uptime."
My turnips listen for the soft cry of your love