--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Thu, Sep 22, 2016 at 6:33 AM, Joseph Honold mozzwald@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.