Ok I Tried The Whole Separate Appdata Dir Thing

[WizardStan]

Ugh, this reminds me of all of those windows programs needed to clean up after the messiness of the os.

I think it would just be better to make it more logical in the beginning, then we wouldn't need all of that.

If the apps data dir was in the same dir as tha app we wouldn't need this kind of thing. It would make sense. If you want to delete the app just nuke its subdir.

Except then, instead of having 3 quake files in the appsdata directory, you have three of them in the menu (or desktop, or apps) directory. Your way is not any more logical, it requires the user to put each PND into its own separate directory, and that doesn't make any sense to me. It's a single file, why does it need its own directory?

 

[skeezix]

skeezix & dflemstr, thanks for the clarification. So yeah, no problem with the system then. Just one question: if the user already makes the PND's appdata directory in advance what happens? I ask because for some users I think it'll be more straightforward to dump the syscards in the syscard directory rather than having to run the emulator first for that directory to be created, then exiting the emulator and throwing the syscards there.

The union magivc doens't know if it created it or something else (ie: think second run, the dirs and contentds are already there now, its not going to wipe them out.)

If somethign pre-makes the dirs, its just all there and auto-overriding or becoming visible to the pnd stuff. Its very natural.

jeff

 

[skeezix]

DaveC -- like I'vce always said, we'r at version 1.0; you can';t launch with 10.0, you have to get there. No one said the system shipped was 'it', and 'final'; have mercy on us More optionsd are good (you know me!), but its hard to keep up with the demands.. system has been out, like 2 weeks

jeff

 

[skeezix]

I can certainly see where DaveC is going, and coming from, and he's right on a lot of levels, but as I said waaaay up .. it imposes a certain discipline on a user day zero; I think the current system is a great default, and a more knowledgable user can opt to switch to a DaveC approved path system shoudl they wish to, later.

Consider this scenario -- user stgicks pnd file into /pandora/desktop; uses it for a few days, and now has appdata in their desktop directory. Then they move the pnd file to menu .. oops, they've lost all their appdata, and got a _new_ appdata dir in /pandora/menu .. plus the old one. User is confused -- what happened ot my saves, and now why do I have two directories? Or worse tell a new user why they have to put a pnd file in its own directory

OVer time, I'll still keep it as is -- it makes sense to me; I can back up a single appdata dir and poof, all good

But I can certainly see a place for DaveC's approach; its a philsophical thing -- a user choice, and its equally valid (and the default approach is equally valid!).

--

That said, we just need time to get it; I made a quick hack that works okay, but sudo needs tweaking to be happy with it, and theres some security concerns. If someone wants to (See other thread) propose some changes to sudoers file, thats cool; otherwise oyu'll have to wait for me to get around to it. And package it up into a pnd file to apply the mod. But most of the mod is already done (see other thread.)

jeff

 

[SomeGuy99]

Random idea:

Support PNDs within zip files. Inside the zip file is the PND file and the appdata folder.

That way both are attached to each other, making management easier. You also don't have to hunt down the correct appdata folder. It is more logical.

Add a modification within the firmware to browse zips as folders. Other desktop operating systems like Windows can already do that, so it would work across the board.

Updating the app would just mean dropping a new pnd into the folder/archive. Inside the archive could be a single folder called 'appdata' so you could even have multiple pnds within the folder which can access the same data. By default the firmware will launch the most recent PND within the archive, but you can support choosing which one. Overides for pxml settings and the default launched pnd can be saved within the archive, for example in a 'config' folder.

So it may look like:

Picodrive.zip
_____pico_drive_1.0.pnd
_____pico_drive_2.2.pnd
_____/appdata
_____/config
_____run.cfg (contains settings for 'launch most recent version, or load version X')

The zip is just a logical container. It could be any number of supported formats so the end user isn't forced to use zip (they can repack it in a tar file say).

I understand the primary disadvantage is the scanning speed... hmmm...

 

[Tempel]

Anyway, I would think a median solution to all this could be having the default appdata directory being the name of the pnd file, but if there were potentially conflicts, due to say different versions or whatever, it could fallback to using the name configured within the pxml file.

This isn't really necessary as long as developers creating the PNDs make them well-behaved. According to the PXML spec, the appdata directory name can be specified; it's up to the developer to make it something understandable to the user. dflemstr's PXML archetype gives a little more info on that.

DaveC's problem here was that he tried three different Quake 2 PNDs, each with an arbitrary appdata directory name. As the platform matures, there will hopefully be just one Quake 2 package, and it should have an appdata name of "quake2" or something equally obvious. If there's more than one Quake 2 PND around, hopefully they're all similar enough to be able to share an appdata directory (and hopefully developers make that happen). Then it's just as obvious as you had hoped to make it.

 

[WizardStan]

Support PNDs within zip files. Inside the zip file is the PND file and the appdata folder.

