Re: CD policy needed.
On Tue, Jul 31, 2001 at 03:02:32PM +0200, Robert Bihlmeyer wrote:
> > I had thought of using the GNU/Linux Popularity contest. Is the user-base
> > of the Hurd large enough to be of use to us?
>
> More importantly: is the number of GNU/Hurd users willing to install
> popcon high enough? Obviously, the popcon numbers could give us these
> as well.
>
> Unfortunately, popcon has currently no notion of architecture, at
> least the public statistics don't differentiate by it. The only thing
> I can see is that (if it's working correctly) no Hurd user has it
> installed, currently -- the hurd package has no votes. But so have
> silo, and milo ...
Actually, silo does have one vote and a few OLD... look in the UNKNOWN
section. I guess using the i386 Packages file as a source of section
information doesn't quite work either.
silo (and even lilo) could easily be a victim of popularity-contest though:
you don't really run their binaries that much. Once the install the boot
sector, you're set unless you upgrade your kernel. So don't trust them too
much. (I think it would still be enough to differentiate between, say, lilo
and grub, since they both have the same handicap.)
Anyway, you're right that I don't see any votes at all for the hurd or milo
packages. I'm not sure what would cause this:
- maybe no hurd user has popcon installed
- maybe popcon isn't compiled for hurd (I guess you checked this)
- maybe popcon doesn't run properly on hurd
- maybe most hurd users haven't configured their mail
- maybe popcon somehow doesn't notice the hurd package
- maybe hurd doesn't do file atimes correctly
- maybe most hurd users don't run their systems for long periods, ie. when
cron.weekly is running. Maybe they don't even run cron.
As a starting point, if you actually run the popularity-contest binary from
the command line, do the results make sense? Do you see the hurd package?
Now, as for the lack of differentiated results between arches...
Are we sure we want that at all?
The current set of results is only for 1200 people, which is much much
smaller than the actual number of debian users. It's already suspicious,
because we probably get plenty of skew in the _type_ of users - I suspect
it's mostly debian developers who actually run popularity-contest, since
it's not installed by default. If we started subdividing by architecture,
the results would probably be statistically insignificant. Worse, they
would be really easy to forge. (Right now, you have to be really bored to
forge 1200 messages to popcon and upset the results week after week; but if
there are only five other users, just a couple forged results in a cron job
would mess up the results for your arch.)
My theory is that aside for arch-dependent packages, the architecture of
your computer should have very little relation to which packages you use.
To sparc users prefer gnome more than alpha users and less than hurd users?
I doubt it.
You have to include arch-specific packages like hurd and grub on the first
CD anyway... for the others, I think you should just use the plain popcon
results. Of course, you also have the power to _start_ with whatever
packages you're sure you need (a modified gcc, different X server, whatever)
and fill the rest of the CD with popcon results.
> * Use a hacked popcon that submits to another address, i.e. generate
> independent stats for hurd-i386. Effort: minimal
>
> * Make stock popcon take architecture into account. I imagine that
> this could benefit others as well, but not as much as hurd-i386,
> probably. Effort: depends on whether only the statistics generator had
> to be modified (because arch is already gathered), or the protocol as
> well.
I would rather do the second than the first, since at least that way we have
the option of easily recombining the results afterward. Well, I guess it
would be easy enough both ways.
Have fun,
Avery
P.S. This message will probably get rejected from the mailing list since I'm
not subscribed. Please forward it for me if it does. For the same reason,
you might want to leave me on the cc: list.
Reply to: