What Should The Pandora File Archive Look Like?


QUOTE

If you really want to go down this awful (non debian package repository) route, you might consider some sort of union FS type setup. Each "package" is a union filesystem that can reside on an SD card. It's just mounted/unmounted like a regular filesystem so it's fairly removable. A properly crafted system would probably solve most of your "problems" (aside from the obvious main problem).

The rest of the modern world just goes, "oh, you want this? just run apt-get install wizbang_of_your_choice".



Goatzilla - not sure what this solves? Are you saying that each package is a unionfs on the SD card and that it contains all the dependencies? If it does that - then aren't these just monolithic packages? If the dependencies are on different physical volumes then it doesn't solve the problem. Or am I missing something.

The rest of the modern world isn't dealing with a small amount of valuable "always available storage" and two removable high capacity storage devices that can't be guaranteed to be there. Yes, the goal is for the end-user to be able to go "whatevercommand whizbang_of_your_choice" and be done. We're just figuring out how to make it foolproof.

BTW, to folks saying GBs are cheap - I plan on reusing my old SD cards - yes, even the 128MB ones! This isn't just a financial decision it's environmental sound to reuse rather than replace on every level.

Option (1) - store all shared components on internal storage. How much internal storage do we have available?

Option (2) - distribute applications with all dependencies packaged in one file/directory/package. Worst problem is with python, fenix and the like. With python you have options to make a single binary - don't know how efficient this is. I know nothing about fenix. Note: at the moment I'm not listing the different alternatives for "monolithic packaging" schemes.

Option(3) - do nothing other than use the standard package manager (apt-get).
Option(3a) - create a standard usage pattern for the pandora whereby SD slot 1 is always the system files (i.e. the shared libraries) and SD slot 2 is always the applications and user data.

Option(4) - have a per SD card dependency catalog with libraries being shared by everything on that card. Maybe this could be done by a fork of apt-get? (In fact, I don't know how apt-get stores its catalog and deals with removable media)

Option(5) - ?

Finally, I assume this is only a question for applications distributed in the "pandora file archive" - people with "mad Linux skillz" are free to install any compatible package in any way they choose.

So, what are the pros and cons of both? (BTW, it's cheating to just list the pros of your favored solution or just the cons of the other options - try and present both pros and cons of any option you discuss - ack! I feel like a damned teacher!)
 
Please tell me we won't have to statically link but the most obscure libs... Mainstream ones should be included in the firmware. Sure space may not be a problem for some (although having 2MB executables instead of 200KB will eventually pile up), but it will be for the archive's bandwidth :p
 
Squidge said:
We can just use UPX on the executables which will bring the 2MB down to about 400KB ;)
Though if cramfs or similar is used, that would be a pointless thing to do anyway since the entire image would be compressed.
 
Last edited by a moderator:
Orkie said:
Squidge said:
We can just use UPX on the executables which will bring the 2MB down to about 400KB ;)
Though if cramfs or similar is used, that would be a pointless thing to do anyway since the entire image would be compressed.

This cramfs things seems interesting. But where will be put extra files that will not be part of the package? I mean, where do we put roms, bios etc.? in a standardized directory? Also, cramfs is read only, no? So we also need a standard place for configuration files, themes, etc.

My favorite for now is the roxfiler approach: simple and easy.
 
Last edited by a moderator:
pepone said:
This cramfs things seems interesting. But where will be put extra files that will not be part of the package? I mean, where do we put roms, bios etc.? in a standardized directory? Also, cramfs is read only, no? So we also need a standard place for configuration files, themes, etc.

My favorite for now is the roxfiler approach: simple and easy.
By abusing "mount --bind" the scripts allow you to create a single save/config/whatever directory outside the cramfs image which can itself contain several files/directories which need to be writeable. When I get chance to make a proper tool for making these images, it will simply be a case of selecting which files and directories need to be writeable from a list.

This could be done for a ROMs directory, but I would personally prefer a standard directory for that since some people may be using multiple emulators for a single set of ROMs.
 
Last edited by a moderator:
On the gp2x, people suggested using a directory called "roms" in the root directory, and then the name of the system in there to store the roms in. Eg. /roms/snes or /emu/roms/snes. I don't see any problem in continuing this, and it would be perfect for multiple emulators to use the same roms.
 
QUOTE

