The software side


Guys, if you are serious about helping notaz, why not starting to show what you can do with the current Pandora that can be reapplied to the Pyra later on ? Otherwise you are just talking the talk but not walking the walk.
The point was to start working on the firmware for the Pyra now so that they aren't hurrying to get it done last minute when release rolls around. Telling them to work on the Pandora until they've "proven themselves" is just wasting time they could be developing for the Pyra to prevent said last minute scenario.

-God Ginrai
 
The point was to start working on the firmware for the Pyra now so that they aren't hurrying to get it done last minute when release rolls around. Telling them to work on the Pandora until they've "proven themselves" is just wasting time they could be developing for the Pyra to prevent said last minute scenario.
 

The point is that there's tons of things you could start working on with the current Pandora to be reapplied later on, on the Pyra. System tools, upgraded PND system, etc... can be done even if there is no physical Pyra available, and benefit both platforms. 

It's not just about "proving yourself", it's more like "what are you guys waiting for ? There's already a platform where you could do stuff and close to nothing is happening, so why should we take your word you'll do anything on the Pyra" ?
 
The point was to start working on the firmware for the Pyra now so that they aren't hurrying to get it done last minute when release rolls around. Telling them to work on the Pandora until they've "proven themselves" is just wasting time they could be developing for the Pyra to prevent said last minute scenario.
 

The point is that there's tons of things you could start working on with the current Pandora to be reapplied later on, on the Pyra. System tools, upgraded PND system, etc... can be done even if there is no physical Pyra available, and benefit both platforms. 

It's not just about "proving yourself", it's more like "what are you guys waiting for ? There's already a platform where you could do stuff and close to nothing is happening, so why should we take your word you'll do anything on the Pyra" ?
What do you objectively have against this topic?

It's difficult to understand your point. We are wasting time trying to prepare a plan and follow the plan (action) and you argue that we should stop what we are doing (action) to make some... action!

We can run Debian on the current OpenPandora, so it'll be easier to test our changes to the future Pyra handheld. Whatever.
 
We are wasting time trying to prepare a plan and follow the plan (action) and you argue that we should stop what we are doing (action) to make some... action!

Strawman. It's not what I said at all. Learn to read.

The guys who want to work on the Pyra already have open docs for the existing OpenPandora and yet are not doing anything on the firmware level. What's holding them ? So what can we actually expect from them if notaz opens up his plans for the Pyra ? Lots of discussions with nobody but notaz doing the actual work ? 
 
Last edited by a moderator:
The guys who want to work on the Pyra already have open docs for the existing OpenPandora and yet are not doing anything on the firmware level. What's holding them ? So what can we actually expect from them if notaz opens up his plans for the Pyra ? Lots of discussions with nobody but notaz doing the actual work ?
 I'm new to the community and I haven't lost the faith yet.

But moving on... I don't think the current OpenPandora PND's system will be replaced by the PND's successor. Too low internal space for a Debian install + chroot's compatibility.

I don't know what are the OpenPandora firmware's issues (besides the lacking of documentation inherited by OpenEmbedded system). The only problems I'm aware are the ones that affect me and I've sent pull requests on github to solve them.

Can you elaborate what are the current issues that should be worked on?
 
Can you elaborate what are the current issues that should be worked on?
The current PND system is still lacking (files extension support has only been recently added but can probably be improved, default applications -> linkage with specific PNDs is still non-existent in xfce) and its development is open (libpnd is on github as far as I can remember) yet the only person who actually works on it once in a while is skeezix, and he does not have much free time. 

The work on the DSP was more or less done by two people (bsp and notaz). 

I fail to see a large community of people actually developing stuff for the firmware together, no matter how open it is. I'm not saying we shouldn't, but that's simply a fact.
 
The point is that there's tons of things you could start working on with the current Pandora to be reapplied later on, on the Pyra. System tools, upgraded PND system, etc... can be done even if there is no physical Pyra available, and benefit both platforms.
 Not really. A lot of things will change moving from Angstrom to Debian. It would be better to start building those tools for a debian system so you didn't have to hack around with them to get them working correctly with the new system. It's all about a strong foundation.

It's not just about "proving yourself", it's more like "what are you guys waiting for ? There's already a platform where you could do stuff and close to nothing is happening, so why should we take your word you'll do anything on the Pyra" ?
 "Don't talk the talk if you can't walk the walk" is an idiom specifically referring to someone needing to show (or prove) that they can do (or start doing) what they are talking about. If you did not mean this, then you should not have used this idiom.

