... we're still alive!


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.

I don't see the point in a recovery partition. My Pandora travels in a carry case with SD slots and a couple extra SD cards, one blank, one with android stuff, and one with SZ 1.71 on it. If my stuff gets jacked, just pop it in and reflash. I would bet most people have the same.
[doublepost=1459744310,1459744200][/doublepost]
"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.

Guess you missed notaz post. The image is about 1gb. You will have plenty of space. You still haven't said why your backup can't be on a microsd seems like that would work perfectly for you. I mean cmon we will have the potential to have 1.5TB worth of space (with all SD slots filled at 512GB),
but you can only have a backup on the emmc?

You are really stretching now. Can't remember your key? Walk over to the modem, reset it and use the default password.

Next up: "But swordfish, what if you are cooking with hot oil and can't walk over"
 
Last edited:
From the wiki:


So it seems you can indeed use both at the same time.
I am not sure whether taken this for granted is a good idea or not. Maybe I missed that, but has this been tested (either with the Pyra, or at least a similar setup) outside some synthetic tests ? If not, it may be a good idea to wait until that has been put to use in more "practical" situations.
 
16 GiB would be enough but 32 GiB would be preferable, given equal speed, power consumption and neglible increase in unit retail cost (up to maybe 20€). On my work computer arch linux I have 13 GiB /usr and 40 GiB /var (mostly cache), so I'm not confident 16 GiB would let me install stuff without worrying about running out of space. Anyway, it'd probably still be enough.
 
Edit: Keep it simple. Regular users dont use that much space, and are dependent on there being no hackery. If we look beyond ourselves, there are lots of different users who may want a pyra.
Blind users (keyboard and sound), photographers (dual fullsize SD), Big or difficult to drive headphones audio listeners (will pay anything), journalists (can edit and send in the field (the field is not a table you can sit down on with your laptop, nor is a phone a tool for the job)

Think about how many industry jobs virtualize some company image, or just want a thin-client.
Selling lots of pyras+spares all of a sudden makes 1000 units seem like a small number.

I used to work for Krones, suits would constantly ask about that little computer I brought with me everywhere. I guess that's why I wanted to see a Windows option for the Pyra. Its' time as a professional tool will come, eventually.
 
Not unless you want to run into tons of issues.
Linux recognizes the screen size as 720x1280, when you run the script and enable the SSD with rotation, it turns to 1280x720, however, the framebuffer doesn't really update (thus, our currently used fbturbo doesn't work).

Also, you won't be able to see ANYTHING until everything has been booted, like a bootmenu, etc.

The only proper way is putting this into the kernel, where all other drivers also reside.
Indeed.

There is already a sketch for the kernel module driver. So that nobody has to start from scratch. It compiles and loads but is still wrong in the internal logic for communicating in the proper sequence with the panel driver:

http://git.goldelico.com/?p=gta04-k...58.c;hb=refs/heads/work/hns/video/dss/ssd2858

So the key task to make it useable is to fix the interaction sequences with the panel driver and the dsi driver (who is initialized first with which parameters and where do they come from?).

PS: harddisks are restored, and almost all files have been rescued. So back to normal working mode.
 
  • Like
Reactions: rSl
Im Glad the burned Pyra was just a April Fool,
Good news indeed, expekt for your PC Crash..
Well, i think i would be fine whit the 8gb Solution, but i wouldnd mind to pay some € extra if you shose the 16gb..
I will mostly use the Pyra for Emulation and gaming, and i have a 128 gb Card allready running on my Pandora, whit my Roms on it, and there is plenty of space left on it...
 
[...] journalists (can edit and send in the field (the field is not a table you can sit down on with your laptop, nor is a phone a tool for the job)
Thanks for thinking of me. :)

What sells the pyra for me is the promise of being a handheld laptop.
Same here. I'd prefer at least 32 GB, and I would gladly pay for it.


P.S. Thanks for the PM as well.
 
Well, I have seen a linux distro with LXDE, Firefox, Office suite run from < 40MB ISO (www.slitaz.org).
But with Debian it will need a few GB just for some basic system.

My intuition tells me that with:
eMCC <= 8GB I'll use one SD card slot as unremovable storage
(eMCC == 16GB || eMCC == 32 GB) I'll have to use one SD card slot as expandable storage most off/all the time
eMCC >= 64GB - I won't have to use SD cards or use them only occasionally
 
