On Sat, Mar 7, 2009 at 7:06 PM, Andy Walls <awa...@radix.net> wrote:
> Actually it appears to be a meta-script.  It builds a script of i2c-set
> commands to reload an eeprom.  You then have an opportunity to review
> the script to reload the EEPROM and then run it.
>
> You first have to load the gun, then pull the trigger an shoot yourself
> in the foot. :)

Yeah, this is really not a very good argument.  Think of the average
user - he reads something on a newsgroup and thinks, "Oh, maybe my
eeprom is corrupted."  And then he blindly runs the three steps above.
 But he doesn't have the eeprom on his machine, so he copies it from
someone else's dmesg output he finds on the Internet, and doesn't
realize that the HVR-850 based on the Auvtiek chipset is different
than the HVR-850 based on em28xx.  Instant eeprom corruption.

>> Do you really want to be responsible for the
>> first time some unknowing user runs this against cx88 or some other
>> chipset you never tried it against and it bricks their board?
>
> Section 11 of the GPL legally absolves the authors of most, if not all,
> responsibility

Perhaps "responsible" wasn't the best word to use as it implies a
legal implication.  Sure, you're not legally responsible, but you
better feel damn responsible if you hand a tool like this to some user
who is just trying to "make his device work" and he trashes it out
because he doesn't know what the hell he is doing.

> The script should state in big letters that EXPERT knowledge of the
> device in question is required to reduce the risk. Perhaps reiterating
> portions of section 11 of the GPL.  (But then again, what is the risk of
> a non-functioning device continuing not to function?).

To answer your question, consider the definition of "non-functioning"
to an average user.  This can mean *anything*.  He could be trying to
use tvtime to watch a DVB tv source.  And he runs this script and
breaks a perfectly good piece of hardware.

> The real risk is running the linux code that trashes the eeprom in the
> first place.  I would look to prevent that code from running, or at
> least flag the risky condition in the kernel log.

I don't doubt that this tool could be useful for a select few
developers, but indeed it needs to say something like "Don't ever run
this tool unless somebody who knows what the hell he is talking about
tells you to".

Devin

-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to