A possible PND-system replacement


Oh excellent, thanks @slaeshjag it's a Debian Wheezy VM. @TrashyMG only the libgtk-3-dev, I'll try another version as well, if not then I'll comment them out. re: A15 not sure anything will be suitable really this is an vexpress-a9 machine, just haven't figured out the kernel recompile for vexpress-a15 yet (likely not for a while either).
 
I haven't built on wheezy in a long time.

I'm currently targetting Jessie, and probably switching to Stretch whenever I upgrade my computers to it.
 
slaeshjag said:
I haven't built on wheezy in a long time.

I'm currently targetting Jessie, and probably switching to Stretch whenever I upgrade my computers to it.
Click to expand...
Well I can tell you it does work in stretch, I moved to aTc's Stretch install a month ago.
 
I got bit further on by commenting out only to throw another load of syntax errors, so probably Wheezy is a dead end for any pyra related fun. Nevermind, back to researching a15 VM's, thanks.
 
Maybe this have been talked about, but in case of a CPU upgrade to ARM64, is the dpb system ready for that ?
 
Well, at the core of it all it really needs is a label to identify its intended architecture, and then the pnd runner can do a context switch to 32-bit mode to run it (assuming we're running a 64-bit OS) if it's not a 64-bit ARM package, or maybe lanuch QEMU on it if it's a completely foreign architecture. All that's really needed right now it the tag to identify its ABI, and it sounds like it's already got that and more, so that's good then.
 
Well it would be sleashjag, The code is a bit old, but I haven't had too much issues with it... I'm also using the factory installed Linux kernel and know there are some AUFS dependencies that would likely break if not using the specially compiled kernel aTc puts out.
 
Yup. And I found out that AUFS isn't included in the Linux kernel.
This is annoying.
 
Linux-SWAT said:
Does it looks like functional enough to replace AUFS ?
Click to expand...
Well AUFS can be enabled in the kernel easy enough aTc has experience with doing so.

This looks promising, but I know AUFS was used over other things was it could handle spanning different filesystems better than most... but not that familiar with this.
 
Magic Sam said:
Hello all,

I just stumbled upon this:

github.com

GitHub - mhx/dwarfs: A fast high compression read-only file system for Linux, Windows and macOS

A fast high compression read-only file system for Linux, Windows and macOS - mhx/dwarfs
github.com github.com

Could DwarFS become a replacement for SquashFS, as used in PNDs and (if I remember correctly) DBPs ?

Cheers, Magic Sam
Click to expand...
Believe this lacks two key features needed for DBPs, one DwarFS creates a readonly filesystem and we need to have a writable filesystem, and it doesn't mention any ability of creating unions which allows DBP root and appdata directory to merge over a local mount.
 
SquashFS is also read-only - and it should be like that. That's the whole point of the mentioned union in the first place. Writes to the mounted app directory should not alter the app itself.
And i think the union is a feature of the kernel, not of SquashFS itself.

DwarFS sounds good and sounds like a better choice than SquashFS if someone would attempt a redo (Sadly, nowadays thats a big if). But if it will improve performance of running games on Pandora or Pyra in reality is a different thing.
 
Last edited:
I vote for AppImage.
Does pretty much all we need.
That appdata folder would be obsolete but in the same location as the AppImage is
 
Askarus said:
I vote for AppImage.
Does pretty much all we need.
That appdata folder would be obsolete but in the same location as the AppImage is
Click to expand...
AppImage lacks dynamic/automatically loading and it's clunky to add custom files/ROMS etc to the appdata directory...

@Nilsnsn & @Magic Sam
From my understanding the issue isn't really squashfs with DBPs, you don't really need a squashfs image to make a DBP file from slaeshjag's original post. I think all the issues that arise from the DBP system and further maintainability is that it currently requires AUFS and needs to be manual enabled back into aTc's kernel builds.
 
TrashyMG said:
AppImage lacks dynamic/automatically loading and it's clunky to add custom files/ROMS etc to the appdata directory...
Click to expand...
Actually there is a daemon that adds AppImages to your start menu.

I do not really see the need for an appdata folder any more.
For ROMS and files, they should not be in specific appdata folders anyways but on universal places where different emulators can access them.

It might be a different story for ports of commercial games that just contain the engine but need game files.
Would it not be possible for an AppImage to specify the location of those files relatively to the location of the AppImage?
Post automatically merged:

DBP has the huge disadvantage to (at least currently) not working on exFat drives which is what large SD cards use.

Because of that issue I wanted to place one in my home folder just for testing.
Did not work, because the DBP needed to create an appdata folder in my root directory where it had no permission for.

So in the current state, DBP is useless for me.
 
You must log in or register to reply here.

Similar threads

Wally
Creating a DBP (Amended instructions)
Replies
11
Views
5K
sebt3
sebt3
Wally
DBPUtils Script
Replies
17
Views
6K
Wally
Wally
Farox
Pyra How to made a DBP for Pyra
Replies
7
Views
3K
sebt3
sebt3
sebt3
DBP repository
6 7 8
Replies
141
Views
41K
nachoz12341
N
WizardStan
Docker vs DBP
2 3
Replies
46
Views
12K
WizardStan
WizardStan
Back
Top