The software side

pmprog

DNF (Did Not Finish)
Joined
Apr 25, 2011
Messages
3,929
Well, at one time, you need to get the PND, right? That's when you've got internet access
Yes, but not necessarily on the Pyra
Hey, don't start the flame war again. Just say if we agree with the most recent solution and, if not... tell why.
I have no interest in flame wars (Just saying I sometimes download PNDs on my desktop and copy to the SD cards, there's no malice in my tone).I also don't even know what the "most recent solution" is! It's hard to find any real information in this thread, because it's buried by crap.
 

vinipsmaker

Member
Joined
Jun 22, 2013
Messages
209
Location
Brazil
Website
vinipsmaker.github.io
Last edited by a moderator:

moxie

The voice of reason, sense and exasperation
Staff member
Joined
Aug 15, 2006
Messages
2,707
Age
47
Location
South of Sweden
My main mode of operation is downloading pnds to the SD card on my desktop machine. I do realize that things might be different on the Pyra than now, but I'd just like to point out that pmprog is not alone in this.
 

pmprog

DNF (Did Not Finish)
Joined
Apr 25, 2011
Messages
3,929
You guys are introducing too many moving parts to already fragile system.
The problem with design by committee! Although, I'm not sure what's exactly fragile about the PND system?
I think one of the main reasons people download PNDs on desktops is that the Pandora's WiFi isn't always particularly reliable. If the Pyra's is, then it might not be as much of an issue.

At the same time - the idea of putting PND's on SD cards inheritantly screams that you need to be able to copy them without T'internet - because if two Pyra's meet up, one might say "yeah, give us a copy of that app", and bang - copied via SD.

Isn't that the point?
 

Cloudef

Member
Joined
Dec 30, 2009
Messages
460
Location
Gensokyo
@pmprog, the current fragility is that there is not really defined guidelines for packaging PND.

So they are not really self-contained, they just work with current firmware because it's in kind of "frozen" state.

.next for example which aims to be complicant with PNDs already has breakage, so you mostly need to introduce compatibility layer.

iOS (dunno about android) isn't really self contained either.. They just have single framework you dynamically link against (which is imo also bad, since you can't backport features to older iOS versions and it brings more version handling boilerplate to developer). Everything else that is not in the iOS is of course linked statically or the dynlib is included.

Introducing two kinds of "PNDs" is just going to make things more complicated IMO.

I would leave packages that have dependencies stay as .deb and PNDs totally self-contained.
 
Last edited by a moderator:

vinipsmaker

Member
Joined
Jun 22, 2013
Messages
209
Location
Brazil
Website
vinipsmaker.github.io
iOS (dunno about android) isn't really self contained either.. They just have single framework you dynamically link against (which is imo also bad, since you can't backport features to older iOS versions and it brings more version handling boilerplate to developer).
> new device supports GPS

> new Android introduces suppport for GPS

> I made an app that uses GPS

> app requires newer Android version, Android is bad and not self-contained

At least they have a reason.
 

Cloudef

Member
Joined
Dec 30, 2009
Messages
460
Location
Gensokyo
At least they have a reason.
Expect when accesing the GPS api from older android (the library is just layer to the internals).It could return error status for unsupported OS version or something, instead of making developer check for all kinds of OS versions for different code paths.

Most of the library changes in iOS for example are UI elements, which makes no sense to update whole OS for..
 

vinipsmaker

Member
Joined
Jun 22, 2013
Messages
209
Location
Brazil
Website
vinipsmaker.github.io
Expect when accesing the GPS api from older android (the library is just layer to the internals).
API that didn't exist in older versions? This reminds me of the DOS apps. I was reading on the wikipedia and I've read some messy things about how they could use more RAM.

Most of the library changes in iOS for example are UI elements, which makes no sense to update whole OS for..
Yeah... we developers are humiliated by decisions of the marketing team... and we have to take it, because the f****** users.

Things on the OpenPandora community here are different.
 

Cloudef

Member
Joined
Dec 30, 2009
Messages
460
Location
Gensokyo
API that didn't exist in older versions?
Read my post fully. The api doesn't exist and it would notify developer so when he accesses it using the framework.Of course, we don't have such convient frameworks so the situation is much more complex for us.
 
