Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> Still, at least this isn't Windows - you don't have to reboot. Oh, wait,
>> yes you do apparently. At least, you don't *have* to, they just tell you
>> that some updates won't completely take effect until you do.
> 
>   Linux doesn't support switching kernels on-the-fly. Not many OSes do.

Yes it does, search for "kexec".

Post a reply to this message

Darren New wrote:
> There's no good way under Linux (without walking thru /proc and trying to
> parse it, and hoping it doesn't change while you do so) of telling what
> DLLs a given program is using that isn't in a package. There's also no
> good way of telling what programs are running right now.

fuser and lsof can tell you what programs currently have a certain file 
open. Probably it's race-condition-prone. Probably theu work by walking 
through /proc and parsing it.

> There's also no good way
> of figuring out if a currently-running program is compatible with the new
> DLL you just downloaded, even if that running program hasn't loaded that
> DLL.

If a shared library is ABI-incompatible, it will have a different soname, 
which means it will have a different *filename* too. Programs linked to the 
old version of the library won't be *able* to load the new version, and 
viceversa.

> (For example, you have your media player running, and you update the media
> player executable and all the codecs. But now you go back to the running
> media player and play a different file, which loads the new codec DLL that
> is now incompatible with the running executable.)

For dynamically-loadable libraries like that, it may need a custom solution, 
such as a function (with stable ABI by itself!) that can be called to ask 
the codec's ABI version, so the media player can tell if it's compatible.

Or don't break the compatibility to begin with ;)

Post a reply to this message

Nicolas Alvarez wrote:
> fuser and lsof can tell you what programs currently have a certain file 
> open. 

There is that, yes.

> Probably it's race-condition-prone. Probably theu work by walking 
> through /proc and parsing it.

""" Since lsof reads kernel memory in its  search  for  open  files,  rapid 
changes in kernel memory may produce unpredictable results."""

I.e., it works like "ps" used to before /proc.  And yes, it looks like it 
would be race-condition prone. But probably good enough, really.

Lacking a transactional capability is also problematic.  If you get half way 
through the upgrade of something and your program or even system crashes, 
you could be screwed, especially if what got corrupted was important to 
getting the system running again. I'm not sure if Linux has transactional 
file systems in common use. But again, that's off topic to the original 
"Windows locks executables" rant and more onto "mainframes actually worried 
about this crap."  Or more precisely, people actually worry about this crap 
when a crash costs actual real large amounts of money per second of downtime.

> If a shared library is ABI-incompatible, it will have a different soname, 
> which means it will have a different *filename* too. Programs linked to the 
> old version of the library won't be *able* to load the new version, and 
> viceversa.

That's a point, yes. Assuming you manage to avoid DLL Hell.

> Or don't break the compatibility to begin with ;)

Such is rarely done on purpose, yes.

-- 
Darren New, San Diego CA, USA (PST)
   Forget "focus follows mouse." When do
   I get "focus follows gaze"?

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> Warp wrote:
> > Invisible <voi### [at] devnull> wrote:
> >> Still, at least this isn't Windows - you don't have to reboot. Oh, wait,
> >> yes you do apparently. At least, you don't *have* to, they just tell you
> >> that some updates won't completely take effect until you do.
> > 
> >   Linux doesn't support switching kernels on-the-fly. Not many OSes do.

> Yes it does, search for "kexec".

  As far as I understand, kexec does not allow switching kernels on the fly.
It's simply a mechanism for rebooting (an already running system) faster by
bypassing most of the tasks done during a regular boot (ie. detecting and
configuring devices). I don't think it allows for programs to keep running
through the reboot. (In other words, there's still a downtime of the system
involved. It's just significantly shorter than with a normal reboot.)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>> Yes it does, search for "kexec".
> 
>   As far as I understand, kexec does not allow switching kernels on the fly.
> It's simply a mechanism for rebooting (an already running system) faster by
> bypassing most of the tasks done during a regular boot (ie. detecting and
> configuring devices). I don't think it allows for programs to keep running
> through the reboot. (In other words, there's still a downtime of the system
> involved. It's just significantly shorter than with a normal reboot.)

In fact, I think this [or something like it] is what OpenSUSE does when 
it's finished installing everything. It says it's going to reboot, but 
it doesn't actually reach the BIOS screen.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message