 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
--
Darren New, San Diego CA, USA (PST)
Forget "focus follows mouse." When do
I get "focus follows gaze"?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Of course, if I was going to do that, I'd have to sit there and freeze
>> the VM at the exact point where the error pops up so I can write down
>> precisely what it said.
>
> Does it reboot after the install completes? If not, see if the messages
> are out there somewhere, like with the "dmesg" command or whatever it's
> called?
It says it's going to "reboot", but there's no BIOS screen. I don't know
if it just stops one kernel and loads the other or what...
Trying to pause the VM at the right instant would probably be a lot less
work than trying to figure out Linux.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 26 Jan 2010 11:17:47 +0000, Invisible wrote:
> I used to quite like OpenSUSE. However, the other day I installed it
> about 13 seperate times. Let me tell you why.
If you were to ask some questions over in forums.opensuse.org, I'm sure
someone would be happy to help you out with the issues.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 26 Jan 2010 08:18:07 -0500, Warp wrote:
> Linux doesn't support switching kernels on-the-fly. Not many OSes do.
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.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 27 Jan 2010 18:44:18 +0100, Jim Henderson <nos### [at] nospam com>
wrote:
> On Tue, 26 Jan 2010 08:18:07 -0500, Warp wrote:
>
>> Linux doesn't support switching kernels on-the-fly. Not many OSes do.
>
> 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
--
FE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
