[Arm-netbook] Future case idea: subnotebook/PDA with QWERTY keyboard

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Thu, Sep 22, 2016 at 6:33 AM, Joseph Honold <mozzwald at gmail.com> wrote:
> On 09/21/2016 10:46 PM, Luke Kenneth Casson Leighton wrote:
>>> I don't see how a housing that needs a particular libre bootloader, kernel or driver is non-compliant with the standard (as it is currently written). Perhaps there needs to be more clarification of the boot process and software requirements for compliance?
>>
>>  there is: mainly the burden is on the Cards (not the Housings), but
>> it is essential that the I2C EEPROM at address 0x51 contain the
>> required "identification" information... and that hasn't yet been
>> completely implemented yet.
>>
>>  so until that's work's been done, people implementing Housings need
>> to be keenly aware of that... if they would like to be able to claim
>> "compliance".
>
> ok, so it's not written in the spec yet.

 correct.  this is a massive project.  i've been the only one working
on it, so all previous discussions were "theoretical", therefore were
a bit nebulous, but they _did_ spur me to actually think about it (for
several years, over several years).

 the fact that you now actually want to know means that it's time to
actually thrash it out and document it properly.

>>  no :)  that would bring the standard into disrepute, by violating the
>> tagline "Just Plug It In: It Will Work".  now you have to replace that
>> with: "First You Must Check If The Hardware Is Compliant With The
>> Hardware Standard, Then You Must Check If The Software Is Compliant
>> With The Software Standard, Oh And If Both Those Things Are True Then
>> Yes You Can Plug It In and It Will Work.  Or, You Could Just Try
>> Plugging It In And Guessing".
>>
>> ... that's a clear violation of the basic underlying principle of the
>> EOMA68 standard's simplicity, isn't it?
>
> seems simple enough to me. two shiny stickers, one says EOMA68 HW Compliant, other says EOMA68 SW Compliant. If it's missing the SW, the manufacturer should supply you software :P

 the very fact that two separate and distinct stickers exist *is* in
and of *itself* a clear violation of the simplicity principle "Just
Plug It In, It Will Work".  the physical form-factor (the hardware
connector interoperability) *is* a "guarantee" that "If You Can
Actually Get It Into The Socket, Which Is A Simple Act Taking A Few
Seconds And Requiring No Technical Knowledge, It Will Work".

let's try an analogy.  let's take an SD/MMC Card.  if you have on the
outside of the SD/MMC Card "SD/MMC SW Compliant" and there were some
that didn't, and you couldn't even tell if some little fuck in a back
yard factory somewhere was REMOVING (or worse ADDING) stickers, how
long do you think it would be before other Memory Card Standards took
over in full force from SD/MMC?

no.  we simply cannot possibly expect people - force people - to read
stickers in order to make technical decisions.  you plug it in, it
works.  no thought required.

to even consider doing anything else would *automatically* bring the
standard into disrepute (even before it got off the ground).



>>> It just doesn't make sense (to me) to effectively lock someone to a particular bootloader/kernel that is potentially less capable by denying them compliance. As long as my housing works with free/libre software, what's the problem?
>>
>>  the EOMA68 standard is not merely about "working with free / libre
>> software".   it's about making **100 MILLION AND ABOVE PER YEAR**
>> free/libre Housings (and Cards) and ensuring that the returns rate is
>> well below 0.001% (0.001% of 100 million a year is a hundred THOUSAND
>> units a year, which is absolutely insanely large, and could well
>> represent the entire profit margin for that year.  mass-volume is
>> radically different).
>>
>>  you cannot possibly expect, with those kinds of numbers, that people
>> will be capable of compiling their own kernels etc. etc. or even that
>> they are capable of installing a new OS.  they want something that
>> "just works".  if it don't work, they'll return it (or discard it).
>
> I don't expect the average consumer to compile any software. If you allowed housings to be bootable, (via sd card for example), a manufacturer can supply a sd card with the device and provide their own update channel.

 as noted further down: this scenario was discussed a few years ago
and discarded as completely unworkable.  how would you:

 * ensure that a MIPS-based Card was capable of booting from media in
someone *else's* Housing
 * ensure that a RISCV-based Card or an FPGA Card was likewise capable
of booting from the same media
 * how can the Card Manufacturer even know that there's going to *be*
an SD Card slot?

these and many more scenarios make it flat-out impossible to make any
kinds of "Lowest Common Denominator" assessments.... or more to the
point: the "Lowest Common Denominator" is *literally* the "Empty Set".
i.e. there *are* no common boot methods from Housings.  period.




>>  anyone who is plugging in (for example) an EOMA68-A20 into a (for
>> example) router Housing is probably the kind of expert who knows what
>> they're doing.  if they're even *remotely* contemplating that kind of
>> re-purposing / mixing-and-matching (and are the first or one of the
>> first to consider doing it) i think it's safe to assume that they
>> would be capable of customising (or entirely replacing) the OS with
>> one that is more suited to the job of "being a router" as opposed to
>> "being a desktop OS".
>
> If an average consumer buys a housing that claims it is a router and plugs in their old A20 cpu card (that contains a pre-installed desktop style OS) the hardware may be configured correctly per the dtb, but they surely won't be happy when they find out they need to setup a firewall, dhcp server, etc, etc, and much much more.

 the fact that they took a CPU Card with a *desktop* OS is the clue
here.  if they did that, they should expect to have "a set of desktop
functions".  i did answer this above.   they have two choices:

 (a) go get a router OS for that CPU Card (this is not unreasonable
under the circumstances)
 (b) go install the software required (this is not unreasonable under
the circumstances)


