[lsb-discuss] next version

Matt Taggart taggart at carmen.fc.hp.com
Wed May 7 17:53:39 PDT 2003


Dan Stromberg writes...

> Assuming enough people see the merit in what I'm proposing, what's the
> next step?  Wait for the next version of the LSB and bring it up then?
> Does this group have any sort of formal decision-making process (like an
> e-government or a voting system), or does the loudest voice win?

The lsb-futures group tracks proposed candidates for addition to
the LSB. This is an open group and everyone is invited to participate
in the mailing list and conference calls. We have developed and
maintain a list of criteria for determining when things can be added
to the LSB,

http://www.linuxbase.org/futures/criteria/

and we track proposed additions to the LSB at,

http://www.linuxbase.org/futures/candidates/

We talked about your proposal at this week's phone conference on
Tuesday. We agree that the idea has merit as an open source project
but we're not quite sure how it would be standards related. In order 
to be considered for the standard then it would need to be able to
pass the criteria listed above, which means an implementation,
mainstream acceptance etc.

There are similar projects that you might want to take a look at,

The Linux Counter
  http://counter.li.org/
  They seem to require users/machines to register via a web page and
  don't have an automated way to register machines.

The Debian popularity contest package
  Package page
  http://packages.debian.org/unstable/misc/popularity-contest.html
  Results
  http://people.debian.org/~apenwarr/popcon/
  This package has some nice features
   * opt-in
   * anonymous
   * sends by email so can go through firewalls
   * runs periodically via cron

A more generic package with the features above would be really cool.
That means
* opt-in
* anonymous (*and* verifyable would be cool too)
 * having a unique id that's not hardware related(no serial number,
     or MAC address) to verify that it's unique machine.(I'm not
     sure how this work work, needs discussion)
* send via email
* run via cron

If you write it so that it's easy to add additional tests I bet you'd
get quite a few contributions. Just a few tests off the top of my head,

* Distribution
 * package list and usage(like debian popcon)
* third party applications(if they want to be found, maybe a
   mechanism for this?)
* kernel version
* lsb version
* hardware details
 * architecture
 * physicial memory
* uptime, load, etc.

Basically anything that people think would be a valuable statistic for
developers/media/the public to know, that _doesn't_ compromise the
systems anonymity.

If you can guarantee anonymity you'll get quite a few users who are
willing to run it because they recognise the value to the community
of collecting these statistics. It will always be a very small fraction
of the overall userbase, but might be a good statistical sample. So
you won't get enough users to be able to prove the size of the installed
base, but enough to estimate. So once it's implemented, widely
deployed, etc. we could look at it for LSB. I suspect there would be a
lot of push back against standardization due to privacy reasons(even
if it _is_ anonymous). Even so, it would still be a good project and
solve most of the problem you're trying to solve.

Thanks,

-- 
Matt Taggart        Linux and Open Source Lab
taggart at fc.hp.com   Hewlett-Packard





More information about the lsb-discuss mailing list