Patrick O'Callaghan wrote:
Until you reboot, some updates are not installed, they're just sitting
there in a disabled state. It's the reboot process that commits the
change.
It is almost what happens on Fedora with preupgrade.
But for Fedora this is only used to do huge changes to the system
(at the Windows 2000 -> Windows XP level).
Windows does it basically every time.
Although I haven't investigated it in detail, I suspect that this
is
because of a fundamental design limitation of Windows. On Unix-like
systems a file can be deleted while still in use, and any processes that
haven't closed it just keep on using it with no problem. Windows doesn't
allow this, so the update can't actually install the new files
(including new executables) until every process using them has stopped.
The easiest way to do this is to reboot.
OTOH on Unix the updated files (and executables) are completely
installed. Any existing processes that use them will at some point have
to be restarted (see the needs-restarting app already mentioned) but
that can be done as needed.
The more you think about it, the smarter the Unix file access model
looks. Ken Thompson is a smart guy and the use of inodes to disconnect
directory entries from the files they refer to is one of the smartest
things he ever did :-)
You are perfectly right.
The Unix access model never has locked files. You can always delete them
(and recreate them again with different content).
It is trivial on Unix to update glibc and sshd while being connected
remotely through ssh.
The only disadvantage is that some programs could still use old version
of the files, if they were already running during the upgrade. For example,
if you upgrade the libjpeg to fix a vulnerability, you are not totally
sure if your browser is still using the old one. But you can discover
these cases easily with a simple "lsof -n|grep deleted".
--
Roberto Ragusa mail at robertoragusa.it