Re: [Peep-develop] peep's popularity problems

[Michael G. <mg...@ee...>]

  Hey Xavier. Probably the best way to go about this is to get Collin
to let us know what the schedule is with his PhD.  I can't promise
massive amounts of time at this point but we can definitely make
progress. Unfortunately, we never quite finished up the 0.5.0 release
(although we were so close). That's definitely something on the
agenda. Then we can work on some of the nice configuration frills
we talked about. More below.

On Sun, May 18 @ 11:54, xavier renaut wrote:
> (01:18:54) node3667: we need to think about why peep is not a success if we want it do be more used...
> (01:19:54) magilfix: There are definitely a lot of people that have tried the software and I think it was a success just because it got people thinking
> (01:22:43) node3667: i really think peep is good software
> (01:23:16) node3667: but it looks like only sysadmin who have too much time in their hands are using it
> (01:24:03) magilfix: Cool. I think a lot of people are messing around with it.. I'm just not sure whether it's really taken off. It's hard to tell because when you do a good job, you tend not to hear about it from the general population :)
> (01:24:49) node3667: hum, i don't know, i really think i would generate more traffic on mls
> (01:25:13) node3667: peep is not (maybe it's part of the problem) a trivial tool
> (01:25:26) magilfix: I agree.. We were working on making it easier to configure
> 
> (01:26:08) node3667: right now i already find it easy to configure
> (01:26:27) node3667: that's the stuff about deployement, communication which is a hassle
> (01:26:56) magilfix: Well, send us any suggestions :)
> 
> First, i really think we shouldn't start mimicing netsaint/nagios
> (ie no email....)

  Agreed. We haven't been very communicative as of late. I'd like
to blame a busy schedule but that's no excuse so I'm guilty too :)

> i'm using nagios and it's doing a pretty good job. no need to come
> up with something that would do half his job and integrated 
> with something that do realtime analysis.

  Yeah, looking for ways to combine tools is really important for us
since we fit a particular niche.

> and i believe this were peep is good : real time monitoring.
> i believe this is the niche for peep. 

  Definitely. Always has.

> 2 problems (maybe?) with peep :
> 
> - setting up the communication channels between hosts
> part of the hassle is that for peep to work,
> we need a peep client on each machine. 
> means managing multiple peep configs, maybe it implies cvs....

  Well, do we have ways that solve this problem in a LAN setting -
i.e., the autodiscovery protocol (and leasing when using UDP). But,
a separate tool (such as cfengine, rdist, NFS, etc) must be used to
share configuration data.

> we should advertise the network values of syslog on 
> the doc. it looks far easier to set up a syslog server
> that deploying peep around. the network possibilities
> of peep are really really nice though, and we need to
> keep that. sometimes syslog is not possible. (i think
> traffic monitoring here, between others...)

  Agreed. Maybe we haven't played up this point enough. Perhaps too
much flexibility is a bad thing since it invites complexity. Part
of the reason that syslog is *easier* though is because people just
expect to have to push their syslog configurations out to the hosts.
It's harder convincing people to take that extra step. Perhaps we need
a "how-to" or some experience stories on how to best use the software.

> 
> - using sound 
> we need to ease the processing. not many sound cards
> thoses days accept multiple locks on /dev/dsp,
> so we need to make it work with alsa and/or esd.
> fyi, i'm using esd on my machines thoses days.
> ppl don't want their /dev/dsp clogged all day by a program.
> ppl want their im/irc alert working. (talking to much about
> my self maybe ;-)

  Actually, we do have ALSA support (I forget which version at this
point and since it moves quickly, it might need updating, but I think
it was the 0.9.x version). Esd is another way to go.

> and i don't know, maybe our culture is to much sight-centric,
> not really audiophile... audio is for entertainement (think
> music) when i explain peep to people, they're smiling
> when they learn that peep is sound based. 
> "realtime monitoring tool" sounds cool. this is peep.
> maybe ppl don't believe in sound. they believe in 
> popups. blinking. visual. another power of peep
> is that it's investigating another field yet
> unutilized professionaly speaking : the ear.
> (sound like i'm selling the lastest nonexistant dot com product.)
> (our product is based on a totally unexploited technology,
> multiply your productivity  !!)

  It's definitely a cultural thing. I remember when I was originally
preseneting the work that I had dissenters who doubted it's usefulness
just because it uses sound. It's unfortunately, but there are strong
ties to music and hearing and no more. That's something to work
on over time, but seems more like a mission than producing good
software, which is somewhat less tangible.

> may be a visual output plugin might be a hooker for people ?
> see attached file to see what i mean. sound would appear
> like drops of rain, left and right for left and right ear.
> real time, say 10 fps / sec
> i don't know how to do that (using the screensaver rain ?
> using winamp plugins ? look for something else ?)
> but i'm thinking that if we do it, we need to do it 
> fast. like to come up with something in 1 day or less... 
> this is a teaser. a hooker for ppl.
> no need to loose time on it. 

  I think providing some kind of visual output or integration with
a visual component would have definite value for people.  It gives
them the excuse to move beyond the novelty of the idea since the
visual is useful. I think it's important that any kind of visual
component is very straight-forward without too much abstraction. The
audio is already very abstract. We need something concrete to draw
people in. Collin was working on a visual display that had some strong
promise. I think we should pursue integration. I can't remember how
far along he had some in that respect.

> may be another problem is that our closest competitor,
> netsaint/nagios, is already filling the niche...
> reports, availability, the power of nagios is logging and
> retaining information. 

  Still different but I see your point. Why use the gathering framework
of Peep if you have another tool that substitutes but fits another niche?
Well, we do still offer uniqueness, so I'm not too worried. I think
our real problem is that we need to rekindle the fire and let the tool
evolve some more. I'll let Collin wax eloquent on that regard.

> we can ask ourself the question : what does peep brings to 
> ppl that nagios doesnt ?
> 
> - coolness factor
> 
> - realtime (i'm searching for a situation where it's needed, but 
> i can't find one)
> 
> - audio usage (could be counter productive at first, though i think
> it's the best choice made)
> 
> thoses 3 items are not enough. peep is not plug and play so
> it doesn't help. we need to find "real advantages,
> necessities" to "market" peep.

  But you must admit that 0.5.x is a huge step in the plug-and-play
direction. Keep in mind that realtime monitoring is more than a specific
situation but more like a state of mind: The administrator always
wants to be aware of all activity within the network at all times to
detect general problems; I don't think it's quite a question of
a specific situation where we shine.

  Thanks for starting up the discussion again Xavier. It's been
too long :)

                  -- Mike

-- 
Michael Gilfix
mg...@ee...

For my gpg public key:
http://www.eecs.tufts.edu/~mgilfix/contact.html