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.