The guys who want to work on the Pyra already have open docs for the existing OpenPandora and yet are not doing anything on the firmware level. What's holding them ? So what can we actually expect from them if notaz opens up his plans for the Pyra ? Lots of discussions with nobody but notaz doing the actual work ?
So you're saying that aTc's work on .next is nothing? Or Cloudef's work on libpndman is doing nothing?

With a quick glance through the commit history in the git repo, I see some commits from Cloudef and sebt3:

2011-09-02 Cloudef Fix leaks on discovery test commit | commitdiff | tree | snapshot
2011-09-02 Cloudef Fix even more leaks commit | commitdiff | tree | snapshot
2011-09-02 Cloudef Add version && package version support to discovery commit | commitdiff | tree | snapshot
2011-08-27 Grazvydas Ignotas get rid of EOL spaces commit | commitdiff | tree | snapshot
2011-08-27 Cloudef Fix leaks on libpnd commit | commitdiff | tree | snapshot
2011-08-04 Grazvydas Ignotas pndevmapperd: add unexpected charge stop workaround commit | commitdiff | tree | snapshot
2011-08-04 Grazvydas Ignotas pndevmapperd: don't do charge control too often commit | commitdiff | tree | snapshot
2011-08-04 Grazvydas Ignotas pndevmapperd: don't blink when charging up commit | commitdiff | tree | snapshot
2011-06-20 Grazvydas Ignotas pndevmapperd: add basic charge control commit | commitdiff | tree | snapshot
2011-06-13 sebt3 Merge branch 'master' of ssh://openpandora.org/srv ... commit | commitdiff | tree | snapshot
2011-06-13 sebt3 add /sbin/ to each losetup call as it seems to be missi ... commit | commitdiff | tree | snapshot
2011-06-08 Michael Mrozek /conf/desktop: Changed document viewer to links commit | commitdiff | tree | snapshot
Honestly, you're accusing these people of doing nothing when they have done things, and it's really disrespectful. If you're not going to contribute anything constructive to the conversation, you might as well just excuse yourself from this topic.
-God Ginrai
 
Last edited by a moderator:
I am following this discussion a little and wonder what the real use case of PNDs is and how to find a solution just for what the PNDs are really needed.

In my (quite distant) view (please correct me if I am wrong) PND is a system to enable using removable media (SD cards) like ROM cartridges for consoles. This means the code on the SD card is more or less bundled and self-contained and after insertion into the SD slot it gets automounted and adds itself to the menus. On eject those things are undone.

With Debian the architecture would be that the basic system that is permanently on the device in internal memory is installed/modified/extended by apt-get install.

But stock Debian has no such automount mechanism as I think we need.

So there should be some daemon that monitors for newly inserted SD cards, checks for "PNDs" and does what is instructed by some control file within the PND bundle. This can even include some .deb package and instruct the system to install it. Or can do something else. So that insertion of a SD card adds the PNDs to the system.

This PND manager itself would just be another .deb package that can be installed through apt-get install on top of the Debian system.

If we do this in a clever and general way, it has even a chance to become an official part of the Debian system.
 
Last edited by a moderator:
Honestly, you're accusing these people of doing nothing when they have done things, and it's really disrespectful. If you're not going to contribute anything constructive to the conversation, you might as well just excuse yourself from this topic.
Mouhaha, if you look at the git repo for the last 12 months, only Cloudef has done anything apparently, so sorry if I didn't mention him, but it's hardly a "large and active community" working on the firmware stuff right now, unless you have a better way to interpret that.

https://github.com/Cloudef/libpndman/compare/master@%7B1.year.ago%7D...master 
 
So you're saying that aTc's work on .next is nothing?  
 

Even for aTc on the .next thread, great job that he did (mostly by himself, again) -but how many community members tried it ? I bet it's less than 10, based on the feedback on the thread. You don't build an OS without sufficient testers. 
 
"Don't talk the talk if you can't walk the walk" is an idiom specifically referring to someone needing to show (or prove) that they can do (or start doing) what they are talking about. If you did not mean this, then you should not have used this idiom.
Look, I don't know how to put it better than what aTC is requesting in the beginning of this thread: 

- Open, transparent, coordinated software development, right from the start.

        Everyone should be able to follow the design/development, and be able to complain about any problems they see there. (and maybe help avoid/fix them)

        Attracting as many people as possible to help develop/maintain this thing is important. (not to mention that anyone involved at this stage will probably buy one  :)

        Git repo/bug trackers for everything.
Right now with the Pandora you don't have coordinated software development already, except for very, very few projects. Most projects are the fruit of the hard work of people working on their own. Slackware -> Linux-SWAT at 99%, CodeBlocks: PtitSeb, and the list can go on.

