Discussion About Additions To The Pnd Format


sverm said:
God Ginrai said:
That's why I suggested the symlinks shouldn't be deleted, to get rid of the excessive wear.

The issue I have with that is that if you try-then-delete a lot of software, you're going to end up with lots of symlinks over the years, and who knows what virtual spaghetti that could turn into. I would err on the side of keeping NAND read-only, unless a special kind of PND comes around whose sole purpose is to update the Pandora base firmware (by "base firmware", I mean OS, environment, GUI, sanctioned standard libs, and not media players, emulators, roms, or recently updated libs only required by certain games)

Just my $0.02 worth.
in other words, yet another +1 for a purely ramdisk-based solution, and deletion of symlinks in that ramdisk by the pnddaemon after PNDs are unmounted, to make management more simple.

So far, this is how the FS layout would look:

Code:
/ - There's an UnionFS on the root directory. The / directory is the overlay and /mnt/overlays is the "base" directory.
|-- dev/
|   `-- shm/ - Ramdisk
|       |-- overlays/ - The directory where all of the symlinks are stored.
|       |   `-- usr
|       |       `-- lib
|       |           |-- libfoo.so.3.8.9 -> /mnt/pnd029883/libfoo.so
|       |           |-- libfoo.so.3 -> /mnt/pnd029883/libfoo.so
|       |           `-- libfoo.so -> /mnt/pnd029883/libfoo.so
|       `-- pnd029883/ - A mounted PND
|           |-- overlay/ - This directory contains the symlinks that now have been copied into the /mnt/overlays folder
|           |   `-- usr/
|           |       `-- lib/
|           |           |-- libfoo.so.3.8.9 -> /libfoo.so - I'm meaning the PND root when I say / here.
|           |           |-- libfoo.so.3 -> /libfoo.so
|           |           `-- libfoo.so.3 -> /libfoo.so
|           `-- foo.so
`-- usr/
    `-- lib/
        |-- libfoo.so.2 -> libfoo.so - Note that an older version is already present on the system
        |--#libfoo.so.3 -> /mnt/pnd029883/libfoo.so - These come from the UnionFS overlay
        |--#libfoo.so.3.8.9 -> /mnt/pnd029883/libfoo.so
        `-- libfoo.so - This already exists on the system and thus "shadows" the overlay version of it.

...so the commands needed to do this are:
(once per boot:)
Code:
sudo mkdir /dev/shm/overlays
sudo mount -t unionfs -o dirs=/:/dev/shm/overlays none /
^ I don't actually know if that last one will work, can anyone check? Otherwise, we'd have to chroot the whole system to another folder, which would be possible but not so fun.

(Once per PND:)
Code:
sudo mount -o loop mypnd.pnd /mnt/pnd029883
find /mnt/pnd029883/overlay -type l -exec sudo cp -n '{}' /dev/shm/overlays/ ;

(Before a PND is unmounted; this is not quite safe but we can work on it:)
Code:
files=`find /mnt/pnd029883/overlay -type l`
for file in $files; do
  if [ -e "/dev/shm/overlays/${file}" ]; then
    sudo rm "$file"
  fi
done

...and we're done. Easy, right? Oh, and of course, this is done by the pnddaemon; we don't do it manually.
 
Last edited by a moderator:
Enverex said:
What's wrong with the /home on the NAND? I'm not keen on having no settings stored on the device itself, it's also where Linux needs to store your logon details and other basics, things that shouldn't be on an SD card...
1/ NAND can be worn out. If user don't care about it he heavily use it and one day suddenly BANG - NAND is worn out.
2/ NAND is too small to store user files in it. If user don't know nothing about it, he store anything he download, edit or so in NAND and suddenly BANG - NAND is full.

-- edit --

