Pre Installed Programs


Rygiz

Still Fresh
Joined
Apr 16, 2008
Messages
53
Location
Canada
I did a search, but I couldn't seem to find it (bad keywords?), oh well.

I don't want to get a speculation thread going or anything, I'm just wondering if there's been any official word on stuff that will/might be installed on the Pandora when shipped. Clearly there'd be a media player and junk...But what about GIMP (since we saw it working), a specific document viewer, Firefox, etc. I'd imagine they're trying to keep it to a minimal, no one likes bloat ware.


Just tossing this out there...Sorry for speculation bait *cringes*
 
Last edited by a moderator:
'SONY' said:
A basic program with specific emulators is a definite, mate. :)
I doubt any emulators will shipped with the Pandora.
 
Last edited by a moderator:
'Izolo' said:
'SONY' said:
A basic program with specific emulators is a definite, mate. :)
I doubt any emulators will shipped with the Pandora.

You're right. You'll have to download them yourself. :lol:
 
Last edited by a moderator:
We're building a system to make app installation stupidly easy.

We're still banging it out, but assuming it all comes together and works (and it should, we're nearly there) .. you'll download special apps in a bundle, a .pnd file. Inside that will be a directory structure and so on for the app to live, but users won't care (unless they unpack it into a directory.)

So an entire app (all its data etc) can be downloaded as one file, dropped onto an SD card. Stick the card into Pandora, and te launcher shows the app in its category. Tap to run and it just works. No unzip, no set up.. just download and run. Piece of cake. (You are of course able to unpack it, futz with it, put it in anywhere you want on sD or in NAND, etc.)

We also intend to build the OS in such a way that you can just use Angstron packages if you want to, but thats suboptimal. (I can explain why if you want.)

Anyway, its going to be easier than on the gp2x, which was not really rocket science either :)

We or I will start writing up some docs on the wiki soon, so folks can get an idea how it wll/does work.

(For devs.. it is pretty easy to pack up the files into a .pnd; trivial on linux, a little work on Windows.)

jeff
 
Last edited by a moderator:
What (if anything) come with the standard linux package? I'd say that's all you can expect to be on the system when you get it. anything else might be one a disk with it aside from things that would probably be illegal to sell with it.
 
Last edited by a moderator:
'Alpha2' said:
What (if anything) come with the standard linux package? I'd say that's all you can expect to be on the system when you get it. anything else might be one a disk with it aside from things that would probably be illegal to sell with it.
Well, there is no "standard linux package" - Linux is just a kernel, it is up to you (the packager, at least) to add stuff. I believe that in the case of the Pandora we will have the standard GNU tools, configuration utilities for WiFi and such, plus Matchbox and the GMenu GUI, with probably some kind of file browser (rox? or is this functionality built into GMenu?). I would imagine there would be some basic utilities like a text editor and maybe a web browser, but I do not know of any specific information about included software...
 
Last edited by a moderator:
'skeezix' said:
put it in anywhere you want on sD or in NAND, etc.)

Can you expand on that a bit? Craig once said, long ago, that NAND was going to be off limits. The reasoning being that you didn't want to do any futzing with OS upgrades: just reflash the entire NAND and be done; this meant any software installed to the NAND would be wiped out.
Like I said, that was many months ago (going on 6 or 8, I think) but I'd be interested in knowing if that's no longer the case. It would definitely make things much easier to install regularly used apps to the NAND and just keep data on the SD cards, but I understood where Craig was coming from originally.
 
Last edited by a moderator:
'WizardStan' said:
'skeezix' said:
put it in anywhere you want on sD or in NAND, etc.)