It's not because tomorrow someone set up a github account that this is going to change. There's already a number of Pandora-related github accounts available where contributors are very few (most of them only one...). 

So, it's all good to wish things are going to get better, but that does not explain why so many, current Pandora projects are simply mono-author so far. Lack of interest? People preferring to do stuff on their own ? No time to spend on other's projects? Whatever the reason, the problem already exists. 
 
Last edited by a moderator:
So there should be some daemon that monitors for newly inserted SD cards, checks for "PNDs" and does what is instructed by some control file within the PND bundle. .
That's exactly what libpnd does behind the scenes. There's no reason why it should not work on Debian, but PNDs may not be compatible because of the architecture they were compiled for (hardfp, softfp differences)
 
So you're saying that aTc's work on .next is nothing?
 
Even for aTc on the .next thread, great job that he did (mostly by himself, again) -but how many community members tried it ? I bet it's less than 10, based on the feedback on the thread.
Honestly, while it doesn't directly answer your question of "how many people tried it", an earlier post by aTc in this topic speaks about your main concern. I've quoted the relevant comments and applied bold to emphasize areas of interest:

Of course it's difficult to pull off, that's why you have to start early with these things.

And these things don't have to be taken to extreme levels, just that there must be some way for a complete outsider to join in.

Take the .next stuff for example. Despite beeing something hardly anyone cares about, it has its own reasonably easy to find section on the forum, it has a few posts that sort of tell what's going on, a github repo that makes contributing easy, and a build system that's not completely impossible to set up. And it actually attracted a few people that jumped in and helped a bit.

And that's for something that's hardly an official pandora team project, based on a near unusable OE base system. An official pyra project based on debian should have it far easier.

If the infrastructure is there, people will show up, that's how all open/free projects work.

There are already too many devices out there that have great hardware specs, but are near unusable thanks to bad software.

Getting a software dev team and infrastructure set up should be just as important as getting the hardware itself developed.

Just because you now have a kernel and a somewhat working debian image doesn't mean that you can just sit back and wait.
You don't build an OS without sufficient testers.
 Well, this topic already has people offering to test:

I could help out in testing and bug reporting. while I do have coding experience, I don't think I have the time to contribute in any meaningful way to the actual development of the OS.. I'm way too busy between working full time and classes I'm taking. However I'm actually considering buying the omap5432 EVM development board myself.
EDIT: Are you incapable of answering everything at once? It makes it hard to respond to all your points.

"Don't talk the talk if you can't walk the walk" is an idiom specifically referring to someone needing to show (or prove) that they can do (or start doing) what they are talking about. If you did not mean this, then you should not have used this idiom.
 Look, I don't know how to put it better than what aTC is requesting in the beginning of this thread: 

- Open, transparent, coordinated software development, right from the start.

        Everyone should be able to follow the design/development, and be able to complain about any problems they see there. (and maybe help avoid/fix them)

        Attracting as many people as possible to help develop/maintain this thing is important. (not to mention that anyone involved at this stage will probably buy one  :)

        Git repo/bug trackers for everything.
 Right now with the Pandora you don't have coordinated software development already, except for very, very few projects. Most projects are the fruit of the hard work of people working on their own. Slackware -> Linux-SWAT at 99%, CodeBlocks: PtitSeb, and the list can go on.

It's not because tomorrow someone set up a github account that this is going to change. There's already a number of Pandora-related github accounts available where contributors are very few (most of them only one...). 

So, it's all good to wish things are going to get better, but that does not explain why so many, current Pandora projects are simply mono-author so far. Lack of interest? People preferring to do stuff on their own ? No time to spend on other's projects? Whatever the reason, the problem already exists.
 I can quote and bold all day:

Of course it's difficult to pull off, that's why you have to start early with these things.

And these things don't have to be taken to extreme levels, just that there must be some way for a complete outsider to join in.

[...]

If the infrastructure is there, people will show up, that's how all open/free projects work.
-God Ginrai
 
Last edited by a moderator:
Well, this topic already has people offering to test:
Sure, but there's testing and testing. I'm not talking about TrashyMG here, but lots of people who test stuff on the repo just limit their feedback to "it does not work", and you need to spend lots of time to get actionable feedback and find out the root cause why it does not work on their Pandora. That's time not spent coding. 

When to comes to OS, you need people who spend large amount of time to test many aspects in order to find bugs. It's very time consuming and they need to be able to report in an effective way the issues. Look at how many distros out there work well ? Even Ubuntu has a huge list of bugs, while they have literally ten of thousands of testers. In the end you'll need people to take care of these bugs, and we are back to the chicken and egg situation with not many people working on the firmware, and priorities being set on certain issues that are critical vs others that wont be fixed. 

