http://neugierig.org/software/chromium/notes/2011/08/zygote.html

Check out the third paragraph.
-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On Thu, 04 Aug 2011 18:45:22 -0700, Darren New wrote:

> http://neugierig.org/software/chromium/notes/2011/08/zygote.html
> 
> Check out the third paragraph.

It's a shame he doesn't get the Linux pieces down very well.

The package manager, for example, doesn't control whether files are 
replaced or deleted - what he's seeing is part of the standard filesystem 
behaviour.  I could just as easily cause the problems he describes by 
deleting necessary files while a program is running.

Similarly, his assertion in the last paragraph is laughably funny - ask 
any user of Slackware whether the apps they use are 'lame ports of 
Windows apps" because they're all installed through tgz files.

And what he asserts about Chrome and Chromium not working well together 
shows a lack of understanding of packaging dependencies for RPM and DEB 
packages.  They *could* well set up a dependency that says not to install 
if Chromium is installed (or to identify the packages as non-compatible).

Jim

Post a reply to this message

Jim Henderson <nos### [at] nospamcom> wrote:
> I could just as easily cause the problems he describes by 
> deleting necessary files while a program is running.

  If the program is keeping the file open, then deleting the file won't
affect it. However, if it's a file that the program opens and closes
repeatedly during its execution, then that's indeed the case.

-- 
                                                          - Warp

Post a reply to this message

On Fri, 05 Aug 2011 11:12:28 -0400, Warp wrote:

> Jim Henderson <nos### [at] nospamcom> wrote:
>> I could just as easily cause the problems he describes by deleting
>> necessary files while a program is running.
> 
>   If the program is keeping the file open, then deleting the file won't
> affect it. However, if it's a file that the program opens and closes
> repeatedly during its execution, then that's indeed the case.

Yes, and that's the case regardless of whether it's the user at the 
console doing it or a package manager doing it. :)

Jim

Post a reply to this message

On 8/4/2011 21:17, Jim Henderson wrote:
> what he's seeing is part of the standard filesystem
> behaviour.

Nah. I can overwrite a config file, or I can write a new file and rename it 
to be the config file, and these are entirely different things on Linux. The 
package manager just happens to do the latter.


The whole story is basically:

1) We can't just fork, because glib and other libraries might have locks 
open, and in that case things with threads break, and we use threads.

2) We can't just fork+exec, because if we exec, we get the new version of 
the executable which expects the new versions of files and it might not 
communicate well with the existing running processes.

3) So instead we start a helper process to hold open all the old versions of 
files because that's the only way to keep them from being deleted once 
they're unlinked, and the package manager unlinks old versions of files. And 
stuff often breaks if we forget to make sure every file we might need gets 
versioned this way.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On Fri, 05 Aug 2011 13:31:11 -0700, Darren New wrote:

> On 8/4/2011 21:17, Jim Henderson wrote:
>> what he's seeing is part of the standard filesystem behaviour.
> 
> Nah. I can overwrite a config file, or I can write a new file and rename
> it to be the config file, and these are entirely different things on
> Linux. The package manager just happens to do the latter.

Sure, but he's describing the behaviour as a package manager behaviour, 
when in fact it's an OS/filesystem behaviour.

> The whole story is basically:
> 
> 1) We can't just fork, because glib and other libraries might have locks
> open, and in that case things with threads break, and we use threads.
> 
> 2) We can't just fork+exec, because if we exec, we get the new version
> of the executable which expects the new versions of files and it might
> not communicate well with the existing running processes.
> 
> 3) So instead we start a helper process to hold open all the old
> versions of files because that's the only way to keep them from being
> deleted once they're unlinked, and the package manager unlinks old
> versions of files. And stuff often breaks if we forget to make sure
> every file we might need gets versioned this way.

But that's not what he wrote, and in writing it the way he did, he got 
some things wrong.  <shrug>  It happens, but it's important to understand 
how he got them wrong so the above makes sense.

Jim

Post a reply to this message

On 8/5/2011 13:35, Jim Henderson wrote:
> Sure, but he's describing the behaviour as a package manager behaviour,
> when in fact it's an OS/filesystem behaviour.

What "behavior" do you think is enforced by the file system that isn't a 
choice of the package manager?

> But that's not what he wrote, and in writing it the way he did, he got
> some things wrong.<shrug>   It happens, but it's important to understand
> how he got them wrong so the above makes sense.

I think that's pretty much exactly what he wrote. I didn't see anything he 
actually got wrong.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 8/4/2011 21:17, Jim Henderson wrote:
> The package manager, for example, doesn't control whether files are
> replaced or deleted - what he's seeing is part of the standard filesystem
> behaviour.

Or, to put it another way...

% echo alpha > alpha ; echo beta > beta
% (sleep 20 ; cat ) < alpha &
% sleep 3 ; cp beta alpha

What does "cat" print?

% echo alpha > alpha ; echo beta > beta
% (sleep 20 ; cat ) < alpha &
% sleep 3 ; mv beta alpha

What does "cat" print?

They're both standard file system behaviors. It's the choice of the package 
manager to use one technique over the other, not the choice of the file system.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On Fri, 05 Aug 2011 13:46:57 -0700, Darren New wrote:

> On 8/5/2011 13:35, Jim Henderson wrote:
>> Sure, but he's describing the behaviour as a package manager behaviour,
>> when in fact it's an OS/filesystem behaviour.
> 
> What "behavior" do you think is enforced by the file system that isn't a
> choice of the package manager?

That of allowing files to be deleted while they're open.  I don't "think" 
that's a choice of the package manager, because it is in fact how *nix 
filesystems work, regardless of what the app thinks about it.

>> But that's not what he wrote, and in writing it the way he did, he got
>> some things wrong.<shrug>   It happens, but it's important to
>> understand how he got them wrong so the above makes sense.
> 
> I think that's pretty much exactly what he wrote. I didn't see anything
> he actually got wrong.

I guess we'll have to disagree on it.  I read his description and found 
that it made no sense at all, and I'm not exactly a newbie to Linux....

Jim

Post a reply to this message

On Fri, 05 Aug 2011 14:19:32 -0700, Darren New wrote:

> It's the choice of the
> package manager to use one technique over the other, not the choice of
> the file system.

Yes, it's a choice of whether to rename the file or delete it.  That's 
not really my point.

Jim

Post a reply to this message