Auto-Mounted Pnd Files?

[WizardStan]

Adding pnd support to other distro is -easy- - just build libpnd and poach pndnotifyd.

sdl has sound . Lib sdl sound is not part of sdl, it is someones random extension with mp3/etc decoding. It was an example of... We have tonnes of common libs in panda distro, but no distro has all possible libs.

Jeffphone

Ok. I'm not familiar with this "sdl sound" extension library you're talking about. I thought you meant the built in "grab a channel and send some data across it" sound that the SDL library has.

 

[mindlord]

Adding pnd support to other distro is -easy- - just build libpnd and poach pndnotifyd.

sdl has sound . Lib sdl sound is not part of sdl, it is someones random extension with mp3/etc decoding. It was an example of... We have tonnes of common libs in panda distro, but no distro has all possible libs.

Jeffphone

Ok. I'm not familiar with this "sdl sound" extension library you're talking about. I thought you meant the built in "grab a channel and send some data across it" sound that the SDL library has.

There is a SDL extension called SDL_Sound that adds extra functionality like volume control, sample splitting, and other handy, but not altogether necessary functions. It also adds mp3 decoding, midi and mod support. There are a fair share of games that use it, but it's not as widely accepted as OpenAL.

 

[WizardStan]

There is a SDL extension called SDL_Sound that adds extra functionality like volume control, sample splitting, and other handy, but not altogether necessary functions. It also adds mp3 decoding, midi and mod support. There are a fair share of games that use it, but it's not as widely accepted as OpenAL.

And I assume they intentionally named their extension to be ambiguous with the actual SDL audio library? Instead of something that makes it an obvious distinction, like "Sound Plus" or something? Bah. (Yes, projecting my ignorance and blaming it on others is unhealthy. Shoot me later )

 

[rabidpoobear]

There is a SDL extension called SDL_Sound that adds extra functionality like volume control, sample splitting, and other handy, but not altogether necessary functions. It also adds mp3 decoding, midi and mod support. There are a fair share of games that use it, but it's not as widely accepted as OpenAL.

And I assume they intentionally named their extension to be ambiguous with the actual SDL audio library? Instead of something that makes it an obvious distinction, like "Sound Plus" or something? Bah. (Yes, projecting my ignorance and blaming it on others is unhealthy. Shoot me later )

That's how pretty much all of the SDL extensions are named though, SDL_ttf for true type fonts, etc.

 

[WizardStan]

That's how pretty much all of the SDL extensions are named though, SDL_ttf for true type fonts, etc.

SDL doesn't have any sort of font library built into it, as far as I know. It does have a basic audio library, however, causing questionable ambiguity.

 

[Lozrus]

SDL doesn't have any sort of font library built into it, as far as I know. It does have a basic audio library, however, causing questionable ambiguity.

Smaller dependencies (single libraries etc.) can be included as part of your game/app PND release anyway (either statically compiled, or by including an so) so it's not such a big deal if (for example) sdl_mixer is missing from the base OS. It seems to be more of a problem for really large dependencies (like Mono, Java, QT etc) and general OS enhancements (adding command line tools, help files).

Of course, anyone who is comfortable with Linux can install these on SD somehow, but I want my .NET games to be easily acessible to anyone and so would really like to provide a "Mono.pnd" package somehow. It would be great to be able to say "drop the 'Mono.pnd', or 'Java.pnd' onto your SD and you will be able to just run and .NET or Java based pnd packaged games".

I will package up Mono anyway and see how easy I can make its installation. It will be a good learning experience and maybe I can contribute something more useful to this converstation afterwards.

 

[Pleng]

Well I guess you could make a little script inside your PND that uses libPND to check for the presence of MONO. If it's not there a little messagebox could come up saying 'You need to have the MONO PND installed to run this game', if it is go ahead and run the game with MONO.

