Slashdot Mirror
Vista To Be Updated Without Reboots
UltimaGuy writes "Microsoft is working on a new feature for Windows Vista, known as Restart Manager, which will update parts of the operating system or applications without having to reboot the entire machine. From the article: 'If a part of an application, or the operating system itself, needs to updated, the Installer will call the Restart Manager, which looks to see if it can clear that part of the system so that it can be updated. If it can do that, it does, and that happens without a reboot.'"
If a part of an application, or the operating system itself, needs to updated, the Installer will call the Restart Manager, which looks to see if it can clear that part of the system so that it can be updated. If it can do that, it does, and that happens without a reboot.
Yes, and I am sure NOTHING could go wrong there...
Not being able to kill services in not a limitation of windows, it's a limitation of the task manager. Use Sysinternal's Process Explorer - it will let you kill any process, even if doing so will crash windows.
What planet are you from? World of Yesteryearland?
There's tons of GUI applications to shutdown and restart services on UNIX these days. Plus, some package managers are smart enough to shutdown a service, apply the updated files, copy over the settings, if some configuration files have been altered and then restart the service.
ALL FROM A GUI!
Again, welcome to the world of the future Mr. MS Apologist.
If you ignore the other uses of a tool, does that make the tool less useful, or you less useful?
How is this new, my {Unix| Mac| Linux} system has done this for years
Your mac most definitely has not done this for years. Even updating Safari requires a reboot on OSX. My mac can't go a week without Software Update asking for a reboot.
Unfortunately, FAT32 and NTFS aren't inode based filesystems and don't support in place replacement. That and their lousy file locking method.
I have no
This is really just a sign of poorly composed installers. Apple's PackageMaker tools allow the installer to require a restart. However, it's trivial to extract a package's components by hand, unlink any in use kexts or halt any processes with open files that need to be updated, and place the new files from the package where the belong. Then you can restart the updated kexts and launch the updated processes yourself. No restart required. Apple's installer just tries to keep things simple for Joe Average User, and that means running the install, and then restarting to shutdown processes and clean up.
If your an uptime junky, just do it all by hand.
At least when one had to reboot to update, one could usually make an informed choice whether to interupt one's work, close everything, and reboot. One can only assume that the "update without reboot" process will not be without risk. That is not a slam against MS; software isn't perfect. One way we deal with such imperfection is by minimizing the consequences of a crash or fault.
What if "update without reboot" is, in the name of consumer friendliness, as well as in the supposed interest of the "mommies and daddies out there," both automatic and invisible, and something goes wrong and/or is corrupted in the middle of a vastly important project?
There is safety in being forced to reboot. It means you aren't doing something else.
Only Women Bleed (Sex, Sharia remix)
IIRC, NT can quite happily delete open files. The problem is that the Win32 DeleteFile function tries to open the file with exclusive access when it deletes it - so that will fail if anyone else is using it. I have no idea why it does that...
This post explains more.
Why multiple updaters? Here's a brief description of each(names abbreviated in some cases to save my fingers)... Microsoft Update - Lets you download updates for Windows and MS Office all at once... Windows Update - Lets you download just updates for Windows itself... MS Windows SUS - A corporate version of Windows Update, that lets the network admin decide which updates get pushed to machines in the domain, and all client machines refer to that server for updates instead of Windows Update MSI - The "standard" installer used by most Windows programs when you first install them MS SMS - The old version of SUS (see above)
As much as we'd like some software companies to just update our current products it's unlikely that it'll happen. For you see, giving updates for free is not where the money is at, especially when you have an astronomical user base.
It's that way with a lot of things, for example I have a Wireless card that was sold AFTER the release of WPA but its drivers were never updated to work with WPA because they decided to abandon a perfectly fine card. If you contact the company they'll admit it no problem, they know they can get away with it and make even more money by doing something else.
For a lot of companies money comes before security. Unfortunately, thanks to a large ignorant user base (not everyone, but the majority), this is a perfectly fine business model for them.
$fortune
Tomorrow has been canceled due to lack of interest.
Bollocks, it completely depends on the update needed. Java doesn't IIRC, but anything like a Security Update will. Turn off auto-install and it won't do anything but tell you there's an update, you can run the install when it's convenient.
It doesn't mean much now, it's built for the future.
Windows XP is stable. It's the third-party device drivers that cause the vast majority of the problems. Seriously, get the drivers right and the box will stay up as long as any Linux box. I've got an old PC as a media player, it's got hardly any cruft on it and it's rock solid. I'd quote the uptime, but it's low at the moment due to me doing some electrical work in my flat recently. The only thing that forces a reboot is the odd Windows Update, which is sounds like they've now sorted. Nice. Uptime is stability.
Once the makers of the thousand hardware devices start bundling close-sourced drivers for Linux, you'll see the exact same problems there. I mention closed-source specifically, as the ones that provide OSS drivers "get it" and will have theirs fixed for them as and when required.
I'm guessing you don't use MS products and are just talking out of your ass. I haven't seen a serious crash from a Windows box (either at home or for 4 years at work) since about 2001 apart from driver problems clearly caused by NVidia. I've had things like the desktop lock up on me but killing and restarting explorer.exe with the task manager seems to cure that. Meanwhile I now work at a Linux based company and have rebooted on a regular basis. Of course this isn't in line with /. groupthink so I'll be immediately modded into oblivion.
The slashdot crowd once again rears its ugly "i'm a linux zealot so I'll say anything against windows and for linux even if it's not true" head. I'm a regular user of both Windows XP and Ubuntu Linux. BOTH operating systems support killing and restarting MOST services without taking down the entire computer, as well as OSX. BOTH operating systems will let you dynamically load and unload hardware drivers without a reboot. BOTH operating systems will allow you to change your network configuration without requiring a reboot. BOTH operating systems require a reboot for kernel modifications. Windows requires a reboot for core DLL files since it doesn't have a runlevel 3 to drop back to like Linux does. But for all intensive purposes, if I have to shut down all services as well as X-windows, I'm not that close to being any better off. As other users have pointed out, don't blame Microsoft for the software maker's innability to report when a reboot is actually required or not. Linux never tells you when you "should" reboot unless you've installed a new kernel, it just blindly assumes you're ok, when sometimes you are not. This was also pointed out for OSX, whose update manager usually suggests a reboot even though the OS is capable of surviving without it. I can also tell you from personal experience that you can offer to "reboot later" and continue using the newly installed software with no problem most of the time. The difference in these approaches is that when grandma and grandpa install something and windows doesn't reboot for them and a conflict arises, they're left with a blue screen of death and can't understand what happened. When a linux user updates but doesn't restart X, and then applications start hanging, he/she knows, "oh, guess I just have to restart, that was my fault." When the general public isn't well educated and is using your software, you just do what's safest for them.
Define "in use". If it's a program that's currently running and using it, no it doesn't. Even if the old library gets unlinked (deleted) it doesn't go away until the last process using it has exited. New libraries are named by their version (foo.so.X.Y.Z). Old ones go on living and things that are using them keep on using them.
Even programs that depend on older major versions of the library can coexist without anything special; minor versions are assumed to be binary compatible (and should be), but even if not you can manually specify which library to link if it comes down to that (like, if you broke the box and you need to rebuild it without rebooting).
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
"But for all intensive purposes, if I have to shut down all services as well as X-windows, I'm not that close to being any better off."
What intensive purposes?
Or did you mean intents and purposes?
I haven't seen a serious crash from a Windows box
This is believable. Windows has gotten a lot more stable with 2K/XP.
I've had things like the desktop lock up on me but killing and restarting explorer.exe with the task manager seems to cure that.
I've found that a lot of times in 2k/XP , if explorer starts chewing through memory due to a leak somewhere, using the task manager to kill and restart explorer.exe usually only provides a temporary fix, with the system becoming unstable again soon.
Meanwhile I now work at a Linux based company and have rebooted on a regular basis.
I find this a bit surprising, and kind of hard to believe given the lack of specifics. The great thing about linux is that, even when you have a run-away process chewing through memory, you can always kill -9 it and it will go away, even if that process is X-Windows/KDE/something big. As compared to Windows, where you can end task a process many times before it decides it will finally exit.
There's not as much groupthink here as you might believe. I happen to think that Linux is, overall, a lot more stable than its counterpart based on my own experience -- I couldn't care less what position the zealots here supports.
http://cltracker.net -- powerful craigslist multi-city search
From the description it sounds complicated as all get out. Doing dependency checks in real time while the system is running, unlinking in-use libraries, etc.
This is the result of a (now decades old) decision waaaayyy back in the DOS days. DOS, as you may well know, was originally very much a single-user, single-tasking O/S. Many have said that it doesn't even qualify as an "Operating System" and was really little more than an interrupt handler. Whatever. Call it whatever you will, A rose by any other name is still a turd. (ahem)
Anyhow, they ran into a problem when introducing DOS to network situations. What happens when you have two people trying to edit the same file? What do you do to keep things in a consistent state?
The *nix way is to allow it, and fork the file writes. Thus, a file remains in its original form as long as a program is accessing it, and if the file is overwritten by another process, there are two copies of the same file. This lets you do an update on a busy, heavily loaded system with dozens of users without interrupting things. Users still using the old copy of the program will continue using the old program until the process quits, and users newly accessing the program get the new one.
But Microsoft's solution was to lock the file, so that if user A was accessing the file, and user B tried to access it, they were given a low-level permission denied error. This decision was most likely made because it was a quick hack, and easily written.
When DOS went "multi-user" with Windows, for retro-compatability, the same behavior was used for interprocess file accesses. And, when the NT codebase was brought in, for retro-compatability with Windows, and all of its applications, as well as DOS, the same behavior was followed.
So today, we have an Operating System vendor trying to market their product as "Enterprise Ready" that's severely hampered by a quick hack and a poor design decision made some 20 years earlier.
Think about the incredible contortions Microsoft has to go through in order to introduce this feature of being able to restart services and DLLs because of this stupid decision made back in the early 1980s! Just unimaginable complexity so that perhaps a hundred man-hours of programmer time could be saved back in 1983! And that cost rises exponentially every year, now probably costing Microsoft in the tens of thousands of man-hours today. The cost of "fixing" this would be incredible - it's now pretty much a permenant fixture...
Really, I think this is a very interesting perspective on the often permanent nature of decisions... they often last WAAAYYY longer than you ever think, and certainly well past the original scope of the decision! Keep this in mind next time you get started on a project!
I take from this two lessons:
1) Try, very, very hard, when a project is young, to consider the ramifications of decisions, and try to anticipate where the project will likely go in the future when it "grows up".
2) As soon as you realized that you've made a mistake, as soon as you've realized that you've mistakenly built in an inherent limitation, don't hesitate to go thru the pain it takes to make it right. No matter how expensive it might be today, it will be far, far more expensive to fix it in the future, and will cost you in reduced performance and suitability every single day.
How much of the anti-MS sentiment so prevalent today among the tech community would be here if MS had just eaten the pain, and paid the price it takes to make a truly high-quality product early on?
I have no problem with your religion until you decide it's reason to deprive others of the truth.
When a library is replaced the original is deleted, but the content still hangs around until all programs that rely on that library close, at which point the file system deletes the content.
Not quite - it's more general than that. When a file that an application has open is deleted, the link to it is removed (so you can't see it any more, nothing else can access it, etc) but the data is left in place and any file handles remain valid. Once the last handle to it is closed, then the inodes are marked as being free.
That's the case for *any* file, be it a library, an mp3, a text file, etc.
For what it's worth, I can see situations in which replacing a library that's in use could be problematic. If you start another instance of the app that's using it, for example, and the library that's changed defines a communications protocol, then you may well have problems if the two instances try to communicate. That may be relatively ok if it's an instant message system, but not so good if it's something more critical like an RDBMS. Not likely, perhaps, but not impossible.
The main issue is that in windows, two files can not exist under the same name (no concept of linking).
The same is true of Linux. In the case of deleting a file that's in use and replacing it with a new copy, there are not two files with the same name. There is one file with the name, and an area of data that is no longer linked to. That area of data *used* to have that name, but doesn't any longer.
When deleting a file that's in use, an OS has three options:
1. Delete it anyway and damn the consequences
2. Delete it but keep the data available for the application(s) using it (the Linux way)
3. Prevent deletion of the file (the Windows way)
Note that 3 isn't the only way it works under Windows, it depends how the file was opened. For example, WMP is perfectly happy to allow you to delete media files while you're playing them, notepad is fine with text files disappearing out from under it, etc.
It's official. Most of you are morons.
Actually Linux does care whats on disk, it just doesn't care about the name in the filesystem tables, just the file itself, which means you can delete or reuse the name while the file is used.
Linux is not Windows
The problem with task manager is that it does not enable the privileges it needs to kill any process... this can lead to "end process" messages being ignored (access denied) for processes that you don't own. This includes stuff that is running as SYSTEM (even when you are Administrator).
The solution? There's a kill.exe utility in the windows resource kit that includes a -f switch... this does much the same thing as kill -9 in unix. The only time this will fail to terminate a process immediately (assuming you run it as admin) is when the kernel has a handle to the process still open (pending I/O operation etc). In this case, the I/O operations are cancelled and the process will disappear when they are done cancelling.
Another solution is to write code to acquire SeDebugName privilege (which will allow you to open a handle to any process on the machine) and then call TerminateProcess yourself.
>can you see your local hard drive from the applications on the desktop machine that you're remoting into?
mount nfs/smbfs/cifs
>Can you see your local printer
cups
>Can you hear sounds played by applications when you remote into a PC?
network sound daemon/arts/esound
>Same thing with fast user switching...
In *nix, you just x/vnc/nx and open a few GUI desktop AT THE SAME TIME.
Fuck user switching.
>As to changing OS components while running... Sure, Linux has had kernel modules, FreeBSD has had a microkernel... but is there a tool to automate dependency checking, to see which services need to be shut down, to actually shut them down / unload modules, and then relaunch services?
modprobe does automatically load LKM.
FreeBSD is not microkernel.
most init script are written to auto load modules, start dependencies.