2:53 p.m.
Hi,
I got this bug assigned to yum the other day:
https://bugzilla.redhat.com/show_bug.cgi?id=446836
it's not really a yum item, yet, b/c yum can really only USE the data,
not generate it.
However, I don't know where it should go. Is anyone working on this sort
of thing?
-sv
--
I only speak for me.
4:14 p.m.
seth vidal wrote:
Hi,
I got this bug assigned to yum the other day:
https://bugzilla.redhat.com/show_bug.cgi?id=446836
it's not really a yum item, yet, b/c yum can really only USE the data,
not generate it.
However, I don't know where it should go. Is anyone working on this sort
of thing?
-sv
"
Very similar to ubuntu's popularity meter,
but better.
"
Cough, *Debian*, cough.
I'd be interested in this too. Smolt has opt-in ways to send stats, could we hijack
that submission infrastructure to also do software inventory?
If so, the code seems like it would be pretty simple.
We'd probably want that to be /another/ opt in switch since it's slightly
different info?
--Michael
4:25 p.m.
On Tue, May 27, 2008 at 03:53:18PM -0400, seth vidal wrote:
Hi,
I got this bug assigned to yum the other day:
https://bugzilla.redhat.com/show_bug.cgi?id=446836
it's not really a yum item, yet, b/c yum can really only USE the data,
not generate it.
However, I don't know where it should go. Is anyone working on this sort
of thing?
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
Dan.
--
|: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
4:39 p.m.
On Tue, 2008-05-27 at 22:25 +0100, Daniel P. Berrange wrote:
On Tue, May 27, 2008 at 03:53:18PM -0400, seth vidal wrote:
> Hi,
> I got this bug assigned to yum the other day:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=446836
>
> it's not really a yum item, yet, b/c yum can really only USE the data,
> not generate it.
>
> However, I don't know where it should go. Is anyone working on this sort
> of thing?
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
that's been my general impression which is why I was curious who wanted
to look at it since my overt bias against them is a bit discouraging :)
-sv
7:09 p.m.
On Tue, May 27, 2008 at 05:39:51PM -0400, seth vidal wrote:
On Tue, 2008-05-27 at 22:25 +0100, Daniel P. Berrange wrote:
> On Tue, May 27, 2008 at 03:53:18PM -0400, seth vidal wrote:
> > Hi,
> > I got this bug assigned to yum the other day:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=446836
> >
> > it's not really a yum item, yet, b/c yum can really only USE the data,
> > not generate it.
> >
> > However, I don't know where it should go. Is anyone working on this sort
> > of thing?
>
> 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
that's been my general impression which is why I was curious who wanted
to look at it since my overt bias against them is a bit discouraging :)
I think a more useful metric would be a popularity list based on which
programs are *run*. You'd obviously have to exclude things that are
typically batch-run/scripted - eg bash would dominate. Count any binary
run with a .desktop file perhaps, although that'd exclude mutt and emacs.
IIRC mugshot/gnome live is already able to track this kind of metric
Dan.
--
|: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
5:43 p.m.
On Tue, May 27, 2008 at 1:25 PM, Daniel P. Berrange <berrange(a)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.
-jef"Did i mention that I hate social networking"spaleta
5:51 p.m.
On Tue, May 27, 2008 at 4:43 PM, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
On Tue, May 27, 2008 at 1:25 PM, Daniel P. Berrange
<berrange(a)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.
They would be better suited with:
People who installed Thunar also installed ... bsd-games and fortune_mod
-jef"Did i mention that I hate social networking"spaleta
Stephen "Amazon is our salvation..." Smoogen
--
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"
3:49 a.m.
On Wed, May 28, 2008 at 12:43 AM, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
On Tue, May 27, 2008 at 1:25 PM, Daniel P. Berrange
<berrange(a)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
4:25 p.m.
On Tue, 27 May 2008 15:53:18 -0400
seth vidal <skvidal(a)fedoraproject.org> wrote:
Hi,
I got this bug assigned to yum the other day:
https://bugzilla.redhat.com/show_bug.cgi?id=446836
it's not really a yum item, yet, b/c yum can really only USE the data,
not generate it.
However, I don't know where it should go. Is anyone working on this
sort of thing?
I'm looking at something along these lines, but don't have anything to
show yet. I should have something for public consumption (text, not
code) this week.
-RN
--
Robin Norwood
Red Hat, Inc.
"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching
4:31 p.m.
2008/5/27 Robin Norwood <rnorwood(a)redhat.com>:
On Tue, 27 May 2008 15:53:18 -0400
seth vidal <skvidal(a)fedoraproject.org> wrote:
> Hi,
> I got this bug assigned to yum the other day:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=446836
>
> it's not really a yum item, yet, b/c yum can really only USE the data,
> not generate it.
>
> However, I don't know where it should go. Is anyone working on this
> sort of thing?
Doesn't mugshot collect this kind of data for it's application
recommendations?
1:43 a.m.
seth vidal wrote:
Hi,
I got this bug assigned to yum the other day:
https://bugzilla.redhat.com/show_bug.cgi?id=446836
it's not really a yum item, yet, b/c yum can really only USE the data,
not generate it.
However, I don't know where it should go. Is anyone working on this sort
of thing?
I do not think that user would be that much interesting in
having/knowing the top 1000 software used...
By doing this that would influence them, and oriented them to the most
used one... better stay in another famous and world well known
proprietary software that almost every one use...
But I do think that I would like to have this information for the
package I maintain !
Nowadays as packager the only feed back that told me that my packages
are used is basically bugzilla, which mean that if I have packaged a
good software that runs without problem I have no idea whether I have
worked for myself or if other people are actually using it.
In brief:
* I do not want/need these information for all the packages as a user
* I want these information for my packages as I am a packager.
Hope it makes sense :)
Regards,
Pierre
5873
days inactive
5874
days old
10 comments
9 participants
participants (9)
-
Daniel P. Berrange -
David Nielsen -
Jef Spaleta -
Michael DeHaan -
Pierre-Yves Chibon -
Robin Norwood -
Seth Vidal -
Stephen John Smoogen -
Yaakov Nemoy