(hmm I guess that would mean you'd have to mount the MONO PND from within your game. Is that doable?)

 

[Lozrus]

Well I guess you could make a little script inside your PND that uses libPND to check for the presence of MONO. If it's not there a little messagebox could come up saying 'You need to have the MONO PND installed to run this game', if it is go ahead and run the game with MONO.

(hmm I guess that would mean you'd have to mount the MONO PND from within your game. Is that doable?)

Nice idea! I was thinking of just putting all of the Mono related files in a set location on SD with a launch script in my game/app PND to enable it (trigger a script in the Mono folder to set-up paths, environment vaiables or whatever is required). But keeping Mono in a single PND package is definitely the goal. I'm very interested in the viability of this, I guess it's just a user permissions issue which would probably apply either way.

I really like the idea of PND's searching for other dependency PND's and activating them as required.

This must be of interest to Java developers too. Maybe even more so as it could allow them to easily use different Java VM's for different games to get the best speed/compatibility. Same for any other runtime environments/interpreters etc.

This seems like a good way to solve the Mono/Java dependency issue. As a solution to the help files/extra command line tools/OS enhancements issue, why not support an "Autorun" folder in the SD structure as well as the "Menu" and "Desktop" options that have been demonstrated? This means the user has to make a choice (it's not as dangerous as any PND being able to automount) but it is much easier to manage than permission pop-ups etc.

 

[skeezix]

You could mount a pnd from within a pnd .. Just use pnd_run.sh

but yeah, more to do as we go

jeff

 

[ashdjones]

Of course, anyone who is comfortable with Linux can install these on SD somehow, but I want my .NET games to be easily acessible to anyone and so would really like to provide a "Mono.pnd" package somehow. It would be great to be able to say "drop the 'Mono.pnd', or 'Java.pnd' onto your SD and you will be able to just run and .NET or Java based pnd packaged games"

Think about the road you're heading down: ie. a new layer of dependency hell. Is this fun for a user? You'll be effectively breaking the uniformity of drag-drop-execute in regard to PND files. It just adds headaches for people as they try to keep track of it all.

To conserve SD space, why not this:

An application, possibly as part of the firmware will scan an SD card and look at the contents of all the PND files. It will take any duplicate libraries and place them in Another PND/Mounted Folder or whatever (which is the whole point of this topic anyway) and remove the one from the PND.

Perhaps this can be presented a Free-Space creating utility that pops up when an SD card gets full?

 

[Lozrus]

Think about the road you're heading down: ie. a new layer of dependency hell. Is this fun for a user? You'll be effectively breaking the uniformity of drag-drop-execute in regard to PND files. It just adds headaches for people as they try to keep track of it all.

Having a Mono.pnd maintained by a single person (in the case of Mono, I will attempt to do this) which .NET based PND's can depend on seems to be a perfect way of avoiding dependency hell. I also think it makes things as easy as possible for the user.

I think you may have been responding to the first half of my post (although you didn't quote it) about including smaller dependencies within individual game PND's. This does make your PND's larger (so I suggest is only for small libs) but it actually avoids dependency hell as it means that your application is being shipped with exactly the library version it has been built and tested against. Therefore, no dependency issue and it is as easy as possible for the user (i.e. they dran and drop their PND and it just works).

To conserve SD space, why not this:

An application, possibly as part of the firmware will scan an SD card and look at the contents of all the PND files. It will take any duplicate libraries and place them in Another PND/Mounted Folder or whatever (which is the whole point of this topic anyway) and remove the one from the PND.

Perhaps this can be presented a Free-Space creating utility that pops up when an SD card gets full?

This could actually cause a form of dependency hell. What happens if a developer needs a particular library built in a special way (maybe with options that are not usually compiled in, or experimental features that should not be available system-wide) and so builds their own version and includes it in their PND. This tool would then delete the custom library and point the developers application at a generic version, probably not ending well. Plus remember that most developers who include dependencies inside their PND will statically compile against them so this space-saving tool would probably not find many matches anyway.

Of course, including generic dependencied inside indivitual game/application PND's is wasteful of space. And so I would hope to see the common dependency sets spun off into some common PND's anyway. Obviously this includes Mono and Java, but also SDL extras, Allegro etc.

 

[ashdjones]

Think about the road you're heading down: ie. a new layer of dependency hell. Is this fun for a user? You'll be effectively breaking the uniformity of drag-drop-execute in regard to PND files. It just adds headaches for people as they try to keep track of it all.

Having a Mono.pnd maintained by a single person (in the case of Mono, I will attempt to do this) which .NET based PND's can depend on seems to be a perfect way of avoiding dependency hell. I also think it makes things as easy as possible for the user.

I think you may have been responding to the first half of my post (although you didn't quote it) about including smaller dependencies within individual game PND's. This does make your PND's larger (so I suggest is only for small libs) but it actually avoids dependency hell as it means that your application is being shipped with exactly the library version it has been built and tested against. Therefore, no dependency issue and it is as easy as possible for the user (i.e. they dran and drop their PND and it just works).

To conserve SD space, why not this:

An application, possibly as part of the firmware will scan an SD card and look at the contents of all the PND files. It will take any duplicate libraries and place them in Another PND/Mounted Folder or whatever (which is the whole point of this topic anyway) and remove the one from the PND.

Perhaps this can be presented a Free-Space creating utility that pops up when an SD card gets full?

This could actually cause a form of dependency hell. What happens if a developer needs a particular library built in a special way (maybe with options that are not usually compiled in, or experimental features that should not be available system-wide) and so builds their own version and includes it in their PND. This tool would then delete the custom library and point the developers application at a generic version, probably not ending well. Plus remember that most developers who include dependencies inside their PND will statically compile against them so this space-saving tool would probably not find many matches anyway.

Of course, including generic dependencied inside indivitual game/application PND's is wasteful of space. And so I would hope to see the common dependency sets spun off into some common PND's anyway. Obviously this includes Mono and Java, but also SDL extras, Allegro etc.

No. What I mean is 'another layer' of dependency. For example, can I just install said PND file? No, I need to go off and install MONO.PND. You've just traded the original layer of dependency - the application/library level - to a new one based on PND packages.

It sounds straightforward in theory, but surely packages such as this MONO.PND will be updated over time to reflect changes in the libraries within. Then you have versioning to deal with. The user has to keep track of which version of MONO.PND to use - a lot less simple than just drag-drop-execute.

For the 'disk usage saver' app I would imagine - although very time consuming to carry out - how about it does a binary level analysis to determine if each library is indentical or just simply shares the same name. The only disadvantage I can foresee is that the generated 'DEPENDENCY.PND' which is automounted cannot be deleted without breaking all the other PND files that have been modified and linked to it. It would be nice if the procedure could be reversed (perhaps using a database to track all the PND changes) and the PND files are restocked with their original libraries (and possibly the DEPENDENCY.PND is deleted).

 

[Lozrus]

No. What I mean is 'another layer' of dependency. For example, can I just install said PND file? No, I need to go off and install MONO.PND. You've just traded the original layer of dependency - the application/library level - to a new one based on PND packages.

It sounds straightforward in theory, but surely packages such as this MONO.PND will be updated over time to reflect changes in the libraries within. Then you have versioning to deal with. The user has to keep track of which version of MONO.PND to use - a lot less simple than just drag-drop-execute.

Ok, I see your point, and I partially agree. I'm a big fan of distributing dependencies within the package (where it makes sense). It's a lot like the PC BSD package system which works well. I'm only contributing to this thread because I want to develop with C# and I want my games to be as easily installable as possible. However, I really think that there needs to be an alternative for very large dependencies. I can't really seen anyone downloading a 30Mb PND with a 100kb .Net game and entire Mono framework (made up figueres, the reality may be better or worse than that example).

I agree that versioning is absolutely an issue which developers need to consirer. But my proposal is not much different from the situation on desktops today. Users still need to install the correct .NET framework version, or JVM before they can use .Net or Java apps. Bundling this as a PND just makes it that much easier to install/remove.

Anyway, Skeezix has suggested pnd_run.sh which I think will be enough for me to get started doing things my way. I'll definitely have a go and see how it turns out.

I honestly doubt that a dependency scan/move tool can work effectively (at least without a LOT of effort). And I suspect that the appearance of DEPENDENCY.PND would be just as confusing to users as any error message asking them to install Mono.PND. But if you are considering developing it then it would be interesting to be proven wrong, and pretty cool to see it working.

 

[ashdjones]

Ok, I see your point, and I partially agree. I'm a big fan of distributing dependencies within the package (where it makes sense). It's a lot like the PC BSD package system which works well. I'm only contributing to this thread because I want to develop with C# and I want my games to be as easily installable as possible.

Yeah, this is the problem. You want to minimise the work for users but bloated file sizes for software is bad.

However, I really think that there needs to be an alternative for very large dependencies. I can't really seen anyone downloading a 30Mb PND with a 100kb .Net game and entire Mono framework (made up figueres, the reality may be better or worse than that example).

Maybe we should just consolidate all of these frameworks and soforth into a few really big files? They would be patches for the firmware?

And for people who want more power: each patch can be split up into smaller parts. So you choose to install the big patch (has everything), or the little ones. Then for the software entry you can just put 'requires firmware patch 3' or something in the description?

But if you are considering developing it then it would be interesting to be proven wrong, and pretty cool to see it working.

Unfortunately I don't know enough about Linux and how it works under the hood... I'd really love to learn though.

 

[shadow.8]

Adding pnd support to other distro is -easy- - just build libpnd and poach pndnotifyd.

Thanks, I had assumed this all along, just wanted to be sure of myself.

 

[skeezix]

Removing from pnd is bad.. So far all changes go to appdata folder via the aufs union we do.. Rebuilding a on on the fly just means you've now go broken pnds if anyone else copies them

on one hand we're talking 8gb sdhc cards so why worry over a little duplication? It's the big grtuitous dupes to avoid, but let's def avoid giant dep chains

but I could see one giant mono pnd they several pnds depending on.. Just 1 pnd dep. The problem is versioning, and people needing additional mono libs .. A mesh dependancy ... Must be careful

but I can't say much.. Surrounded by screaming kids at indoor playground right now

jeffphone

 

[ashdjones]

Removing from pnd is bad.. So far all changes go to appdata folder via the aufs union we do.. Rebuilding a on on the fly just means you've now go broken pnds if anyone else copies them

Yeah. In this state you could say they have been converted, or 'operated upon' but so long as the procedure is reversable then I don't see an issue. It's something that would be useful further down the line when we've all crammed our 16gb cards to the max. It could be an alternative to choosing which PND files to remove. I would see it a 'power user' option.

 

[Lozrus]

Maybe we should just consolidate all of these frameworks and soforth into a few really big files? They would be patches for the firmware?

And for people who want more power: each patch can be split up into smaller parts. So you choose to install the big patch (has everything), or the little ones. Then for the software entry you can just put 'requires firmware patch 3' or something in the description?

Definitely, a statically compiled in library here adds too small an overhead to worry about (i think that most GP2X binaries statcally linked to better versions of SDL). It's just the big stuff that worries me. For ease of use I would hope that any Mono dependent PND will throw up a clear message when run if Mono is not present (clearly explain what file you need and where to get it from, maybe a direct link to the file on Pandora App Store is allowed).

Advanced users can do whatever they like, that's the beauty of Linux, I'm not too worried about them

but I could see one giant mono pnd they several pnds depending on.. Just 1 pnd dep. The problem is versioning, and people needing additional mono libs .. A mesh dependancy ... Must be careful

That's exactly what I will attempt to do for Mono. We can see how it works out.

but I can't say much.. Surrounded by screaming kids at indoor playground right now

Join in, be a screaming kid too and forget about PND's for a while

 

[ashdjones]

Okay, so I did a really ropey diagram to elaborate on this hypothetical 'SD space saving app'.

 

[dflemstr]

Dudes, take a look at Haiku's "packagefs" or the old thread we had about this exact issue a couple of moths ago. It's all been discussed before.