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

On Fri, 05 Aug 2011 22:00:43 -0400, Jim Henderson wrote:

> Yes, it's a choice of whether to rename the file or delete it

Agh, rename or copy.

Jim

Post a reply to this message

On 8/5/2011 18:59, Jim Henderson wrote:
> 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.

Well, yes, it allows files to be deleted while they're open.

"thankfully, package updates write a new file and rename it over the old 
name, leaving our open copy the only remaining reference to the old name."

That's the only place where he makes a distinction, and that's what I'm 
talking about. As I demonstrated elsewhere, it's a choice of the package 
manager whether to write a new file and rename it, or overwrite the old 
file, which is what he's talking about here.

> 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....

OK. It made perfect sense to me, and I'm not exactly a newbie to Linux *or* 
Unix.

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

Post a reply to this message

On 8/5/2011 19:00, Jim Henderson wrote:
> 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.

OK. Then I'm not seeing your point. What statement do you think is actually 
incorrect?  I must be missing something, because you're not the only person 
who has told me there are incorrect assertions in the article, but I've not 
gotten anyone else to actually say what they are either, other than arguing 
that Linux's package management isn't "inferior".

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

Post a reply to this message

On 8/5/2011 20:24, Darren New wrote:
> Well, yes, it allows files to be deleted while they're open.

Or, more technically, unlinked. The files obviously don't get deleted.

-- 
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 20:25:59 -0700, Darren New wrote:

> On 8/5/2011 19:00, Jim Henderson wrote:
>> 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.
> 
> OK. Then I'm not seeing your point. What statement do you think is
> actually incorrect?  I must be missing something, because you're not the
> only person who has told me there are incorrect assertions in the
> article, but I've not gotten anyone else to actually say what they are
> either, other than arguing that Linux's package management isn't
> "inferior".

"one distinction between "lame port of a Windows app" and "real Linux 
software" is exactly whether you distribute as a tarball or as a package."

Factually incorrect, as I said, ask anyone using Slackware what they 
think of that statement and they'll laugh you out of the room.

"Secondly, and more importantly, we knew that regardless of what we did 
for Google Chrome the Linux distros would attempt to stuff Chromium into 
their package manager even when they know it breaks the app, much like 
they've done to Firefox."

Factually incorrect, since package management systems that use RPM or DEB 
allow for the creation of packages that won't install if a conflicting 
package is installed.

"Now that I've summarized it in these terms it sounds a little 
depressing, but there it is"

Factually incorrect, because he got the previous two statements 
completely wrong.

Jim

Post a reply to this message

On 8/5/2011 21:20, Jim Henderson wrote:
 > "one distinction between "lame port of a Windows app" and "real Linux
 > software" is exactly whether you distribute as a tarball or as a package."
 >
 > Factually incorrect, as I said, ask anyone using Slackware what they
 > think of that statement and they'll laugh you out of the room.

Does a tarball on Slackware actually track dependencies? I think any general 
statement you make about Linux is going to be wrong in at least one 
distribution. Plus, that's one distinction. He's obviously talking about the 
distros that actually have packages.

 > Factually incorrect, since package management systems that use RPM or DEB
 > allow for the creation of packages that won't install if a conflicting
 > package is installed.

I think making a Chrome update package that won't install if Chrome is 
already present would be counterproductive.  What do you think the 
"conflicting package" would be?


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

Post a reply to this message

Le 06/08/2011 07:20, Darren New nous fit lire :
> Does a tarball on Slackware actually track dependencies?

well, it won't compile if the dependencies is not already installed. ;-)

I remember trying to compile gnome on a slackware (old gnome, old
slackware,... old time). It was a bit a game of "try and error/again" as
there was a lot of modules, with no clear order described.

Gentoo is also source-based, and it does track dependencies in its
packages system. It's easier that slackware, as long as you are ok to
follow their option/use system.

(but it can be complex if you want option A for some packages and not-A
for some others... which have a common package!)

Post a reply to this message

On 8/5/2011 22:39, Le_Forgeron wrote:
> Le 06/08/2011 07:20, Darren New nous fit lire :
>> Does a tarball on Slackware actually track dependencies?
>
> well, it won't compile if the dependencies is not already installed. ;-)

Well, yes. The trick is (A) keeping things up to date, and (B) not 
uninstalling dependencies for code that's installed. :-)

I mean, there were lots of UNIX systems without any sort of package manager. 
That's what RedHat fixed.  So I'd say, yes, sure, a "real" Linux program is 
available as a package.  If your Linux doesn't use packages, then obviously 
you don't use the package version of the program.

> (but it can be complex if you want option A for some packages and not-A
> for some others... which have a common package!)

That was always the problem I ran into, yes. Or conflicting versions of DLLs 
both referenced without version numbers.

-- 
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 22:20:09 -0700, Darren New wrote:

> On 8/5/2011 21:20, Jim Henderson wrote:
>  > "one distinction between "lame port of a Windows app" and "real Linux
>  > software" is exactly whether you distribute as a tarball or as a
>  > package."
>  >
>  > Factually incorrect, as I said, ask anyone using Slackware what they
>  > think of that statement and they'll laugh you out of the room.
> 
> Does a tarball on Slackware actually track dependencies? I think any
> general statement you make about Linux is going to be wrong in at least
> one distribution. Plus, that's one distinction. He's obviously talking
> about the distros that actually have packages.

It's been a long time since I installed a package on Slack, so I don't 
know how they track dependencies.  But my point is that he says that 
distributing a tarball doesn't make it "real Linux software", but a "Lame 
port of a Windows app".  There are plenty of software packages for Linux 
that are only distributed as a tarball.  Truecrypt comes to mind, 
actually.  One might argue that there is also a Windows version of 
Truecrypt so it might qualify as a "lame port of a Windows app" until one 
realizes that architecturally, the Linux version is quite different 
(doesn't require a system-level device driver on Linux, but it does on 
Windows - for example).

If he's "obviously talking about the distros that actually have 
packages", then the point becomes meaningless because it's self-
referential.

>  > Factually incorrect, since package management systems that use RPM or
>  > DEB allow for the creation of packages that won't install if a
>  > conflicting package is installed.
> 
> I think making a Chrome update package that won't install if Chrome is
> already present would be counterproductive.  What do you think the
> "conflicting package" would be?

Chromium, which is what he's talking about.  Chromium is different from 
Chrome.

Jim

Post a reply to this message

On 8/6/2011 12:29, Jim Henderson wrote:
> distributing a tarball doesn't make it "real Linux software",

No he doesn't. He says that's one way you can tell. And obviously he's not 
speaking technically. I.e., I think you're reading way too much into the 
part that talks about the motivation for making it work with Linux package 
managers.

> If he's "obviously talking about the distros that actually have
> packages", then the point becomes meaningless because it's self-
> referential.

I disagree. There are lots of lame ports of Windows software that's 
distributed as a tarball for Ubuntu, for example.

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

Post a reply to this message

On Sat, 06 Aug 2011 20:17:55 -0700, Darren New wrote:

> On 8/6/2011 12:29, Jim Henderson wrote:
>> distributing a tarball doesn't make it "real Linux software",
> 
> No he doesn't. He says that's one way you can tell. And obviously he's
> not speaking technically. I.e., I think you're reading way too much into
> the part that talks about the motivation for making it work with Linux
> package managers.
> 
>> If he's "obviously talking about the distros that actually have
>> packages", then the point becomes meaningless because it's self-
>> referential.
> 
> I disagree. There are lots of lame ports of Windows software that's
> distributed as a tarball for Ubuntu, for example.

Like I said, we'll have to agree to disagree.

Jim

Post a reply to this message