Linked by Thom Holwerda on Sun 16th Dec 2007 17:57 UTC
Windows The first publicly available test release of Vista SP1 has been released a few days ago, release candidate 1. "The Windows Vista Service Pack 1 Release Candidate is now available to the public. In addition to previously released updates, SP1 contains changes focused on addressing specific reliability and performance issues, supporting new types of hardware, and adding support for several new technologies. SP1 also addresses some management, deployment, and support challenges." Ars reports that it finally enables the hotpatching support in Vista.
Thread beginning with comment 291376
To read all comments associated with this story, please click here.
no shit
by netpython on Sun 16th Dec 2007 18:59 UTC
netpython
Member since:
2005-07-06

"Hotpatching is a process in which Windows components are updated while still in use by a running process. As you can imagine, this handy feature eliminates the need to reboot,"

No shit, now where does this dejavu feeling come from?

Without knowing we had a feature in our midst for years on various *Nix platforms.

Edited 2007-12-16 19:01

Reply Score: 12

RE: no shit
by leos on Sun 16th Dec 2007 19:23 in reply to "no shit"
leos Member since:
2005-09-21

Yeah, the "file in use" is one of the biggest misfeatures of windows. Especially when windows will completely randomly decide that a file I'm trying to delete is actually in use and I can't delete it (even though it's just some random video file I haven't played in months). Unfortunately they still haven't fixed it properly, instead opting to create a hacky workaround for updates.

The nix updates are so much more logical. If a component is updated, apt will ask you if it should restart the corresponding service, instead of having to reboot the whole computer (which, given that no version of Windows has any kind of session support, can be a big pain).

Reply Parent Score: 6

RE[2]: no shit
by google_ninja on Sun 16th Dec 2007 19:38 in reply to "RE: no shit"
google_ninja Member since:
2006-02-05

The reason is because there is an implicit flock() on running files in windows. The problem is sometimes it doesn't automatically ulock properly. In linux they took a different approach, running files can be deleted, when the file is reloaded off the disk it will just be the new one. This can lead to some odd behavior, but completely eliminates the issue that windows has with not unlock files properly.

Regardless, linux has fuser -k, to do the same thing in windows is pretty complected, even though it is needed alot more because of the implicit locks.

Reply Parent Score: 7

RE[2]: no shit
by edogawaconan on Mon 17th Dec 2007 02:22 in reply to "RE: no shit"
edogawaconan Member since:
2006-10-10

Yeah, the "file in use" is one of the biggest misfeatures of windows. Especially when windows will completely randomly decide that a file I'm trying to delete is actually in use and I can't delete it (even though it's just some random video file I haven't played in months). Unfortunately they still haven't fixed it properly, instead opting to create a hacky workaround for updates.


It's fixed in vista. As that's the first thing I noticed when trying vista...

Reply Parent Score: 0

RE: no shit
by cetp on Sun 16th Dec 2007 20:15 in reply to "no shit"
cetp Member since:
2007-12-16

Unix systems gladly replace system libraries that are in use, and just hope that not problems happen because two different versions of the same library are in use simultaneously. The further away from the core libraries you get, the lower the odds of a problem, but it's still a risk. The Unix approach is basically "Let's just go ahead and do it, it'll probably be ok."

Windows takes the safe approach of only updating libraries that are not in use. I'm sure you'd wind up with weird glitches if your apps were using multiple versions of GDI simultaneously. The Windows approach is "It may be ok to update this now, or it may not. Just to be safe, let's not update it until we can guarentee it's safe."

The Vista implementation tries to free up libraries, and if it can, will then update them in place.

Reply Parent Score: 10

RE[2]: no shit
by kaiwai on Sun 16th Dec 2007 23:37 in reply to "RE: no shit"
kaiwai Member since:
2005-07-06

Unix systems gladly replace system libraries that are in use, and just hope that not problems happen because two different versions of the same library are in use simultaneously. The further away from the core libraries you get, the lower the odds of a problem, but it's still a risk. The Unix approach is basically "Let's just go ahead and do it, it'll probably be ok."


But at the end of the day, I want control over my operating system. I'll decide whether or not something is deleted, whether or not it is over written. UNIX treats me like an adult and says, "if you want to do that, you know the risks, you're a big boy".

Windows takes the safe approach of only updating libraries that are not in use. I'm sure you'd wind up with weird glitches if your apps were using multiple versions of GDI simultaneously. The Windows approach is "It may be ok to update this now, or it may not. Just to be safe, let's not update it until we can guarantee it's safe."


