I'm too lazy. Make me some SD cards ..


You could end up in a situation where you're spoiled for choice. Why don't you decide what you fancy getting into right now, and just set that up? Then when you're bored of that... set up the next thing.

=~. O =
 
Maybe we should make an image of an SD-install of SZ with some additional packages already installed (e.g. mc, gcc, etc), and with a bunch of PNDs on it too. It would be a card you can boot from, or just insert in a NAND-booted Pandora (but then you only get the PNDs, of course). Since it would probably be quite large, it's probably best to share it using a torrent.

Once this SD card image exists, all we need is a page with some easy-to-follow instructions on how to dump the image onto a card.

Or if you don't care about the SD card being bootable and, the "image" can be just a tarball of PNDs, which you just have to extract on an empty SD card.

Thinking out loud now:

Another approach would be to make a front-end for milkyhelper that can be used to create lists of PNDs, share those lists, and install them. That wouldn't be hard to make (it's mostly a matter of making a nice GUI for it). The idea is that you can easily create nice lists like "Selected homebrew games", "Recommended utitilies", "Popular emulators", put those lists online somehow, and then anyone with the tool can easily pick lists and download and install everything (or perhaps a subset of it).

The advantage of that approach is that it is more future-proof (if an update happens, there's no need to update some image).

Such a tool would be pretty nice to include in the first-boot procedure. Or maybe it could somehow be built into PNDManager.

Creating a list would just be a matter of selecting a subset of the PNDs you have installed on your Pandora, and writing the PND identifiers to some text file.

You could even have meta-lists that are collections of lists. A list would have an identifier just like a PND, so lists can refer to sublists. So you could have a "master" list, e.g. "EvilDragon's Pandora Setup for Reviewers", which contains sublists "Selected games", "Selected applications", "Selected emulators" and so on; some of these sublists could have sublists of their own. Once you have installed a list, it becomes a kind of "subscription" -- the list can be updated with new items, and when that happens, you will be asked if you want to download the new stuff.

In terms of implementation, the list could just be a PND, where the PXML file does not have any <application> section but some other tag to indicate that it is in fact a PND-list. The PND would contain nothing but a text file (say, called "list") with a list of PND identifiers, and maybe an icon. So it would also have an author and a title and a version and so on, and it could just be uploaded to the repo without needing to modify anything on the server side (well, except that it would have to validate PXML without an <application> section). The only thing that would need to change is PNDManager, which would need to handle such PND-list files.

A basic handler for PND-lists would just download everything on the list -- I guess that could even be done with some shell script that passes the list to milkyhelper or something like that. A nice handler for PND-lists could have a gui that shows the list and its sublists in a tree view, and lets you tick or untick some of the boxes to customize your selection (the list itself would have some default setting). Your selection could be saved in the appdata dir of the list, for future reference, when an update happens -- so it only proposes to download PNDs that are in a sublist branch that you had selected.
 
Thinking out loud now:

Another approach would be to make a front-end for milkyhelper that can be used to create lists of PNDs, share those lists, and install them. That wouldn't be hard to make (it's mostly a matter of making a nice GUI for it). The idea is that you can easily create nice lists like "Selected homebrew games", "Recommended utitilies", "Popular emulators", put those lists online somehow, and then anyone with the tool can easily pick lists and download and install everything (or perhaps a subset of it).

....
Thats a simple, but good idea. Thinking back about various thread of new Pandora(board) users asking about the best emulators or games of genre x, where such a list would come in handy. Or for personal convenience: if (for whatever reason) it happens that you need to reinstall all the pnds you usually have - just make a custom list, with your favourites.

But I would not want to put that into a pnd, I would rather see the repo functionality expanded - I favour a "keep it simple" approach in general.

In the context of this thread, I don't think this is what torpor wants: he wants everything presetup, meaning that additional datafiles that may be needed for some pnds should already be in the prpoper directory on the SD-Card as well
 
But I would not want to put that into a pnd, I would rather see the repo functionality expanded - I favour a "keep it simple" approach in general.
If we (ab)use the already existing PND format to contain such lists, there is no need to expand any repo functionality, and it just becomes a client-side implementation thing to make sure that the PND-list is properly handled. It will be necessary to do some kind of client-side implementation anyway. So imo, "keep it simple" is in this case to not have to modify the repo server software.
 
Thats exactly the problem I have with your idea: abuse is always bad, and usually should only be an option if a quick fix is needed. But I guess my post was not cleverly worded: by writing "keep it simple" I meant "don't overload things with functionality". But currently I'm not sure if it would be necessary to bring such a functionality to the repo after all, this could well be kept on the client side (for now).There was already the idea to misuse the pnd for distribution of other things (like skins for MiniMenu iirc) in the past, but it was ultimatly dropped - but I can't remember anymore why. Long story short: it may be beneficial if another mechanism was created to support that on a server side, as there may be other usecases we currently just don't think of.
 
_wb_/thatgui/klapse:

Yes, I'm talking about Plug 'n Play SD cards that have everything - the content - already in place and ready to go.  This *would* require some effort on the licensing, so maybe we start with "make an SD of the coolest totally legal content", and include the details on how to GoG the files, if needed.

I'd be willing to pay eu20,- per SD card that is made available somehow to the public for downloading (i.e. I don't want it just for myself).  Maybe put a minimum: 8gig/16gig image on the donation.  Maybe we could pool a few more interested parties and make this a real effort to get the packaging done in a way that also provides someone with some sort of cash reward for the effort .. 

Maybe this could evolve into a function for the REPO - i.e. license real content and make it part of the PND distro from the repo?  Maybe it could be an additional function of PNDManager, or some such thing?  I don't know - but I do know that having such a resource packed and ready to go would mean a lot to me, and my use of the Pandora.  The #1 reason I don't put the Pandora to use much any more is the hassle of setting up the SD cards - which were admittedly already set up/formatted for other devices - and so I make this humble appeal.
 
Ideally what you would want is a selection of software the user could choose between - so by creating their own unique image to download... the size of which is up to them. Automating this process sounds like a huge amount of work though. I would imagine this 'image building service' should have a mandatory fee scaled to the amount of software the user chooses for the image. This would help motivate setting up and maintaining this system... and could possible be even used with the Pyra as well.

=~. O =
 
SD card images are not a very good idea unless you have an automated process to create them, and even then:

- images are snapshots that get outdated quickly as the PNDs it is composed of get updated

- images are huge monolithic files to download

- you need an additional storage medium with enough free space to store the entire image

- images are not flexible: it's all or nothing, no easy way to install them partially or to slightly modify them

- the download counters at the repo would be incorrect

- some PNDs can be downloaded freely from the repo but without the right to re-distribute, so you can't put those in the image without explicit permission

For these reasons I think my proposal is much more suitable.

The only problem with my proposal is that it is quite easy to implement (just a matter of GUI and glue), there is no interesting challenge, it's just boring work and not perceived as urgent or very important, so it's not easy to find volunteers who want to do the coding :/
 
Back
Top