[Arm-netbook] identification EEPROM: writable or not?

Aaron J. Seigo aseigo at kde.org
Tue Nov 5 17:05:26 GMT 2013


On Tuesday, November 5, 2013 16:25:01 Derek wrote:
> > having  only (c) resolves possible ambiguities by not allowing for them.
> > what do you see as the benefits of specifying both option (a) and option
> > (b) instead of option (c)?
> > (keep in mind that (c) is really just a+b)
> 
> I would characterize C as "I can't decide between a or b, thus I abdicate
> and make it an option.  Luke is fond of saying "No options in the spec," for
> good reason.  Tough cookies, let's put this brick on the wall!

sort of; (c) proposes that portable software must treat the EEPROM as non-
writable (so that’s a decision, albeit one that affects software) but otherwise 
leaves it *unspecified*. unspecified is not the same as an option.

that said, there are already lots of options in the OEMA68 spec (e.g. which 
USB versions, which ethernet speeds) and there are unspecified items such as 
covering multiple displays.

imho a standard of this sort contain the minimal set of rules to be useful, as 
that keeps both development and certification simpler, which in turns makes 
adoption and successful interoperability more likely.

so the question perhaps is: how important is it for the EEPROM writability to 
be specified?

if it is not important for interoperability or otherwise useful standards 
conformance, i would label it as “unnecessarily complex” and leave it 
unspecified.

> If I may stand on the shoulders of giants, the GPL allows you to use and
> modify code, and makes you grant the same right to the next person.  Open
> hardware such as EOMA68 should likewise grant the right of defining the
> device to the next owner.  Not that it need be permanently read-write, but
> that it must be available and suitably easy.

if a goal of the EOMA68 is to force open hardware, then i agree.

if that is not a goal, i would give the decision to the vendor. they are best 
positioned to know what will serve their audience best.

-- 
Aaron J. Seigo



More information about the arm-netbook mailing list