Subject: Re: automatic package statistics
To: Hubert Feyrer <hubert.feyrer@rz.uni-regensburg.de>
From: Julian Assange <proff@iq.org>
List: tech-pkg
Date: 10/15/1999 03:47:14
Hubert Feyrer <feyrer@rfhs8012.fh-regensburg.de> writes:

> On Thu, 14 Oct 1999, Tim Rightnour wrote:
> > I think the right thing to do is write a perl script that looks at the logs for
> > ftp.netbsd.org, and records how many times that distfile is downloaded, or
> > attempted to be downloaed. (if that one is in the logs, not sure).
> 
> This is very very true - the ftp server's logs should be really used for
> some statistics. Maybe I should find time to continue that project ...
> 
> 
> > What I would not object to, is logic in bsd.pkg.mk, that sends out information
> > like the above, but must be explicitly turned on by the user, and ships with a
> > NO in mk.conf.example, with a comment urging people to turn it on (with proper
> > explanations of what it does).
> 
> Well, given all the reasons stated here by many people, I'd prefer not to
> see such code for now.

i.e instead of collecting privacy protecting, optional, accurate,
    USEFUL, upgradable aggregate statistics, we will collect mandatory
    ambiguous privacy violating statistically useless LOG FILES. Anything!
    Just so we don't have to THINK. Or do something NEW.

This reminds me of nothing more than the current ipv6 link address
encoding lunacy.  Another symptom of correlatory, rather than logical
thinking.

        "A dog has four legs and a tail. Therefor anything that has four
         legs and a tail is a dog".


-------------------------------------------------------------------------------

    P1: ethernet address----\
                             \
    P2: global spread---------\
                               ) C1: privacy violation
    P3: MS document ID--------/
                             /
    P4: microsoft-----------/


   P'1: ethernet address----\
                             \
   P'2: global spread---------\
                               ) C'1: privacy violation
   P'3: link/48 encode--------/
                             /
   P'4: ipv6----------------/


While the structure of P'->C' might be correlated to P->C. It isn't
P->C. It isn't P->C, because once you delve into the domain you
immediately find that P'2 associated only P'1 only indirectly. Via P'4
& P'3. Once you apply a little logic you realise that there is a
necessary AND between P'1 and P'2 that doesn't actually exist.

Kre's post was probably the worst example of this. Despite stating
that the feature would be made optional (opt out), Kre further spread
the taint to pkgsrc as a *whole*, refusing to use it at all. Nevermind
that whole chain of functional relevance could be disabled by the last
AND. (i.e AND the damned feature is TURNED ON AT ALL). I know this
happens sometimes to the best of us, but these sort of correlation
equals causation arguments are pure voodoo.

-- 
Stefan Kahrs in [Kah96] discusses the
   notion of completeness--programs which never go wrong can be
   type-checked--which complements Milner's notion of
   soundness--type-checked programs never go wrong [Mil78].