zip files aren't random access. You can't "open" a file in the middle of it, change it (especially not add or remove from it, you may be able to get away with simple character substitution maybe), and then write it back. At least not without decompressing the entire archive or simply blanking out the old file and writing an entirely new one. In the simplest scenario, every time you saved your game, it would have to append the new file to the end of the zip. Your zip file would just keep getting larger and larger. The only way to avoid that would be to decompress the entire archive and recompress it every time you updated a file and that would be disastrous.
There's also a lot of other things that are problematic with the idea of just zipping things up. Trust me, zip is bad.

 

[SomeGuy99]

Support PNDs within zip files. Inside the zip file is the PND file and the appdata folder.

zip files aren't random access. You can't "open" a file in the middle of it, change it (especially not add or remove from it, you may be able to get away with simple character substitution maybe), and then write it back. At least not without decompressing the entire archive or simply blanking out the old file and writing an entirely new one. In the simplest scenario, every time you saved your game, it would have to append the new file to the end of the zip. Your zip file would just keep getting larger and larger. The only way to avoid that would be to decompress the entire archive and recompress it every time you updated a file and that would be disastrous.
There's also a lot of other things that are problematic with the idea of just zipping things up. Trust me, zip is bad.

What about a tar file? Is that random access? The only important part is that the files are bound together.

But that wouldn't work because there's no native support in Windows etc.

 

[WizardStan]

What about a tar file? Is that random access? The only important part is that the files are bound together.

It's the fact that they're bound together that prevents you from being able to edit them. There's no simple way to make a file in the middle of the tar ball bigger or smaller.

 

[SomeGuy99]

What about a tar file? Is that random access? The only important part is that the files are bound together.

It's the fact that they're bound together that prevents you from being able to edit them. There's no simple way to make a file in the middle of the tar ball bigger or smaller.

So what you're saying is that these file formats have to be uncompressed into a cache and then rebuilt?

I see your point.

 

[laurencevde]

A filesystem-image is random-accessible. Any FS could be used. The only dealbreaker is that they don't auto-resize themselves...

Come up with something that's mountable r/w, is reasonably fast, and can autoresize itself when needed, and it's viable. Until then, it's basically a no-go...

 

[DaveC]

Or worse tell a new user why they have to put a pnd file in its own directory

OVer time, I'll still keep it as is -- it makes sense to me; I can back up a single appdata dir and poof, all good

But I can certainly see a place for DaveC's approach; its a philsophical thing -- a user choice, and its equally valid (and the default approach is equally valid!).

--

That said, we just need time to get it; I made a quick hack that works okay, but sudo needs tweaking to be happy with it, and theres some security concerns. If someone wants to (See other thread) propose some changes to sudoers file, thats cool; otherwise oyu'll have to wait for me to get around to it. And package it up into a pnd file to apply the mod. But most of the mod is already done (see other thread.)

jeff

Why is that worse? What is the big deal to put a pnd into a folder? Did we put .GPEs in folders with their data files on the GP2X and Wiz? Yes. Did everyone freak out and walk in confused circles bouncing off of walls holding their aching head because we did that? No. I don't see this huge issue with putting a pnd into a folder. So what? Many times if users are using minimenu they will have icons, OVL, and preview pics in that folder too. I do NOW and I can't even put the appdata in there yet. Adding that appdata in the app's subfolder would be trivial at this point. I almost HAVE to have the pnd in its own subdir for all of the override stuff.

So now the main reason for the mess is to save a few minutes when backing up your card once in awhile? (BTW that appdata may not be as small as you think, PAKs, WADS, ROMS etc are almost always bigger than the executable anyway) That doesn't make much sense. If you do it like that and your card bites the dust you are going to have to not only restore the appdata dir but all of the pnds too, and you better pick the right pnds that went with the right appdata folder or no worky. Or you could just put the SD in a reader, drag the folders into your backup directory. So it takes a few minutes longer, BFD. At least when you restore the card you just grab the folders in the backup spot drag to the card and do something else. You won't have to rebuild anything.

And why couldn't we do this: I mentioned it before but no one commented.

"Couldn't this be as simple as having one override file In a designated spot on the SD that would tell pnds to do it as I said with putting the data dir in the same folder as the app? The pnd would look for this file on startup. (basically a flag saying "I want my appdata with app")If the override is not there it just does it in the one appdata dir as it does now."

 

[mindlord]

Sorry, but if your going to put the PND in some sort of container along with an appdata directory - the only logical container is... [drumroll] ... a directory. Seriously, you guys are thinking too hard.


I'm probably going to regret this later...

*** BEWARE RANT ***
No amount of bikeshedding is going to allow PNDs to replace modern package management. I hate to break it to you guys, but color it any way you want "dropping a file into a specific directory" is still "installing" it as far as I'm concerned. The way it looks now and as simple as PNDs are they are still more complicated and causing more angst than a repository and package manager would've. Torpor explained it well enough that you can use a package management system with removable media and not have things break. Getting a repository online should be a very high priority for you guys right now.

