 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am Tue, 26 Jan 2010 16:25:59 -0800 schrieb Darren New:
> Orchid XP v8 wrote:
>> ...which is interesting, given that SUSE is a Novell product. (Although
>> we are talking about OpenSUSE here, so maybe that doesn't count?)
>
> I wasn't talking specifically about one package or another. Just in
> general.
>
>> ...OK...but isn't this [part of] what package managers are supposed to
>> manage?
>
> Tell me how a Linux package manager is going to tell you whether anyone
> is currently running a program that needs some DLL it's going to
> replace.
If it is done correctly, it knows which programs depend on the "DLL" and
is going to update this programs as well, then - if they are running - it
will ask the user to restart this programs. At least Ubuntu asks me about
restarting the program. (Also, if I run an executable it seems "locked",
at least it refuses to overwrite it - which sounds to me the same as what
you described, what windows is doing, or do you mean something else?)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 27 Jan 2010 19:45:32 +0100, Fredrik Eriksson wrote:
>> The stock kernel doesn't, but there is a company that has developed a
>> way to patch the live kernel and have the patch take effect. I forget
>> who it is, but I've heard about it and from people who've used it.
>
> http://www.ksplice.com
That's the one I was thinking of, yes. :-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Florian Pesth wrote:
> If it is done correctly, it knows which programs depend on the "DLL"
No, it knows which *packages* depend on the DLL.
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. 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.
(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.)
UNIX has always been a "95% is good enough" OS. Linux is doing slightly
better, but still isn't 100% there.
> (Also, if I run an executable it seems "locked",
You can't write to a program that's executing, in UNIX. Never could.
What you *can* do is delete the executable while it's running (well,
technically, "unlink" it), and create a new file with the same name.
In Windows, to delete a file, you have to have write permission, and since
you don't get write permission to an executing file in Windows (just like in
UNIX), you can't delete the file.
In UNIX, you don't need any permissions on a file to unlink it from the
directory its name is in.
--
Darren New, San Diego CA, USA (PST)
Forget "focus follows mouse." When do
I get "focus follows gaze"?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am Wed, 27 Jan 2010 14:11:40 -0800 schrieb Darren New:
> Florian Pesth wrote:
>> If it is done correctly, it knows which programs depend on the "DLL"
>
> No, it knows which *packages* depend on the DLL.
>
> 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.
Right, if you install programs not in the package management, the package
management doesn't work on this programs. But this is to be expected,
isn't it?
(BTW, how do you ensure "atomic" process table lookups on any
multitasking OS? It is not, that you can prevent the starting of new
processes just after your check, can you?)
There's also no good
> way
> of telling what programs are running right now.
Just out of curiosity: Is there any way to tell of a process in windows,
which executable file it stems from? What happens, if you unmount the
volume the executable file is on or if the process you are looking at is
actually a child process from the original one?
> 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.
Again, how do you expect to solve this problem without some form of
either package management or a different centralized software
distribution system (for example like the App store for the iPhone)? I
can always compile a DLL with a same name which is incompatible to what
some program expects. That can only be solved by package management.
>
> (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.)
If the package management works, this is what happens:
You update the *package* of the media player. When you do this the
package manager notices, that you have an older version of that package
installed and checks if you have an instance of the program running (It
doesn't really matter, if this check is done in a nonstandard way,
because the package manager knows *exactly*, what version is installed
and how to check it.). It pops now a window asking you to restart the
player.
Of course if you don't use the package management you might break the
system, but thats not different than tinkering with windows on a low
level.
>
> UNIX has always been a "95% is good enough" OS. Linux is doing slightly
> better, but still isn't 100% there.
Sure, it is still some way to go (I'm doing some administration on some
linux machine on my job, but my primary job is using them for physics
simulations - so its pretty annoying if the stuff doesn't work. And yeah,
if it works for "practical purposes" its fine for me, even if it is
technically broken.)
>
>> (Also, if I run an executable it seems "locked",
>
> You can't write to a program that's executing, in UNIX. Never could.
>
> What you *can* do is delete the executable while it's running (well,
> technically, "unlink" it), and create a new file with the same name.
>
> In Windows, to delete a file, you have to have write permission, and
> since you don't get write permission to an executing file in Windows
> (just like in UNIX), you can't delete the file.
>
> In UNIX, you don't need any permissions on a file to unlink it from the
> directory its name is in.
Thanks, didn't know that!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Florian Pesth wrote:
> Right, if you install programs not in the package management, the package
> management doesn't work on this programs. But this is to be expected,
> isn't it?
Yep. But notice how this differs from Windows. If it can replace a DLL, it
means nobody is using it right now, whether that program is in the package
management system of Windows or not.
> (BTW, how do you ensure "atomic" process table lookups on any
> multitasking OS?
Well, you could do something like (for instance) trying to open the
executable for writing. If it fails, someone is running it. If it succeeds,
then nobody at this point can "exec" it, because they'll get back that the
file is busy from the exec call.
At least, that's how it works on serious operating systems, like mainframes.
Everything you would commonly want to do is atomic in one way or another.
> Just out of curiosity: Is there any way to tell of a process in windows,
> which executable file it stems from?
Sure. The task manager does it no problem, so I can't imagine it's hard.
> What happens, if you unmount the
> volume the executable file is on
Dunno, offhand. I suspect either it doesn't let you unmount it or the
process gets killed before the unmount completes.
> or if the process you are looking at is
> actually a child process from the original one?
Which would the "original" one be?
>> 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.
>
> Again, how do you expect to solve this problem
This one is definitely more difficult, yes. In Windows, this is part of what
the COM system does, or you use NTFS atomic transactions. So either you say
"replace all these files including the executable" and the executable fails
so none get replaced, or you put the new COM software out there and
atomically update the registry to point to the new COM server.
> can always compile a DLL with a same name which is incompatible to what
> some program expects. That can only be solved by package management.
Sure. I'm just saying that package management systems fall down at some
point, more or less complexly. You *can* ensure this doesn't happen under
some systems. UNIX isn't one of them, because the semantics aren't there in
the atomic parts of the system.
There's a reason it's called the "registry".
> If the package management works, this is what happens:
> You update the *package* of the media player. When you do this the
> package manager notices, that you have an older version of that package
> installed and checks if you have an instance of the program running (It
> doesn't really matter, if this check is done in a nonstandard way,
> because the package manager knows *exactly*, what version is installed
> and how to check it.). It pops now a window asking you to restart the
> player.
How does it know how to check if some random user is using an arbitrary
program at the moment? Or if that program is running in a way that can't be
interrupted with a "window"? What if I started some long-running data
munching job in the background and logged out. Who do you ask if you can
replace its DLLs? Or if it's not in a package but the DLLs it's using are?
> if it works for "practical purposes" its fine for me, even if it is
> technically broken.)
Yeah, I grew up on mainframes where the folks writing the OS actually paid
attention to all the corner cases, so it bugs me when there's no guaranteed
way to see if something is already running, etc.
It's only since /proc came along that you could even tell if a service was
already running and not restart it if it was.
> Thanks, didn't know that!
Yeah, Windows doesn't have a problem deleting an open file in general. It
just has a problem deleting an open file that you specifically said "don't
let others delete this while it's open." It just happens that the OS opens
executable code files that way, so it can page out of the files directly
without copying them to swap space.
--
Darren New, San Diego CA, USA (PST)
Forget "focus follows mouse." When do
I get "focus follows gaze"?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Invisible <voi### [at] dev null> 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
|
|
| |
| |
|
|
|
|
| |
|
|
