2GB of RAM should be adequate to run the Debian OS, 3 Android VMs, web browser, LibreOffice, a movie and one incredibly resource intensive game all at once - but not much more than that. :lol:
For the eMMC - you guys are thinking about it backwards and valuing size over speed.
eMMC is capable of TWICE the data rate of microSD. However the fastest eMMC are MUCH more expensive per GB.
eMMC maxes out at 200MB/s (+/-)
microSD maxes out at 100MB/s (+/-)
If a 16GB 200MB/s eMMC costs the same as a 32GB 100MB/s eMMC, I'd rather have the 16GB eMMC installed.
Max out the speed on the internal eMMC. I can already buy microSD cards that max out the speed of the microSD port. That gives the end user a choice of sorts. Use the smaller, but super fast internal eMMC or drop in a slower but much larger microSD card.
Heck, if it makes the eMMC considerably faster, I'd be OK with the eMMC being only 8GB. User data can all go on the two SD cards anyway.
I'm not sure if raw transfer speed is really that important for the eMMC. It would have a bit of impact on the boot time, and the time needed for a suspend-to-disk, but other than that, I don't think it really makes a huge difference in practice between 100MB/s and 200MB/s. At least not for the loading times of most software.
For data transfers (e.g. if you put movie files or something on the eMMC) from the eMMC to something external over USB 3.0 or eSATA, it does make sense to have an eMMC that is as fast as possible.
The thing is: if the eMMC is small, you'll probably want to use it only for software, not for data, so the fast data transfers are not really very useful.
If the eMMC is big, you might want to use it for data, and then the data transfer speed matters more.
So I would say: try to find a good balance between speed, size and price.
Two use cases.
1. My vision above with smaller (16GB isn't all that small) but crazy fast eMMC is to use the eMMC much like it is on the Pandora. For OS, primary/system programs plus /swap and suspend-to-disk - combined all of that should fit in 8-12GB. By placing those on a VERY fast eMMC it would allow for the fastest possible boot/reboot/shutdown/suspend/restore cycles possible. All other data and programs would then live quite happily on the SD cards.
2. If a user would prefer the option of having a large or even huge (up to 200GB), somewhat slower microSD in place of the eMMC for software, data and all - that is still an OPTION. They would need to buy the microSD card, copy the OS over to it, install, etc.
The Pyra does not have to ship with a huge eMMC to allow both types of use cases (small&fast Vs large&slower). The Pyra can ship with the solution to 1 above, and option 2 can be filled by end users. If it doesn't ship with the solution to option 1, then option 1 is from then on NEVER an option.
That eMMC -can- be VERY fast storage, but can never be as large as a microSD.
The microSD can be VERY large storage, but can never be as fast as the eMMC.
Let each play to it's strengths - make the eMMC the FASTEST it can be, then of those fast options, make it the largest that will fit the budget for the component. But let's take advantage of the strength of that eMMC controller's speed capabilities for what gets soldered to the board.
How much energy does RAM memory need? I suspect it's not a huge amount compared to all the rest, but keep in mind that RAM is always powered, even in standby mode when the screen and the CPU are effectively consuming zero power, so perhaps the power consumption of the RAM does play a role in the battery life.
Well... Linux
does support memory hotplugging...
2GB of RAM should be adequate to run the Debian OS, 3 Android VMs, web browser, LibreOffice, a movie and one incredibly resource intensive game all at once - but not much more than that. :lol:
How will that work, if Android itself requires 3 GB of RAM? (will Android VMs be officially supported?)
Where on earth did you get the idea that an Android VM would need 3GB or RAM? The Samsung Galaxy S, a powerhouse flagship of it's time, had 512MB of RAM. Many Android phones were released with only 256MB or RAM.
I do not expect anything beyond the shipping Debian OS and it's components to be 'officially supported'. EVERYTHING beyond that is expected to be community driven/invented/maintained. Android VM capability would likely be a post-production community created product - if it happens at all. This is the same 'support' as the Pandora has with every emulator, program, etc... The community is nothing without the hardware to work on. The hardware doesn't do much without the community.
This is a totally different model from most consumer devices that you can buy in a store. In those cases the manufacturer wants to control the hardware and the software and anything either can do - to make sure that they can monetize all of your interactions with either.
