another Microsoft x Linux study

[bballad]

One bit that you *nix are annoing me on...you keep sugesting that windows admins would just patch a production box...that is never done, we have dev and qa servers (at least at every place I have ever worked has had this setup) you never do a change to production untill its benn tested...this is just as true in the windows world as it is in the unix world.

It seems in this test they had the admins installl all of the patches that come out...that is never done, we go through the patches and see which are needed and which are meaningless (why would I put a MS office patch on my server?) MS has a long history of releasing patches that break everything...why would I just load that into production.

[IKnowNot]

I started reading this after four glasses of wine, after four consecutive 16 hr. days at work, but accidentally deleted before finishing.
So please bare with me as I am sober now. Here is what I remember of my findings of this study. I Hope this is what you were looking for here.

1) there was a choice between Red Hat and Suse. As Suse had earlier in the target year been acquired by Novel, was this a wise choice?

2) They repeat many, many, many times about how they chose what software applications to use, saying they chose those that were used most by the industry, which would be the best indicator. However, they only mention twice ( once on page 21, second on page 45 ) that the applications had to be written for both Linux and Windows ( first criteria for consideration ). Were there other packages written strictly for Linux that were better suited?

3) What were the applications ( and versions ) used in the study? Or did I miss that?

4) They discuss the problems with SLES 8 during milestone 1 ( “... some upgraded components were out of support from SLSE 8 ...”), then were compounded at milestone 2. At milestone 1 SLES 9 was already available. If you were administering these systems, would you try to patchwork the system at this point or do the upgrade now? Apparently, after the upgrade of SLES everything came back into sync. Just as the requirements of a system may change over time necessitating modifications and enhancements to the systems, so must the update/patching schedules change with those requirements.

5) This was a lab experiment, done over a short period of time and using only their tests to verify the results. It does not take into consideration real world attacks, publicly available ( and private ) exploits, etc. which stress systems daily. How would these have effected each of these systems? These certainly add “pain” to administrators.

[cacosapo]

A buddy sent me this link from slashdot about this same subject http://interviews.slashdot.org/artic...tid=11&tid=106
I think that is a good reading about "research" and "metodology".

[guardian alpha]

you keep sugesting that windows admins would just patch a production box

Correct, because any unpatched program that exists on your computer is a possible weakness. If you do not have the software then naturally the patch should not be applied. If you do have the software then it is safer to merely uninstall the program you do not use so that you can avoid the additional unneeded patches for the Windows-based server.

But never, ever, complain that Linux users want Windows admins to keep on top of patches. If we don't encourage common-sense techniques of updating then you end up with events similar to Sasser.


Edit: I never thought of this before, but I now realise that it may come down to trusting the patches you download. With Microsoft it is common that a released patch will create a new bug or glitch that must be fixed with a no-so-quickly-released update. It never occured to me that I trust the open-source development model in Linux so much that when I do update to a more recent program the rare times it may go wrong is almost always fixed within a 24 hour period by the time of patch release. I'm not talking about bleeding edge, but sheer code handling and release to the public.

I've never had that same level of trust in Windows updates.

[bballad]

IKnowNot: you hit the main flaw right on the head...if the application they used required windows 2k would they have foreced the admins to run it on NT4? Why did they try and force the application to run on a older version of SUSE tehn what was required by the app?