[Arm-netbook] Game Console OS

[Luke Kenneth Casson Leighton]

On Wed, Aug 13, 2014 at 1:28 PM, Richard Zink <zink at hexatux.org> wrote:
> On Wed, 13 Aug 2014 11:14:43 +0200
> Miguel Garcia <gacuest at gmail.com> wrote:
>> Seems a good idea. The problem is when you have many devices based on
>> EOMA-68 (such as routers, etc.). That's difficult with your idea. You
>> would need several OS at once.
>
> Why not just implement the system (OS side) a bit different:
>
> - Put the base OS on the microSD onboard the EOMA68 module
> - Put an additional storage (Flash/SD/eg.) onboard the carrier board (Laptop/Beamer/TV/Router/eg.)
>
> With this way it would be possible to have all specific drivers shipped with the CPU module
> and have the desired user space programs (GUI/Shell/needed programs) shipped with the
> carrier.
> So it would be easier to swap the CPU card (on which you could store your user settings).

 ok think it through.  remember that the guiding rule is, for the
end-user "it must just work" and that translates to (in the standard)
"there must be ZERO options" (as in, you are not permitted to choose
"i think i will implement only part of the standard", nor does the
standard itself say "you may implement only one of the 2 USBs, you
*MUST* have both, even if they are slower or faster").

 so, what in effect you are saying is that *ll* carrier boards *must* have:

 1) some additional storage.  that would need to become part of the
specification.  it would then be necessary to specify the minimum
requirements (size, transfer rate).  the type doesn't actually matter
because the EEPROM can specify where it is accessible from as a
DeviceTree overlay.

 2) userspace programs *per CPU*.  so, there must be MIPS versions of
the programs, ARM (32-bit) versions, ARM (32-bit) hard-float versions,
ARM (64-bit) versions... when they come out, x86 versions of the
programs (32-bit, 64-bit, 486 variants)....

 basically (1) is not hugely desirable but could be done but (2) would
be a complete nightmare of the first order.

there are two maybe 3 possible ways around it though:

2a) you ship interpreted applications *only*.  java, python, perl,
ruby, .NET and so on

2b) you actually ship the full source code and the CPU Card will have
a complete compiler

2c) you have a web site that allows OS applications to be downloaded,
stored on e.g. external media or whatever the end-user chooses.

i think, really, 2c is the most practical / realistic way.  allow
people to select and install complete OSes, provide a base mechanism
to do that.

which would be kinda cool.  "oh you plugged in to this type of base
unit, let me just offer you the opportunity to download a complete OS
you can use which is customised to fit it".

l.