Take a deep breath and ask yourself, which is easier, checking as many boxes for as many applications as you want in a package manager and clicking install. All dependencies for all the selected apps are filled automatically and no duplication of libraries between applications is needed. Or navigating through several pages of website to find the program you want, clicking install, navigate the download path to /media/mmc???/pandora/menu or desktop OR apps, and saving. Going back the the website to search for another application and repeating the whole process X times for each program? I'm afraid that's not forward progress in the Linux world.

The only scenario where this isn't preferable is where the end user doesn't have Wifi, but isn't that why the Pandora supports Gadget Ethernet via USB? So you don't have to sneakernet files via SD cards? Where are the gether drivers at anyways? These drivers are mission critical to persons without wifi or SDHC card readers. If people can't get online with their Pandora's at all there are other solutions, perhaps something like apt-on-cd. Rule #1 in the Linux universe - anything is possible with the right tools and the tools are a click away.

*** END RANT ***

I'm not knocking your work Skeezix, for what they are PND's are great solution to a problem. I know you've put a whole lot of work into them, and it's only natural to defend your work. Truly it is a feat of software engineering to get all those parts to cooperate in that way. PNDs solve a particular problem, but I fear that the problem they solve isn't the one currently addressed. PNDs are perfect what what Craigix has planned for them, a way to track and distribute paid applications. For the free stuff, a repository is clearly the path that makes most sense. I humbly suggest you don't try to shoehorn PNDs into a square best filled with real package management.

 

[MDave]

Preferences seem to be the problem here.

I'm sure it isn't too hard to have some config menu somewhere to ask how they want the data stored. Keep everything as it is, or put all files related to a PND in the same folder.

 

[DaveC]

Take a deep breath and ask yourself, which is easier, checking as many boxes for as many applications as you want in a package manager and clicking install. All dependencies for all the selected apps are filled automatically and no duplication of libraries between applications is needed.

I for one HATE transparent installers that spray files all over (think windows) without me knowing what it is doing.

To me putting a pnd into a subdir on an SD card with my icon files is pretty easy. The appdata dir is a bit messy for my liking but still at least there is nothing hidden going on.

And I am one of those who doesn't happen to be near a wifi spot 24/7.

 

[skeezix]

Mindlord - try not to sidetrack us into that convo, from an entirely valid convo

(I don't need to defend; could rip the whole thing out except for breaking users, for all I care pnds can coexist with a repo if we go there so no big deal. As I repeat.. It's not a competition more to point - I had a lot of issues when experimenting, so someone go try a multi card repo based installer and see how well it actually works, and code up a package manager that asks the user where to install to, handles when dependancies vanish from the other card, etc. Maybe it's fine in practice, *shrug* we built something, it works, if we go another direction, fine by me there's no shame in tossing something out to see if people like it - and they do!

jeffPhone

 

[torpor]

Did you guys look at GoboLinux before you did all this PND nonsense? Just wondering, because Gobo solved this problem ages and ages ago ..

What is GoboLinux?

 

[j6cubic]

Did you guys look at GoboLinux before you did all this PND nonsense? Just wondering, because Gobo solved this problem ages and ages ago ..

What is GoboLinux?

One big problem I see with the way Gobo does things is that you'd need to dynamically rebuild everything in /System/Links every time any vomume is mounted or unmounted. I'm not sure whether that's good for performance. Also, some other locations would have to be constructed via unionfs with the results being unintuitive to the user (such as possibly some applications not working depending on which order the cards where inserted in).

Setting up a system where the only useful storage consists of two removable cards is not easy. No matter what you do you'll always end up with rather nasty hacks. For instance, Gobo does nothing to address the issue of suddenly missing packages. All you get is "the symlinks are suddenly broken", which does nothing to rectify the fact that you have to install the package again. And in certain configurations you can end up with the files being there but the symlinks missing.

I like Gobo's way of going about filesystem management. But it's not going to solve our problems. Self-contained applications (= duplication of all neccessary libraries) are fairly unavoidable in our case if you don't want to burden the user with keeping track of inter-SD card dependencies.

 

[RobertJ]

What I don't get about this whole conversation, is Windows has been doing pretty much the same method of appdata storage since Windows 2000, and anyone who remembers how bloody awful things were before that when instead of a \Users (formerly \Documents and Settings) directory, we had some apps storing stuff in program dirs, others in a Profiles dir under \Windows, should be incredibly averse to going back...

...and Unix/Linux has been doing it for even longer with a /home/username system.

And yet there is a lot of talk about it being a strange Pandora only thing.

Shrug.

 

[Pleng]

The way it looks now and as simple as PNDs are they are still more complicated and causing more angst than a repository and package manager would've.

Not really. It's only a small, very vocal, minority that are are feeling the burn. Most of us love the PND system, and just don't understand the 'problems' raised in this thread.

Anyway this thread is NOT about PND vs Reop. There have been plenty of those, this one has an altogether different purpose.