I recently upgraded my debian jessie install (including various compilers and lots of large documentation packages, but mostly empty package cache) to testing with an 10G root partition. It was close, but it did work. Deleting the package cache brought it down to 6G again I'm confident that 8G would work totally fine for most users. And just like with RAM, there are certainly use cases that require larger memory, but very few are of the type '8G is too little while 32G is enough for all times'. If I can get 16G at the 500€ price point, I'll be a happy customer.
 
What do you think?

Good to see we're getting some answers to the questions in this thread, your responses are much appreciated.

From a personal perspective 16GB sounds too small for my anticipated usage of the Pyra. (I was hoping to eventually use at least 8GB for a dedicated Android installation & have plenty of room left for Linux + Swap File + Hibernation to Disk). Can you please let us know the costs for 32GB & 64GB eMMC sizes.

If USB3 performance on Pyra is more or less as good as eMMC performance then the need for a bigger eMMC stops being a deal breaker (for me) as you can buy a low profile 128GB USB3 flash drive for less than £30.

With that in mind it would be great to see some benchmarks and hear some 'general feelings regarding user experience' about using microSD, Full size SD, USB2 & USB3 as alternatives to eMMC. FWIW using a Chuwi Hi 10 windows tablet I've found that the difference in loading times when using a micro SD card or USB2 flash drive for installed programmes in stead of eMMC is highly noticeable (i.e. slower than eMMC) but when using a USB3 flash drive the difference is slightly noticeable (a tiny bit slower). I tried a variety of micro SD cards & Flash drives.

it's appreciated that funds are tight and that even adding €10 to manufacturing costs could be the 'straw that broke the camels back' however it's my understanding that using a 5Ghz wifi chip for an extra €10 is being considered. This shows that we still have some 'wriggle room' when it comes to prices. Why not do a poll asking people if they'd rather see the extra €10 spent on faster Wifi or a 32GB eMMC (in stead of 16GB). Personally speaking I'd much rather see a bigger eMMC.

From hearing the desires of people on the forums it seems very sensible to me to enquire as to whether people would be interested in a Premium Pyra with 4GB of Ram & 32GB emmC (if the base model was 2GB Ram & 16GB eMMC). My strong suspicion is that if the price difference was around €50 (based on approx €25 of additional manufacturing costs) then there would be plenty of takers. I fully accept that I've no real idea how difficult it would be to produce models with different RAM & eMMC sizes and my suggestions are based on it not being overly difficult, i.e. using identical Ram modules but more of them for 4GB and simply swapping the eMMC parts for different batches with no tweaks to drivers / other components / board layout required.

I've a very strong gut feeling that a lot of potential sales could be lost to people who would want more than 2GB Ram & 16GB eMMC, an official poll complete with costing information would hopefully give some indication if this were the case.
 
Last edited:
This is how I see it as someone who has been playing with debian testing and now jessie on ARM devices for the last couple years:
4GB: the OS can fit and run here, even could have some development libraries and compiling tools. Needs a bit of discipline, can fill it up quick by mistake. I have a few RPis running jessie with only 4GB without issues.
8GB: healthy amount for the OS, development tools and even some heavier applications.
16GB: What I typically run with on my boards, Still use additional storage for project work.
32GB: Could be less lazy about moving things from my download directory, could do most of my project work on this, if I wasn't concerned with NAND wear of course.

until the beginning of last year when I put together a new computer, my desktop Linux box only had a 30GB SSD to hold the OS.
 
Last edited:
What happens with any size within reason is your priorities change or oversight gets in the way of discipline.
So you learn not to be more disciplined (even though you get the ability), you learn to plan ahead. And avoid "saving yourself poor".

Last year wasn't when you bought that computer. And you didn't replace it with a new one that was exactly like it. The reason you bought a new one was even you, given abilities very few people have, found it too cumbersome or lackluster.

Can do something, to a level of cumbersomeness, and could be avoided, to a level of simplicity.

If its pennies to the pound, I go simplicity each time. Bragging rights on the internet are very similar to sympathy-stories.

I have been using debian on ARM since armv5 times.

Some things are fun for the challenge, but never when you want to get real work done.

The argument of "but you could get a *, root it, then install, then replace, dremel this, then this and that" gets old. Real honesty out of the box is why I love the pandora and pyra.

Give people what they want, as in what they actually use, do and wish for, and they will repay you gladly in time saved searching, waiting, or procrastinating.

I don't see the point in a recovery partition. My Pandora travels in a carry case with SD slots and a couple extra SD cards, one blank, one with android stuff, and one with SZ 1.71 on it. If my stuff gets jacked, just pop it in and reflash. I would bet most people have the same.
[doublepost=1459744310,1459744200][/doublepost]