Can you expand on that a bit? Craig once said, long ago, that NAND was going to be off limits. The reasoning being that you didn't want to do any futzing with OS upgrades: just reflash the entire NAND and be done; this meant any software installed to the NAND would be wiped out.
Like I said, that was many months ago (going on 6 or 8, I think) but I'd be interested in knowing if that's no longer the case. It would definitely make things much easier to install regularly used apps to the NAND and just keep data on the SD cards, but I understood where Craig was coming from originally.
The NAND storage has never been off limits, don't be so over dramatic. If you want to install apps to NAND you can do. Probably want to avoid putting a swap partition on it but that's about it. Maybe you could use drive partitioning if you want to keep apps on the NAND after copying OS upgrades to it. Linux, AFAIK, sees drive partitions as part of one combined file system (e.g. doesn't matter whether your home directory is stored on partition A or partition B). You might need some tweaking to get apps running as before, but some clever soul here might work out some way of automating whatever needs doing.
 
Last edited by a moderator:
'skeezix' said:
We also intend to build the OS in such a way that you can just use Angstron packages if you want to, but thats suboptimal. (I can explain why if you want.)
OK, I'll bite. Why is this bad?
 
Last edited by a moderator:
tonsofquestions said:
OK, I'll bite. Why is this bad?
You're going to be limited to putting things on the NAND and only on the NAND because it doesn't really work nicely for something that's removable. For some applications this makes sense- but you're going to have a limit to what will go on at any given time.
 
Last edited by a moderator:
'skeezix' said:
We also intend to build the OS in such a way that you can just use Angstron packages if you want to, but thats suboptimal. (I can explain why if you want.)
I want. Can you please?
I really like to have some good system for installing SW directly from repository on the net. I like Synaptic on Ubuntu, so somethink similiar will be cute - even some command line tool, such as apt-get or so.

'Svartalf' said:
'tonsofquestions' said:
OK, I'll bite. Why is this bad?

You're going to be limited to putting things on the NAND and only on the NAND because it doesn't really work nicely for something that's removable. For some applications this makes sense- but you're going to have a limit to what will go on at any given time.

I hope I not limited to install SW from Ångström repository only to NAND. o_O I rather install it on SD card.
 
Last edited by a moderator:
'peca' said:
I hope I not limited to install SW from Ångström repository only to NAND. o_O I rather install it on SD card.
You could of course mount an SD-card to /usr, but then you would not be able to run without the card. Another option would be to install the entire ångström image onto an SD-card and boot from there.
 
Last edited by a moderator:
'peca' said:
I hope I not limited to install SW from Ångström repository only to NAND. o_O I rather install it on SD card.
By the sound of things, it'd be a very simple process to convert something in the existing Angstrom repository into a .pnd file, so somebody's bound to either make a tool that does it for you, or just convert everything and put it in the pandora repository early on.

One question I have, is how are dependencies dealt with? Will everything still have to statically link against everything it needs?
 
Last edited by a moderator:
Zeno Arrow said:
The NAND storage has never been off limits, don't be so over dramatic. If you want to install apps to NAND you can do.

Trust me, I sometimes know what I'm talking about. It was months before you even joined that it was said, and no one has said otherwise.

craigix said:
We don't really want anyone to mess with the NAND in any way, this includes programs trying to install libs to it.

craigix said:
We don't want anything being installed on the NAND including non standard libs, we want programs to include any libs in their own folders so everything is neat and tidy and runs without issues (no looking or asking for libs from elsewhere), I hate the way windows becomes bloated with libs everywhere and we have a limited amount of NAND to work with.
This was, of course, about 4 months before we got the 512MB upgrade, so with twice as much space it may no longer be an issue, but I don't want to run up any speculation until someone says "yes, we have a plan for upgrading the OS without botching any of the programs you have installed to the NAND"
 
Last edited by a moderator:
Well, first ..

You can of course do anything you want; your box, open source evreything, make it do what you like ;) But let me discuss a bit from a normal user perspective (ie: not hacking in knee deep.)

