Discussion About Additions To The Pnd Format

[polyroy]

Yes this does come from the documentation of aufs. Just ran a simple test on an Ubuntu machine which apparently doesn't use aufs (i.e. it doesn't work).

Not sure about Ubuntu, but in Debian I need the appropriate aufs-modules- packages for my kernel and I need to load the module aufs explicitly.

Edit: major constraint warning: It appears that most kernels are compiled to allow a maximum of 256 loopback devices, with a default limit of 8 as a boot-time parameter. If this cannot be increased, we won't be able to have more than 256 PND's simultaneously mounted at any time (due to it being an ISO and all). Quite a big issue, considering I was trying to simulate a mount of 100.000 loopback devices to see if there was such a thing as a 64k barrier.

 

[Sphinxter]

[2a: I love how you guys who don't want the NAND to be touched suggest we use ipkg. Doesn't that install on the NAND?

Surprising but no one here believes you're that stupid, quit trolling.

 

[WizardStan]

Let me see if I can summarize correctly. Stop me at any point along the way.
1) PND gets mounted into /mnt/pnd12345
2) Overlay from PND is unioned into /overlay directory
3) /pnd/root is unionfs with /
(2 may no longer be necessary because Caine is a genius? Instead unionfs / and all PNDs directly into /pnd)
4) / remains 100% untouched, while /pnd is free to do whatever it wants.
What about use case 2? Icon packs. The window manager looks in /usr/share/icons. Will it now have to look in /pnd/root/usr/share/icons? This seems like it would work great for PND applications, but what about NAND installed apps? Suppose Firefox is preinstalled on the NAND. How would we get a plugin into that? Would it have to be told to look in /pnd/root/usr/lib/mozilla/plugins instead?

 

[multiplex]

You, sir, are a genious. Either that, or you've simply read the manpages more than I have. Gentlemen, we just cut away one whole layer of complexity from the system. We now don't even have to care about the overwriting of symlinks; UnionFS will handle it for us.

*facepalm*

Edit: major constraint warning: It appears that most kernels are compiled to allow a maximum of 256 loopback devices, with a default limit of 8 as a boot-time parameter. If this cannot be increased, we won't be able to have more than 256 PND's simultaneously mounted at any time (due to it being an ISO and all). Quite a big issue, considering I was trying to simulate a mount of 100.000 loopback devices to see if there was such a thing as a 64k barrier.

http://www.slax.org/documentation_loop_mount.php

And Slax? It probably has a more stable system for something like this, but I think that it now is far too late to switch system for the Pandora. It could be an alternative package manager, however. The PND system as it is defined now, won't conflict with any other packaging system since it uses the UnionFS system to to effectively become the "fallback" file provider.

I was going to say that I had only suggested it as an interesting example to learn from, and not for actually using on the Pandora but thinking about it some more, that's exactly what I'd suggest. PND for games and applications, and Slax modules for one-click installation of icon packs, KDE, libraries, etc., assuming the LZMA compression isn't too much overhead on the Pandora. They're just squashfs images mounted onto aufs, which seems to be what you're gravitating towards anyway.

"far too late to switch system for the Pandora" is a bit of a laugh, though. Grafting the functionality you're talking about onto the PND system is no less of a switch.

 

[God Ginrai]

