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."
"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...
I wouldn't be too sure about that; I just installed Xen on a box this past week, and the testing branch has been remarkably stable. Have you actually used Xen? That said, I like to think that the poster's larger point is that virtualization technology and its implementations - in VMWare, Xen, etc. have made patch management easier to manage, especially with all of the work going on in migrating apps and OSes. That, to me, will be the real benefit of such work.
The Norton Anthology of English Literature, 4th Ed., Vol 2
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.