dflemstr: I think that something that you call UnionFS (I'm mostly Windows guy - apologize my lack of deeper Linux knowledge) may work. If user don't insert storage card, then everything stay in RAM. If storage card is used than everything can be stored on it. I think that final behavior will be tuned up after time. I know that wearing of NAND is not so fast to scratch it by few weeks of using. But I really like if I can every write redirect to card even if it means that I must shutdown system before switch it.
 
Last edited by a moderator:
I'm really not sure exactly what problem we're trying to solve here but anyway.

If it does become necessary for some reason to allow certain PNDs to write to the NAND, can we at least have the system pop up a warning of some kind that it is being done. You know something like "The application you are attempting to run is trying to access the system memory. Only allow this if you trust the source" etc etc...
 
Since this is more about the implementation than the Pnd format, I will just mention what, in my opinion, is the best way to deal with setting up filesystems.

On NAND:
Pandora firmware, squashfs or something, read-only, with space reserved to whatever we decide will be the maximum firmware size for any release.
NAND-friendly (UBIFS or something) writable root overlay (if possible)

Now, when the user inserts their first SD card, they should be asked whether they would like to make that SD card their new root/home overlay FS due to space/wear limitations. (ignore the UI-details for now) The contents of the overlay will be copied to the SD card, and the overlay in NAND will be marked stale by presence of some file. It can fall back when that SD-card is no longer inserted, and if size permits, the user should be able to update the overlay on NAND from SD card if allowed.

If the SD card is formatted EXT2/3, this would make for the most universal approach (even Windows can access it) as the entire overlay's contents can reside in a subdirectory of the SD card. If it uses (god forbid) FAT32 or something permission-incompatible, we are forced to either assign a seperate partition on the SD card or make an image file. Advantages of are of course that we can use some sort of SD-card friendly filesystem, if such a thing exists. (Since UBIFS is meant for MTD)

This will allow developers to use the IPKG system to modify stuff to the OS, and edit everything freely. It will allow everyone to fill their SD cards with a lot of junk. And it will also allow for VERY easy reverting to factory firmware by erasing (reverting, not shadow-erasing) non-/home files from the overlay.

I'm sorry that I cannot comment on how PND's should overlay in this system. I was hoping either aufs or UnionFS would solve all our problems magically. But all your talk about spreading all those ugly symlinks somehow gives me the impression that this is not possible.

Edit: Hey, here's an idea: you can tell UnionFS (or aufs) with special commands to which "union" layer (well, branch for aufs) certain files should go. So, all you need to do is make both a RAM overlay AND the (standard) persistent overlay, and tell UnionFS (whenever the PND daemon makes the symlinks) to specifically throw them in the RAM overlay.
 
peca said:
1/ NAND can be worn out. If user don't care about it he heavily use it and one day suddenly BANG - NAND is worn out.
2/ NAND is too small to store user files in it. If user don't know nothing about it, he store anything he download, edit or so in NAND and suddenly BANG - NAND is full.

-- edit --

dflemstr: I think that something that you call UnionFS (I'm mostly Windows guy - apologize my lack of deeper Linux knowledge) may work. If user don't insert storage card, then everything stay in RAM. If storage card is used than everything can be stored on it. I think that final behavior will be tuned up after time. I know that wearing of NAND is not so fast to scratch it by few weeks of using. But I really like if I can every write redirect to card even if it means that I must shutdown system before switch it.
The solution to your two problems is that you just tell the user to not store things in the /home folder. The NAND has about as many writes as the average SD card, so that's not a problem.

Oh, and you can of course manually move the operating system to an SD card, and then all writes will happen on that SD card. It's not possible to have that as the default setup, however. UnionFS could be used in situations like this, but that's not what I was using it for above.

@polroy What you propose sounds systainable, but it's not a one-size-fits-all solution. Also, I'm only worried about the PND management system here; if people want to make SD overlays, then sure, do so, but until there's a working system that can manage the hotswapping of SD cards and the data branching of the NAND vs the SD card when the SD card is removed, then I'll look more into it. For now, I think that a RAM overlay with hooks should be enough (and it takes the least amount of memory because no file duplicates will be mounted, and the NAND's version of stuff can be preferred).
 
Last edited by a moderator:
peca said:
1/ NAND can be worn out. If user don't care about it he heavily use it and one day suddenly BANG - NAND is worn out.
2/ NAND is too small to store user files in it. If user don't know nothing about it, he store anything he download, edit or so in NAND and suddenly BANG - NAND is full.

-- edit --

dflemstr: I think that something that you call UnionFS (I'm mostly Windows guy - apologize my lack of deeper Linux knowledge) may work. If user don't insert storage card, then everything stay in RAM. If storage card is used than everything can be stored on it. I think that final behavior will be tuned up after time. I know that wearing of NAND is not so fast to scratch it by few weeks of using. But I really like if I can every write redirect to card even if it means that I must shutdown system before switch it.
The solution to your two problems is that you just tell the user to not store things in the /home folder. The NAND has about as many writes as the average SD card, so that's not a problem.

Oh, and you can of course manually move the operating system to an SD card, and then all writes will happen on that SD card. It's not possible to have that as the default setup, however. UnionFS could be used in situations like this, but that's not what I was using it for above.

@polroy What you propose sounds systainable, but it's not a one-size-fits-all solution. Also, I'm only worried about the PND management system here; if people want to make SD overlays, then sure, do so, but until there's a working system that can manage the hotswapping of SD cards and the data branching of the NAND vs the SD card when the SD card is removed, then I'll look more into it. For now, I think that a RAM overlay with hooks should be enough (and it takes the least amount of memory because no file duplicates will be mounted, and the NAND's version of stuff can be preferred).
 
Last edited by a moderator:
dflemstr said:
The solution to your two problems is that you just tell the user to not store things in the /home folder. The NAND has about as many writes as the average SD card, so that's not a problem.
Yes, but an SD card is expendable. It fries, you get a new one. You did keep a backup of all your favorite PNDs, right? Whereas the NAND is not easily replaceable in the Pandora. It fries, you need a new Pandora.

If you make the NAND read-only, and all save data, settings, programs, shortcuts, symlinks, etc... on SD, then you ensure that if something weird happens, you can just eject the SD, boot without one, and troubleshoot in a mode not altered by any customized settings. By having no SD card at all, everything could be saved to a RAMdisk. You could play with the Pandora in non-destructive mode, using whatever is in the NAND in read-only mode, all with default settings.

Just like, say a PlayStation 1 where, if you don't have any memory cards, you can't save any games.
 
Last edited by a moderator:
dflemstr said:
@polroy What you propose sounds systainable, but it's not a one-size-fits-all solution. Also, I'm only worried about the PND management system here; if people want to make SD overlays, then sure, do so, but until there's a working system that can manage the hotswapping of SD cards and the data branching of the NAND vs the SD card when the SD card is removed, then I'll look more into it. For now, I think that a RAM overlay with hooks should be enough (and it takes the least amount of memory because no file duplicates will be mounted, and the NAND's version of stuff can be preferred).

I think aufs deals just fine with disappearing branches, and branch configuration seems to be its strong point too. I've been trying to find proof of this (only found some people discussing this lightly), but I guess I'll have to set up some tests myself.

And, if you leave it completely up to the user where they intend to store their files, how is this not one-size-fits-all? :) The default is a fully functional system with which you can do everything (just with slightly limited storage). If you know of an app which produces huge configuration files, and you can't use that configuration without the app, you can always symlink it's config directory to some seperate media (the same place the app is stored) if you don't want to move your root overlay from NAND. I believe this is quite flexible, and if not, fitting it to your needs it should require minimum changes in the (default) configuration on the NAND. You should even be able to reduce the size of the NAND overlay to free up most space which you can use for other NAND-ish purposes. Add in a default bootloader in the standard firmware (which gives you the option to boot from SD), and you'll be as flexible as anything, completely bypassing the NAND if you wish.
 
Last edited by a moderator:
The only technical issue I have with PND (which I actually like) is that if you progress this through a few months of linux development, many of your support libraries will change. At some point, a few of them will go through a major version change and break backwards compatbility. This logic then suggests that you either:

1. Have to assume that everyone has a pandora-angstrom-OS-1.x (the initial official OS) software library and each .pnd will have to include all of the library upgrades necessary to run whatever program it represents.
2. Restrict software bundled to .pnd to those that don't drastically need to modify the OS.
3. Each .pnd has a built in "OS version" checker and therefore is only compatible to that and higher.
4. A mix of the above.

This is not a trivial issue because a few of the low-level GNU programs/libs and a few more of the xorg programs/libs are inter-dependant on each other and are upgraded simultaneously in order to maintain compatibility with each other but not necessarily backwards compatibility. Hopefully you can see my concern where a PND with gameX, using the latest software, may require to be bundled with a large portion of a OS to support it.

I guess what it still vague at least in my mind is the scope of PND use? Is this going to be drop-in software for end-users intended for games/high-end apps, or is this going to be a de-facto way of "upgrading" your default OS without requiring a rewrite to NAND?

Thoughts?
 
viridior said:
I guess what it still vague at least in my mind is the scope of PND use? Is this going to be drop-in software for end-users intended for games/high-end apps, or is this going to be a de-facto way of "upgrading" your default OS without requiring a rewrite to NAND?
Core updates (To X11, the Kernel, glibc etc) will happen through IPKG. PNDs are only meant as a means to deploy applications easily and without the need to install them. However, what you can package in PNDs should be up to whoever chooses to package something in them; my point with this discussion is that the technology shouldn't be the limiting factor.

I can see PND being used by:
1. Users who have made homebrew games or emulators and want to deploy them.
2. Users that have packaged nice applications (for instance MPlayer, or GEdit, or GNOME, or Apache) in a neat way and want to share them amongst others because the installation process is so easy with PNDs.
3. Users who have created artwork, levels, games etc that are too big to fit on the internal NAND.
4. Companies who want to deploy commercial applications.

Oh, and the current model I'm proposing allows for dynamic library linking that doesn't break versioning compatibility. As you've seen in my examples, if the Core OS version 3.4.7 no longer has libfoo.so.2 (because the Pandora devs decided it's out-of-date), the PND will just use its internal version and all will be well. There just won't be an issue with dynamic library conflicts.
 
Last edited by a moderator:
dflemstr said:
viridior said:
I guess what it still vague at least in my mind is the scope of PND use? Is this going to be drop-in software for end-users intended for games/high-end apps, or is this going to be a de-facto way of "upgrading" your default OS without requiring a rewrite to NAND?
Core updates (To X11, the Kernel, glibc etc) will happen through IPKG. PNDs are only meant as a means to deploy applications easily and without the need to install them. However, what you can package in PNDs should be up to whoever chooses to package something in them; my point with this discussion is that the technology shouldn't be the limiting factor.

I can see PND being used by:
1. Users who have made homebrew games or emulators and want to deploy them.
2. Users that have packaged nice applications (for instance MPlayer, or GEdit, or GNOME, or Apache) in a neat way and want to share them amongst others because the installation process is so easy with PNDs.
3. Users who have created artwork, levels, games etc that are too big to fit on the internal NAND.
4. Companies who want to deploy commercial applications.

Oh, and the current model I'm proposing allows for dynamic library linking that doesn't break versioning compatibility. As you've seen in my examples, if the Core OS version 3.4.7 no longer has libfoo.so.2 (because the Pandora devs decided it's out-of-date), the PND will just use its internal version and all will be well. There just won't be an issue with dynamic library conflicts.

I pretty much agree that this is the way packages should be handled, but I don't think the default user should be privileged. Other then updates to the system he should login to root to make changes on the nand. It would protect people new to linux from accidentally erasing the nand.
 
Last edited by a moderator:
I would like to also encourage that any of these overlay/write-to-nand/whatever hacks be discouraged as much as possible. Writing to the NAND, or changing the file system (whether temporary or permanent) should not be a recommended way of solving a problem unless there is no other way of solving the problem.
 
WizardStan said:
I would like to also encourage that any of these overlay/write-to-nand/whatever hacks be discouraged as much as possible. Writing to the NAND, or changing the file system (whether temporary or permanent) should not be a recommended way of solving a problem unless there is no other way of solving the problem.

Well, as the sole purpose of an overlay is to not modify a filesystem while unifying all available data anyway, and if you modify the filesystem you don't have a reason to use overlays, I am confused by your statement. We have to have the ability for PND's to augment the function of the OS, either in a permanent way (extraction, which won't happen anyway, except maybe in configuration) or temporarily (overlays / (temporary) symlinks).

A filesystem on the NAND can be pretty durable if you set it up properly. Some people will want the ability to use the device without SD cards, at least initially, but if the pandora "out of the box" refuses to do anything because it can't write to /home, I for one will be quite disappointed with it.

Some things I would like to push:
1) Give the user a choice (where stuff is stored)
2) Do not restrict them in what they can or cannot do, whatever your principles may be (others do not neccessarily agree with them)
3) Allow for an easy way to revert to factory defaults and start over, and if possible without losing user data (when desired)

Which seems to fit my mentioned setup. But I need some confirmation on the state of hot-removal of branches in unionfs/aufs.
 
Last edited by a moderator:
As a person who gets the concept of this discussion yet knows absolutely NOTHING about anything here, I would like to say that it sound's like a person like myself who has no experience would prefer not to risk the NAND for any reason, should have steps implemented to protect that. Unless for a really good reason, I would not want to write much of anything to NAND at all.
I can replace an SD card. But I'll only have 1 Pandora, so I don't want to risk the NAND. Maybe someone could quickly explain why aside from say an OS update why I would ever want to write to the NAND instead of SD?
 
I agree with everything above the following statement, it makes sense and should be fairly intuititive.

"Oh, and the current model I'm proposing allows for dynamic library linking that doesn't break versioning compatibility. As you've seen in my examples, if the Core OS version 3.4.7 no longer has libfoo.so.2 (because the Pandora devs decided it's out-of-date), the PND will just use its internal version and all will be well. There just won't be an issue with dynamic library conflicts." Sorry for not doing a normal quote, the new theme doesn't play well with IE6, which I'm forced to use at work. :/

This is what was my last point. This implies that its up to the maker of the PND to determine what additional software will be needed to run his program. Each packager could either base his PND to work with Core OS xx.xx.xx and therefore not all PNDs may work with whatever version of the OS a end-user is using (not abnormal) or you could go the other extreme of including all the libraries and programs necessary to make your PND work, essentially duplicating a portion of the OS within the PND. Obviously the later wouldn't be entirely true, but my point is that there is no defined scope for libraries/support packages and each PND could be appending with a "sub-OS" which then of course will further load down the system. These are the kinds of thoughts I have when we start blurring the line between what is on the NAND, or SD, or a combination with unionfs and what real effect it will have on performance.

If we establish the scope as just end-user programs and the immediate support libraries, then I think my above statements will be trivial, but undefined... What prevents me from packaging an entirely new OS (that uses newer software/libraries) for malicous purposes? Or if as a end-user I have a hugh problem loading PND because it overloads my system/I get all kinds of weird erros, is that the main OS dev's problem, or the PND maker?
 
Poem58 said:
I can replace an SD card. But I'll only have 1 Pandora, so I don't want to risk the NAND. Maybe someone could quickly explain why aside from say an OS update why I would ever want to write to the NAND instead of SD?

Because the internal NAND wears down even slower than an SD card when the appropriate technologies are used. You can take advantage of the MTD in the system, but there is no such thing as MTD the moment you are talking about SD cards. If, by default, it uses UBIFS, and we count on the NAND to have at least 10.000 write/erase cycles, then you'll need to write 5.12 terabytes of data to a 512MB UBIFS volume before it is "worn out". There is no risk. The moment a user inserts their SD card they will be informed of the eventual wear, and they can adjust for that. This will happen long before that 5.12TB is reached :)

If it were some idiot FS which allows for 10.000 consecutive writes to the same position, that position will have worn out. But you don't use those for the system for exactly that reason.
 
Last edited by a moderator:
polyroy said:
Well, as the sole purpose of an overlay is to not modify a filesystem while unifying all available data anyway, and if you modify the filesystem you don't have a reason to use overlays, I am confused by your statement. We have to have the ability for PND's to augment the function of the OS, either in a permanent way (extraction, which won't happen anyway, except maybe in configuration) or temporarily (overlays / (temporary) symlinks).
Modifying the file system (even temporarily, in memory, with an overlay) means you're making assumptions about the file system, which means putting restrictions on the file system.
Suppose that, right now, icons are stored in /usr/share/icons. A few months go by, and a new kernel is released, and it is decided that icons should be stored somewhere in /opt (imagine a very good reason (which I don't have) was given, or imagine that I used a better example than icons that you could easily find an example for. Just work with me here). Your icon PND file no longer works because you relied on an overlay.

Here's a thought that just occurred to me: instead of trying to come up with a generic solution, why not start creating specific solutions? The PND format, as it is right now, without updating anything, is great for stand alone click-to-run games and apps. "What about icon packs and library upgrades?" you ask. Start adding subtypes which can be specified in the PND file.
The daemon opens up the PND, sees it says "I am an icon pack; my name is blueicons". The daemon then, instead of mounting it to /mnt, mounts it into the icon directory, wherever that may be. Or mounts it to /mnt and creates a symlink automatically. "I am a library" gets symlinked to the library directory, wherever that may be; it could even make a specific "SD Mounted" directory so it doesn't interfere at all with the default ones. "I am a service" gets asked for a password, notified about what's going on, and installed to the init.d. Etc...
Could this solution work? Could we come up with enough specific use cases, consolidated into minimal subtypes, that the need for a generic catch all could be eliminated?
This has an added security benefit. Settings in the daemon allow you to turn subtypes on and off. "I want apps and icons. Don't let libraries and services run" and a warning appears if you insert an SD card with PND files which claim to be libraries or services. "What? AwesomeGame.PND is a service? That doesn't sound right."
Just a thought.
 
Last edited by a moderator:
polyroy said:
Because the internal NAND wears down even slower than an SD card when the appropriate technologies are used. You can take advantage of the MTD in the system, but there is no such thing as MTD the moment you are talking about SD cards. If, by default, it uses UBIFS, and we count on

Don't forget of course that life expectancy depends not only on the number of writes, but the free space. The more free space there is, the longer the nand lasts.
 
Last edited by a moderator:
sverm said:
dflemstr said:
The solution to your two problems is that you just tell the user to not store things in the /home folder. The NAND has about as many writes as the average SD card, so that's not a problem.
Yes, but an SD card is expendable. It fries, you get a new one. You did keep a backup of all your favorite PNDs, right? Whereas the NAND is not easily replaceable in the Pandora. It fries, you need a new Pandora.

You may not be able to replace the NAND, but as polyroy said, that's a long way away. Also, even if you can't replace the NAND, you still don't need a new Pandora, because you can boot from SD. (IIRC, the bootloader is not in the NAND itself)

And WizardStan, it's never a good idea to make specific solutions. That just leaves you with a good system that is now overflowing with hacks to make it work for specific things. It's better to come up with a general solution. What's wrong with the Ramdisk UnionFS idea?

-God Ginrai
 
Last edited by a moderator:
dflemstr said:
I can see PND being used by:
1. Users who have made homebrew games or emulators and want to deploy them.
2. Users that have packaged nice applications (for instance MPlayer, or GEdit, or GNOME, or Apache) in a neat way and want to share them amongst others because the installation process is so easy with PNDs.
3. Users who have created artwork, levels, games etc that are too big to fit on the internal NAND.
4. Companies who want to deploy commercial applications.

NAND should not be touched by SD card / PND insertion.
NAND does not need to be touched by unix-style HOME configuration settings in .dot directories

from uses you mentioned
PND use 1:
game executable with included library bloat: 5 to 20 MB,
100% sure it works because the library are included, no risk of crashing the game with a new library that introduce a bug
"it just works" and that's what you want in a game console when you just want to play a game.

PND use 2a:
install applications thru rpm, ipkg, etc.
PND should be for removable apps, there are already two dozen permanent app installation distribution formats, no need for a new one.
really, for the love of all that is good pleeeeeeeease don't create a new installation package format for linux.

PND use 2b:
include a 10MB MPlayer PND package with each SD cards containing movies
you know that mplayer version plays your movies fine and will always play it fine, pop in the card, it works.
10MB mplayer vs 700MB movie = 1.4% waste
10MB mplayer vs 4.7GB DVD dump = 0.2% waste
10MB mplayer vs 32GB SDHC card = 0.03125% waste

PND use 3:
a. install the expansion pack on the SD card with the original game on the SD card.
b. have the game (open source, special pandora version) look for expansion packs on the SD cards

PND use 4:
as a professional, last thing I want is some updated, optimized, suddenly more memory hungry library to crash my game for whatever reason.
so I want my games to ALWAYS and ONLY run with the included libraries.
otherwise I get emails and complains from users: "the game crashes on my machine" which I can't reproduce, can't fix, get a bad reputation for, and I get unhappy users: everybody loses.
the user will not be able to guess that its because game Y updated the ALSA libs to a new DSP-accelerated version with an accidental +1 buffer overrun / alignment round off error or whatever reason.
http://www.mobygames.com/developer/sheet/view/developerId,68260/
http://www.google.ca/search?hl=en&q=stephane+hockenhull

as for saving in HOME, have HOME point to the SD card when running an game off a PND, you want to keep the saves with your game or Apps on the SD card.
this way, whatever apps or games are running will find its associated files on the SD card.

no UnionFS, no NAND writes, pure plug and play.
its been done, tested and proven to death in the professional game industry in the last 20+ years.

and anyone who'd want to install apps or update the system, can easily do so without using PND.

last thing anyone wants is worry that a PND will suddenly trash its system or other apps/games.
and why not run the games and PND apps (like firefox, gimp, etc) as a special extremely limited user, all the game/apps needs to access is its own SD card or at most both SD cards.

KISS and cheers :)
 
Last edited by a moderator:
Back
Top