There's two solutions:

- either you hire people for the next year to spend real 100% time building the system with notaz

- or we continue as a "community project", knowing very well that with the limited resources we have, nothing will be "commercially grade perfect" by the time the Pyra comes out. 

Personally, I can live with the second option (which seems to be the way we seem to be going), but that's because I set my expectations accordingly. I know the current Pandora has many issues even currently, yet it's "acceptable" for me. 
 
Last edited by a moderator:
A lot of things will change moving from Angstrom to Debian
 By the way, I'd be interested to hear from you about what "lots of things" will change from Angstrom to Debian. Apart from having a full repo, I mean.
That was an inference based on the comments I've been seeing in #openpandora. I do not have enough knowledge on the OS level to be able to tell you in detail. However, if Cloudef or aTc would oblige, I'm sure you can have your answer.

-God Ginrai
 
Wow, a lot of stuff going on here :)

Don't have too much time right now (need to leave for the train back home soon), but I'll try to explain a few things, what I think of them and why...

First, about the OS...

As mentioned above, the Pandora had issues with an OS that became outdated quickly, mainly because OE seems to be a bit picky on whether it wants to build stuff or not.

I've been following aTc great work on .next, and it still looks like that an image that built fine two days ago doesn't build properly two days later because of random recipe changes by someone... this is something we really don't need anymore.

Therefore, I think Debian should be a fine OS for us.

We can use the official Debian repositories, so it stays up-to-date.

And then provide our own repository with higher priority that has stuff like nub, LED, etc. configuration tools or optimized SDL ports like the one from notaz for the Pandora.

This way, we don't have to maintain too much for the base system - as Debian is updated automatically.

Let me know if you think there are any issues - I'm certainly no expert in that stuff :)

Next, onto anything we add ourselves...

One thing I learned from notaz during the last years is that we should stick to mainline kernel as close as possible.

Otherwise, you will have hacks that will make it hard updating to new kernel versions in the future. And if people can simply build the kernel from mainline, it's easier to run any ARM Linux distribution on the Pyra.

So whatever we plan here - no evil hacks.

About compatibility and the PND system:

I never said the PND system is perfect and shouldn't be optimized. There ARE things we can improve, and we should do that as good as possible.

I also don't need 100% backwards compatibility - many things will probably be re-ported or exist in Debian anyways.

But there's some stuff that doesn't have the sourcecode available and where the original dev is gone. Mostly homebrew games - and they don't need a lot of special things, so that would be great.

Also, porting everything again takes time. So if a new Pyra owner can simply put his old card into the system and many of his stuff runs fine from the beginning until updated ports are there, that would be great.

Now, onto the PND System...

This is what I appreciate about the PND System.

I have many, many programs installed. About 60 - 70 GB. It won't fit the internal storage.

How can I install them with standard Debian package manager?

I know, I could mount the SD Card into the filesystem, but that will probably cause issues with FAT32 cards.

Using EXT4 cards is no solution, as many non-Linux users probably want to copy their roms onto the cards with normal Windows.

And what happens when the card gets lost? Then Debians database is completely screwed, as it doesn't find files it expects that they have been installed.

Would you even be able to use the internal OS without having to reinstall it completely?

Just think you're on holidays and lose the card - you will be unable to use the system at all?

Also, when we're at exhibitions like the GamesCom, we've got 10 Systems for the people to play.

We create one SD Card which we clone multiple times and put them into the Pandoras.

We don't need to install everything onto every Pandora.

If one messes around with it, we replace it with a different one.

Can these things be achieved with the normal Debian system?

If yes, I'd be happy to NOT use PNDs, but then we need to find another option.

Next is handling of PNDs for devs.

Right now, devs create the PNDs and upload them to the repo.

The users browse it with PNDManager, see screenshots and install it.

Do debian files support screenshots and automatic categories, as PNDs do that right now?

Does a dev have to create his own debian repository or can we create a community one where devs can upload the same way they can do with the repo right now?

Think about my above points.

Is that all achievable without major hacks in the Debian system?

If yes, we won't need PNDs anymore.

If no, then I think having a dual-version (repository for standard stuff like libreoffice, firefox, the base system, etc.) is fine and PNDs for stuff needing a lot of space and can't be found in normal debian repo (games, emulators, etc.) would be best.
 
Zaxoon have been built using only one (single) tester.
Hey, we all know how well it went then. How many fixes we have required to get a **working hardware clock** ?? Yeah, up until 1.60 SZ. I'm not pointing any finger here, on the contrary I know how difficult it is to address all little issues, but certainly more testing is required than a single working environment on a single machine.
 
Back
Top