The software side

[ekianjo]

Beside, thanks for killing that thread, how constructive from you....

I'm not killing any thread, I'm just pointing out the flaws in the logic. Please enlighten me in case my perspective is completely wrong and the current state of firmware collaboration on the pandora is the best thing ever. We are all adults here, and we should have realistic expectations, and the reality of the Pandora does not really match what some people would like the Pyra to be. I'm a little concerned by the vocabulary of aTC in the first thread to be honest, where he requests stuff the be open right from the start to be able to "complain" (I know it's not the only thing he's pointing outm but still). Having endless discussions prior to releasing the Pyra may lead to having stuff unfixed / unfinished by the time of the release. I don't mind the earlier part of the development being "closed", as in "within a small team" (and aTC or others could well be part of that team), but not necessarily open for everyone else. Sometimes you need fast-decision making more than openness. The dynamics are not always compatible. 

By the way, notaz's stance on staying as close as possible as the mainline kernel is probably the best way to proceed, so you don't break everything every single time there is an update. 

 

[God Ginrai]

Beside, thanks for killing that thread, how constructive from you....

 I'm not killing any thread, I'm just pointing out the flaws in the logic. Please enlighten me in case my perspective is completely wrong and the current state of firmware collaboration on the pandora is the best thing ever.

Speaking of flaws in logic, how about the fact you are shooting down attempts at improving the state of firmware collaboration with an argument that basically amounts to "It doesn't work now! How could it work later?!"

-God Ginrai

 

[thatgui]

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

Is that the whole repo ?

 

[ekianjo]

Speaking of flaws in logic, how about the fact you are shooting down attempts at improving the state of firmware collaboration with an argument that basically amounts to "It doesn't work now! How could it work later?!"

Again, missing my point. Sigh. 

Let me make things simple :

1. ATC calls for things to be open in the first thread. 

2. Most of the current firmware work on the Pandora is opened, with several repositories accessible. 

3. Almost no-one works on the current firmware stuff on the Pandora, and most of the work that's happening is spent on individual projects. 

4. I'm therefore saying "hey, are you sure making stuff opened is really going to work for the Pyra firmware ?"

Really, you don't see the logic ? 

PS: I really like the idea of transparency and openness, don't make me say things I didn't, btw.

 

[Cloudef]

I hacked up yesterday pacman's makepkg to create PNDs from AUR recipes. Of course there should be more involved in the end product.

But I think I can come up with working prototype what I mean with creating PND's from recipes near future (including chroot for current pandora (which is actually urjaman's work)).

 

[ShleeDragon]

I could totally see the Archlinux-arm platform being built for the pyra.. the arch base, + alarm base + pyra base + pyra community would be a really nice fit. (AUR could be grown for bonus applications.)

PND system would work on the side without major conflict... because the arch installer has dependency management.

arch is the kind of break early break often OS tho.. because the Debian OS is stable and slow. I think it's a winner

edit: https://github.com/archlinuxarm/PKGBUILDs explains the alarm system pretty well.. they build the PKGs from archlinux core, overriding only limited tweaked PKGs from ALARM git... so most of the heavy lifting is done upstream

I'd love to see archlinux as the base, but yeah.. stick with what we know works

 

[God Ginrai]

Speaking of flaws in logic, how about the fact you are shooting down attempts at improving the state of firmware collaboration with an argument that basically amounts to "It doesn't work now! How could it work later?!"

 
Again, missing my point. Sigh. 

Let me make things simple :

1. ATC calls for things to be open in the first thread. 

2. Most of the current firmware work on the Pandora is opened, with several repositories accessible. 

3. Almost no-one works on the current firmware stuff on the Pandora, and most of the work that's happening is spent on individual projects. 

4. I'm therefore saying "hey, are you sure making stuff opened is really going to work for the Pyra firmware ?"

Really, you don't see the logic ?

aTc called for "open, transparent, coordinated software development, right from the start".

The Pandora OS development was not open at the beginning, and it certainly wasn't coordinated. Notaz and co. did a great job, but what aTc is requesting is for things to start out organized from the outset, which is something that did not happen with the Pandora.

PS: I really like the idea of transparency and openness, don't make me say things I didn't, btw.

I never said you didn't. I said you were shooting down attempts at improving the state of firmware collaboration, which is exactly what you are doing.

