The Pyra is crying!

[WizardStan]

The eMMC is on the CPU board while the cell module is on the base board: by distinguishing cell vs no-cell and big eMMC vs small eMMC there's actually 4 possible versions. It's one thing to say "this one board, populate the part or don't" but it might be another to have to do it on a second board.

 

[pablocrossa]

The eMMC is on the CPU board while the cell module is on the base board: by distinguishing cell vs no-cell and big eMMC vs small eMMC there's actually 4 possible versions. It's one thing to say "this one board, populate the part or don't" but it might be another to have to do it on a second board.

Plus the fact that it isn't a simple binary "populate or not", it's a "populate this part or that one", plus all the different stock needed... Seems like a bit ambitious for a project this size, resources are probably better spent elsewhere (note that I am no expert and know in no way about resources for the Pyra or how to manufacture a device).

 

[Wrath Of Khan]

And I would suggest to make two models of the Pyra, a cheap base model and a more expensive premium model. Features of the base model:- 4GB (or maybe 8GB) fast eMMC, enough to install a decent base OS (after all that's still much larger than the Pandora NAND), but not much spare room- no 3/4G- wifi with 2.4GHz only- cheaper than the premium model (e.g. 450 EUR) Features of the premium model:- 16GB (or maybe 32GB or even 64GB) fastest-possible eMMC- 3/4G module- wifi with 2.4GHz and 5GHz channels- all other tech specs identical to the base model- 250 EUR more expensive than the base model (e.g. 700 EUR) This is just a completely made-up proposal, and just my personal opinion.I would personally want to get the premium model, but I think it's good to have a more affordable option that still has all the essential features, in particular for people who intend to still use a phone or tablet as primary internet device. Or if you're mostly interested in retro-gaming/emulation, then there's no need for lots of internal storage and fancy internet options.

+1Would make sense to get a wider audience that may be scared by the high price of the Pyra. And since the Pyra is compared modular, it should not be that much of an issue to start with two different priced versions. I would buy the "basic" version by the way.

I just wonder if maybe the market is too small for two models of the Pyra. It also still depends on the final price of the current model proposed by evil dragon.If it happened, two models, I'd be in for the premium model.

ED already confirmed that he want to offer 2 versions of the Pyra, one with 3G/4G and one without.

Yes I know of the optional 3g/4g module. But anything more than that and ed might have a hard time selling two vastly different models.

 

[thatgui]

And I would suggest to make two models of the Pyra, a cheap base model and a more expensive premium model.


Features of the base model:


- 4GB (or maybe 8GB) fast eMMC, enough to install a decent base OS (after all that's still much larger than the Pandora NAND), but not much sp... 


Features of the premium model:


- 16GB (or maybe 32GB or even 64GB) fastest-possible eMMC


...

This would mean that ED would have another variable to take into account when calculating the price > the more complicated the differences between products get, the more complicated it is to make a guess how many items of the individual products will be sold.

Grench is on the right track, its all about finding the sweet spot. Could be eight, but I am leaning towards 16 too: I going into my seventh year as a linux noob now, establishing 12 GB as root patition size to be sufficient, this includes a lot of dev tools(+libraries and sources), webserver, sql database server, and the "standard-set"(libreoffice, gimp and alike). With an additional four, most use cases should be covered.

 

[_wb_]

The eMMC is on the CPU board while the cell module is on the base board: by distinguishing cell vs no-cell and big eMMC vs small eMMC there's actually 4 possible versions. It's one thing to say "this one board, populate the part or don't" but it might be another to have to do it on a second board.

I thought the CPU board only had the SoC and RAM, not the eMMC? I could be wrong though.

 

[matzesu]

Well, this shure make sense, as whit diverent CPU Boards you need diverent Linux Versions, so you have to put they on the CPU Board because elswere the Pyra wouldnd work after you change to a diverent one..


Wonder how the Batteriecontakts work then and where they are locatet: the CPU Board, if i remember correctly sticks between the USB Ports and the SDXC Slots so are also the Batteriecontakts and the Sim Slot on the CPU Board??

 

[Neelix]

The eMMC is on the CPU board while the cell module is on the base board: by distinguishing cell vs no-cell and big eMMC vs small eMMC there's actually 4 possible versions. It's one thing to say "this one board, populate the part or don't" but it might be another to have to do it on a second board.

I thought the CPU board only had the SoC and RAM, not the eMMC? I could be wrong though.

To quote ED:

As mentioned, we're planning to put the CPU together with the memory and storage on a pluggable daughterboard. This saves money in production (since the mainboard will be two-layer and only the small CPU board needs to be more complex), and it adds the possibility to upgrade the Pyra in the future with whatever SoC / memory / storage will become available in the future.

The emphasis is mine.    At that point at least the plan was to put the eMMC storage on the CPU board,  and I don't recall seeing any evidence since then to contradict that.

-Neelix

 

[_wb_]

The eMMC is on the CPU board while the cell module is on the base board: by distinguishing cell vs no-cell and big eMMC vs small eMMC there's actually 4 possible versions. It's one thing to say "this one board, populate the part or don't" but it might be another to have to do it on a second board.

I thought the CPU board only had the SoC and RAM, not the eMMC? I could be wrong though.

To quote ED:

As mentioned, we're planning to put the CPU together with the memory and storage on a pluggable daughterboard. This saves money in production (since the mainboard will be two-layer and only the small CPU board needs to be more complex), and it adds the possibility to upgrade the Pyra in the future with whatever SoC / memory / storage will become available in the future.

The emphasis is mine.    At that point at least the plan was to put the eMMC storage on the CPU board,  and I don't recall seeing any evidence since then to contradict that.

-Neelix

Oh, I see. Well in that case perhaps a one-size-fits-all eMMC is needed, and then I would argue to prioritize random access read speed, reliability (in terms of wear / bit rot) and size, in that order.

 

[levi]

Grench is on the right track, its all about finding the sweet spot. Could be eight, but I am leaning towards 16 too: I going into my seventh year as a linux noob now, establishing 12 GB as root patition size to be sufficient, this includes a lot of dev tools(+libraries and sources), webserver, sql database server, and the "standard-set"(libreoffice, gimp and alike). With an additional four, most use cases should be covered.

My current system, built using Arch and XFCE has a 60MB /usr partition (which I'll admit, is a little tight), 30MB for /boot, 5GB for /var (of which, only 1.3GB is currently used) and 4GB for root (in case I forgot anything; seeing as it currently holds only 25MB of data, I guess not).

I don't have apache installed, or a database engine, but I'm not sure I would on a Pyra either.  So my current estimate is for a system like this you could run it comfortably in 2.5GB of contiguous space.  I guess Debian is a little more heavyweight than Arch though, so maybe I could justify 4GB.

FWIW, about 70% of my install currently is old package files, for the current packages and the previous set in case I need to roll back anything.  I suppose I don't need those permanently mounted, and could shrink my install down to about half a gigabyte if I moved that on to removable storage.

 

[Xcl4m4t10n]

Is Pyra still crying? .

 

[TrashyMG]

Is Pyra still crying? .

Most likely, like ED said in another post, new solder masks to fix the issue will take time to manufacture.

 

[Grench]

Is Pyra still crying? .

Most likely, like ED said in another post, new solder masks to fix the issue will take time to manufacture.

Old one could be signed by the whole team, framed and sold at auction to support the project.  Better than recycling.  Re-purpose and monetize the garbage.

 

[sepulep]

Oh, I see. Well in that case perhaps a one-size-fits-all eMMC is needed, and then I would argue to prioritize random access read speed, reliability (in terms of wear / bit rot) and size, in that order.

I think these may actually correlate with each other...i.e. bigger chips will be faster (at least that is the case for SSDs) and be long term more reliable (more room for wear levelling)

 

[Kev2442]

I'd go for the premium version no matter the cost. Does anyone want a kidney by the way ?

I'm a Linux noob, so...

Can you copy over settings and installed software from a distro to another ?

For example, imagine an hypothetical CPU upgrade. The eMMC is different, hence the Debian installation. Can I simply copy over my everythings over to the new Linux ?

 

[TrashyMG]

I'd go for the premium version no matter the cost. Does anyone want a kidney by the way ?

I'm a Linux noob, so...

Can you copy over settings and installed software from a distro to another ?

For example, imagine an hypothetical CPU upgrade. The eMMC is different, hence the Debian installation. Can I simply copy over my everythings over to the new Linux ?

Settings, sure those most likely won't change much... However installed software depends if we stick to the same architecture. If we make a move to an x86 processor, the current programs compiled for the current processor will be binary incompatible and not run. With that said, most software is opensource so it's not hard to just install the x86 version of the programs...


I also don't expect any CPU upgrades for a few years down the road, And it may not necessarily be an x86 processor. 

 

[CFWhitman]

I'd go for the premium version no matter the cost. Does anyone want a kidney by the way ?

I'm a Linux noob, so...

Can you copy over settings and installed software from a distro to another ?

For example, imagine an hypothetical CPU upgrade. The eMMC is different, hence the Debian installation. Can I simply copy over my everythings over to the new Linux ?

Well, besides the theoretically possible switch of architectures that TrashyMG mentioned (and he is correct about the implications), it depends on how the software is packaged/installed. PND packages like we use on the Pandora would transfer fine. Packages that you installed from apt-get would end up on the eMMC, and so would have to be re-installed.

Incidentally, it's also possible that a newer generation ARM chip could create issues, but they would most likely be confined to system files and not likely to affect things like games. Of course, programs compiled for the new architecture generation would most likely make more efficient use of it.

 

[Wally]

Well, besides the theoretically possible switch of architectures that TrashyMG mentioned (and he is correct about the implications), it depends on how the software is packaged/installed. PND packages like we use on the Pandora would transfer fine. Packages that you installed from apt-get would end up on the eMMC, and so would have to be re-installed.

Incidentally, it's also possible that a newer generation ARM chip could create issues, but they would most likely be confined to system files and not likely to affect things like games. Of course, programs compiled for the new architecture generation would most likely make more efficient use of it.

PNDs will NOT transfer fine as they're soft float instead of hard float and are stuck with libraries that were built in from years ago. There's also the fact that the PND system isn't going to be implemented into the PyraOS because of all this.

DBP is now the new standard and it's based on Open Desktop which is already built for purpose.

 

[slaeshjag]

It is possible to have a softfloat installation side-by-side just like you can have i386 libraries installed on an amd64 system. Problematic libraries include the OpenGL|ES drivers, although lunixbochs may have at least a partial solution for that. Assuming the OpenGL|ES drivers will work at all on the pyra's default distro.

 

[elw3]

Its not a question of hard and softfloat. 

There is simply no point to make this, all the "easy" pnds can be just recreated as pyra package while the optimized pandora special stuff simply wont run anyway as you can not emulate what is needed. 

 

[bzar]

Elw3: Want the non-paying job?