Last edited by a moderator:

pmprog

DNF (Did Not Finish)
Joined
Apr 25, 2011
Messages
3,929

SeeThruHead

Member
Joined
Dec 23, 2010
Messages
112
I'm going to preface this post by saying that I am not a computer programmer, nor a linux user or even a pandora owner. So please feel free to laugh at or ignore this post as you see fit. That being said I am a user of android devices like the nvidia shield and android smartphones and I'm curious why a system that seems to work on these devices could not be borrowed/improved upon for the use of the Pyra.

You could turn PND into self contained offline installers the way I believe apk's are. They could be copied from any pc to sd card and then run from the pandora. The application would be isntalled into the main nand and then the pnd could be deleted. You could then give the user the option (lets say in an application manager) to move the app to an sd card and create a symbolic link from the original location to the moved content. Of course it's more complex than that like moving only data files or code that is specific to that app but you guys would know better than I. Then you have a background process that when the sd card status changes it checks the health of the symbolic links and enables/disables (or shows/hides) apps as necessary. The end result it seems would be a system that seems (to the end user) to work like the current pnd system in most use cases. Is this feasible or is my ignorance about linux preventing me from seeing the flaws?
 
Last edited by a moderator:

_wb_

Microbe
Staff member
Joined
Apr 5, 2012
Messages
5,387
Age
38
Location
Brussels, Belgium
Introducing two kinds of "PNDs" is just going to make things more complicated IMO.


I would leave packages that have dependencies stay as .deb and PNDs totally self-contained.
But what does "totally self-contained" even mean? If you use bash, perl, python, java and ruby, do you have to include all of them and their dependencies? Do you want to statically link against all libraries, even libc? Maybe you need to include a copy of the kernel too, just to be sure...

"Totally self-contained" is not an option. There have to be at least some dependencies. On the Pandora, there were plenty of deps, but they were implicit, which means the firmware cannot really be upgraded without breaking some deps and thus some PNDs. That is not a future-proof solution in the long term, and it is the main cause of headaches for firmware maintainers.

My proposal is to make it explicit what the deps are, so the deps can be handled in a sensible way. It's an extra feature -- you don't have to use it if you don't like it. But if you don't declare deps, you don't get to complain if suddenly your PND no longer works on a virgin firmware since you were depending on something without including it or declaring it.
 

Cloudef

Member
Joined
Dec 30, 2009
Messages
460
Location
Gensokyo
But what does "totally self-contained" even mean? If you use bash, perl, python, java and ruby, do you have to include all of them and their dependencies? Do you want to statically link against all libraries, even libc? Maybe you need to include a copy of the kernel too, just to be sure...
Of course libc and such are backwards compatible by design. There has to be drawn line to somewhere of course.

We discussed on IRC though, and I'm fine with runtime with set of dependencies allowed to be dynamically linked, as long as that runtime is well defined. This way it's not too much hassle to include in different distro either.

My proposal is to make it explicit what the deps are, so the deps can be handled in a sensible way.
I guess this is same as we discussed on IRC?

https://github.com/Pyra-Handheld/TODO/issues/7]https://github.com/Pyra-Handheld/TODO/issues/7
 
Last edited by a moderator:

_wb_

Microbe
Staff member
Joined
Apr 5, 2012
Messages
5,387
Age
38
Location
Brussels, Belgium
I don't like having to define a runtime now, knowing that we will be stuck with it forever. E.g. today it would have to include relatively old versions of GTK and Qt and SDL etc, because they are still used. At some point we may want to get rid of those, but it will be impossible because it will break stuff.

If you are using SDL 1.2 and you can just specify that as a dependency, then even if in 5 years everyone has only SDL 2.4 and SDL 3.0 installed on their device (which could be the successor of the Pyra by then), things will still work because the explicit dependency will tell your device to download the legacy version of the library.

I'm trying to envision a PND format that will still work nicely in a decade or even two. Not something that works fine now, is still OK when the Pyra is released, becomes "meh" a year later and a minor pain in the donkey one year after that.
 
Top