gruso
thunderbox
Great work.dflemstr said:First shot at a FAQ: http://pandorawiki.org/PND:FAQ
Last edited by a moderator:
Great work.dflemstr said:First shot at a FAQ: http://pandorawiki.org/PND:FAQ
Could someone pretty please put a site map on the wiki? It's impossible to find any pages without knowing the link beforehand.dflemstr said:First shot at a FAQ: http://pandorawiki.org/PND:FAQ
You can always search for "pnd"... Or look in the PND category: http://pandorawiki.org/CategoryWhiteBat said:Could someone pretty please put a site map on the wiki? It's impossible to find any pages without knowing the link beforehand.dflemstr said:First shot at a FAQ: http://pandorawiki.org/PND:FAQ
"PND" search returns no results. That'll stop most people in their tracks, they won't go looking for categories. I think at the least the main page needs a few more links, PND and USB being the obvious ones. I believe only Chip can do this.dflemstr said:You can always search for "pnd"... Or look in the PND category: http://pandorawiki.org/CategoryWhiteBat said:Could someone pretty please put a site map on the wiki? It's impossible to find any pages without knowing the link beforehand.ND or in the FAQ category: http://pandorawiki.org/Category:FAQ etc.
dflemstr said:You can always search for "pnd"... Or look in the PND category: http://pandorawiki.org/CategoryND
Yeah I noticed, the search is completely broken. What's up with that?Gruso said:"PND" search returns no results. That'll stop most people in their tracks, they won't go looking for categories. I think at the least the main page needs a few more links, PND and USB being the obvious ones. I believe only Chip can do this.
Friendly, yes. Efficient, no way! It's fast enough for nobody to notice, but it would be possible to speed up the discovery and PND access stuff by at least a factor of 3. The reason why it hasn't been sped up by that factor is probably that nobody wants to do the needed bit-twiddling (e.g. BASH scripts are being used and the format requires massive amounts of fscan() to find metadata so yeah it's *slow*, relatively speaking).Gruso said:My opinion, it's going to rock. No doubt it will be built on after release, or supplemented by PND management utilities. But even as it stands, it's more friendly and efficient than anything that has appeared on an open handheld. Or a desktop computer, arguably, but I'm not feeling arguable so let's not go there.
sudo apt-get update
sudo apt-get upgrade
Yes.Dimacus said:Dose it look like everything (the data contained in the PND and the appdata folder) is in the current cwd, only when you try to write to the cwd, it writes to the appdata?
Which duplicates? You mean, what happens when the app writes to a file that already exists? It depends on which unionfs is being used; I think that aufs will copy the file from the PND to the appdata folder and then make the changes to the copied file.Dimacus said:If so, how are duplicates handled?
When a .pndfile or PXML.xml dir get mounted, any writes back to the mounted area are put into appdata, with a subdir by the unique-id. i.e.: With the hypothetical MAME.pnd, it might update its config files after a user changes something, or create new files, or store hiscores or whatever. If it doesn't write them to NAND, and doesn't want ot write them to /mame/some/dir, but instead record it to itself for whatever reason, it would go to /pandora/appdata/MAMEs-ID/ instead. The pnd or PXML.xml app area is never modified during a run, only the appdata. (But when an application reads its own path, it will pick up the appdata version of the file instead of the actual file. Then magic of union-type filesystems!)
dflemstr said:Which duplicates? You mean, what happens when the app writes to a file that already exists? It depends on which unionfs is being used; I think that aufs will copy the file from the PND to the appdata folder and then make the changes to the copied file.