btw joseph, could you please use a mailer that doesn't place entire paragraphs onto a single line? the general rule for mailing lists is to have line-breaks approximately every 70 chars or so. usually this can be achieved by ensuring that you reply "plaintext" mode only, disabling "rich text" for replies.
On Fri, Sep 23, 2016 at 4:41 PM, Joseph Honold mozzwald@gmail.com wrote:
the fact that you now actually want to know means that it's time to actually thrash it out and document it properly.
Yes, this should be documented. More on this at the end.
ack.
to even consider doing anything else would *automatically* bring the standard into disrepute (even before it got off the ground).
Sure, it's probably not the best idea to use stickers. But I have a another idea. You continue to have the restrictive EOMA specification but create a separate permissive specification that utilizes the EOMA spec as a basis. Call it something significantly different and not likely to be confused, maybe PEMA (Permissive Embedded Modular Architecture). These two specs would be compatible on a hardware level (and retain the free/libre software requirement) with other certain restrictions removed (eg, the bootable housing restriction). I can sell my bootable housing as compatible with the PEMA spec.
unfortunately that doesn't work, because of the following scenario:
* someone buys an EOMA68 Housing * they also buy an EOMA68 Card * they are happy (because it "Just Works") * they then get sold something which is sold to them as an "Upgrade" EOMA68 Card * it fits into the slot. * but it doesn't work
after a LOT of trouble, and annoyance, and a very very public and embarrassing fight on a forum, where various "Consumer Watchdog Groups" get involved, which is then picked up by the BBC, *and* the Guardian newspaper, *and* TheRegister *and* slashdot (all of which generates MASSIVE confusion thus bringing EOMA68 into total disrepute as a "Just Plug It In, It Will Work" standard)...
... after all that, it turns out that it was some fuckwit china 3rd party clone who took a PEMA card and deliberately mis-sold it as EOMA68-compliant.
the answer's no. sorry.
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.
I still don't think the idea of *allowing* (not requiring) housings to be bootable is unworkable.
oh. allowing? of course not. that's perfectly reasonable. but remember: the EOMA68 standard is based exclusively around *mandatory* requirements. i've told the story several times now from my university professor's *two* separate experiences with standards that were lost golden opportunities, thanks to "optional-itis" - one of those was the X.25 standard.
The "lowest common denominator" here is the USB bus
ah! no it's not! there is no guarantee that Housings *require* USB peripherals at all. thus the idea must remain "allowed" rather than "mandatory as part of the spec"
and SD/MMC bus on the EOMA68 connector which *IS REQUIRED* as per the spec
yeeeees....
and *could* contain bootable media.
wark-wark. the keyword here is "could". it could also not have any connection at all, or it could be used for GPIO, or it could be used for connecting to SD/MMC-based WIFI..
you just don't know (because that's down to the Housing Implementers) and that's why booting from Housing-based media must remain "allowed" rather than "mandatory as part of the spec".
This means, if a housing chooses to implement the SD card, it *might* be bootable media.
yep. that's why booting from housing-based media has to be "allowed" (i.e. "not prohibited"), but not "mandatory". but (re-reading what you mention below), if it is added to the spec that it is optional to sell Cards which *always* look for external boot media on Housings and will *FAIL* if that media is not present, that is NOT okay.
so it has to be something that the end-user chooses for their own convenience, rather than being something that is RELIED on.
Let's switch to the Pocket QWERTY Computer as an example instead of router. The A20 cpu card ships with Parabola, a desktop/workstation style OS. I want my customers to have a good experience when they use my handheld housing. Using an OS tailored for desktop/workstation computing is *not* a good experience on a small screen (I've tried this with the Zipit and it "worked", but was not very productive). I can make this transition even *easier* for average consumer by supplying a SD card with Replicant or some other custom libre distribution designed for small screens.
or, you could supply multiple OS SD cards for them, and set up the NAND to look an OS on the A20's MicroSD Card slot.
yes, i'm keenly aware that the alteration of the OS to suit LCD size is a Big Deal. putting it another way: it's a PAIN IN THE ASS! :)
it's made even more complicated (for the A20) by the fact that the people who did the sunxi u-boot and mainline kernel didn't think about this in advance: they've specified that the LCD shall be set up by u-boot and u-boot alone, leaving absolutely no possibility for changing the LCD size without a total reboot! oops...
I could partition the SD card and put any number of distributions on there with a boot menu. This way, they do not need to fuss with installing an OS to the cpu card NAND that works *well* with the housing. When next years latest and greatest cpu card comes out, I can get a beta version of the cpu card, produce an OS that works with my handheld and publish it on my website for free download before the new cpu card ships to customers. I could sell SD cards for cost+shipping with pre-installed OS for the new cpu card if the customer doesn't want to bother making an SD card. Easy-peasy for average consumer. Files on the cpu card NAND can be accessed easily via mounting so you still have access to all your data.
yyep. all perfectly reasonable.... and nothing to do with the spec... but if the Card is incapable of booting *unless* that external media is present, that's unacceptable.
The A20 card has a micro sd slot. Is booting from this allowed in the spec?
anything at the other end of the card - user-facing - is permitted. there are absolutely no restrictions (other than anything protruding must not physically impinge on the ability to insert the card into Housings).
so of course it's permitted: it's part of the Card. it travels *with* the Card.
now, the key difference here between booting from Housing-based media and Card-based media is: the Card-based media (removable or not) stays *with* the Card. it thus *guarantees* that the Card will boot.
What if the next CPU card does not have an SD slot (it's not required by the spec)?
now you're into "cheap-ass" territory. people who pay cheap-ass money for cheap-ass goods can expect to "get what they pay for". given that we're talking saving $0.20 for a lack of a micro-sd card slot, you know we're talking *real* cheap-ass money-misers :)
no, if manufacturers are saving $0.20 you know that they're probably trying to produce something for the $12 to $15 retail market. all bets are off as to "features" at that point.
basically at this level of cheap-ass-ness as long as they're compliant with the "bare minimum" EOMA68 spec i'll tolerate it.
Now average consumer is forced to install a different OS to internal NAND if they want a *useful* device.
or, because it was so utterly cheap-ass they just buy another $12 to $15 Card with a handily pre-installed OS. so in these circumstances, end-users would, instead of buying a replacement MicroSD card, would just treat the ENTIRE CARD as being "A Computing Appliance".
buying one that has Android preinstalled ($12) and another with Games preinstalled ($12) - heck you could even have completely different Games Cards just like you had or have Cartridges (Nintendo, Gameboy) - is perfectly reasonable.
What happens if average consumer installs handheld OS to their A20 card NAND, plugs it into their laptop or desktop? Handheld OS for a workstation doesn't seem very *useful*.
i don't see why that has to be considered to be absolutely true. i hear people complaining "i'm using my phone but the screen's too small" - would it not be incredibly convenient to just temporarily pop out the Computer Card and pop it into a Housing with a larger screen, even for five minutes, just to view a document properly?
My suggestion here is to make a housing "just work" as the *housing* is intended. If my housing doesn't work as intended when the cpu card is plugged in, it puts my company *and* the standard into disrepute.
you can always sell multiple OS cards and have end-users swap them over. in a few years time i envisage that we will have other methods to deal with this, starting most likely with VMs / OSes that are selected at boot time (exactly as you describe), and moving to adaptation at the OS level later (including icon size, menus and so on).
certainly i know that KDE is capable of adapting applications dynamically, by way of simply specifying a different "spec" file. applications can therefore *dynamically* adapt to screen size or other features (such as touchscreen / mouse).
this *really* is still at the very early phases, but it really *has* been thought out. the last discussions on this "OS adaptation" were something like three years ago, though.
hmmm, good point. need to make sure that there's proper training for retailers and that they understand the consequences of misinforming their customers.
Here, you are defining "desktop OS computer card" which isn't defined anywhere in the spec. I see no claims in the spec that there is such a thing as a desktop computer card, router computer card, phone computer card, etc etc.
that's correct.
With your claim of “just plug it in: it will work”, the retailer would be justified selling a *ANY* cpu card and *ANY* housing together and expect it to work. Is it the right thing to do? No.
no. retailers can only be directly involved once the OSes have been adapted to cope with the variation. that might take a few years: i can live with that.
as long as it does not bring the standard into disrepute in the process, i *might* permit a *limited* retail sale of say products where the CPU Card is preinstalled in the Housing, or where the LCD size is sufficiently similar between two Housings so that the difference is effectively immaterial (say, a 1366x768 LCD screen size for a Laptop and a 1280x800 for a tablet - something like that).
remember, the primary purpose here is to ensure that the units on both sides don't end up in landfill. if that's likely to happen, i'd rather the units weren't sold AT ALL (until they and the OSes *are* ready).
this is the difference between this project and a standard commercial profit-maximising outfit. a standard profit-maximising commercial outfit would rush ahead and get things out the door as soon as they could.
If you sell me a cpu card and a housing with the claim that “just plug it in: it will work”, it should work as intended as a complete package. If I have an old cpu card collecting dust, I should be able to use it under the claim “just plug it in: it will work.”
within reason... and within the expected cost, yes. in the 2nd-hand market and "recycling / re-use" market, i expect there to at least be *one* technically-competent person who makes the necessary phase-change adjustments before selling/handing the item(s) over to the next non-technical end-users who will expect that claim to be true.
Allowing the housing manufacturer the *option* to boot from media can assist in fulfilling this claim.
*thinks*.... the moment i hear the word "option", that is an instant red flag. options are what destroy standards. i spent five years analysing a range of standards, and 25 years ago it was deeply impressed onto me through the example of X.25 quite how dangerous "options" are.
so, to reiterate above: if the Card will *not function* unless that external media expected to be on a Housing is discovered, that is completely unacceptable.
now, on the other hand, if there is at least some level of functionality (whether it be Lowest Common Denominator or something) then that *might* be tolerable. if there is a "Download A Full OS" button, that also might be tolerable.
it's complex, basically, and would need careful evaluation on a case-by-case basis.
Mr. Salesman can have a rack of SD cards to sell to average consumer and provide a free or paid service of installing the OS on the card for them. Or, average consumer can use my nifty cross platform free/libre SD Card Imaging program to download and install the correct OS for them. Easy-peasy, nowhere near impossible.
yes. these can go into the main MicroSD slot actually on the Card. bit of a pain that they have to be for a particular CPU, so it would probably make more sense (given the low cost of the Computer Cards themselves) to just sell the OS preinstalled (an Android EOMA68-A20, a ChromeOS EOMA6-A20, a GNU/Linux Distro EOMA68-A20 etc etc. blah blah) but there you go.
Again, my issue here is the misleading/lofty claim of “just plug it in: it will work.”
no, that's the *goal*. you've misunderstood. it's the *goal* that that claim be true. remember, we're still working this out! so, you're helping to refine what is and is not permitted.
but everything gets "judged", "does the claim still hold?" if the answer is "yes" then it's okay. if the answer is "no" then, clearly we either wait until more work (on OSes for example) has been done, or we just have to live with it.
The way I understand it after your explanations this phrase should be "just plug it in: it will work, but if you want it to be useful you'll need to install and configure software yourself" which is completely against the idea of the project.
if there's a techically-literate person in the loop / scenario, i find that to be perfectly acceptable.
The use of this phrase needs to be rethought and/or reworded. Since ethics is a hot topic on the mailing list these days :) ... it's unethical to claim “just plug it in: it will work” when the housing doesn't work as intended. Sure, it will boot and be some sort of Frankenstein device, but it's not a useful device.
Let's try a silly example. I sell you a Harley Davidson Motorcycle (without an engine installed) and I sell you a separate lawnmower engine that fits perfectly into in that motorcycle. I tell you "just plug it in and it works." You go home, plug in the engine, strap on your helmet, start your engine and ... you ride free on the open road at a whopping 1 mph. Sure, it works, but it's not a good experience. Obviously, this example isn't very good in relation to EOMA and software, but it makes the point of customer dissatisfaction when the claim is "just plug it in and it works".
well if you look more carefully you'll see that i actually qualified this a number of times over the years (bear in mind that you're new to the conversation so won't have seen this) with the (sotto voice) of the more honest salesman, "But You Get What You Pay For, Know What I Mean".
if people pay $12 for a Computer Card, they Get What They Pay For.
normally this was in the context of people paying for Cards with USB 1.1 interfaces instead of USB 2.0 interfaces, but the same rule applies: if you pay only $12 retail for a Computer Card where the processor is a single-core MIPS 1ghz (or less), you cannot expect it to perform miracles.
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.
Understood. And this leads me to the specification which, if documented properly, would reduce the likely hood of an incident.
actually, we've already had some 3rd party implementers fail to listen, implementing *hardware* that did not comply to the specification. they also tried to take control of the EOMA68 Standard by making public statements without consultation and without authorisation. i had to publicly reprimand them and make it absolutely clear - publicly - that they were acting in a completely unauthorised fashion and were not permitted to make further statements or claims.
so no: even from this one incident, we know *already* that people can and will fail to read the specification properly. a Compliance Test is therefore absolutely critical.
At a minimum, there needs to be some sort of *disclaimer* / *notation* / *message* at the top of the EOMA specification page that indicates it is a "work in progress" and possibly point to a section (at the bottom/separate page?) with all of the unwritten/unfinished requirements/proposals/ideas.
good idea. just have to find time to do that :)
I was under the impression that the standard was mostly complete
the hardware side is.... but it's a really complex project, and it's still at an early phase. this current phase is where, with the hardware in place, the software can begin to be created.
we had to *have* hardware in order for there to *be* the opportunity to get the software ready... so that's next.
and only after the fact, this information is coming to light (my fault for lack of due diligence in research and asking questions). I understand you've been working on this for a long time and *you* have this all worked out in your head, but I (and likely others) surely don't. If I had known how restrictive the specification is going to be, I would have thought much harder about using EOMA for a project/product. I obviously misunderstood how far along the project is. Perhaps the roadmap you mentioned previously would help.
apologies - i haven't had time to write one. this is one of the down-sides of there not being enough other people involved. expecting other people to be committed for five years without payment of any kind and without hope of financial renumeration for potenially several more is a bit too much... so all the people that *were* expecting to financially exploit this project (and jeapordise it in the process) have all left (some of them are still causing huge problems, but that's another story).
Based on the specification on the elinux.org wiki, I had plans/ideas which now need to be completely changed to support restrictions that are nowhere to be found (not easily anyway).
review what i said above about being able to boot from removable media actually on the Card itself: i think you'll find (after evaluating that) that the perceived restrictions are incorrect / unjustified / insert-suitable-word-here.
It's quite frustrating to hear "you can't do that" time and again. My impressions of the specification based on the information readily available are clearly incorrect. I see it more as a hardware spec with the additional requirement of free/libre software being provided/available. That's my interpretation and is obviously incorrect.
yes. this is a mass-volume standard that *happens* to have libre software as a preference (where closed / proprietary software is tolerated under certain strict circumstances).
I understand the basis for your restrictions against booting from a housing, it just doesn't seem like a good idea to me and isn't very free/libre, IMO.
anybody is perfectly at liberty to completely ignore the EOMA68 standard (from a software perspective) - in doing so they are NOT permitted to call it "EOMA68 compliant", that's all.
manuel's team (with the hand-held games console) will be choosing this route. they will simply be using the EOMA68-A20 as a "module".
if you recall, i brought this up on the OSHWA mailing list a month or so ago. there is a naive expectation that the Four Freedoms may be applied to create a Hardware Compliance Standard without further adaptation or taking into consideration the consequences:. that simply isn't true.
so we have the scenario where the OSHWA creators have failed to add a disclaimer or add any indications that someone who puts an OSHWA "sticker" on a product is not liable for any damages, and that the person doing so is simply blithely permitted to put that sticker on, regardless of the fitness for purpose *of* that hardware, thus bringing the *ENTIRE* OSHWA Certification process into disrepute and exposing its writers to massive liability!
they seem to have ignored my advice and warnings about this, but the fact that i have mentioned it discharges my obligation to them...
the fact is that we simply cannot just naively create hardware standards - even Open ones - and expect that the Four Freedoms will be sufficient or adequate safeguards all on their own.
If you make it easier for manufacturers to provide a good user experience, then the customer is happy and will use it longer.
deployment to retail *WILL* be delayed indefinitely until that statement becomes true.
Don't get me wrong, I still think the idea is good and has good intentions. I'm happy to support it. I'm just pointing out issues I see to hopefully make it better.
appreciated.
so. summary:
(1) use the A20's on-board SD card slot. you'll be able to do what you're expecting (deploy multiple OSes) (2) don't worry about cheap-ass Cards. people Get What They Pay For. (3) technical users are expected to be involved in transforming / repurposing 2nd-hand cards (4) "Just Plug It In, It Will Work" is qualified by sotto-voice "But You Get What You Pay For" (5) Hardware's ready so that software can be worked on (6) Four Freedoms cannot be deployed as-is to Hardware Standards. (7) Retail deployment is DEFERRED INDEFINITELY until such time as the expected outcome is true. NOT the other way round.
errr... i think that's it. let me know if (1) works for you. i think it should.
l.