Goatzilla - not sure what this solves? Are you saying that each package is a unionfs on the SD card and that it contains all the dependencies? If it does that - then aren't these just monolithic packages? If the dependencies are on different physical volumes then it doesn't solve the problem. Or am I missing something.

The rest of the modern world isn't dealing with a small amount of valuable "always available storage" and two removable high capacity storage devices that can't be guaranteed to be there. Yes, the goal is for the end-user to be able to go "whatevercommand whizbang_of_your_choice" and be done. We're just figuring out how to make it foolproof.

BTW, to folks saying GBs are cheap - I plan on reusing my old SD cards - yes, even the 128MB ones! This isn't just a financial decision it's environmental sound to reuse rather than replace on every level.



It basically solves the whole "removable, copyable system on the SD" thing. It doesn't necessarily solve the monolithic package thing as I'm not really in favor of that in the first place. It's actually similar to the cramfs idea; in fact a union'd cramfs, if possible, would be interesting.

The whole "whatevercommand whizbang_of_your_choice" system has already been very heavily worked on and tested, and continues to undergo development. That's great that you're trying to figure out a "foolproof" method, but it's seriously getting into the "reinventing the square wheel" realm of things.

I applaud reuse of old cards, but you should take care not to inflict unnecessary damage on a larger, more broad ranging infrastructure to just to save old cards. There are plenty of other uses for old cards.


Squidge said:
Assuming you have Wifi and an x-term. Plus it makes it more difficult to copy applications elsewhere without knowing exactly what files it needs. Want to clean up your card? You'll have to wipe and start again as you've no idea what programs need what files. I agree that apt-get and the like make things a lot easier for the desktop, but not for a mobile device. Self-contained software just makes the whole thing a LOT easier for everyone (apart from the purists, maybe - "But I could have saved 200KB if the libraries were seperate!")
I think functional wifi is an acceptable assumption for a mobile device. Both the PSP and NDS have wifi. My EEE has wifi, and so does my N770. Wireless is the preferred route on mobile devices for the simple fact that they are supposed to be... mobile. I routinely update the EEE and N770 via a wireless connection of some sort, many times (in fact most of the time) when I'm not at home and don't have another machine available to "sneakernet" a package onto a card to then transfer it to a destination device. Hence, mobile.

You can clean up a card by using various tools already available with Debian to remove packages that you don't want or need. You decide the "DO NOT WANT" part of that; the tools can tell you what you don't need. (aptitude, deborphan, etc).

I think these are sort of unrelated side issues anyways. People have been installing Debian packages without network connections for a long time.

It boils down to more or less one question: do you think you can come up with something better than what already exists?

What does your GP2x experience tell you?
 
Last edited by a moderator:
GoatZilla: I like how the GP2X was set up in regard to files. Very simple, drag and drop. And we know the Pandora will have built-in wifi. But not everyone has wireless internet available, lol.
 
Yrx said:
GoatZilla: I like how the GP2X was set up in regard to files. Very simple, drag and drop. And we know the Pandora will have built-in wifi. But not everyone has wireless internet available, lol.
Exactly, so while you may have WiFi the safe option is to use a USB connection method for transferring files. But by no means not have a WiFi system system set up though.
 
Last edited by a moderator:
Squidge said:
On the gp2x, people suggested using a directory called "roms" in the root directory, and then the name of the system in there to store the roms in. Eg. /roms/snes or /emu/roms/snes. I don't see any problem in continuing this, and it would be perfect for multiple emulators to use the same roms.
Yupp, to organize the Roms onto the SC this System is not bad. I use it for some Emulators like your SquidgeSNES and the other SNES Emu, Megadrive, MS, GG. So I have one ROM Source for many Emulators, saves much space.
Sadly, not All Emulators support external ROm Directories. This should be standard onto the PANDORA. So we could have one Arcade/Mame Directory and Emus like for Neo Geo or CPS2 etc could grab the roms from there. :) (The option just to display the supported ROMS or a fav-Rom list into the Emulators is very useful then. )
 
Last edited by a moderator:
Squidge said:
On the gp2x, people suggested using a directory called "roms" in the root directory, and then the name of the system in there to store the roms in. Eg. /roms/snes or /emu/roms/snes. I don't see any problem in continuing this, and it would be perfect for multiple emulators to use the same roms.
Or make the directory configurable so that people can have things where they want them, with the default directory being what you suggested.
 
Last edited by a moderator:
Back
Top