l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2004 Jul 19 16:02

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Here's my project, please give me some feedback
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Here's my project, please give me some feedback

Jeff Newmiller wrote:

On Sun, 18 Jul 2004, Kedar Soman wrote:

I am developing a website to log programming errors. The URL is as follows
The reason for doing this is many times the error message tells us nothing
about what to do to correct the error. Google is the only option, which does
work mostly. But it would be good to have some website which tells us "what
folks have done when they faced certain error". This would be especially
good for novice programmers.

My point above about trusting your input also applies to Google searching,
and to your project as well, only in reverse. When presented with error
messages, Google tends to find questions in email/newsgroup threads, and I
follow the thread to the end to find more and more refined answers to the
problem. From looking at your site, the answers given there represent the
research of the people who originally encountered the problem... and they
are posting their "aha!" solutions at the same time as the problem.
I did tech support for for a number of years, and we used to call this the "voodoo" fix. It was the fix that worked one or more times for one person. Unfortunately, these voodoo fixes plauged our knowledge base and it was tough to differentiate tried and true (and/or official) fixes from the less than proven solutions. I can see this being a problem with the error message repository in question. If I can publically add solutions to problems in a public knowledge base without any credentials or without any governing review process, I can publish fixes with any of the following problems:

1. Solutions that worked for me because of some coincidence (aka the phallacy of false cause and effect). For example "uninstalling version 1.7, reinsalling version 1.6, and then rebooting fixes the problem". wrong! Rebooting fixed the problem.

2. Solutions that seemed to work for me are poorly communicated or just plain wrong, and by following my suggestions you'll either waste your time or perhaps even damange your system or cause loss of data.

3. Deliberatly malicous incorrect fixes for common problems. I can see this being similar to some of the socially engineered virus-type schemes like phishing. It wouldn't be tough to do either: just find some common but nasty error message and post a solution that asks the user to delete some critical file, or install some fake patch, or whatever else. Of course it's ultimately up to the user to use common sense and do proper research, but it's a possibility to consider.

Just some thoughts about potential pitfalls...I'm not trying to be critical in any way.


vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
O'Reilly and Associates
For numerous book donations.