But it continuously fails everytime; as pointed out by one person, claiming that a file is 'in use' but never used; claiming an application is in use even though the application has been killed (and all dependencies). If Microsoft can't get it right, then they should take the UNIX approach until such time that they can get their 'secure solution' working.

The Vista implementation tries to free up libraries, and if it can, will then update them in place.


But when things go pear shaped you end up with half finished updates. I've had numerous updates fail from the very first Windows - all due to this stupid 'locking' idea Microsoft adopted.

Like I said, give me the end user power, if I balls up my system, its because I do so of my own choice, don't think that you as the operating system know what I want as an end user. If I want to over write, delete or modify a file, I want to do it for a good reason.

Reply Parent Score: 6

RE[2]: no shit
by pixel8r on Mon 17th Dec 2007 03:01 in reply to "RE: no shit"
pixel8r Member since:
2007-08-11

Unix systems gladly replace system libraries that are in use, and just hope that not problems happen because two different versions of the same library are in use simultaneously. The further away from the core libraries you get, the lower the odds of a problem, but it's still a risk. The Unix approach is basically "Let's just go ahead and do it, it'll probably be ok."

And it is ok 99% of the time, unless you do something you shouldn't. Thats your fault though, not a fault of unix.
Its a lot simpler and less error prone than you make out. Different versions of a library are almost always Newer versions which are also backwards compatible with older versions. They either add features whilst keeping the interface and old features intact, or they fix bugs in existing features whilst keeping the behaviour the same. If an app worked with an older library it will work just the same with the newer one. All you need to do to make sure your app is using the newer library is close it and re-open it. If you're worried about the newer library containing bugs that will crash your apps...consider that this is just as likely to happen in windows and has nothing to do with what we're talking about.
I've used Linux for 6+ years now and never noticed a problem with library versions. All I noticed is that reboots are only necessary if I'm upgrading the kernel.


Windows takes the safe approach of only updating libraries that are not in use. I'm sure you'd wind up with weird glitches if your apps were using multiple versions of GDI simultaneously. The Windows approach is "It may be ok to update this now, or it may not. Just to be safe, let's not update it until we can guarentee it's safe."


safe approach? or easier approach? Its just the way they chose to do it. admit that its not as good...

The Vista implementation tries to free up libraries, and if it can, will then update them in place.

and if it cant free them up? we then have the same problem we always had, with no solution. reboot?

Reply Parent Score: 1

RE[2]: no shit
by wirespot on Mon 17th Dec 2007 04:42 in reply to "RE: no shit"
wirespot Member since:
2006-06-21

Unix systems gladly replace system libraries that are in use, and just hope that not problems happen because two different versions of the same library are in use simultaneously.


They aren't used "simultaneously", at least not in the way you're implying. To put it in a simplistic manner: running processes have already read the previous version of the library and have everything that's needed with them. New processes will read the new version. The replacement of the library on disk happens transparently, and atomically, may I add.

What you probably mean is that at some point you may have two processes running with different "snapshots" of files (config files, libraries etc.) That happens to be one of the most useful and powerful features of *nix OS's. It does extremely little harm (most of which is purely academical) and a lot of good.

Consider for example that I can run the same application several times side by side with different libraries and configurations and compare them first-hand. Doing the same in Windows would require duplicating the entire install base of the application and tweaking each copy.

If you want practical uses, they're all around us. I for instance tweak my fontconfig settings by launching several gcolor2 processes and changing my .fonts.conf in between. Then I can compare the font rendering variants in much greater detail.

Reply Parent Score: 3

RE[2]: no shit
by gustl on Mon 17th Dec 2007 15:40 in reply to "RE: no shit"
gustl Member since:
2006-01-19

"Unix systems gladly replace system libraries that are in use"

Not really

usually you have the library abailable as:

liblibrary.so.1.2.3

and two symbolic links

liblibrary.so.1.2 -> liblibrary.so.1.2.3
liblibrary.so.1 -> liblibrary.so.1.2.3


What happens if someone "updates" on linux to liblibrary.so.1.2.4 ?

very simple: the old version is kept for programs which need the old one, and the symbolic links are reset to point to the new version.
And the new version has to be binary compatible with the old one, otherwise it would have to be a 2.0.0 release.
I experienced not one updating problem due to replaced libraries in 8 years of Linux usage. What happened was a mangled Kernel after a Kernel update (must have been too serious byte-flipping on the hardware or in the wire, because a re-download and reinstall cured the problem).

Reply Parent Score: 1