Slashdot Mirror
Windows Cheaper to Patch Than Open Source?
daria42 writes "Is Windows cheaper to patch than open source software? Of course this Microsoft-commissioned report thinks so - but a number of people disagree, including a key Novell Asia-Pac exec, Paul Kangro. Kangro highlights problems with the report including the fact that it refers to problems faced by administrators before 2003: before significant improvements were made to Linux patching tools. 'We didn't have tools like Xen for Linux then,' says Kangro. 'When I patch my Linux box I don't need to bring it up and down any number of times.' Kangro also points out the report doesn't mention costs associated with rebooting systems after a patch is applied."
It might be easier if you have no idea how to really use a computer, and are not willing to learn. Those people will never leave the "comfort" of a familiar thing. They fear change, especially when it forces them to actually think for themselves.
And they said zombies weren't real!
So microsoft says windows is cheaper to patch, whereas Novell (who own Suse) say linux is cheaper to patch.
Can someone tell me why this is news?
[...]problems with the report including the fact that it refers to problems faced by administrators before 2003: before significant improvements were made to Linux patching tools. 'We didn't have tools like Xen for Linux then,' [...]
Oh, come on. Practically speaking, we don't have Xen for Linux *now*. Sure it's cool and all (which is why it's slipped into this basically unrelated story) but it's not nearly ready for the Linux mainstream and I'd be surprised if more than a handful of people are using it heavily in production.
Every time I read about another "paid by Billy G" report it always reminds me of the joke.. How many Microsoft engineers does it take to change a lightbulb. None Microsoft defines darkness as the new standard..
Really? The 'apt-get update && apt-get upgrade' i did earlier today on my debian (testing) box took less than a minute, and isntalled not just the latest security patches but also the latest versions of all my software. That was pretty-much free.
Conversely, windows update only updates windows (not my other apps), and takes at least 15 minutes every time i run it.
Any company where the majority of the cost is in the patching process itself, rather than the testing of the patch, the secondary servers in the test lab that they can make sure it doesn't blow services up on, the payment of skilled people to identify the problems and fix them *when* they happen and various other people costs is of course going to be more expensive than "I set up windows updates once, so now it updates me magically whether I like it or not", even without the reboot thing.
There is also some really iffy logic in breaking down one single piece of the ownership cycle and claiming that it is cheaper and ignoring the rest. I tell you, paying for college for my persistently vegetative child is uber-cheap, I can't say enough for persistent vegetation...
The cost of rebooting on some machines is astronomical. I know we had some management software on a data line connected to the stock exchange. From the hours of 8-5 any downtime would cost over $10k/second, not to mention any lawsuits that could have been processed if someone lost money and couldn't sell their stocks when they wanted. On the other hand, most machines are not nearly that critical, and reboots can be done at off hours. I would say that Windows systems are less costly to patch for another reason. Almost anyone with technical ability can patch windows. You can hire windows admins on the cheap. To get Unix admins will cost more if you want someone that knows what they are doing. I wonder if they take the cost of knowledgable staff into the equation. Otherwise, the cost of patching for either can be huge or trivial depending on the patch and the situation. Also, Windows is a lot better now with the reboots. You don't have to reboot nearly as much as in the past.
/. ++
I just can't agree with that report. From 1999 to 2002 I did work for a datacentre with 150 Linux servers and 26 NT and then Windows 2000 server servers. Keeping figures on those I can say that the total downtime due to upgrades and patching for both groups in total was almost the same.
Here's what else the Microsoft report found....
Linux will recalibrate your refrigerator's coolness setting so all your ice cream melts and milk curdles. It will demagnetize the strips on all your credit cards, reprogram your ATM access code, screw up the tracking on your VCR and use subspace field harmonics to scratch any CDs you try to play. It will give your ex-boy/girlfriend your new phone number. It will mix antifreeze into your fish tank. It will drink all your beer and leave its dirty socks on the coffee table when there's company coming over. It will hide your car keys when you are late for work and interfere with your car radio so that you hear only static while stuck in traffic. Linux will make you fall in love with a hardened pedophile. It will give you nightmares about circus midgets. It will replace your shampoo with Nair and your Nair with Rogaine, all while your current boy/girlfriend is dating behind your back and billing their hotel rendezvous to your Visa card. It will seduce your grandmother. It does not matter if she is dead, such is the power of Linux, it reaches out beyond the grave to sully those things we hold most dear. Linux will give you Dutch Elm disease. It will leave the toilet seat up and leave the hairdryer plugged in dangerously close to a full bathtub. It will remove the forbidden tags from your mattresses and pillows, and refill your skim milk with whole. It is insidious and subtle. It is dangerous and terrifying to behold. It is also a rather interesting shade of mauve. These are just a few signs. Be afraid. Be very, very afraid. Windows is so much safer.
The weak spot in the credibility is always..."Microsoft commissioned report".
(Apologies to Laika)
"Kangro also points out the report doesn't mention costs associated with rebooting systems after a patch is applied."
This is a really underated cost that not many people include or even consider. The environment I work in has a few thousand servers and 130K desktops; all running a mix of 2K, 2003, XP - and other Windows flavors. (Like that's my choice).
The reboots after patching are a major pain, everything needs to be checked and always, and I mean ALWAYS, some servers will fail to come back up.
It's costly stuff...
How about desk-bound employees and their patches? Don't we count?
I use a lot of non-MSFT apps, and if one of them fails to work with the patched Windows system, I'm goung to lose a lot of time. I've already had one "security patch" to something do wierd things to my system, making it impossible for me to see the hard drive password prompt. Multiple that by every laptop in the company and you have a lot of support calls.
Another "security patch" seems to have hosed the network finder so that it can't automatically pick up a new IP address from the LAN. I have to manually change the settings and ..... guess what? REBOOT to force it to pick up the new IP address. Every time I have to log on from home, that's TWO reboots and two manual interventions to what should be automatically happening.
We, Unixers, usually miss the point that, while we don't have to reboot the whole computer at each and every important patch, we have to bring services down and then back up when they are significantly patched. For a database server it's not the system uptime that counts - it's the database uptime. If it goes down, I could as well have rebooted the whole server - the phone will ring just the same.
While this is a whole lot better than Windows, they are getting closer.
And... Well... The fact it was paid by Microsoft says nothing about the report. I sure would like to see the other reports paid by Microsoft that say FOSS is cheaper, more reliable, more ethical and that are tucked away somewhere in a folder marked "secret"
http://www.dieblinkenlights.com
Patching open source is easy and does not need to be done as often
:)
This isn't always true!
1. If you are actually using the fact that some package is open source and run a modified source tree you need someone to maintain that tree for you. You may have to fuss with patches, especially if large or if they affect areas you have customized.
2. Depending on your package patches come willy nilly, with no co-ordination. MS releases patches the second Tuesday of every month. This actually allows some type of planning.
3. Depending on your package patches may come in series: three patches in three days, for example. I have never figured this out, but its almost like the attitude is, "well, while we are here". Additionally, you have products that are in "heavy development" with pretty serious point releases weekly or monthly. This really sucks if you are working against product. Do you wait and just upgrade once a year or every two years, or do you keep on the treadmill? MS has one good thing going for it, in that for example I installed some Win2k Servers in mid 1999 that are still on the same OS install almost 6 years later. I installed some RedHat servers at the same time, and well needless to say, I've upgraded from RedHat 5.x a number of times since
4. Patches for Linux, like Windows, still need to be tested in a production environment. Especially if you are running from a largely source built system. I admin a heavily customized web server that was built almost entirely from source, and I can very rarely do a simple "make && make install", let alone install a binary RPM. As long as there is that uncertainity, it has to be tested if you are running real IT shop.
MS is really starting to get its act together on some things, and patching is one of them. The balance with patching is the overhead versus the urgency. The OSS crowd generally see's every patch as urgent, and it reflects in the release schedule. MS generally sees few patches as urgent, and it also shows.
Well, lets look at the facts:
@ Both Linux and Windows can be easily configured to auto-update patches.
@ Windows patches are smaller (binary diffs as opposed to full updated packages).
@ However, there are more critical updates to Windows.
@ Windows has SUS, whereas Linux doesn't seem (excuse me if I'm wrong) to have any kind of distributed patch management for large businesses.
If bandwidth costs (it does), it could well be that Windows easily has less data to transfer for large organisations.
If we're talking about uptime then yes, Linux will be more "cheaper" (better uptime, minimal loss of business) in this respect.
I think Kangro was referring to more than lost business but also lost productivity.
In the case of desktops, it's going to be lost productivity. Sure you can schedule them to update and reboot in the middle of the night, but what if the user was working on something? The admins have to spend some time planning and scheduling mass updates or leave it to the user. It's trivial to reboot; it's harder to schedule for many machines so that productivity is minimally affected.
Also your argument only applies to mission critical or production machines. It does not include any development and/or testing machines that may not have a backup. Many organizations do not have the money to have a backup for every non-essential machine.
Our company is installing a new enterprise application. Every time we are rebooting the test servers, our consultants and employees are not working on the app. With new system setups, rebooting a lot is not uncommon.
Well, there's spam egg sausage and spam, that's not got much spam in it.
Sorry but this stuff is particularly trivial, patching 10, 100 or 1000 machines.
/afs/admin/scripts/patchme' >> /etc/crontab.master
e.g.
echo 'ALL:root: 15 18 * * *
Where the crontabs are centrally managed, patchme checks for resources, goes to sleep for a while, runs OS, platform and rev specific patch download and install subroutines which run yum update, apt-get update, patchadd, rpm -Uvh etc. Report progress to a central monitoring system like Big Brother or Zabbix as the patching process runs through the various stages.
Even talking about the cost of the patching process itself is missing the point. Anyone who has a lot of machines will already have a largely automated enterprise wide cross platform patching system in place. Applying a specific patch will be a case of dropping a pre-tested file into a directory on a file server. If you don't have such a system WTF are you doing wasting your time on Slashdot?
Deleted
Why is this a story? I mean seriously. These TCO articles come out all of the time, and they are bullshit all of the time. Don't we already know this? Does anyone with half a brain pay attention to these "studies"? There's nothing we can do to stop them, and we only discredit them here... Where everyone knows they are bullshit. It doesn't even have anything to do with some prejudice against Microsoft. Any company will bs their way to more sales. Welcome to life, people.
I hate grammar Nazi's.
Sure this is an inconvenience, but (still) overrated. It's just not a major issue to reboot a machine. Word. Move on.
What continues to be a major road block to widespread adoption of Linux by the masses is not just patching, but just installing applications at all. It just can not be said with a straight face that installing patches or an application on Linux is as easy as with Windows for average computer users. There are just way too many pitfalls that can trap a user in hours and days of searching for strange dependencies and other things. And a smooth GUI installer....
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
Can Slashdot concede that Microsoft-funded studies will come out in favor of Windows being better, and that some non-Microsoft-funded studied will come out in favor of Linux, and stop wasting our time with this banter?
________________________________________________
suwain_2
Windows installers are nightmares on the enterprise level. Too many dialogs that feature settings that should have been issued on a command line. Too many dialogs with non-installation information. (Hello?...EULA/README SHOULD BE HANDLED IN THE APPLICATION!!) These two create a situation where if you are going to install a piece of software on more than a handful of machines you really wish they had a silent install. More often than not you are stuck babysitting installs blindly clicking "Yes"s and "Okay"s and "Next"s. Yay for the TCO.
A "sin" Microsoft cultavated along time ago is confusing "installing" and "configuration" together. If you tie both of these process together it makes support murky. Did the installation fail to place files or did it mess up setting some value somewhere? Installers should be concerned with tracking/placing software components. Programs should be concerned with configuration. Because of MS including this level of complexity it also had the side effect of making it hard for a user to inspect packages before installing. There is no way for a desktop user to find out what a MSI package provides, what it requires, etc before installation. Another side effect is that people writting installers are often forced to package all depedancies with their application instead of making seemless stacking installs.
Making a Windows installer actually enforce component dependancies suffers from the same "DLL Hell" type problem that has plagued Windows forever. Most installations are written loosely: you can uninstall CompA which ProgramB depends upon and the system happily complies.
With all of that said, Windows installers are bad. Linux and other Unix-like systems are okay but they are more interested in software integraty than ease of use. You can't beat Mac: Drag a folder into the apps folder and its installed, take it out of the folder to uninstall it. At this point I can't imagine why anyone would any system to be more like Windows.