Time to End Microsoft's Patch Tuesday? 256
buzzardsbay writes "Techtarget's resident security curmudgeon, Dennis Fisher, is calling for an end to Microsoft's monthly security patching cycle. Fisher points out that 'a hacker only needs one unpatched system, one little crack in the fence in order to launch a major attack on a given network. The sheer volume of the patches Microsoft releases each month makes it quite difficult for even the most conscientious IT department to get every patch out to all of the affected systems in a reasonable amount of time.'"
I have always wondered... (Score:5, Interesting)
Volume of patches won't get better (Score:3, Interesting)
So the sheer volume of daily patches would make this better?
Now, MS should take a clue from Apple and have a lot more "rollup" packages than they currently do.
Re:End Patch Tuesday (Score:2, Interesting)
I haven't patched anything from MS since years, but as far as I recall there was always some downtime due to reboots after applying a patch. I think MS had to release patches monthly, else there would be more downtime. Now that the Patch Tuesday goes to
I think the Patch Tuesday is here to stay, at least 'till the end of this year (vista sp1?).
Re:I have always wondered... (Score:5, Interesting)
The reason Windows updates require reboots is because open files cannot be replaced. So if a DLL is in use at the time of update, it won't actually be installed until you reboot.
Unix systems, otoh, have decided that the name of a file (the thing the user has control over) is not what actually ids a file, but instead the location on disk is the id. Hence why Unix updates don't require reboots and instead result in the problems you've mentioned.
I've always wondered how someone could consider the Unix design a good idea. Two different programs can open what they think is the same file, yet get completely different results. And yet some people don't seem to get why this is a really bad thing for shared libraries (or even files in general).
Re:I have always wondered... (Score:3, Interesting)
For example, you can create a temporary file by opening it (with create option), then deleting its name while keeping the file open.
Your file will be available as long as you don't close it, and will vanish automatically when you close the file, your program crashes, the system reboots, or whatever.
No more TEMP directory filling with crap, no need for a program that removes old tmpfiles left when a program crashes, etc.
Re:I have always wondered... (Score:3, Interesting)
Considering how well the Unix way works, I wonder how anybody could consider Windows a good idea. In Windows updates requires a reboot far too often. And in Windows you often get errors about files being busy for no good reason. OTOH with Unix you can upgrade a running program and not even notice. The running instance keeps running, any new instance will use the new version. Only problem is, that this usually works so smoothly, that you don't even notice. I recall once noticing, that I had KDE using libraries that had been deleted a month earlier. (Yes, I had in fact not logged out for a month).
If you get completely different results, there is a design flaw. We are talking about bug fixes here. The old version have a bug, and if the program triggers that it might crash or even worse produce undefined results (which could be to let in an attacker). The new version does not have the bug. As long as you don't produce the condition, which would trigger the bug, the two versions are supposed to behave exactly the same. And if you do trigger the condition, it is obviously an advantage that the new version behaves as intended. Of course it is not good that the old version doesn't, but the only way to avoid that is by never introducing bugs, which we all know is rarely feasible.
Re:I have always wondered... (Score:3, Interesting)
This is not a "trick". A file in Unix exists independent of its name(s). Each file has 1 name when created, but you can delete the name or add more names. When the number of names becomes zero, the file is deleted as soon as all processes that have it open do close it. As long as it is open, it is a fully functional file that occupies space and can be read and written to.
There even is a special function in the C library to create a temporary file:
FILE *tmpfile (void);
This creates a file, opens it for read+write and immediately deletes it. It is available as a temp file until it is fclose'ed.
In Unix this is simple to implement. The corresponding function in other systems is tricky and does not work completely correctly.
When you don't believe it, browse to your TEMP directory in a Windows system, usually C:\Documents and Settings\yourusername\Local Settings\Temp.
You will find many files with
How about they stop changing my default browser... (Score:2, Interesting)