package popularity ratings

Yaakov Nemoy loupgaroublond at gmail.com
Wed May 28 08:49:49 UTC 2008


On Wed, May 28, 2008 at 12:43 AM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> On Tue, May 27, 2008 at 1:25 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
>> Isn't any package popularity rating going to be hugely skewed such that
>> the 'default install set' packages are basically always rated top, making
>> rankings of dubious value
>
> I personally see zero value in a flat popularity rating.
> I would see more value if we could find a way to correlate users such
> that I could datamine the application preferences of people who were
> already running systems similar to mine.
>
> For example, XFCE users as a breed might prefer certain applications
> which are not 'popular' in the general userbase, but were immensely
> popular inside the XFCE subculture. Those shared preferences would
> never show up in a flat popularity rating..a rating destined to be
> dominated by FVWM2 users...so such a flat rating would never really be
> what XFCE users would find value in.
>
> But if we had a way to correlate a systems/usages/people with other
> systems/usages/people which are mostly similar, then we have something
> interesting as a metric...a metric that can support both common and
> niche subgroups..based solely on individual usage cases or habits.
> That way XCFE users, would end up correlating with other XCFE users
> and would have the software 'popularity' ranking biased by that
> correlation.
>
> It would end up being dynamic, in that as your usage patterns changed,
> how you would correlate with others would change as well without
> anyone elses habits changing.
>
> Centralization of 'popularity' is simply not flexible enough to be
> interesting in the brave new world of the social network.

This is actually an old issue, and it got brought up again last
February when I spoke to the people at OpenSuSE.  But first, a little
history.

When Smolt was started, there were privacy concerns.  The decision was
to restrict the amount of information collected, to ensure that there
would be fewer complaints.  The final decision was to collect no
packaging information.

Then, I came up with a privacy scheme that should eliminate 95% of the
legitimate concerns one may have.  This reopened the decision to
collect arbitrary information.  Nevertheless, Smolt and the project is
concerned primarily with hardware, although we can be linked to easily
with other databases.  Personally, I would like to see packaging
information kept out of our database anyways, just for complexity
issues.

Then, I spoke with some people from OpenSuSE and they mentioned that
they had a similar project, one which collected information about the
initially installed DE.  We may include the capability to collect this
information in a future version but it will probably be disabled by
default on Fedora.  If it does get setup, in the Fedora Land, the
values would be determined by which DE package groups have been
installed.  Even so, the information can be selectively hidden from
smolt, if the user prefers.

Finally, I am interested in combining several programs into the
firstboot screen.  This way, we can make it easy for the user to
decide how participatory he wants to be.  Getting this together is on
the Agenda for the summer.  That said, Smolt itself won't be concerned
with package information and details.

- Yaakov "sick of recurring conversation threads" Nemoy




More information about the devel mailing list