Internal memory will still be limited, just not as much as on the Pandora (and this will always be the case for mobile systems, at least comparatively more so than in stationary ones). Therefore everything is still a PND candidate. IMO especially large optional components like office and development tools, though there is now the additional option of using the distributon (or other repository) provided package.
Why should the internal memory be limited ? The last news in that regard where, that either NAND or an MicroSD-Card can be used as non removeable storage. While theoretically everything is a pnd candidate, I doubt, that many applications, readily available in the debian repository, will see a rerelease as a pnd. There may be some, but especially non games with often times slow release cycles won't generate much interest on taking on the struggle - especially if they are rather "hard" to handle and transition into a pnd has some drawbacks (like it is with Firefox currently, no offense, hdonk).And even with development tools and the rare heavier packages (like Liobreoffice), I doubt you will fill up your NAND quickly. Media (gfx, audio, video) are the ones that will eat away the internal storage, so games is the real factor, which are inherently are a lot more viable candidates:
Being distributed as a PND has nothing to do with being optimized for the system. A Pyra .deb package repository will exist just like now a Pandora .ipk one exists which distributes specially adjusted versions of standard packages.
Just a matter of how you see things. For the reasons given above, I see only applications/games with a fast release cycle, or that need rather heavy adjustments,that won't make it upstream, (I.E mostly games) to be likely candidates for someone to create and maintain a pnd.And there is also the possibility to create custom debian packages and distribute them, if the debian repo only offers a rather outdated version of an application/game
Looking into my crystal ball..
Mines from a different manufacturer. I see a lot less use of pnds.
That's exactly all I mean - newer versions of libs with bug fixes get released. We've been significantly protected from that on Angstrom versus how it will be on Debian, as we managed to pick a dying platform, but on Debian things will get updated all the time and dependencies on newer stuff will get baked into all sort of components. I guess there's still a lot of scope for games that only vaguely depend on SDL versions and so on, and indeed aren't typically distributed via the Debian repositories.
Some of the recent PNDs do take rather a long time to download though, so if libs from those could be migrated to the update repos then that's an improvement as I see it, though upgrading existing libs might cause issues for older games and software, as the SGX video driver does occasionally (though that's largely down it it being closed source, and should be less of a problem with open source libs hopefully).
But won't that be a problem then in the future, negating the pnd idea? If you think that essential libraries are updated a lot more frequently than it is now, wouldn't that lead to the conclusion that in order to keep some sort of "plug and play" functionaliy left for pnds, you have to include even more libs into a pnd? Otherwise people would need to constantly keep their system up to date to make sure they can run the latest things released on the repo.
That or have an automated incremental diff mechanism.
Seems a lot more reasonable to hope someone implents this than hoping that every single dev interested in the plattform is willing/able to pull of modularizing their work.
Also I'm not in favor of redundantly including copies of general-purpose libraries inside the package (or using statically linked binaries), not so much because of the size overhead, but mostly because that makes it impossible to have an update/bugfix of such libraries without having to update all packages that depend on it. Imagine a crucial security bug in libpng or libssl or whatever -- if it can be fixed just by updating the library, it's not that big of a deal, but if you also have to hope that all authors of all packages that depend on it will repackage their stuff, then it may take ages before the problem is solved. Some of this could be somewhat solved by having an automatic compilation+packaging system (cf. what Cloudef is doing), but even then you still get the annoying problem of needing to re-download potentially a lot of packages each time a widely used library gets updated. Of course if you're using very specific libraries that are not worthwhile to have installed globally, it's something else.
How often will that happen in reality (I have no experience with debian) ? And I don't see a need for every package beeing updated with new lib version. If the whole package still works, why change something in it ? There could be security concerns, but how many applications/games will affect that?
Finally I think not all of the metadata should be included in the package itself. Of course the textual metadata, the icon, and perhaps one screenshot should be inside the package. But the rest of the screenshots, and perhaps videos or whatever, they should not be included in the package itself. There simply is no point in that. You want to look at those screenshots (and videos and whatever) before you download the application, and once you've downloaded it, you don't need them anymore. They should be hosted only on the repo server, and it should be possible to update them without having to modify the package itself.
I disagree. While things like videos unneccesarily increase the size of a pnd, I don't see any reason to limit the amount of screenshots - what harm is done by including several kbs of pictures ?
It depends on how big they are. The NAND is only 2GB. Perhaps there should be no NAND at all, and instead a MicroSD card.
Where does this number come from ? The last time people were throwing arguments at each other about that topic, Ed leaned more towards 16GB, while some community member wanted to slap the extra money needed for 32GB onto the sales price
On the Pandora space is very limited so it was reasonable to put in only the very basics in the pre-installed system. But if we have 2GB or 4GB to work with, it becomes harder to make a partition between what is "useful enough" to put in the base system and what is "too exotic" and should be put in the PND instead. E.g. which of the interpreted (or runtime-requiring) programming languages do we need to put in the base system? Probably bash, perl, python again. Probably also Java. What about Lua? Ruby? Haskell? Erlang? Common Lisp? Scheme? ML? Scala? Prolog? Mercury? Oz? PHP? Tcl? etc etc
Where do you put the cut-off? It's impossible to predict the future and know now which one of these will turn out to be the most important.
While you cerntainly can't predict the future, you can at least make estimations about what will be commonly used, this is no new territory here, most conclusion could be drawn from experiences on desktop debian installations and the content of pnds currently on the repo.