Drop support for SuperZaxxon in new PND format

[vinipsmaker]

This is the second topic to resolve conflicting requirements and I hope to solve them all before help in the design of the new format/tools.

The first issue was related to dependencies. And it seems that everyone agrees on the possibility of state .deb packages as dependencies (at least in the light PNDs).

This feature turns the new format incompatible with the SuperZaxxon. So, can we drop the "Should the new format be supported by Pandora AND Pyra?" ( http://pandorawiki.org/New_PND_format#The_2014.2FPyra_effort ) requirement? The compatibility under the current OpenPandora hardware can be provided by the Pandian OS. Nobody loses.

The only change is: The developers won't have the burden of maintain a system that will work on both OS.

 

[_jr_]

Who cares? Seriously. If you think you can design a better format just go ahead, do it, and document how it rates against the requirements.

 

[vinipsmaker]

Who cares? Seriously. If you think you can design a better format just go ahead, do it, and document how it rates against the requirements.

I think a lot of people here can design a better format, but a new format won't be useful if no packages use it.

The "lone wolf" approach would be to repackage all packages in OpenPandora repo, but I want the community help to do this task, then we should create a format that the community like.

 

[Granitehead]

I think ideally we should design the os for the Pyra in a way which also allows it to run on the Pandora. Then we would only support the new os.

The Pandora could probably only run flat .pnd-nexts because there wouldn't be the space for .deb dependencies, but when we support both anyway...

 

[_jr_]

I was not saying that you should code it all, just write down the design. Obviously you already have something in your mind. Removing requirements until they fit your preferred design is the wrong way to go. Show the designs and discuss them. It's the only way ED can choose what he likes most.

 

[comradekingu]

The pnd packages are binary softfloat, and repackaging them into the maintainable deb not only makes sense, but enhances performance too. Long term you can run debian on omap3 till your arms fall off. _And_ its easier to maintain that backwards compatibility.

TL;DR drop the maintaining of a problem now when it makes sense rather than repeating it.

 

[kuru]

In't out-of-the-box PND backwards compatibility one of the main points of the P2?

 

[comradekingu]

You could do that additionally, but it wouldnt be as good a solution as doing something about the problem at hand, which in turn is inherrent in pnds.

 

[vinipsmaker]

The Pandora could probably only run flat .pnd-nexts because there wouldn't be the space for .deb dependencies, but when we support both anyway...

But this would mean that we cannot rely on any lib already installed on the system and it is really nice to have at least libs to abstract hardware access. More future-proof.

I see two solutions for the flat pnd-next "problem":

• It's possible to run the Pyra OS (Debian/Pandian) on the OpenPandora hardware from the SD card. Maybe there is a performance bottleneck (didn't test yet), but it might be a low overhead and we have two SD slots to avoid I/O overhead.
• Include a very minimal Debian chroot which includes only the expected minimum dependencies to run the flat .pnd-next.

I was not saying that you should code it all, just write down the design. Obviously you already have something in your mind.

There are some devs that are already designing the new format and I don't want to compete. I just want to help the development.

Removing requirements until they fit your preferred design is the wrong way to go.

But some requirements conflict and cannot be implemented simultaneously. They need to go.

The pnd packages are binary softfloat, and repackaging them into the maintainable deb not only makes sense, but enhances performance too. Long term you can run debian on omap3 till your arms fall off. _And_ its easier to maintain that backwards compatibility.

TL;DR drop the maintaining of a problem now when it makes sense rather than repeating it.

This.

In't out-of-the-box PND backwards compatibility one of the main points of the P2?

This topic is not about run SuperZaxxon apps on Pyra OS. It's about the possibility of run Pyra OS packages on the SuperZaxxon.

The possibility of run SuperZaxxon apps on Pyra OS can be done without removing feature requests.

 

[Granitehead]

The Pandora could probably only run flat .pnd-nexts because there wouldn't be the space for .deb dependencies, but when we support both anyway...