-God Ginrai

 

[ekianjo]

Notaz and co. did a great job, but what aTc is requesting is for things to start out organized from the outset, which is something that did not happen with the Pandora.

But my point is, even when things were opened for the Pandora, there was not much involvement anyway to fix the existing Pandora issues. So what does that mean ?

 

[sebt3]

Notaz and co. did a great job, but what aTc is requesting is for things to start out organized from the outset, which is something that did not happen with the Pandora.

But my point is, even when things were opened for the Pandora, there was not much involvement anyway to fix the existing Pandora issues. So what does that mean ?

Your point is realy clear, what you refuse to get is that your attitude is counter productive.

You're telling everyone : why the f**k care to do a coordinated effort on this as it failed so far. You're actually making sure this will fail the same way this time around.

Tell me more about self-fulfilling prophecy...

 

[Klumpen]

As I said in the #openpandora:

Nobody needs pnd if we get "Synaptic", it's even easier to handle for coders and users alike.

 

[ShleeDragon]

Do you know what linux needs? more package management standards.

 

[bzar]

Pyrd: As has been said, .deb packages are nice and dandy when installing to the non-removable storage, but just stops being useful when dealing with stuff installed on SD cards. Most applications will probably be installed and distributed like this either via mainline debian repos or some community repo for our own stuff. Games, however tend to be more storage space consuming, so installing them to removable storage makes more sense. Since .debs don't AFAIK have any system to handle removable storage we need something else.

 

[Neelix]

As I said in the #openpandora:


Nobody needs pnd if we get "Synaptic", it's even easier to handle for coders and users alike.

That only works for installation of software to the internal storage. Internal storage is going to be big enough for installation of the system and a limited amount of what the user considers "essential" software, but for everything else the need exists to be able to install software to an SD card, and then have the OS recognise that the software is installed when the SD Card is there and recognise that it's not installed when the SD Card is removed.


The existing PND system accomplishes this but it is messy and has several known issues. This is the perfect opportunity to redesign it from the ground up with an eye to solving those issues.


- Neelix


Edit: h34r:

 

[EvilDragon]

Synaptic also doesn't support screenshots AFAIR (or does it?), which is not important for stuff like FireFox or Libreoffice, but certainly for games.

 

[Neelix]

Synaptic also doesn't support screenshots AFAIR (or does it?), which is not important for stuff like FireFox or Libreoffice, but certainly for games.

It does in the Ubuntu version (I can't speak for other versions)  though it's mostly just tacked on as an afterthought rather than integrated nicely into the interface.

- Neelix

 

[ShleeDragon]

As much as I hate the "idea" of a walled garden - I like the idea of the PND if it's going to maintain the "just working" drop and run system.

 

[ptitSeb]

What is wrong with PND? It's an easy plug'n play system, usable by everyone, and working well.

What is the limit of the PND system, really?

With the PND, I can advise everyone to buy a Pandora. It's easy to use as a Console. Can be easy as a SmartPhone (with the Minimenu has main GUI, and PNDManager to add/remove PND), or as advanced as a Linux Full PC (with distro like Slackware on a SDCard).

Without PND (or somthing equivalent), that plug'n play easy to use side maybe lost. Don't create a hardware for just a small linux elite.

 

[Foxgod]

I am all for PND as well, the Pyra should be comfortable like the Pandora was in terms of Software.

 

[PokeParadox]

Hmmm as opposed to having a button to switch to joystickmode or keyboard mode... why not - again tying in with having an action mapping daemon running, let the daemon handle which mode should be used. i.e. straight debian packages will not announce to the daemon and will run in keyboard mode. Games and other involved ports would use the API and announce to the daemon to use the actions and the device as buttons/joystick.

And yes maybe some people will not use the API but if it is their from the very beginning and is a recommended standard then hopefully most people would make the effort.

If most applications follow a recommended standard then the outliers would get voted down or frequently commented on that they do not.

The problem with Pandora is everyone resisted the idea of recommended standards and only later on was the situation taken more seriously. And if there was an API I certainly wasn't aware of it.

 

[ekianjo]

The existing PND system accomplishes this but it is messy and has several known issues. This is the perfect opportunity to redesign it from the ground up with an eye to solving those issues.

How is it messy exactly ? Yes it has issues but most of them are transparent for the user.