We have the best situation out there, we have the option for both with the current situation.. Performance wise, I like the eMMC solution over uSD..
Even if we get the lowest planned eMMC size of 8GB, I doubt that for just OS related things we would fill it too quickly. I run my omap5 devboard on an 8GB SD card, on my debian armhf install I have a good set of compiling libraries, languages, python, mono..etc and on top of that Libreoffice and other utilities and I haven't even used half of it yet.
It isn't, that was one of the driving factors behind the PND system. If it were easy or practical to install dependencies to removeable media the Pandora would have done it. PNDs were the solution.
It would not be hard to modify the Debian package manager to check the currently visible PNDs and give a warning if you're trying to remove something that is a dependency of one of them.
Yes, that seems like a reasonable default. If the field is missing, assume it depends on everything in the Pandora default install.
I don't see a problem if these cases add up. What are the downsides? The pnds itself would still work, and if a gain in performance is of interest the maintainer will do the update anyway. The only reason I could think of would be security, but I do not see many cases where there may be an interest in having them released as a pnd while security is not a concern at the same time anyway.
I don't see any connection between videos that aren't included anyway and screenshots. The resolution will be higher, but I don't think that will inflate the size that much. Having a screenshot with the size of several megabytes, is a general problem - this problem would also exist with only one screenshot beeing possible to include.My company had such a problem recently: Our marketing department included a 1,5MB company Logo into every E-Mail Signature, which led to the rather comical result that file sizes of the 2xFullHD screenshots (usually <500kB jpegs) people send us where still a lot smaller (in terms of file size) than the company logo we got with the e-Mail too.
Very good idea.
I thought this won't be a problem as the new format would not use the same technique as the current (just "glueing" metadata and the first screenshot and the end of the file) ?
I more into leaving everything that is not absolutely necessary to be untouched. Ideally alterations are only made if they are needed to accomodate for the Pyras hardware differences. Otherwise you will increase the amount of maintenance work, without much (or any) benefit to justifiy it.
I do no think so... We already have abandoned packages, which new maintainers try to improve, which is a mess.
Using the default Debian way of installing and manages packages for PNDs _is_ a big benefit imho.
However I am not sure, whether this would confuse users...
Doesn't that cater to my point ? If new maintainers have a hard time on improving the pnd, it is very much likely that a dependency isn't correctly fullfilled anymore. This would happen regardless of wether the lib remains in the system directly or is contained in the pnd. The difference is that you drive up maintence time as for every update on a lib you need to check wether the pnds that rely on it break or not. And if you find some of those, you need to upgrade their binaries too, which makes things even more complicated and time consuming unless you just want to flag these with something like "will only run unless you did not update since %certaindate%" and be done with it.
I disagree if it results in something that needs a maintainer as soon as code changes are made somewhere higher "upstream" (outside of the Pyras realm).Using the default Debian way of installing and manages packages for PNDs _is_ a big benefit imho.
However I am not sure, whether this would confuse users...
If no one is currently available I have to make due :blink: , thanks for the hintI thought you were disagreeing with yourself until I reread the earlier posts.
If this were always the case we wouldn't have the proverbial "dependency hell" that Linux became infamous for.
Try a Qt 4.0 application under Qt 4.8. How you say it is is how it should be, but in many cases isn't. This gets even fuzzier when applications depend on "unintended" functionality within libraries.
Dependency hell is exactly the problem that has been solved by sufficiently smart package managers that can automate the process of recursively installing dependencies.
If you're relying on undocumented/non-guaranteed functionality of a specific version of a library, you're probably doing something you shouldn't do anyway, but if you insist, then sure, feel free to statically link or include that specific version.
If it can be solved with proper installation ordering then it isn't dependency hell.Dependency hell is installing libfoo1.1, writing an application against that, and then upgrading to libfoo1.2 and finding the application no longer works because the interfaces have changed. Do you keep a copy of libfoo1.1 around? That's how desktops do it, but even at 16GB of internal storage there's still a danger of running out with enough "same but slightly different" libraries. And being able to keep each one separate: if your application just looks for "libfoo" without any nuance to the version (because you assume that upgraded versions won't break compatibility) it doesn't matter what the package manager does, your app will never find the version it needs. You then need to go back and either upgrade to use the new libfoo1.2, or at the least recompile so it looks for a very specific version.
