... we're still alive!

[Faust]

I wonder, do some people forget that there is an internal microSD slot in the Pyra? In the past I have always used a single partition for both / and /home (and now use a swap file rather than a swap partition) as I do not like the idea of introducing inefficiency through such fragmentation, or limiting the size of apt-get install space deliberately; on a Pyra I would likely keep the eMMC, and the OS on it, intact as a backup and use a large microSD card for my normal OS and /home. I expect that the speed difference between eMMC and microSD would be unnoticeable.

For me, the main reason for a larger eMMC (32GiB or 64GiB) is for marketing: to not be seen as inferior by people comparing the specifications of the Pyra and the GPD WIN.

You right, I think I will do exactly the same thing, as I already have all sd and Usd card.

 

[thatgui]

Some things I would like to know:

• How much space will the basic OS need (rough figure)
• How much would the 32GB Module increase the final price > I am not into the argument "its already expensive, so who cares about 10 bucks more", especially from people that will buy the device anyway - people outside of this community or the project may think different, especially if it pushes the price over a "mental border" e.g.: 499€ (16GB) vs. 514€ (32GB)
• How much slower will the internal MicroSD slot will be ? If its not a lot slower, I think it should be definately 16GB, those who want more should buy a proper MicroSD Card

 

[slimeycat]

16Gigs is the way to go here.

SD cards are dirt cheap and soon we'll have 1TB SD cards!!!

I think you would want to keep the psychological border at 499Euro

 

[elvissteinjr]

I wonder, do some people forget that there is an internal microSD slot in the Pyra?

So we're actually supposed to not use the eMMC at all? I don't think that's what it is there for.

