What software/emulators are in development for the Pyra?

[thatgui]

To have a dbp of it on SDCard instead of taking space on the internal space.

Even if ED decides that a smaller size (<8GB) for the internal memory module is enough, why give up the comfort of having an supported package from the official debian repo? No offense in hdonks direction (I was very thankful for his work), but as it occured to me it was quite a hassle for him to be somewhat up to date (and getting the whole thing to work, in the first place).
I can see the need for having software as dpbs where alterations for the special environment, the Pyra offers, are sensible. But otherwise its just a waste of resources (imho).

ontopic:
I personally hope for running games created with "Game Maker Studio" (just for AM2R), while there is no ARM port available I am crossing my fingers for getting it to work via exagear

 

[Bosbeetle]

We need a pyra version of pandora panic

 

[_jr_]

For packages you use every day, spending the space on internal memory is probably justified. But if you just want to be prepared for a special occasion, having a dbp on SD card is a good idea. For a lot of larger packages (e.g. Libreoffice, TeX, development tools) it makes sense to have the choice, because every user will have different needs. Having some form of dbp autobuild from upstream would be nice (and IIRC has already been talked about) not only for security critical packages like browsers.

 

[canseco]

Debian repo for stable libs and programs (updated with bug fixes or security updates, whatever you want to call it) and dbp for versions from git/svn, etc, seems good to me.

Very similar to Arch based distros,

 

[Askarus]

Please, please, please make it so we can run it (or have it fly out) from a menu rather than plastered to the bloody taskbar.

Every time I reflash my Pandora I have to spend bloody ages working through the configuration options to turn that fucking thing off (because you can't just delete it like most of the other icons, oh hell no, that would be too easy!), and then I have to reboot to get rid of it. Every. Damned. Time. It's not as if there's that much room on the Pandora's task bar to start with, but no, we have to have that bloody icon permanently attached. Who the hell decided it was a good idea to install it by default?

So please, make it less intrusive.

Edit: Looks like you're hoping to make a suite of preferences editors and have them open from the menu. Good man.

D.

As Pyra will get the latest XFCE or any other DE there's no need any more for the config button.
A simple launcher with multiple options will do fine. It won't give you status information but can do everything else the Pandora config button can.
The big benefit would be everyone can edit it easily and remove it with just 2 klicks.
I would have loved that solution on Pandora but there's a bug with the XFCE launcher.

Here's a suggestion: Why not make a second tak bar, move everything you want from the default one to the new one and delete the default one with the config button. Or will it always be created during startup?

 

[slaeshjag]

It's a tray applet. Iirc, I added a mechanism to block startup years ago, can't remember how though. You could also just remove the autostart .desktop used by DEs to start it.

EDIT: Easier way: menu -> settings -> desktop -> session and startup [click]
application autostart -> uncheck pandora-configtray

 

[rygD]

@thatgui @_jr_ if you need more space to install stuff from the Debian repo you can boot from the microSD (or full size). Kinda funny that there is plenty more storage for the optimized software than the general stuff.

 

[ZXDunny]

It's a tray applet. Iirc, I added a mechanism to block startup years ago, can't remember how though. You could also just remove the autostart .desktop used by DEs to start it.

EDIT: Easier way: menu -> settings -> desktop -> session and startup [click]
application autostart -> uncheck pandora-configtray

Yep, that's what I have to do - every time I reflash my Pandora when the auto-updater goes wrong. Fortunately there's unlikely to be any more updates, but even so - if I have to reinstall the OS, there it will be sitting on an already cramped taskbar.

 

[Grench]

Crazy idea... if the eMMC and the uSD are both going to be accessible in the main session and you're only going to keep your local mirror of the repository for 'just in case', why not put the 'maybe use' data on a uSD and still boot off of the eMMC? You can mount the repository from the uSD at will. Install might be 50% or so slower due to the contention, but 50% of the 50% of the 90MB/s rated speed of many uSD cards now is still 20+MB/s which is faster than the SD cards were on the Pandora. For an occasional access like that, it should be fine.

 

[_jr_]

Crazy idea... if the eMMC and the uSD are both going to be accessible in the main session and you're only going to keep your local mirror of the repository for 'just in case', why not put the 'maybe use' data on a uSD and still boot off of the eMMC? You can mount the repository from the uSD at will. Install might be 50% or so slower due to the contention, but 50% of the 50% of the 90MB/s rated speed of many uSD cards now is still 20+MB/s which is faster than the SD cards were on the Pandora. For an occasional access like that, it should be fine.

I may have misunderstood your idea but that
sounds more complicated to me than having the stuff I need every day on the fastest available storage device while keeping the emergency stuff on the largest available storage device, but still ready to use.

 

[Grench]

I may have misunderstood your idea but that
sounds more complicated to me than having the stuff I need every day on the fastest available storage device while keeping the emergency stuff on the largest available storage device, but still ready to use.

I have a 200GB uSD card waiting to go into the internal uSD slot. How big does the "emergency stuff" storage have to be?

Installing from uSD to the eMMC would be the 'slowest' on board option, but should still go ~20MB/s or so.

Love that active switching so both are available.

It is a great reason why the eMMC does not need to be high capacity. Speed on that eMMC is more important than space.

 

[thatgui]

For packages you use every day, spending the space on internal memory is probably justified. But if you just want to be prepared for a special occasion, having a dbp on SD card is a good idea. For a lot of larger packages (e.g. Libreoffice, TeX, development tools) it makes sense to have the choice, because every user will have different needs. Having some form of dbp autobuild from upstream would be nice (and IIRC has already been talked about) not only for security critical packages like browsers.

Still don't see the need for going through the extra hassle of providing somewhat up to date dpbs when downloading the deb from the repoistory and putting in on the SD-Card "just in case" should be sufficient. But maybe I am not getting the whole idea: How likely is it, that such an "autobuild" functionality will be working with only minor "hiccups" and how do you see that implemented (locally on a Pyra, or should there be a dedicated server/machine providing such a service) ?

 

[_jr_]

The dbp obviously will only exist if someone spends the time to do it (with or without an autobuild framework). My point was more like: if such a dbp exists it is better to have it than keeping the apt packages lying around somewhere. But that is probably the whole misunderstanding. I agree that having the (e.g. libreoffice) packages is a valid workaround in the case there is no libreoffice dbp. But I think we can also agree that installing/deinstalling libreoffice on demand to eMMC isn't a particularly convenient workaround.

 

[TrashyMG]

@_jr_

Cloudef invented PUR that could handle PND building recipes and stored them online for others to use. It wasn't widely used, but it wasn't really advertised much either.. To me it seems like a good method for developers to create one click PND generation. I've been meaning to move my PNDs over to it at some point. I'm just horrible at managing my hobbies. Slashjag has made DBP building a ton easier to manage then generating a PND, implementing PUR to handle DBP building or something similar would be kind of nice too.

 

[bzar]

@_jr_

Cloudef invented PUR that could handle PND building recipes and stored them online for others to use. It wasn't widely used, but it wasn't really advertised much either.. To me it seems like a good method for developers to create one click PND generation. I've been meaning to move my PNDs over to it at some point. I'm just horrible at managing my hobbies. Slashjag has made DBP building a ton easier to manage then generating a PND, implementing PUR to handle DBP building or something similar would be kind of nice too.

I've been building PNDManager PNDs using Cloudef's makepnd (the tool to convert a recipe to a PND) since quite some time ago. Combined with Urjaman's dchrt build environment it's the best PND developer experience around