Pandora Libpnd And Dynamically Linked Libraries

[xweb]

LibPnd is a simple elegant solution so of course I have to make it complicated.
My main concern is that we will have dozens of huge applications with identical statically linked libs just taking up space on a system with limited storage capacity.

So i have just a few suggestions.

what if we just use a pnd file to make a bunch of popular dynamic libs available to other apps. this would reduce the average file size for other pnd's and cut down on duplication.

if we do a "lib.pnd" package in releases we could constantly update it with the newest available libs for that release. This way most application being developed at the time would most likely use the current official lib.pnd package for development. in addition pnd's that require older libs could be stored on sd card that contain the old "lib.pnd" file.

one off or cutting edge libs could still be statically links with the app.

draw backs:
this would make Pandora development a bit of a moving target.
solution: you can still statically link for maximum compatibility. or use the hybrid static / dynamic solution mentioned above.

some one would have to maintain the "lib.pnd" and make decision as to what libs should be includes ( we don't want the lib.pnd becoming a space hog it self).

possible compatibility issues with non pnd apps or os's without pnd support.


Is some thing like this possible?

also i was wondering if i could put pnd's on usb storage and still have them detected/loaded?

and lastly how well does libpnd scale, would a hundred apps on a sd card bring the system to a crawl while it loads?

(i know there is a feature freeze so this would not likely be implemented by launch)

 

[Kramy]

I really don't care, to be honest. Bring on the dozens of duplicate static libs!

Hey, it works for Windows, so why not? Virtually every game stuffs dozens of dll files into its directory. :lol:

As long as you have an 8GB-32GB card, it should be a non issue.

 

[torpor]

what if we just use a pnd file to make a bunch of popular dynamic libs available to other apps. this would reduce the average file size for other pnd's and cut down on duplication.

Yeah, I have an idea: why don't you coordinate the static libs needed with the guys building the OPERATING SYSTEM, where this sort of thing is usually addressed. Unless you want to build a custom bootloader for .PND files, and maybe a little micokernel, and maybe a few other small 'user space' apps for internally managing the PND filesystem, and ..

Look, PND is a bandaid for not having a well-managed OS team. Please don't use that bandaid for anything more than covering up a few bloody sore spots. Instead, coordinate the effort with the guys making PandoraOS to make the entire system as developer- and user- friendly as possible. There isn't much reason for PND to expand into OS territory, other than the OS isn't being managed properly ..

 

[Squidge]

if we do a "lib.pnd" package in releases we could constantly update it with the newest available libs for that release. This way most application being developed at the time would most likely use the current official lib.pnd package for development. in addition pnd's that require older libs could be stored on sd card that contain the old "lib.pnd" file.

So we are back to loads of posts of "I've download X and it doesn't work on my device" with replies of "Download the latest library pack". It completely violates the "Just throw the PND on your SD card and your done" principle of things.

Besides, the OS will ship with a load of library files and apps can dynamically link to these, so apps are not going to be 5GB each. More like several hundred KB, and since the limited storage is 64GB, I don't think we need to worry just yet.

 

[Rockthesmurf]

I think Jeff's suggestion of just trying to use the current system 'as is' is a really good one - there are lots of suggestions of how it could be improved, or how it could be done differently - and it is great that we have lots of people wanting to contribute (if only ideas), but until we have the system up and running, and being used, it is hard to know what actually needs doing. I'm sure if there are any major issues they'll get dealt with as they come up - but at least for the time being I love the fact the system doesn't have any shared libraries/dependencies/etc. I'd much rather spend $x.yz to get an extra XX GB of SD storage if it saves all the headaches of dependency hell.

Steve

 

[skeezix]

Its an observation I've made -- if some spec/tool sytarts 'too complex', it is harder to adopt; if it starts functional, it can take off and then grow. More importantly, an old software rule (from Knuth) is to avoid early optimization, since the side effect of optimization is complexity, and if you optimize before you know actual usage data points, you likely end up complicating stuff that needn't have been optimized anyway.

Likewise, lets see if we can get pnd to take off, and get it into dev hands, before we try making it more ocmplicated and hard to use

That said, we have planned ahead for this sort of thing; it would be pretty easy to add to the system that pnd's in a certain searchpath will be pre-mounted at boot-time, and left booted; we could even union them into important places like /usr/lib to make it invisible to apps, but I'm thinking more along the lines of mounting them into /usr/pandora/lib or /usr/local/pandora/lib or somesuch. So boot yoiur device, it scans (say) SD cards for /pandora/libs, and any pnds there are mounted and _left mounted_, where apps can then find them.

However, this adds a _user complexity_ (not so much code complexity since most of the bits are already in libpnd for this), as others point out; you run into 'my app depends on this other pnd, and doesn't work!, or versioning issues.

With size being less and less important over time (giant SDHC cards etc) it is usually better to 'just make it work' (include what is needed.)

Caveat: If a lib becomes so handy, used by a few popular apps, then the firmware can just get it inclueded as a patch, and thus available to everyone. That is a _much_ more reliable system, since people tend to follow fw patches, and thus everyone has a consistent common set of libs.. not random dependancies.

Anyway, we can sort it out later, but we're on top of it

jeff

edit: I'll put a note or copy of this post in the libpnd-hub on the wiki.

 

[skeezix]

Added a couple sections to the libpnd-hub:

http://pandorawiki.org/Libpnd_hub#A_note_on_including_shared_libs

http://pandorawiki.org/Libpnd_hub#Future_idea:_pnd.27s_for_containing_system-wide_shared_libs

Wrote 'ewm quick, but hopefully reads okay and makes sense (and is agreeable

As I said, not too hard to build onto the system.

jeff

 

[dflemstr]

Caveat: If a lib becomes so handy, used by a few popular apps, then the firmware can just get it inclueded as a patch, and thus available to everyone. That is a _much_ more reliable system, since people tend to follow fw patches, and thus everyone has a consistent common set of libs.. not random dependancies.

I think that the IPKG system needs as much explaining as the PND system does (but that's not your/the OP team's responsibility of course). Because IPKG will play an essential role in the system, and no one seems to be aware of it.

BTW, by "patch", do you mean an actual binary patch (generated by "diff" etc), or an IPKG update package? Just to make that absolutely clear. Also, are there provisions for applying such patches/updates automatically, so that we are able to actually expect an user to download them once in a while? And how does this system relate to the "<osversion>"? Should there be a "/etc/pandorafwversion" file that libpnd compares the PND entry to, and that file is updated by the official Pandora firmware package? Could libpnd, if someone adds a PND that is incompatible with the current OS version, show a GUI that downloads the new patch automatically? etc.

 

[skeezix]

By patch, I do mean ipkg; I believe djw/ED have a repository set up (and unused yet of course), where firmware images, 'patches', and other important updates or applications in ipkg format can live, but to-be-defined-later I'm sure.

I've not worried about <osversion> and such yet -- figuring we as a community need to worry about repositories, on-device clients and so on at the same time; yourself and a few people are mulling such thins in their heads, so I'm not sweating it. But yeah, I have thought of doing a thing where osversion is 'well defined', and then a pnd-validator couild kick up once in awhile on pnd-run time to say 'hey, we see your osversion is < pnd-os-version, so maybe you want to update?' or 'this pnd is not verified for this os-version' .. but those sorts of things tend to be very tenuous and annoying and goofy -- if an app works with many versions of the OS, but not others, etc.

So as per my other stances .. avoiding worrying too much up front about it, until we have a stable system and more data. At the same time, perhaps we need to hard-define <osversion> very carefully so that it can be useful, etc. *shrug*

Ahh, to have the free time to really make a full end to end system ...

jeff