[Popcon-developers] status of executables?

[jeff at linuxwest.com]

-------- Original Message --------
Subject: Re: [Popcon-developers] status of executables?
From: Bill Allombert <Bill.Allombert at math.u-bordeaux1.fr>
Date: Thu, March 03, 2011 2:24 pm
To: popcon-developers at lists.alioth.debian.org
Cc: jeff at linuxwest.com

On Wed, Mar 02, 2011 at 04:54:03PM -0700, jeff at linuxwest.com wrote:
> Thank you for replying so quick.
> 
> Indeed, mounting with strictatime did yield the desired result. I can
> see how some "false positives" *could* happen:
> 
> 1) Opening a directory with a GUI file manager changes atime (to obtain
> file types).
> 2) Executing `file` on a file. Same as above.
> 3) Doing a `grep foo *` within a directory opens the file.
> 
> In addition to the required mount option, do you consider these to be a
> problem? Do you deal with these "false positives" or do you consider the
> result an acceptable margin of error?

I do not have data on the error margin. Maybe this can extrapolated from
the 
popcon data.

If you would like that only files that are executed (instead of merely
read)
to be reported, a possible solution is process accounting, see the
package
GNU acct, but this is more intrusive and probably has an higher overhead
than
strictatimes. (I never tried it, I would be happy to know more about
it.)

> My interest comes from working on a similar project. I had the same
> problems and came up with a complicated solution. However, if you
> already solved the problem, then the only reason to continue working on
> my project is it's not necessary to get atime to achieve the end-result.
> Albeit, that in itself may not be enough to continue my project since
> somebody wishing to use Popcon can simply enable the required mount
> option (at some performance cost, I suppose).

Using strictatimes has indeed a performance cost (which depend on the
filesystem,
the hard-disk, etc.) but it should be compared to the performance cost
of the
alternatives.

Any project of this type is a compromise between conflicting goal. 
For popularity-contest, the goal was to minimize footprint to avoid
discouraging users to install it and to avoid popularity-contest itself
changing the atimes of too many files.

In particular it is written in basic perl (even networking) because all
Debian
systems are required to provide a basic perl environment. For example,
using curl 
instead of popcon-submit would cause popularity-contest to report curl
as used by
all submitters.

If you have different requirement, you will likely do different choices.

Cheers,
-- 
Bill. <ballombe at debian.org>

Imagine a large red swirl here.

~~
<begin proper bottom posting this time :)>

Bill,

I understand you completely. My solution uses dnotify and as I said, is
perhaps grossly complex. The obstacles are the same and in the end, I
don't know if it would offer many overall improvements (of course I
would need to run tests). With that said, it is very interesting. 

Ultimately, your program is much needed for people who want to upgrade
their distro regularly. Kudos to you and your team.

Jeff