>The definition of "plug it in and it works" here is sketchy at best.

yes.  accepted.   i answered (and you didn't acknowledge) that i would
consider it reasonable that someone who mixes and matches in this way
would likely be a "re-purposing" individual, sufficiently technically
aware to fall into either category (a) or category (b).

 if they do *not* consider it "reasonable" then i would say... mmm....
tough.  we can't do everything.


> IMO, "works" means, works as a router like the housing packaging said it would, and I expect most consumers would think the same. Now, average consumer tosses cpu card and housing in the trash and never buys EOMA again because it didn't *just work*.

 if they did that, it's their choice.  we can't stop everybody from
being irresponsible: we can't stop everybody from making decisions
without first getting on the internet and checking "why doesn't this
work, does anyone have any advice".

 however in these circumstances, these are "not normal".  someone buys
a desktop OS and a desktop Housing, they're Certified by the retailer
to work.  if they then buy a 3rd party Router Housing and try plugging
it in, guess what?  they're outside of mainstream aren't they?  i
would expect such people not to be complete idiots.  they
experimented.  i would expect them to be capable of being curious
about the results.  or, to just put the CPU Card back into the Desktop
Housing.

 now, if they bought both devices *second hand*, i would *also* expect
such people to have done a little bit of research in advance, and to
have some common sense.

 therefore, the actual number of people who are complete idiots,
throwing away perfectly good hardware with very little actual thought
and analysis, i would actually expect to be qute small.

 however if there was a fuckwit *RETAILER* who sold a router housing
and a desktop OS computer card and told the customer "yeah yeah it'll
work fine", NOW i have a problem with that, and i will be going after
the seller aggressively because then the RETAILER is genuinely
bringing EOMA68 into disrepute.  actually, the seller (being a total
idiot) would have to accept the items back under warranty (due to the
seller's own ignorance).

hmmm, good point.  need to make sure that there's proper training for
retailers and that they understand the consequences of misinforming
their customers.



> Consumers should expect some kind of setup for any new hardware, especially a networking appliance, but asking them to install and properly configure a router OS is preposterous.

 if the products were mis-sold... YES.

 if the products were bought 2nd-hand... NO

 if the products were bought from different 3rd parties... NO.  you
don't go complaining to Microsoft if the HP printer doesn't work, do
you?



> If you allow a provision for housings to boot, the router housing manufacturer can provide a suitable OS (eg openwrt) and average consumer can be happy.

 no, it can't.  that forces the OS to be pre-compiled for a totally
unidentified CPU.  how can you KNOW what CPUs will be placed into
EOMA68 Card form-factor in the future?  how can you pre-compile
openwrt for a processor that hasn't even been invented yet?

 it's simply impossible.


>>> Can you just require all source code and shipped binaries be available before compliance is approved?
>>
>>  in light of the above, the question may need to be reworded /
>> rethought.  just as the Bill of Ethics points out: entropy will
>> require to be continuously overcome in order to achieve [continuous]
>> compliance.  it's not a one-off "fire-and-forget" process.
>>
>
> Here's a totally different question instead :) Let's say someone makes a non-compliant housing and wants to market it to tech minded folk who can handle installing their own bootloader/kernel. Will it be legal to market it as non-compliant and use the EOMA name?

 NO.  i cannot take the risk that someone gets killed or badly injured
due to an electrical fire caused by non-compliance.  if during an
investigation where someone is killed, i would end up being accused
(and quite probably convicted) of manslaughter.

 the answer is therefore an unequivocable and non-negotiable NO.

 that said: the use of the word "legal" is misleading.  you should be
using the word "permitted".

 now, given that you now know this (and see below as well), if you
were to blatantly *ignore* what i said (which is "NO") and went ahead
anyway, *then* it would most definitely NOT be legal, and you would be
liable for prosecution (both civil and criminal).


>"This housing accepts EOMA cpu cards but is non-compliant with the official specifications" or some such warning?

NO.  the risk is too great that without a proper test in a safe
environment that the 3rd party Housing would not cause irreversible
damage to people's Cards.  even just doing the testing could result in
a short-circuit and cause a fire (due to a design fault in the
Housing).

this isn't "just software", and it's not a "desktop PC" or a
hermetically-sealed unit.

some of these housings will take 20 watts or contain Lithium
Batteries.  20 watts is more than enough to cause an electrical fire,
and a Lithium Battery if overheated or otherwise mistreated could
explode.

 even if it was pure software, certain types of budget smartphones are
actually incredibly dangerous.  one such phone is a low-cost HTC WINCE
phone from about 10 years ago.  during the reverse-engineering we
discovered that the GSM Radio Power Level was software-programmed from
shared memory between the DSP and the WINCE OS. bear in mind that
WINCE has absolutely *no* memory protection (no virtual memory
whatsoever), it was literally possible for any application to set the
GSM Radio Power Level to sufficiently dangerously high levels that it
could cause the (very small) phone to overheat.

 whilst this example is extremely rare (and very stupid of HTC to have
done such cost-cutting exercises) it illustrates that messing about
with hardware is nothing like as straightforward as our Desktop PCs
and Laptops would have us believe.  people who work on CoreBoot (and
other direct-to-the-hardware style programming) will be able to tell
you any number of stories where they've damaged or blown up hardware
by programming it incorrectly at such a low level.

 we need to recognise that and, accordingly, act RESPONSIBLY.

l.