snort-sigs February 2011 archive
Main Archive Page > Month Archives  > snort-sigs archives
snort-sigs: Re: [Snort-sigs] Blog: Google Groups are a

Re: [Snort-sigs] Blog: Google Groups are alive!

From: waldo kitty <wkitty42_at_nospam>
Date: Thu Feb 10 2011 - 04:21:36 GMT

On 2/9/2011 22:47, Joel Esler wrote:
> On Feb 9, 2011, at 10:27 PM, waldo kitty wrote:
>>> I can't handle what other people do (personal websites, ISC, etc), but as far as the information coming out of Sourcefire, there will be pretty much two methods of getting it. The Blog, or the "group".
>> blog? is that like a wiki but "one-sided"?? ;)
> The blog is basically the "news outlet". People get the news, happenings, and pointers to everything else from that one place. That's my goal with it. I am not sure I want "documentation" to reside on the blog. I think that belongs under

understandable... but then one must also subscribe or visit the blog on some
"schedule" of some sort... whereas posting to a list is automatic and doesn't
take any more effort than posting a normal message to the list ;)

>>> If there are updates to the Snort site, (new docs, etc) I'll post about it on the blog.
>>> Discussions are left to the "groups".
>>> There is one other point of discussion that I haven't brought up, but have heard a lot of interest from the community, is to get rid of our "FAQ" that we maintain, and replace it with a Wiki. But I haven't started planning that yet.
>> wikis suck for information gathering and hunting... even though i'm an editor on
>> wikipedia, i still can't find what i'm hunting for 90+% of the time... i'm also
>> an editor on several other wikis and can never find anything on them unless it
>> is something that i've specifically set to be watched... wikis are, IMHO,
>> basically like a stack of postit notes that are maintained by many and which
>> are, basically a stack of "notes" and "documents"... the biggest problem is
>> getting them all to "line up" in a cohesive manner... sure, postits can be
>> alphabetized but is that any better for searching and finding that one specific
>> informative postit in the stack of several thousand???
>> FWIW anyway... but i'm just one teensy cog in the whole machine...
> I agree and disagree. I think the wiki idea has merit, as long as it's "moderated" properly. (notice the word "moderated" in quotes.)

yep... but who want's to coordinate a huge stack of postit notes? ;)

> I'd like to have an FAQ that is started with the FAQ we have, perhaps, but then turned over to the community, so you guys can add the tips and tricks that you've found and worked with over the years. Who knows where that will lead, as long as the information is correct and groomed properly.

true and understandable... a wiki might work for that... as long as the entries
on the index page are properly maintained... one of the wikis i'm working with
is kinda like a documentation book but there's a huge amount of information
that, while it is available if you know what to search for (and the wiki search
suxorz even worse than a wiki) anything that it should be linked to is not
linked... but then again, if it were all linked properly, most easily found
pages would be nothing more than link pages and that doesn't seem to be right...

> But like I said, that's still an idea in the back of my head, I haven't even started a plan for that yet. But there's been interest expressed to me by more than a few people. Internally to Sourcefire and externally (community).

many folk seem to like wikis... i don't doubt or deny that... but i have yet to
find one that is easily navigable by any newbie first entering the realm... and
most oldtimers are also as lost or even moreso than a newbie... why? i dunno...
if i did, i wouldn't be as lost as i am on those that i'm an editor on and i'd
not have near the problems locating necessary information on those that i'm a
meer newbie (aka user) on...

The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
Snort-sigs mailing list