The normal unix filesystem will be on NAND. ie: /usr, /etc, all that. You can reflash that to put a new firmware in and several groups are even working on alternative firmware (ie: gentoo etc.) Anyway, consider -- if you run a normal unix packager, it doesn't know about SD versus the normal filesystem. It would be unadvisable to put user homedir on SD by default, since you might not have SD in, or might swap SDs, or any number of scenarios.. so user homedir must also be in NAND by definition. This means if you use a normal unix packager like apt or whatever, its going to install things in /usr/local/bin say, and your homedir ~ etc, all on NAND, which is fine, it'll work.

But what if you keep installing packages that way..

1) They're on your NAND; which is cool, no worry about losing them. But..
2) You have limited NAND space; you might want to reserve it for user documents that you find important or whatever.. but do you want ot fill it up with new builds of firefox etc? I mean, if you want 500 packages, your NAND will not have the space for it.
3) The firmware lives on NAND; if you fill it up, it might be hard for the pandora team to guarantee theres enough space for next firmware update (ie: not a reflash, but a patch, say.) So it'd be nice to not have everyone by defaut using a packager that fills up the limited resource
4) .. and so on.

The trick is unix packagers assume the filesystem is where they want to put stuff. It is less likely to be the case on a handheld.

(You could format an ext2fs on SD and mount that and so lots of tricks, but we want to make it simple. For the knowbies, they can do all that of course.)

So a bunch of keener fellows have been banging out what we think is a better idea.

THIS IS ALL UP IN THE AIR AND IN DEVELOPMENT, SUBJECT TO CHANGE ETC AND SO ON.

The nitty gritty ideas we had were to divide NAND up into a couple regions; a firmware chunk and a user homedir chunk. The trick is we could use unionfs (or aufs, a newer union-fs style system). We'd make te union setup so that writes to the firmware filesystem are actually written to the user section in your homedir somewhere, an the unionfs proprerties make it so the system doesn't see this. ie: You write to /usr/foo and it ends up in your homedir in NAND, but reading /usr/foo works still. This way if you overwrite stuff in the firmware and blow it up, you just wipe your homedir and reboot, and bam, you're back to a fully working stock firmware. For OS patches we can mount the real NAND fs instead of the union, update the filesystem, remount he union, and poof. Seems brilliant to me, and allows normal packagers to just work, reasonably risk free.

Thats the firmware side.

The app packaging system we're designing uses some similar tricks, in theory. (We're still bangin it out, but its looking cool so far.)

We define a new package type, .pnd. An app could be whatever.pnd, and it includes the PXML file as defined by ED. (Though we've modified the contents of the PXML a fair amount since his last update.) The pnd could be a number of file formats (think of it like a zip file with a PXML appended to it, but we're likely going with an .iso format. Make an iso of the directory you want, append the PXML, rename to .pnd .. good to go.)