Guess you missed notaz post. The image is about 1gb. You will have plenty of space. You still haven't said why your backup can't be on a microsd seems like that would work perfectly for you. I mean cmon we will have the potential to have 1.5TB worth of space (with all SD slots filled at 512GB),
but you can only have a backup on the emmc?

You are really stretching now. Can't remember your key? Walk over to the modem, reset it and use the default password.

Next up: "But swordfish, what if you are cooking with hot oil and can't walk over"

A loss of speed can not be recouped. The space i need isn't about to get smaller, it always gets bigger. And you sound like apple.

While i greatly support the idea of a full-flash recovery partition, it is a dual-edged sword if it means an already limited resource becomes even more of a drawback.

You have never worked in support. Murphy's law works in support.
People are very capable of 1. filling up inode-/space, because that can and does happen. 2. they are not good at getting over barriers, because that is a requirement.

People forget their Wi-Fi key, if they even have one. Telling them to reset their configuration, that was your day, now its theirs. Previously secure password now "works for me", other users angry.

Regular Linux|Gnu users have no problems filling up even 20GB, on / alone. They dont remove old kernels, they don't minimal-install, they don't uninstall programs they tried, or installed thinking they were something else. They will install every KDE-library there is to have some program.

If you don't give them the benefit of the doubt, that is now your problem.
First rule of support is to avoid problems leading to support. If you go one step down, you have normal users filling up their finite storage phones with photos. "I have this problem with my phone" If they even so much as see someone capable of functionally doing how it should be handled in the first place. Doesnt matter if you are at work or not, these people will find you.

Expecting 'most people' to be capable and willing to make a recovery SD-card, is wishful. Me is not the point here, and you arent listening to my needs anyhow. You cant just mentally leap something onto a microSD, because it would mean shipping a microSD. Otherwise it is in no way equivalent.
Just like space in general isn't the same as eMMC space. You could have a union filesystem, but it means SD-cards are no longer modular.

Locking down a choice of microSD card is good for getting a good one, but it means you have to pay extra for something a lot of people don't want. And if they do, in a different size. That is why i like modularity.

The reason I like bigger and better things, is that way you cover more people. Within reason, that benefits everyone.

You don't reduce support-time or help matters by making a support system that works only for experienced users. It hurts sales because the biggest demographic is withered away. Refunds or shelved units for no good reason isn't good.

You are projecting that last strawman argument.
 
Last edited:
Okay, 32GB are at 10 EUR, 64GB at 20EUR. So 32GB would make sense (6 EUR more than 8GB, 4 EUR more than 16GB)
32GB doesn't seem to break the bank IMO and it will alleviate some concerns with space.

EDIT: Well for potential buyers that don't quite grasp that there are more storage solutions on the Pyra than we can shake a stick at.
 
We have 2 SD card slots in the Pyra, why the hell everybody suddenly wants more internal Storage? Pandora was fine with ~512 MB NAND and I really hope the Pyra OS will not be a big, bloated OS but also a small, sleak OS like the one for the Pandora.
Pandora NAND was also slow imho, not sure about the Pyra internal Storage but as long as it is not much faster than the SD cards, I see no reason to not use good old SDs for everything beyond OS.
 
I am pleasantly surprised. Not only by avoiding the drawback, but also an additional +10€ for twice of the performant 32, with better sequential reads to boot, is a very good option to have.

Edit: More space doesn't mean you have to bloat. When discipline is no longer a requirement, you can still employ discipline to make sure the level of value is as high, and keep from bloating.

Like my posts sometimes.
 
Last edited:
Regular Linux|Gnu users have no problems filling up even 20GB, on / alone. They dont remove old kernels, they don't minimal-install, they don't uninstall programs they tried, or installed thinking they were something else. They will install every KDE-library there is to have some program.

But how is this ED's problem? This is pure user error. No mater how much you want to or try, you can't idiot proof things. that 32GB emmc could get filled up the same way.

Expecting 'most people' to be capable and willing to make a recovery SD-card, is wishful. Me is not the point here, and you arent listening to my needs anyhow. You cant just mentally leap something onto a microSD, because it would mean shipping a microSD. Otherwise it is in no way equivalent.

Why would it have to ship with a micro sd? The slot is available, leave it to the user to install one or not, but the port is there for use. The Pandora didn't ship with SD cards.

I also think you are over-emphasizing the "support" role. Most users (even the normal ones) will look on the boards. How much of an issue is support anyway? Has ED mentioned that Pandora support was more than expected? Without ED stating support was more of an issue than expected for the Pandora, this will be a non-issue that you are blowing out of proportion
 
Back
Top