Drudge Report....

[Vorporeal]

To be fair, it doesnt really make sense for some apps to be distributed as pnd files (emulators are a perfect example, with you having to put your own files in with the application's), which is why libpnd also considers a directory with a pxml file in it executable. It will still be the exact same amount of work to install, only you will be copying a directory over instead of a file.

Why? Emulators for OS X are distributed as application bundles, just like everything else (save command-line only tools and daemons). Just because the application needs to reference something in a certain path, that path doesn't need to be in the application's $PREFIX or hardcoded somewhere.

What I think about is the following: The emulator is in a .PND archive. When I start it I need to configure where it looks for ROMs, etc. (if it doesn't just use a file chooser of some sort) and from there everything works just as if the emulator uses a plain directory structure. If the emulator explicitly needs me to install files to my home directory before I can use it, PXML either supports automatically installing a skeleton file or its use as an installation helper is fairly limited anyway.

My assumption here is that no sane application ever needs to modify itself. And an application modifying itself is the only reason why its files need to be in a writable location as opposed to a mounted ISO.

I mean, this isn't Windows 9x where application settings are stored in that application's directory. .PND or no, an application should be able to read from the rest of the directory tree as far as permissions go and it should be able to write to ~/.appname. And emulators really don't need much beyond that.

I suppose it just comes down to preference then. I would rather have my roms in the same folder as the emulator to keep everything together. I don't really see a problem with an app being distributed as a directory rather than a file. If you do, nothing is stopping you from packaging it into a pnd file, all you have to do is execute a script or run the gui program and select 3-4 options.

What if you have two different emulators for the same console on your Pandora? One might be better for certain games, and the other might be better for other games. You'd much rather have one directory in which you put your ROMs than have them in two separate directories. I'm with you on keeping ROMs in their emu's directory, but it's just as easy and clean to make a ROMs directory which has subdirectories that are categorized by system. For something like the Pandora, that's probably the better system.

 

[j6cubic]

GPH have made no source available. However thanks to one member of this community we now have kernel and bootloader source, but the menu is still closed. Root filesystem is mostly standard busybox stuff, so it can be built from OSS sources.

Any kernel and bootloader can be flashed using their "firmware upgrade" mechanism, just name u-boot polluxb, kernel uImage, copy to root of SD and hold R while booting. Be warned though that it performs no checks on what it's flashing, so you can easily flash some junk and brick your Wiz!

Doesn't seem all that GPL-compliant to me - the GPL says the company has to provide all code derived from GPL sources on request, and the post directly contradicts that.

I don't see a definite problem. The firmware has been released; the userland appears to be vanilla busybox and the menu is closed source, which can quite possibly be legal. If they don't use GPL'd libraries they can keep their menu closed without violating anything.

They have no source available without request but apparently one member of the community has either successfully requested it (indicating that they will heed further requests) or has hacked into their office network and copied the sources off their development server (in which case I wonder why he didn't copy the menu). I tend to believe the former.

 

[Dunny]

It's not about "not using their brains". It's about integration. I expect applications for a given platform to properly integrate themselves in order to give me a decent experience. For the Pandora that means supporting the gaming controls and being available as a .PND. If the developer can't even be bothered to package the application correctly, why should I assume that he took the time to make it work decently?

Then you're not the intended audience, are you? I fail to see how zipping up an application is not "packaging the application correctly".

Granted, I'm a Mac user and we tend to be integration junkies

You're really failing to convince me now.

but still – installing a game or emulator on a console should not involve more steps than absolutely neccessary. Otherwise it's not much of a console, isn't it?

I wasn't aware the Pandora was a console.

I mean, this isn't Windows 9x where application settings are stored in that application's directory. .PND or no, an application should be able to read from the rest of the directory tree as far as permissions go and it should be able to write to ~/.appname. And emulators really don't need much beyond that.

All my apps store configuration data inside their own directories. I've not had any problems so far, under any flavour of windows - and besides, when I want to move it from one PC to another, it's a case of zipping up one directory instead of finding the config dir and adding that to the zip, and having to extract part of the zip to one dir and the rest to another.

Not allowing apps to save their configuration to their own directory just seems insane to me - it's my damned dir, I should be able to programmatically store what the hell I like in it.

D.

 

[may88]

Craig, charge 0.02p to join.

I have a McDonalds voucher worth 0.000002p. Can it pay with that?

They only thing I don't like about this is:
People who did not plan on charging for their app will, due to this simple way of doing it. And after paying so much for the bloody Pandora in the first place.. But hopefuly that won't matter, and every thing will be hunky dory.

This is one of my concerns that the App Store over the File Archive will encourage commercialism and degrade the "open" spirit of coding for the fun of it. I feel there are certain Crown Jewels that seem wrong to charge for, emulators for one. Not that the efforts of the Devs are less or unworthy of reward, but I guess it's something that has always be freely available.
However, the AppStore is genius and buying a half decent game for 59p is fine.
Criaginator Core Distributor (aka the box, OpenPandora Appstora ...) - I like the sound of some of these features. Encouraging some truly cool software development will be great for the longevity of the Pandora.

So bugger knows it this is good or bad. A bit of both, no doubt. Time will tell.

Any shite I produce, and really don't get your hopes up, will be free.

 

[j6cubic]

Then you're not the intended audience, are you? I fail to see how zipping up an application is not "packaging the application correctly".

Well, it doesn't play well with the way software is managed on any major platform. Windows users expect an installer (although most Windows users will take anything you give them; there is no such thing as proper integration under Windows), Linux users expect a package in their distro's repository (which is not your problem if you make the source code available) and Mac users usually expect an application bundle (if you don't deliver this your app will be considered not available for the platform).
On the Pandora we have the choice between "one-click install" (.PND) and "more work than most from-source installs" (obtaining everything from the .zip, becoming root, moving all files into the appropriate directories, giving them appropriate permissions).

I wasn't aware the Pandora was a console.

The Pandora is, to quote openpandora.org, "The most powerful gaming handheld there is". The Wikipedia article for "Handheld (gaming)" redirects to "Handheld game console" and this is consistent with the way I've seen "handheld" used in a gaming context. I do think that if OpenPandora Ltd. says the Pandora is a handheld console we can assume it's intended to be one.

All my apps store configuration data inside their own directories. I've not had any problems so far, under any flavour of windows - and besides, when I want to move it from one PC to another, it's a case of zipping up one directory instead of finding the config dir and adding that to the zip, and having to extract part of the zip to one dir and the rest to another.

Not allowing apps to save their configuration to their own directory just seems insane to me - it's my damned dir, I should be able to programmatically store what the hell I like in it.

It's your dir but not the dir of the user that runs the application.

Allowing apps to write to their own directory meaning that either the app resides in the user's home directory or the user is always the administrator and can write to anywhere. This is a big reason why Windows is as virus-infested as it is today – application developers assume that the user has administrative rights and the users can't switch to a more secure model because that would break the application. Thus, if the user catches a virus, theentire OS gets infected. Windows Vista and 7 circumvent this by presenting a virtual hard drive to all applications (mapped to the user's home folder) so that applications that still operate in ways deprecated since Windows 2000 can run without the user opening the entire system up to attack.

Under Linux, you simply can't write where you want to and application developers familiar with the operating system don't assume they can. At all. As a Unix-like operating system, Linux traditionally gives normal users virtually no access outside their own home directory. Unlike Windows, Linux usually does not have a single folder for each operating system, it rather has a single directory for each kind of file.
For example, the binary of your program goes to /usr/bin/, libraries (usually not installed with the program itself) go to /usr/lib/ and data files go to /usr/share/YOURAPP/.
If you don't want to adhere to this format, the canonical way of dealing with this is to put your allication's files into /opt/.

As the user can not write to any of these locations, any configuration data you write is expected to end up in ~/.YOURAPP/, where ~ is a shorthand for the user's home directory.

The Pandora gives you a means of ignoring where to put the individual files, as well as not requiring the user to gain administrative privileges to install your application. It does this through .PND files, which, once mounted, show up as directories in the directory tree. This leaves no clutter behind and allows you to work with a minimum of hassle. It still requires you to write your configuration data to ~/.YOURAPP/, but that's the expected way under Linux.

Assuming that you can write to the application directory is sloppy coding as, under Linux, it's very likely that the user does not have the appropriate permissions to do so.

 

[PoisonedV]

ugh i can't believe we have to PAY for something! I already bought the console why should i be expected to buy games?

omg im posting about this on my ubuntu blog...

 

[Asmo]

ugh i can't believe we have to PAY for something! I already bought the console why should i be expected to buy games?

omg im posting about this on my ubuntu blog...

Not quite what anyone was saying though eh?

 

[danielliu88888]

ugh i can't believe we have to PAY for something! I already bought the console why should i be expected to buy games?

omg im posting about this on my ubuntu blog...

try harder.

 

[Dunny]

Not allowing apps to save their configuration to their own directory just seems insane to me - it's my damned dir, I should be able to programmatically store what the hell I like in it.

It's your dir but not the dir of the user that runs the application.

Allowing apps to write to their own directory meaning that either the app resides in the user's home directory or the user is always the administrator and can write to anywhere. This is a big reason why Windows is as virus-infested as it is today – application developers assume that the user has administrative rights and the users can't switch to a more secure model because that would break the application. Thus, if the user catches a virus, theentire OS gets infected. Windows Vista and 7 circumvent this by presenting a virtual hard drive to all applications (mapped to the user's home folder) so that applications that still operate in ways deprecated since Windows 2000 can run without the user opening the entire system up to attack.

Again, that's not sane in the slightest. I don't care if it's to stop viruses - my app isn't a virus. I've not had a virus infection on any of my Windows machines since windows98, and I was a teenager who shouldn't have been let loose on a PC. This is the major problem here. OS's like linux assume that you're stupid, and that you can't be trusted. This is my PC, it runs how I want it to run.

But anyway. What is this "virtual hard drive" of which you speak? My apps save to their own folder, in the "program files" hierarchy. That's 100% correct - there's no trace of their data in any of the user\appdata\local or roaming structures. This is in Vista, btw, and also holds true for Win7. Allowing the app to write to the app's folder doesn't trigger UAC in either win7 or Vista that I've seen in my tests, and UAC is enabled. Logging in as a different user shows the files all present and correct in the app's folder.

I have heard about this redirection, and I've seen it in apps like mIRC (mIRC's log files, for example, appear in the local\roaming\ directory, and not in mIRC's "logs" folder), but it would appear that by opening files wherever I like and writing to them, I'm getting what I asked for. Of course, all this may be happening transparently and it's pulling the wool over my eyes - but if it is, then it's doing the job a lot better than any linux install.

And you've still not convinced me to waste time building an installer for muppets yet.

D.

 

[MDave]

Not allowing apps to save their configuration to their own directory just seems insane to me - it's my damned dir, I should be able to programmatically store what the hell I like in it.

It's your dir but not the dir of the user that runs the application.

Allowing apps to write to their own directory meaning that either the app resides in the user's home directory or the user is always the administrator and can write to anywhere. This is a big reason why Windows is as virus-infested as it is today – application developers assume that the user has administrative rights and the users can't switch to a more secure model because that would break the application. Thus, if the user catches a virus, theentire OS gets infected. Windows Vista and 7 circumvent this by presenting a virtual hard drive to all applications (mapped to the user's home folder) so that applications that still operate in ways deprecated since Windows 2000 can run without the user opening the entire system up to attack.

Again, that's not sane in the slightest. I don't care if it's to stop viruses - my app isn't a virus. I've not had a virus infection on any of my Windows machines since windows98, and I was a teenager who shouldn't have been let loose on a PC. This is the major problem here. OS's like linux assume that you're stupid, and that you can't be trusted. This is my PC, it runs how I want it to run.

But anyway. What is this "virtual hard drive" of which you speak? My apps save to their own folder, in the "program files" hierarchy. That's 100% correct - there's no trace of their data in any of the user\appdata\local or roaming structures. This is in Vista, btw, and also holds true for Win7. Allowing the app to write to the app's folder doesn't trigger UAC in either win7 or Vista that I've seen in my tests, and UAC is enabled. Logging in as a different user shows the files all present and correct in the app's folder.

I have heard about this redirection, and I've seen it in apps like mIRC (mIRC's log files, for example, appear in the local\roaming\ directory, and not in mIRC's "logs" folder), but it would appear that by opening files wherever I like and writing to them, I'm getting what I asked for. Of course, all this may be happening transparently and it's pulling the wool over my eyes - but if it is, then it's doing the job a lot better than any linux install.

And you've still not convinced me to waste time building an installer for muppets yet.

D.

I see where you're coming from. That's what I like about developing on Windows, you can organise however you want the files and folders of your programs. Makes applications nice and portable too, which is very important if I want to quickly test what I develop with someone on another machine, or even the same machine with multiple OS's with access to the same drive. I don't have to worry about what libraries they have, or making sure this part of my program goes here and configurations go there. I can even plug in a usb stick with a folder containing everything to run my game and take it back and update the files easily. That amount of freedom is something I'm spoiled by

But I've gotten used to doing everything in my user folder in Linux though. I just pretend that is like the root of my drive in Windows

 

[WizardStan]

ugh i can't believe we have to PAY for something! I already bought the console why should i be expected to buy games?

omg im posting about this on my ubuntu blog...

try harder.

Give him a break. He was off for a week or so. Probably needs a couple days to ramp back up to the usual vitriolic criticizing posts.

 

[Esn]

As someone who's never used Linux before, or any version of Windows past XP, I don't understand what you guys are talking about. I'm just hoping that there will eventually be some tutorial for how file management on the Pandora works.

As for the App Store, I'm not sure, like some other people here. My inclination right now is to think that it won't make things any worse and might be a good thing, but we'll see, of course. I remember one game for the GP32, Bolcataxian (the best-designed 2D space shooter I ever played) that won ADIC2004. It was left unfinished because the sponsors never sent the winning prize to the coder. An App Store would've been a good thing back then.

 

[j6cubic]

Again, that's not sane in the slightest. I don't care if it's to stop viruses - my app isn't a virus. I've not had a virus infection on any of my Windows machines since windows98, and I was a teenager who shouldn't have been let loose on a PC. This is the major problem here. OS's like linux assume that you're stupid, and that you can't be trusted. This is my PC, it runs how I want it to run.

No, OS's like Linux assume that you know what you're doing. Whereas Windows has historically been a single-user OS suitable for workstations at best, Unix was developed as an operating system for servers used by many people at once. Unlike all versions of Windows prior to the NT series, it's therefore capable of safely supporting more than one user. It wasn't designed that way because it's somehow simpler, it was designed that way because that way the administrator of a system can ensure that the users don't mess up the system through idiocy or malice.

"I've never been infected therefore nobody should be" is not a good argument – plenty of users are infected through worms or compromised websites, which they can do little about. There are enough 0-day exploits for even up-to-date virus scanners to not deliver 100% protection. If the operating system has proper privilege management and isn't configured in an insecure way (user = administrator), any infection by a virus is limited to the user's home folder any most worms will be unable to deliver their payload. If the configuration is insecure you end up as yet another zombie in a botnet. If you're really "lucky" the worm installed a rootkit and/or directly subverted your virus scanner so your infected system will always check out as clean. Yes, such practices are hardly unheard-of.

But anyway. What is this "virtual hard drive" of which you speak? My apps save to their own folder, in the "program files" hierarchy. That's 100% correct - there's no trace of their data in any of the user\appdata\local or roaming structures. This is in Vista, btw, and also holds true for Win7. Allowing the app to write to the app's folder doesn't trigger UAC in either win7 or Vista that I've seen in my tests, and UAC is enabled. Logging in as a different user shows the files all present and correct in the app's folder.

I'm talking about \USERNAME\Documents\AppData\Local\VirtualStore. If your application tries to write to a location it's not permitted to write to, Windows creates a folder within that path and has the application put its file there. When the application wants to read a file, Windows first hecks whether it's in the folder. It's a hack to enable legacy applications to run without resulting in the same security nightmare that was Windows 95-XP (remember that secutity was easily the most-criticized shortcoming of Windows prior to Vista).

Of course, this doesn't apply if your user account has administrative privileges. Which it doesn't have by default because it's nothing short of dangerously irresponsible. It also might not apply if you do file I/O through one of the several legacy I/O APIs Windows carries around with it but I don't really know about that.

And you've still not convinced me to waste time building an installer for muppets yet.

I most likely will, since you care neither about how the operating systems you write for work nor what the best practices for working with them are. Why should you care whether your application behaves in any way like any other application on that plaform or whether users need to perform nonsenical actions that run counter to anything else on the platform just to get them to run?

I'm honestly surprised that you even talk to potential users. After all, you certainly don't appear to care about them.

 

[gruso]

As long as the launcher provides a facility to create a shortcut icon for non-PND binaries, then it's not really an issue. It's how things have always been done around here; you'd download a zip from the archive, extract it to SD, then create a Gmenu link to the .GPE file. Contempt for users would be Dunny forbidding people from PND packaging his releases, but he said he's ok with that happening. Real contempt would be expecting users to launch from a terminal, but I don't think we're talking about that here.

If we want to reap the full benefits of an open platform we have to respect the choices of the devs who give us free software. If you lay down the law and decree that all devs must follow one rule for the benefit of users, you're just boxing those devs in and taking away their choices. IMO if 80-90% of releases make use of the PND system, it's a good great result for the guys who designed it and the people who use it.

 

[conso]

Linux apps can store data in their dir, as long as they are installed in a home-dir. Still, using `/.appname is by far the better take on it and will let the users decide where to place the app (install it system wide, somewhere in /home/* or on a sd-card).
My pandora will be a multi-user system just like any pc in our home-network and I'd love it if my savestates don't get mixed with those of my nephew. If I want to share data, I can set group-privileges and symlink.

 

[Yoyobuae]

AFAIK, the pnd facilities should have the ability to use UnionFS (or similar). Source

IMO, with such a feature the location of files stops being an issue. You can map whatever files to whatever location and the running applications wont know the difference.

 

[j6cubic]

As long as the launcher provides a facility to create a shortcut icon for non-PND binaries, then it's not really an issue. It's how things have always been done around here; you'd download a zip from the archive, extract it to SD, then create a Gmenu link to the .GPE file. Contempt for users would be Dunny forbidding people from PND packaging his releases, but he said he's ok with that happening. Real contempt would be expecting users to launch from a terminal, but I don't think we're talking about that here.

If we want to reap the full benefits of an open platform we have to respect the choices of the devs who give us free software. If you lay down the law and decree that all devs must follow one rule for the benefit of users, you're just boxing those devs in and taking away their choices. IMO if 80-90% of releases make use of the PND system, it's a good great result for the guys who designed it and the people who use it.

I never used the term "contempt". "Lack of interest" is rather what I meant to express and it was most likely too harsh. I did lose my temper a bit there.

conso points out exactly why it's good to observe platform-specific standards: Writing an application like one did under Windows 9x leads to that application supportig only one user per installation, thus I need to install it once for every user on my system. Linux is inherently multi-user, even if most users are not going to take advantage of that, therefore an application that doesn't play well with more than one user is going to stand out in a negative way. This is what the whole argument was about.

Once you have made your application multi-user safe (by only writing to the user's home directory), creating a .PND is something that should take maybe half an hour once and then five seconds per release. Even without specific tools it should be little more than generating the PXML and then calling growisofs and dd. Note that creating a .PND is actually impossible if the application assumes that the directory its binary resides in is writable (unless .PNDs do indeed use UnionFS magic to enable writes).

Creating a .PND might be more complicated if cross-compiling from Windows, though; I don't know if there are shell-compatible ISO creation tools for Windows.

 

[skeezix]

I posted DOS commandline pnd-making in the libpnd hub wiki, so yes, its trivial even on DOS in XP/Vista/Win7, and either ED or me will whip up a total basic crap GUI until someone gets around to making a fancy shamcy one.

Oh, and vimacs just added squashfs (and other fs) support so now it doesn't just have to be iso, can be piles of other stuff.

jeff

edit; oh and j6cubic -- I saw something above there; you don't need to be ~/aware if you don't want to; just writing back to cwd when your app runs will be directed to SD appdata; writing to NAND homedir is a good idea for user-specific stuff, but of course 99% of pandora folks will (I'm assuming) be single-user, so I'm not too worried about it. (I could be wrong

 

[skeezix]

AFAIK, the pnd facilities should have the ability to use UnionFS (or similar). Source

IMO, with such a feature the location of files stops being an issue. You can map whatever files to whatever location and the running applications wont know the difference.

We're actually using aufs, but same concept; so the app is expected to write back to and be only aware of its own directory .. it shouldn't be "cd"ing anywhere, though of course its free to read other dirs such as /SDcard/roms or whatever. So yeah, apps should just run, write their configs back to themselves and it'll end up on SD in the appdata path, and good to go. Its super-easy for devs .. ie: just automatic, no work at all

jeff

 

[Dunny]

tl;dr

you care neither about how the operating systems you write for work nor what the best practices for working with them are. Why should you care whether your application behaves in any way like any other application on that plaform or whether users need to perform nonsenical actions that run counter to anything else on the platform just to get them to run?

I'm honestly surprised that you even talk to potential users. After all, you certainly don't appear to care about them.

Oh, I talk to my users all the time and I've yet to get any complaints at all that my apps don't behave. Bug reports I do get, but they're all functionality issues - none regarding how my apps integrate with the OS. If after ten years I'm not getting reports that I'm trashing people's system files, then I can safely assume that people really don't give that much of a toss about this "security" madness which prevents people from making the computer do exactly what they asked it to do.

I mean, I've added thousands of new features to my apps users' requests, fixed numerous issues and no email goes un-answered. I think that shows that I care about people who use my software - I feel that telling people "yes, you can" rather than "you're stupid and irresponsible for even wanting to do that" generates much more user happiness.

Performing non-sensical actions just to get them to run? How non-sensical is unpacking an archive to a folder chosen by the user, and then expecting them to double-click an icon? How non-sensical is it for a user to expect the data he's created to be in the folder he put it in? Or in the folder that the application resides in?

"Sorry, but if you want to find your files, you'll have to head into the users folder, then into your username's folder, then into appdata, then the local folder in there, and then finally it may be in the virtualstore folder, under a folder named after the app that created the file."

Christ, is that really better?

"Yeah, your data is in the same folder as you installed the app to, in a subfolder called 'Data'. Have fun."

It's not that I don't care about the way the OS works - I don't care for forcing users to jump through hoops just to get a simple thing done, and I don't care for the stupidity of people who assume that they know what my users want better than they do. If they want to store their data in the user documents hierarchy, they are free to do so. They are free to store it any damned place they please.

D.