[2a: I love how you guys who don't want the NAND to be touched suggest we use ipkg. Doesn't that install on the NAND?

Surprising but no one here believes you're that stupid, quit trolling.

I'm not trolling, you jackass. I was just getting tired of you people bitching about not touching NAND. (especially after we had already moved over to the ramdisk unionFS idea)

-God Ginrai

 

[Sphinxter]

[2a: I love how you guys who don't want the NAND to be touched suggest we use ipkg. Doesn't that install on the NAND?

Surprising but no one here believes you're that stupid, quit trolling.

I'm not trolling, you jackass. I was just getting tired of you people bitching about not touching NAND. (especially after we had already moved over to the ramdisk unionFS idea)

-God Ginrai

Arguing and asking stupid questions just to fuck with people who don't share your point of view, oh, well, that's completely different, my apologies sir.

 

[polyroy]

http://www.slax.org/documentation_loop_mount.php

That, indeed, would be beautiful. However, I have found another limitation: time.

Look at this:

#!/bin/bash
max=7
mkdir -p mnt dev overlay iso/overlay
mkisofs -o dummy.pnd iso 2>/dev/null
mount -t aufs -o br:iso/overlay none overlay
for i in $(seq 0 $max)
do
    cp dummy.pnd $i
    mkdir mnt/$i
done
echo "*** Preparations done, starting timed sim ***"
time for i in $(seq 0 $max)
do
    mknod dev/$i b 7 $i
    losetup dev/$i $i
    mount -t iso9660 dev/$i mnt/$i
    mount -o remount,prepend:mnt/$i overlay
done
echo "*** All done, cleaning up ***"
umount overlay $(seq 0 $max|sed s:^:mnt/ :) 
rm -r mnt overlay iso dev $(seq 0 $max) dummy.pnd

(goddamn markup, the part where it says "mnt/ ", should NOT be separated by a space)
It simulates the PND mounting process and gives info about the final times.

My output:

real    0m1.186s
user    0m0.248s
sys     0m0.772s

And this is for just 8 PND's. Terrible! What can we do about it?

"far too late to switch system for the Pandora" is a bit of a laugh, though. Grafting the functionality you're talking about onto the PND system is no less of a switch.

I agree, let's take a good, long look at what they've done before we continue. If we can't solve the terrible performance issues, nobody is even going to want PND.

 

[God Ginrai]

[2a: I love how you guys who don't want the NAND to be touched suggest we use ipkg. Doesn't that install on the NAND?

Surprising but no one here believes you're that stupid, quit trolling.

I'm not trolling, you jackass. I was just getting tired of you people bitching about not touching NAND. (especially after we had already moved over to the ramdisk unionFS idea)

-God Ginrai

Arguing and asking stupid questions just to fuck with people who don't share your point of view, oh, well, that's completely different, my apologies sir.

Arguing happens in discussion at times. It's something that can not be avoided. You have argued as well. Does that make you a troll? Also, I didn't ask that question to fuck with people. I was asking that question for confirmation. I left it open so that If I was wrong in that assumption that someone could correct me and tell me that ipkg does not install on the NAND.

-God Ginrai

 

[dflemstr]

Arguing happens in discussion at times. It's something that can not be avoided. You have argued as well. Does that make you a troll? Also, I didn't ask that question to fuck with people. I was asking that question for confirmation. I left it open so that If I was wrong in that assumption that someone could correct me and tell me that ipkg does not install on the NAND.

Have no doubt that you're absolutely right in this situation.

IPKG can only install files to the NAND, unless you create some kind of union system with an SD card, and then you'll have to set the NAND to be completely read-only; you can never ever write anything to the NAND ever, not even to make core updates, or the system will break. Also, you will have one SD card that'll stay bound to the device forever; unless you boot with it inserted, the system will go back to the original NAND aka factory defaults, and if you remove it while the device is turned on, the system will crash for sure. In other words, you're better off just copying the OS to an SD card completely and ditch the NAND if you want a stable IPKG.

So yeah, IPKG practically can't be used outside of the NAND. If this wasn't the case, we wouldn't be having this discussion in the first place, now would we?

EDIT:
@ polyroy, It might actually be easier to use IPKG and find a sustainable solution for complete NAND overlays because of those horrible time issues. (Good job dflemstr, you're contradicting yourself in one single post) However, does anyone have any brilliant ideas about how this could be done? Remember, you can't (actually) use "/" as the mount target of unionfs or aufs or any FS for that matter, because the NAND will already be mounted there... Also, how would an overlay work with the hotswapping of SD cards? Unless there's some brilliant solution to these problems, we can forget that it'll work, but there might, as said, be some brilliant solution...

 

[Sphinxter]

Arguing happens in discussion at times. It's something that can not be avoided. You have argued as well. Does that make you a troll? Also, I didn't ask that question to fuck with people. I was asking that question for confirmation. I left it open so that If I was wrong in that assumption that someone could correct me and tell me that ipkg does not install on the NAND.

Have no doubt that you're absolutely right in this situation.

IPKG can only install files to the NAND, unless you create some kind of union system with an SD card, and then you'll have to set the NAND to be completely read-only; you can never ever write anything to the NAND ever, not even to make core updates, or the system will break. Also, you will have one SD card that'll stay bound to the device forever; unless you boot with it inserted, the system will go back to the original NAND aka factory defaults, and if you remove it while the device is turned on, the system will crash for sure. In other words, you're better off just copying the OS to an SD card completely and ditch the NAND if you want a stable IPKG.

So yeah, IPKG practically can't be used outside of the NAND. If this wasn't the case, we wouldn't be having this discussion in the first place, now would we?

EDIT:
@ polyroy, It might actually be easier to use IPKG and find a sustainable solution for complete NAND overlays because of those horrible time issues. (Good job dflemstr, you're contradicting yourself in one single post) However, does anyone have any brilliant ideas about how this could be done? Remember, you can't (actually) use "/" as the mount target of unionfs or aufs or any FS for that matter, because the NAND will already be mounted there... Also, how would an overlay work with the hotswapping of SD cards? Unless there's some brilliant solution to these problems, we can forget that it'll work, but there might, as said, be some brilliant solution...

Knoppix seems to be pretty trouble free, in linux the root is where the kernel thinks root is. On boot initramfs does exactly that, mounts a filesystem right on top of itself already mounted on /. http://www.fullsack..../init.d/mountfs look at polyroys example above where it remounts, even clearer.
Dialog menu driven script to build custom initramfs http://www.fullsack....in/gnxinitramfs note buildinitrfs function where it says, '# launch sequence'.

 

[Sphinxter]

http://www.slax.org/..._loop_mount.php

That, indeed, would be beautiful. However, I have found another limitation: time.

Look at this:

 #!/bin/bash
 max=7
 mkdir -p mnt dev overlay iso/overlay
 mkisofs -o dummy.pnd iso 2>/dev/null
 mount -t aufs -o br:iso/overlay none overlay
 for i in $(seq 0 $max)
 do
     cp dummy.pnd $i
     mkdir mnt/$i
 done
 echo "*** Preparations done, starting timed sim ***"
 time for i in $(seq 0 $max)
 do
     mknod dev/$i b 7 $i
     losetup dev/$i $i
     mount -t iso9660 dev/$i mnt/$i
     mount -o remount,prepend:mnt/$i overlay
 done
 echo "*** All done, cleaning up ***"
 umount overlay $(seq 0 $max|sed s:^:mnt/ :) 
 rm -r mnt overlay iso dev $(seq 0 $max) dummy.pnd

(goddamn markup, the part where it says "mnt/ ", should NOT be separated by a space)
It simulates the PND mounting process and gives info about the final times.

My output:

 real    0m1.186s
 user    0m0.248s
 sys     0m0.772s

And this is for just 8 PND's. Terrible! What can we do about it?

"far too late to switch system for the Pandora" is a bit of a laugh, though. Grafting the functionality you're talking about onto the PND system is no less of a switch.

I agree, let's take a good, long look at what they've done before we continue. If we can't solve the terrible performance issues, nobody is even going to want PND.

Was /etc/mtab a file or a symbolic link to /proc/mounts?

 

[Poem58]

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.

NO RISK!? Only if you can guarantee the maximum number of writes and since some card do fail before others I don't think anyone can make that guarantee.
I understand that you can use the NAND and that it takes a long time to wear out, however I don't see WHY I would want to use the NAND in this answer. What would be benefited by using it instead of the SD card. What would I be writing there and why would I want to. Seeing as how this is all being decided and I have no technical knowledge about these file systems etc. I will be doing what basically everyone else is doing, but I'd like to understand why I would be doing it and I still say unless there is some profound reason, I'd like my NAND left alone as much as possible. However, for really good reasons, I am flexible in this area.

 

[Sphinxter]

Just a thought on the speed but do we really need every, limit 256 PND files mounted all the time? pandorauser probably only wants to run one or up to half a dozen at a time, any more would be wasted, maybe if the desktop was stored on the card along with the icons, .xsession or maybe a PND browser/launcher/umounter?
Ed. another thought, if you've never seen the run command in e17 it's incredibly smart, lightning fast search, homes in on exactly what you want at a keystroke or two, arrow key browser and is quite a marvel in use, a must try.

 

[God Ginrai]

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.

NO RISK!? Only if you can guarantee the maximum number of writes and since some card do fail before others I don't think anyone can make that guarantee.
I understand that you can use the NAND and that it takes a long time to wear out, however I don't see WHY I would want to use the NAND in this answer. What would be benefited by using it instead of the SD card. What would I be writing there and why would I want to. Seeing as how this is all being decided and I have no technical knowledge about these file systems etc. I will be doing what basically everyone else is doing, but I'd like to understand why I would be doing it and I still say unless there is some profound reason, I'd like my NAND left alone as much as possible. However, for really good reasons, I am flexible in this area.

We've already switched discussion away from writing to NAND for this feature. It now involves storing it on ramdisk. dflemster made a post about this a couple of pages back.

EDIT:

Just a thought on the speed but do we really need every, limit 256 PND files mounted all the time? pandorauser probably only wants to run one or up to half a dozen at a time, any more would be wasted, maybe if the desktop was stored on the card along with the icons, .xsession or maybe a PND browser/launcher/umounter?

I know for me, at least, I probably won't even have more than 100 PNDs on each card, because I'll have them filled up with all the files that the PNDs will be using. (Images, videos, games, etc.) I would assume that the file manager should probably allow you to unmount any mounted volumes. (including PNDs)

-God Ginrai

 

[bzar]

I'm not entirely sure I still understand the use of the symlinks here. I thought you initially used them to prevent writing large amounts of data to the NAND or in this case RAM.

Are they required instead to create a single union which is shared by all PNDs? If I read the documentation of UnionFS correctly, we can just add volumes to the mountpoint:

# mount -t unionfs -o remount,add=/foo none MOUNTPOINT

So why do we not join the filesystem directly? Example:

/ - The real root directory of the system
  dev
  mnt
    pnd01 - A mounted PND
      overlay
        usr
          lib
            lib.so.2
  usr
  etc
  var
  pnd
    root - What will become the overlay version of the system
    original - The directory with exposed directories
      usr => /usr - This is a HARDLINK, not a symlink, as shown by the => arrow.
      lib => /lib
      home => /home
      etc - We want to only allow parts of etc to be "changed" by PNDs
        gtk-2.0 => /etc/gtk-2.0
        ...and so on...

Join them:
# mount -t unionfs -o dirs=/mnt/pnd01/overlay:/pnd/original none /pnd/root

/
  ...same as above, completely unchanged...
  pnd
    root
      usr
        ...all the contents of /usr
        lib
          ...all the contents of /usr/lib
          lib.so.2
      lib
        ...all the contents of /lib
      home
        ...all the contents of /home
      etc
        gtk-2.0
          ...all the contents of /etc/gtk-2.0

Adding another pnd:
# mount -t unionfs -o remount,add=/mnt/pnd02/overlay none /pnd/root
Removing a pnd:
# mount -t unionfs -o remount,del=/mnt/pnd01/overlay none /pnd/root

Haven't tested any of this yet though.

If I'm reading this correctly, this is kinda what I was saying last night. Except you're using hardlinks, which is of course the way to go here. I thought up this example to show my idea, but it might not be needed anymore. Aw heck, I'll put it up anyway.

NAND:
/shared1
/shared2
/critical

The shared# directories are places where pnd's can overlay data. Critical directory is a system directory where no pnd must touch for security reasons.

PND overlay:
/shared1/foo
/shared2/bar
/critical/malicious

Malicious is a file that should never be allowed to get to /critical in the filesystem. So if overlaid from root, it becomes:
/shared1
/shared1/foo
/shared2
/shared2/bar
/crirical
/critical/malicious

Which is bad. For this reason we add the overlay directory to NAND (I'll use hardlinks this time):
/shared1
/shared2
/critical
/overlay
/overlay/shared1 => /shared1
/overlay/shared2 => /shared2

...and overlay the PND's there:

/shared1
/shared1/foo
/shared2
/shared2/bar
/critical
/overlay
/overlay/shared1 => /shared1
/overlay/shared2 => /shared2
/overlay/critical
/overlay/critical/malicious

Now the malicious file is not in /critical, because /critical has no link in /overlay.

This might not serve any purpose anymore, but at least it should clarify what I was trying to babble tired last night

 

[Vorporeal]

Would it make sense to only load the XML "package definition" part of the PND when the SD card is inserted, and have it not actually be mounted and overlaid unless the user tries to run the app? If 8 PNDs took ~2s, the implied ~250ms delay for running a program to mount/overlay the PND is (imo) acceptable. Even an extra second to run an app is better than waiting a long time for the Pandora to boot up/load a SD card full of PNDs.

 

[polyroy]

Was /etc/mtab a file or a symbolic link to /proc/mounts?

NoA file, it seems to be generated. Not sure what does that though, this is a standard Debian install. Good find, but I can't see how much of the time this is eating. Anyway, wouldn't such generation be in the 0.2 seconds of user time? It still leaves about ~100ms of sys time per mount.

Perhaps someone can test this in more environments?

Any more advice on speeding this up?

Edit: I should really be ashamed that I answered false to a question which can only be true.

More replies:

Just a thought on the speed but do we really need every, limit 256 PND files mounted all the time? pandorauser probably only wants to run one or up to half a dozen at a time, any more would be wasted, maybe if the desktop was stored on the card along with the icons, .xsession or maybe a PND browser/launcher/umounter?

If there is no reason to pose arbitrary restrictions on the user, please don't. Slax seems to have given us a solution (no loopback restrictions at all, yay!), let's use that. As for your scenario; suppose someone likes to install a lot of theme packs / extensions / whatever, they will have to be mounted all simultaneously to have any effect. That might raise numbers quite a bit. This is also where the mounting slowdown will show the biggest problems. Each time you insert a card, you'll have to wait quite a while for all those extensions to mount.

Would it make sense to only load the XML "package definition" part of the PND when the SD card is inserted, and have it not actually be mounted and overlaid unless the user tries to run the app? If 8 PNDs took ~2s, the implied ~250ms delay for running a program to mount/overlay the PND is (imo) acceptable. Even an extra second to run an app is better than waiting a long time for the Pandora to boot up/load a SD card full of PNDs.

That was indeed the idea all along for most simple tap-and-run apps (those which don't put anything in the overlay, the overlay is a subdirectory in the pnd only meant for OS integration purposes). And here, this makes sense. For extension-like PND's, which extend the basic OS functions, it does not make sense as they could be mounted immediately when the SD card is inserted or the system is booted. This number of autostarted extensions might be small, but you really can't know in advance how users are going to use it.

And another one for Poem58, just to clarify:

What would be benefited by using it instead of the SD card. What would I be writing there and why would I want to. Seeing as how this is all being decided and I have no technical knowledge about these file systems etc. I will be doing what basically everyone else is doing, but I'd like to understand why I would be doing it and I still say unless there is some profound reason, I'd like my NAND left alone as much as possible. However, for really good reasons, I am flexible in this area.

The ability to use the Pandora out of the box, without an SD card, seems like a pretty big reason for me. As said before, you can switch to an SD-card only function the moment you have an SD card available, meaning you won't ever need to touch the NAND if you're all that concerned about that. And to make you realize why writing to NAND isn't all that bad: ALL flash-based devices currently on the market (phones, netbooks) use their internal NAND for storage. Probably most of the time without optimal wear-proof filesystems. They all wear out, but that doesn't seem to bother anyone. There are plenty more things subjected to wear on your pandora too; the hinges, the keys, the SD-card ejection mechanism, will you refrain from using them too? And if those things break (that will probably happen long before the NAND wears out even), the Pandora is broken completely. And if the internal NAND "breaks", the Pandora will still function fine anyway, opposed to all those other devices which do have issues then. You don't need to answer to this, this is just to put things in their proper context.

 

[Poem58]

The ability to use the Pandora out of the box, without an SD card, seems like a pretty big reason for me. As said before, you can switch to an SD-card only function the moment you have an SD card available, meaning you won't ever need to touch the NAND if you're all that concerned about that. And to make you realize why writing to NAND isn't all that bad: ALL flash-based devices currently on the market (phones, netbooks) use their internal NAND for storage. Probably most of the time without optimal wear-proof filesystems. They all wear out, but that doesn't seem to bother anyone. There are plenty more things subjected to wear on your pandora too; the hinges, the keys, the SD-card ejection mechanism, will you refrain from using them too? And if those things break (that will probably happen long before the NAND wears out even), the Pandora is broken completely. And if the internal NAND "breaks", the Pandora will still function fine anyway, opposed to all those other devices which do have issues then. You don't need to answer to this, this is just to put things in their proper context.

Thanks, I know I didn't NEED to answer this but since it was actually informative and understandable I want to. So basically, aside from just being able to use the Pandora without an SD card (which sounds like it would still be terribly useless as what could you do really when you can't even save a file you work on (aside from really small amounts I mean how much space is the OS projected to fill?) or have any games/music to play with no SD card unless you have a couple of songs or a couple of docs already stored on your NAND. I guess you could browse the web, but everything would have to be stored in ram and is it set up to do this?

Look guys, I haven't read the last few pages, I gave up trying to understand all these abbreviated letters and word/word/word references. I just was asking, so I know in the future, since the NAND is limited in space, will have the OS on it and need room for updates, and can be corrupted/fail. In which situations and for what benefit would I have ever wanted to focus on using it. Personally, I was planning on using it like my PDA where I could store one or two (always want this) files on it, but right now I wouldn't even know what those would be. this discussion triggered the "what benefits are there to using the NAND at all" question.
I'll go back and finish reading if I can keep my head from exploding. Sorry if I seem to have derailed you guys from your topic, but how's a guy supposed to learn if he doesn't ask questions, right? Thanks.

 

[God Ginrai]

The ability to use the Pandora out of the box, without an SD card, seems like a pretty big reason for me. As said before, you can switch to an SD-card only function the moment you have an SD card available, meaning you won't ever need to touch the NAND if you're all that concerned about that. And to make you realize why writing to NAND isn't all that bad: ALL flash-based devices currently on the market (phones, netbooks) use their internal NAND for storage. Probably most of the time without optimal wear-proof filesystems. They all wear out, but that doesn't seem to bother anyone. There are plenty more things subjected to wear on your pandora too; the hinges, the keys, the SD-card ejection mechanism, will you refrain from using them too? And if those things break (that will probably happen long before the NAND wears out even), the Pandora is broken completely. And if the internal NAND "breaks", the Pandora will still function fine anyway, opposed to all those other devices which do have issues then. You don't need to answer to this, this is just to put things in their proper context.

Thanks, I know I didn't NEED to answer this but since it was actually informative and understandable I want to. So basically, aside from just being able to use the Pandora without an SD card (which sounds like it would still be terribly useless as what could you do really when you can't even save a file you work on (aside from really small amounts I mean how much space is the OS projected to fill?) or have any games/music to play with no SD card unless you have a couple of songs or a couple of docs already stored on your NAND. I guess you could browse the web, but everything would have to be stored in ram and is it set up to do this?

Look guys, I haven't read the last few pages, I gave up trying to understand all these abbreviated letters and word/word/word references. I just was asking, so I know in the future, since the NAND is limited in space, will have the OS on it and need room for updates, and can be corrupted/fail. In which situations and for what benefit would I have ever wanted to focus on using it. Personally, I was planning on using it like my PDA where I could store one or two (always want this) files on it, but right now I wouldn't even know what those would be. this discussion triggered the "what benefits are there to using the NAND at all" question.
I'll go back and finish reading if I can keep my head from exploding. Sorry if I seem to have derailed you guys from your topic, but how's a guy supposed to learn if he doesn't ask questions, right? Thanks.

Basically, the NAND will probably be used to hold the OS, your settings, and any applications you install from the Angstrom repository. (You might do this at some point because the repository has something that there isn't a PND version of)

-God Ginrai

 

[Poem58]

Seriously, the Applications I add to the Pandora will be placed in NAND!? Everything I read before said you drop the files on your SD card and they are just installed. Seems you could fillup the NAND mighty quick. Not liking the sound of this.

Edit: or do you mean Non-PND software will have to be placed in the NAND? Which I guess would be an actual install where if I understand correctly the PND is an installation free way right?