In my opinion there should be a sane default which leaves some room for installing things, without requiring symlinking or moving /home (with the main media being on SD still, ofc). 16 GB will probably suffice for that (I wouldn't be put off by 32 GB either, but that's not among his choices, so let's not go there).
I don't want a Pandora do-not-touch-the-nand situation again. If we're going to need to keep saying "use a microsd" so often, maybe the eMMC isn't quite big enough on average.

And no, you're free to use it as you like. For me it's just that the eMMCs purpose is not to be not used. If it's too small to be useful in many cases, maybe we should think about making it more useful.
MicroSD usage shouldn't be a requirement and the big SDs should stay removeable media.

 

[Klumpen]

For me, the main reason for a larger eMMC (32GiB or 64GiB) is for marketing: to not be seen as inferior by people comparing the specifications of the Pyra and the GPD WIN.

This should actually be considered. While you guys here are all tech savvy, new customers won't be and most likely just want to see higher specs for the sake of it.
I guess that the crowd that just wants everything to be cheap won't buy a Pyra anyway so maybe pushing the specs might actually raise interest of a certain audience, who knows?

For me personally price doesn't matter so much for such a product. It's a very special device and whether it's 500€ or 600€ would just increase the amount of time to gather the money (which is easier if one knows it a bit earlier) but wouldn't change anything when it comes to the actual decision of buying/pre-ordering as long as the increase of the price is justified by better hardware. I've got no idea how others see this though.
I'd probably not be able to fill even 8Gb, so speed is the important factor.

 

[Christoph.Krn]

Hm, when 90% storage are used up by os and app installs, you have only 10% storage left for your calculation. Well, of course the result would tell when those 10% are done, not the whole device.

Only If the flash was used rawly and unintelligently, but that would be dumb. In reality, wear-leveling systems are put in place to try to spread the wear across the flash no matter how it's used. A fuller device does tend to have negative effects on speed and durability, but that's because the fuller a device, the less free space can be available for the internal management to work with, and the higher the write amplification may go (as you know, affecting speed and durability). That's why SSDs may have a certain amount of hidden free space exclusively for management and not visible to the user.

I know that some wear-leveling systems are more elaborate and sophisticated than others and alledgedly will "intelligently" adapt to certain use-cases, but I don't really know specifics. Theoretically, it could be that 1-bit and other tiny changes are actually just noted down in a "free" area unless or until some specific conditions are met, though that's just speculation on my side. I have no idea to what extent such measures are actually taken, and by whom. So I intentionally used the very lowest number of erase cycles that I considered would likely still be plausible for the Pandora's NAND, to probably compensate for a write amplification factor of up to 10.

PS: "Schwuppdizität" wurde mal von der c't erfunden um SSD-Effekte lose unter einem Begriff zusammenfassen zu können. Eine SSD mit IOPS-Schluckauf und schwankenden Transferraten z.B. hätte weniger Schwuppdizität als eine bessere SSD, aber natürlich mehr Schwuppdizität als eine Festplatte. Nicht zu vergessen esoterische sowie sonstige exotische Auswirkungen...

 

[levi]

So we're actually supposed to not use the eMMC at all? I don't think that's what it is there for.

No but a sane configuration should fit on 8GB easily in my experience, so it's only people who want one or more insane virtualised OSes that might need to move to a micro SD card.

I forgot that in my sub-4GB x86 image I've also got libreoffice and shotwell installed, on top of the gimp, pidgin, claws-mail and firefox on XFCE. I forget how big my partitions were when I ran debian on this machine, but I know I had it on a 64GB SSD with my home directory which means it was sub 12GB, and that was just default debian+xfce+slightly more applications as I didn't know what I wanted back then.

Edit: Having a larger SSD and more free OS space might be worth the number of people who apparently want it, for purely commercial reasons.

 

[Jebe457]

You guys are being ridiculous. If you're quirky enough to want to run a massive OS image, you can mount a 128GB microSD card and bypass the eMMC, while still having 2 SD card slots. The design spec is meant to be used that way to accommodate those of you who want to run a massive OS image.

I would tend to argue for the 16GB eMMC as that should cover a solid OS image with room to spare giving good endurance. The idea is you use the SD cards for primary storage, and pedants can use a microSD card. Given the Pandora gets by with a 512MB ROM, what you can do with Knoppix on a DVD, and this is a Linux system I don't think 8GB would really bottleneck things and see the 16GB more as giving additional headroom at reasonable expense.

 

[rSl]

thanks for this great new update!

personally i plan to use the nand only as a emergency-os and use a large and fast micro-sd-card for main os and userspace.
then one of the regular sd-cards as user-storage and the other sd-card slot for backups and as a 'floppy disk drive' for local content exchange.
so i think 16gb nand would be verry ok for me, as i even want breathing room for wearlevelling on my 'spare os'.
but i think it's also verry important to keep the nand-size somwhow in sync with this upcoming gpd device to not scare new customers with 'too small nand' syndrome.
then again the 499 pricetag is important, argh decisions!
at least a verry good thing is that this nand is located at the cpu-pcb and can be switched out if one breaks it or is concerned with privacy issues after reformating and giving it into others hands.

btw. is dark red from the renders now the official colour? i really like it. still me wants a 'c64c light beige' one, pretty please.

 

[DerTrueForce]

I think that you should go for the 16GiB option. Debian needs around 8GiB for the default install (that said, I don't know how the default install will be customised/cut down), and I think it would be good to install some things (like LibreOffice or Firefox/Iceweasel) on internal storage anyway, so that you don't have to use an SD for that and risk crashing stuff. AFAIK, reading doesn't wear out SSDs. That's writing.
I get that the OMAP5 is the limiting factor on speed, but as long as it's decently fast, I don't see a problem.

 

[TrashyMG]

I think that you should go for the 16GiB option. Debian needs around 8GiB for the default install, and I think it would be good to install some things (like LibreOffice or Firefox/Iceweasel) on internal storage anyway, so that you don't have to use an SD for that and risk crashing stuff. AFAIK, reading doesn't wear out SSDs. That's writing.
I get that the OMAP5 is the limiting factor on speed, but as long as it's decently fast, I don't see a problem.

Well the current base install aTc has of PyraOS(debian jessie) is under 1GB last I recall... while my devboard is out of commision, I'm using his image on the Pandora, currently using ~2.5GB of a 16GB SD card and that is with some compiling utilities and other garbage on it.

 

[Eight Bit]

Oh, and btw Ed, I really like how the rounded keys look. Less cheap somehow...
Also the grain on the surface of the case make it look real good. A bit like pelican case quality. It looks more sturdy than the Pandora all together tbh... does it feel like a pelican case too?

 

[Wally]

16GB would be nice, somewhat fast and most people would be able to put some base apps / compiling tools and whatever on their MMC.. A massive change from the Pandora

 

[vcoleiro1]

ED, can you please post the costs for the 32GB and 64GB eMMCs (for orders of 1600 or more)

 

[comradekingu]

Only If the flash was used rawly and unintelligently, but that would be dumb. In reality, wear-leveling systems are put in place to try to spread the wear across the flash no matter how it's used. A fuller device does tend to have negative effects on speed and durability, but that's because the fuller a device, the less free space can be available for the internal management to work with, and the higher the write amplification may go (as you know, affecting speed and durability). That's why SSDs may have a certain amount of hidden free space exclusively for management and not visible to the user.

I think also trim suffers from overfilling the space.

I never trust any recovery media that can be rendered volatile and modified by the software on the main system. If I buy a laptop, the first thing I do is boot off a CD and image the disk, then wipe everything (recovering the space wasted by the recovery partition in the process) and reinstall fresh from a DVD burned from a hash-verified ISO.

Do you run qubes? You could encrypt the recovery-partition to prevent malicious tampering.
Just checksumming it gives reasonable security. And you could do that with a live image, but then most of the point is gone.

FWIW, I'd be happy with 4, and ecstatic with 8GB - on my x86 arch linux laptop with XFCE, firefox, claws-mail, pidgeon, gimp installed, my system partitions add up to 3.6GB. I won't be putting any user data on my non-replaceable eMMC (apart from maybe my ssh keys if it's set up like the Pandora). The only thing I really miss with SZ on my Pandora occasionally are the man pages.

Speed might be an issue, but I don't tend to reboot my handhelds very often, and that's the main thing where fast media helps IMO.

Edit: A recovery partition is a reaonable idea, but IMO that shouldn't take more than a couple of gigabytes. You don't want it fully featured, and you probably don't even want any networking running on it, unless you're able to update the libs with remote holes in it - but a recovery partition you reflash every time is liable to be corrupted at the same time as the main partition. On balance, I think a separate computer with updated libs is preferable to a recovery partition most of the time. If my arch laptop needs to have its partitions reformatted, I tend to boot off an external CD drive.

So it uses a couple of GB, at 16GB, that takes you down to 14GB. 14GB for a OS-install in 2016. And then what? Its no longer a novice or beginner device, because you have to dick around with SDs.

Its debian, it doesnt often fall victim to exploits. But if it does, you can rewrite. Not sure if you could use jigdo to only do the parts you need updated, but still every release of stable debian goes a long way. You arent wearing anything out. Having a corrupted main partition isnt the reason to reflash. A recovery partition is convenient. Either you have it, or you get a lot of returns and questions from people who otherwise would leave their device in a shelf, cost ED support time, or maybe throw it away.

Btw, look into using USB-boot or PXE, CDs and DVDs are cumbersome.

 

[ilo_pona]

The new keys look great!

I'd prefer 64GB or 32GB of flash. /var grows fast. 16GB would be disappointing unless it can be mounted at the same time as the internal microsd card.

 

[levi]

I had to boot of DVD twice - once to install the system in the first place, and once when my SSD controller broke, and I wanted to see what I'd lost and what I could still access. So far I've not needed to do it that often, so I've not looked into using USB sticks - in fact I used an old image I last used to set up an old desktop that only had USB1.1.

Debian's had plenty of remote holes in the last 12 months, although perhaps I am being overly pessimistic - provided you don't enable sshd, you don't have to worry about openssl holes and so on. When I recover my arch machine, I am using an image from 2013, which would have plenty of holes in it if I actually ran external services on it, but since I don't I'm not bothered.

Against the idea of a recovery partition, the thing I'm envisaging would just dump you at a terminal, so it wouldn't be that user friendly either. Perhaps it should also contain a simple shell script that would take an image off an SD card inserted, and use that to reflash the main partition. But is that actually any easier than downloading the image off the firmware website and unpacking it to and SD card - booting that will reflash the flash? Or are you envisaging a bootable partition that will just reflash everything with an old version of the OS and bootloader after checking that's what the user wants to do? That only really needs a select few services, and compressed rootfs and bootloader files, so shouldn't need all that much space. I could get behind that, if you're proposing to develop it.

 

[comradekingu]

"Not that much space" adds up if you don't have any to begin with. With 16GB it would have to be a netboot image. Which is where new and old users will fall victim to not being able to connect to their Wi-Fi because they cant remember their key.

 

[Young Ace]

I'd like to weigh in and say I would opt for the 16GB.

 

[Blue Shadow]

16GB would be disappointing unless it can be mounted at the same time as the internal microsd card.

From the wiki:

The microSDXC card and internal eMMC use the same interface to the SOC, but controlled by a software-managed switch, allowing both to be accessed near-simultaneously, albeit with a decrease in throughput.

So it seems you can indeed use both at the same time.