Insert your SD into the pandora, a daemon wakes up and detects the .pnd files in its searchpath, and it generates the .desktop files for the launcher in a configured location. (It could also be made as a module for matchbox or other window managers, but our current thoughts are to spit out .desktop files since they're pretty standard and should work simply.) you pop out the SD, the daemon wakes up and rescans, and removes the .desktop files in question. (It should also handle if you just rm the pnd file from within the pandora usage, etc.)

In essence, you go to the gp32x archive (say, or others), download a few .pnd files, drop them on your SD, and thats it. Just works.

More nitty gritty -- the idea is that when the system finds these pnd files, it uses filesystem tricks again.. using fuse filesystem it the pnd files are mounted as .iso's into the filesystem, based on their unique-id in the PXML say. ie: mount whatever.pnd into /apps/123456uniqueid123 and the PXML file part identifies which file in there is the executable and icon, etc. The launcher shows the icons based on the.desktop files, and when you tap one, the launcher knows which executable to run, right out of /apps/123etc/.

What makes this extra clever is unionfs again (ao aufs etc), so that any writes back to /apps/123etc/ go to the SD card instead (but the app doesn't have to know.) ie: Say, to SD card /pandora/appdata/123etc/ dir.

Anyway, the trick is you download a .pnd file, it gets shown in the launcher based on its PXML config. you tap to run it, and it gets mounted, run, and unmounted on exit. Everything works right off your SD including new/changed data. Your .pnd file remains clean (you can copy it to someone else, etc, or delete it) and your apps data stays on your SD card.

You can also unpack the .pnd files yourself into their directory and just drop it on the SD card. In that case, no mount voodoo is needed, so writes back to /pandora/apps/whatever just stay there, for those who want to keep it all together like a traditional gp2x app.

As to locations..

I've overkilled the design really.. everything is based on searchpaths. So pandora apps will use libpnd as their infrastrucuture (to save everyone rewriting all this every time.) A simple call will check the OS and find out the config search path (which can be altered in NAND as you see fit.) Then any time an app needs a config, the config search path is seeked to find it.. so you can use the default config in NAND as shipped, or put replacements of those config files on SD. (Pull out your SD and everythign reverts to defalut firmware config.. seems nice and safe to me!)

The search-path for where apps can be sought after is configured; by default the pnd files and unpacked pnds will be looked for in SD (both) in /pandora/apps if I recall right, including any subdirectories there so you can organize as you see fit, and also a path or two in NAND for built in pnds. (built in apps will probably be built into the normal filesystem like any unix app, but we could possibly include some apps as pnd files so that the user can remove them if they don't want them, to get NAND space back.)

Now, if you want pnd files to be droppable right in SD root, you just add a /pandora/conf/apps config file and put the search path into it, or edit the master conf file in NAND (/etc/pandora/conf/apps is my current plan for that.) Thus you can put .pnd files anywhere you want, but we'll have a defalut behaviour as shipp.ed

Now, before anyone complains, every single path and decision there is in conf files, so you can specify where you want to do things.

And you can use normal unix packagers.

And you can alter things to work as you see fit.

So I think we're keeping the usual flexibility, but also making something dumb-simple for new users, and yet you can play with it to customize it for those woh want to roll up your sleeves. There should be little risk since you can just eject SD cards and/or wipe oyur NAND homedir to revert to built in functionality. And in a pinch, if you wipe everythign out, you can reflash the whole firmware.

Safe and awesome.

Hope it sounds good!

Bunch of hackers in their spare time, woowoo :)

jeff

Included with the firmware will be a good assortment of libs.. SDL etc. So dynamic linking against that stuff will likely be the way to go, which is nice. (Or stat link to your hearts content if you need/want to.)

pnd files aren't going to magicly handle dependancies AFAIK; they're more for apps, like Mac OSX app bundles. a .pnd file includes everything it needs to run the app, that is not part of the firmware. A self contained package, just like a MAME gp2x zip file, say.

jeff
 
Last edited by a moderator:
peca said:
I hope I not limited to install SW from Ångström repository only to NAND. o_O I rather install it on SD card.
1) The repository system is geared for "permanent" media on the machine. Removables make for fun times- you can screw up your machine that way and confuse the hell out of your package metadata. (You've "installed" it, but it's NOT on the machine now...)

2) You can reconfigure your directory structure with the SD so that it's part of the "permanent" store space. However, it's not something that should be configured up by default. You need to know what you're doing when you do that sort of thing.

3) We're not using the packaging system for anything other than the system firmware because it works nicely for that sort of thing, but nowhere near as nicely for the games, etc. that we want to do.

4) The planned launcher framework will take much of the guesswork out of "packaging" anyhow. You'll have a zipfile for small to medium sized applications that you just drop in a specific directory on the SD or NAND. You'll unpack larger or more memory hungry applications into the same directories. From there, in the base of the directory structure will be a launcher hint, much like the .desktop files on the desktop space linux systems that has icon, executable, etc. info in it. Put a title on, take it off. Pop the SD out, there's no dependency chains to worry about, etc.

5) You can always boot up a larger Angstrom or perhaps an Ubuntu image on the SD itself and manage things that way.
 
Last edited by a moderator:
Back
Top