But this would mean that we cannot rely on any lib already installed on the system and it is really nice to have at least libs to abstract hardware access. More future-proof.

I see two solutions for the flat pnd-next "problem":

• It's possible to run the Pyra OS (Debian/Pandian) on the OpenPandora hardware from the SD card. Maybe there is a performance bottleneck (didn't test yet), but it might be a low overhead and we have two SD slots to avoid I/O overhead.
• Include a very minimal Debian chroot which includes only the expected minimum dependencies to run the flat .pnd-next.

I meant running the Pyra OS on the Pandora (from NAND). It would need to be made to fit, but I think that should work. We could include the input abstracting libs and some other very basic libs on both Pandora and Pyra.Then each Pandora would essentially be a slower Pyra without the ability to install lots of .deb packages on NAND but other than that the same (dismissing other differences which aren't important for the argument).

 

[vinipsmaker]

I meant running [...]

Looks like there won't be so much blood, tears and war on this topic. I'll just wait a few days (the chance for other developers show their voices) and mark the issue as solved?

 

[_jr_]

Conflicting requirements are not a problem. Actually something went wrong in the analysis when they are not conflicting. You want flexible and cheap and fast and scalable and intuitively simple and feature rich and ...


Removing requirements is simply wrong. Deciding which solution is good enough despite none fulfilling every requirement 100% is the interesting part.

 

[comradekingu]

Running the pyra os (debian) on nand on pandora means emdebian, effort in providing that is needed maybe when its a better option, which is to say more in tune with the needs and the packages of the pandora community, and with that said, there is insufficient space for deb extentions to said nand, unless you run only the kernel from there and everything else off SD, or some variant thereof.

Maybe thats better performance, but in any event, running off SDs is long term, and the NAND will eventually run out, so debian on SD for pandora is sustainable and maintainable. Its very tangible because it already exists in the form of pandian.

Remove pnds from the equation and you are left with only inconveniences of porting them, which you end up doing anyhow, plus said problem of running debs on removable storage.

You could install at runtime, never turn off, load to ram, etc etc.  Check out http://distro.ibiblio.org/tinycorelinux/concepts.html  which now has an arm build for the pi.

I think debian and the familiarity and trust/userbase that goes with that sells more units than tinycore, but what this all alludes to is, port pnds to debs is effort that turns out for the better in any event. Thats a good place to start if others are figuring out how best to solve the missing pieces to the puzzle.  Pnds have some benefits, but also many drawbacks.

Running debian on SD on pandora works fine, having a working debian on nand for pyra means you no longer have to worry about ext4 support for people running windows. If need be, make the boot partition bigger and fat32 and put deb files there if you want a offline solution.

Content consumption on the actual device is the future. The "i like to think of my linux machine as a console" is selling the whole thing very short. Its a computer, use it to its capability.

There is already a http://pandian.openpandora.org/ repo, just need to chase down the source-code to the pnds, license, build requirements and start compiling. Once thats done, and it needs to be done in some way sooner or later anyhow, its available as armhf on pandora, at which point a performance benefit of running an outdated supersaxxon on nand with softfloat not updated pnds is minute if any.

TL;DR looks like me salespitching debian, but if everything is kept stock its a system my mother can use. If you exceed the needs of a novice you are more apt to tackling the issues you face running out of nand.

Edit: the modular emmc from http://www.hardkernel.com/main/products/prdt_info.php?g_code=G138750181426 is glorious

TLR 2  getting pnds to work on the new system, and getting proposed alterations to work on the pandora is the problem. Future proof, backwards compatible, etc, debian debian debian, all places, smooth into it, starting now.

 

[Løra (Lolla)]

If I had a Pyra, this is how I'd want it to be:


I want a regular system like my Luna (Elementary OS). I want it to update itself (everything on the whole system), and not restart itself (as I want to be in control). I'd like as little work for me as possible, so that it's ready to go.


The only reason I can use my Luna is because it's easy to use, like the Windows im used to, only better.


I dont want the hassle of having to deal with SD cards (chances are I would probably end up losing the SD cards anyway).

 

[Granitehead]

If I had a Pyra, this is how I'd want it to be:

I want a regular system like my Luna (Elementary OS). I want it to update itself (everything on the whole system), and not restart itself (as I want to be in control). I'd like as little work for me as possible, so that it's ready to go.

The only reason I can use my Luna is because it's easy to use, like the Windows im used to, only better.

I dont want the hassle of having to deal with SD cards (chances are I would probably end up losing the SD cards anyway).

This should probably work if you ignore any .pnd-successor and install the default internal Debian to a large SD card which you never remove (unless we get an internal uSD, in which case you could put the OS there).

 

[sebt3]

I was not saying that you should code it all, just write down the design. Obviously you already have something in your mind. Removing requirements until they fit your preferred design is the wrong way to go. Show the designs and discuss them. It's the only way ED can choose what he likes most.

Nope. It's the other way around. The one that will code the solution will just choose whatever suit his mind, realy.All these posts from vinipsmaker about it are just useless noice.

I do have a few ideas on how to fix the pandora/pyra support split, but theses doesnt fit his aganda, so I gave up. Will I manage to find time to implement what's in my mind, that's a good question...

 

[levi]

It strikes me that this is a good opportunity to fix some of the less well designed parts of the PND/PXML spec we've discovered after using them for a few years.

Kingu makes a good point about the sofpfp/hardfp split.  That pretty much means you can't run one set of binaries on the other device unless they've been compiled to only use intereger maths and not use the FPU.  To get Pandora PNDs running on the Pyra OS we'll need some sort of emulation/chroot layer.  But the same could be done the other way, at least on Gigahertz units that can run hardfp SGX drivers (I think) but it's extra work that needs to be done independently of the work designing a Pyra PND replacement, if it's deemed a desirable thing to have.

Personally I think it'll be easier to build PNDs and new packages from the same source, and to me that seems to be the way developments are heading, but we'll see.

 

[vinipsmaker]

Nope. It's the other way around. The one that will code the solution will just choose whatever suit his mind, realy.

Speak for yourself, I respect the user:

https://github.com/vinipsmaker/tufao/issues/9

All these posts from vinipsmaker about it are just useless noice.

It's strange, but I agree with you. One must prove its value under the "show the code" philosophy.

But... have you ever implemented a filesystem without a specification? Some things (like a file format) just need a specification *before* the implementation (specially if you are working in a team).

We'll see.

 

[sebt3]

But... have you ever implemented a filesystem without a specification? Some things (like a file format) just need a specification *before* the implementation (specially if you are working in a team).

So you're planning to reinvent the wheel when you have squashfs, qcow2, iso, tar, zip already available ?Go ahead, have fun

 

[sswam]

The existing PND format with squashfs, trailing metadata, and union mount to appdata works very well.

- efficient - whole app in one compressed file means efficient loading and caching

- base system on NAND is separate, can wipe it and reflash with little or no impact

- can move SD cards / copy PNDs from one Pandora to another, and it just works

What I don't like about it:

- over complicated

- too many features built in, that should be in separate helper scripts

- not transparent - we should be able to execute programs that are in a PND without worrying whether it's mounted or not

- aufs is broken on vfat

- we need differential update of packages

- source code is missing for many of the "open source" PNDs

- if anything changes in pandora/apps, it seems to rescan every PND, which brings system to its knees

- XML is shit.

We can fix these things without burning down the PND format and starting from scratch.

I think we should rework the existing PND format, get rid of libpnd if possible, and replace pnd_run.sh with shorter, simpler, well factored scripts. It would be nice if we can use a Debian-style package description format rather than PXML. XML is comparatively hard to read and write.