Blah
Wanna Be Programmer
Lets not reinvent the wheel here for the sake of a couple of cycles. No stupid file extensions.
If Linux doesn't care either way, you might as well have a common executable extension. The whole point of extensions is to let you know what kind of file a file is at a glance. Either in a GUI file browser or when you type "dir" at a command prompt, extensions help you organize. I don't care what extension you pick, but you have to pick one.Blah said:Lets not reinvent the wheel here for the sake of a couple of cycles. No stupid file extensions.
Which still doesn't stop the launcher showing files which the developer doesn't want to show to a simple launcher. The idea is that an application could have several executables, but the main executable that the launcher runs is the only one viewable to the user.sindbad said:A launcher doesn't need to open all files itself in order to check if they're executable. The file utility can check the mimetype of a file.
The main executable for the script would have the executable extension, so the launcher would execute it regardless, and linux would with how to execute it (ie. launch python interpreter for it)sindbad said:And then there's the issue of scripting languages that can't be compiled to an executable (runtime duplication
huh? Wouldn't you rather rely on the executable flag?Squidge said:It all comes down to the launcher used, which will most likely choose a method based on speed. How fast will reading a directory to find executables based on extensions be compared to opening every file to determine if it's an ARM ELF? Well, the first of course, so it's likely that there will become some standard form of file extension.
What libs are considered standard, and which non standard? Is SDL standard? It would be nice for it to be included in the firmware for dynamic linking, no reason to bloat every package with something that's used in 90% of all software Or perhaps by non-standard you meant interpreters and sandboxes like Python, Java, or Fenix?craigix said:And on the subject of installing things:
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
Alex. said:What libs are considered standard, and which non standard? Is SDL standard? It would be nice for it to be included in the firmware for dynamic linking, no reason to bloat every package with something that's used in 90% of all software Or perhaps by non-standard you meant interpreters and sandboxes like Python, Java, or Fenix?craigix said:And on the subject of installing things:
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
I'm with you in spirit but my God, the versioning, dealing with the versioning of dynamic libraries and underlying inter-dependencies is to open the seventh gate of hell. If it was a perfect world and there was only going to be one version of the firmware and never an upgrade dynamic all the way but in the long haul given what the users will probably mash up all sorts of environments I have to side with Craig, neatness counts far more than anything else. One directory per program and everyone should swear an oath not to step out of theirs.
Yupp, Extensions are very useful for overview, filtering, sorting etc. PEX sounds good, PXE sounds more like a Gaming Console XD.GnoStiC said:we definitely need an extension and i second the pxe or pex OR just px
Alex. said:What libs are considered standard, and which non standard? Is SDL standard? It would be nice for it to be included in the firmware for dynamic linking, no reason to bloat every package with something that's used in 90% of all software Or perhaps by non-standard you meant interpreters and sandboxes like Python, Java, or Fenix?craigix said:And on the subject of installing things:
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
I have no clue about these "libs" etc. But wasn't mentioned, that "Dynamic linking" can make applications faster compared to "static linking"? I thought there was such a theme in combination with the GP2X. And faster is better I think. But of course I also want my system "clean" and I can understand, why Craigix want to keep the NAND free. ".dll-chaos" like under Windows is the last thing we want .
Chip said:If Linux doesn't care either way, you might as well have a common executable extension. The whole point of extensions is to let you know what kind of file a file is at a glance. Either in a GUI file browser or when you type "dir" at a command prompt, extensions help you organize. I don't care what extension you pick, but you have to pick one.Blah said:Lets not reinvent the wheel here for the sake of a couple of cycles. No stupid file extensions.
You don't HAVE to pick anything. .EXE or .COM doesn't equate immediately to executable on Windows. You've got a myriad more of them- and you can have non executable files that have those extensions on them. Now, having said this, a good nomenclature might not be a bad idea, but you don't HAVE to do anything with this.
Dynamic linking of key runtimes is probably a good idea. glibc would be the main one that won't drift TOO much. As long as you explicitly constrain the environment, however, you'll want to either drag along your own versions of the .so's and either LD_PRELOAD or set the LD_LIBRARY_PATH (messy...but some of the pro studios do this on Linux titles...) or statically link the things for app validation purposes. LGP goes the selective dynamic link, statically linked bulk of the libraries route for breadth of support for Linux distributions. (I know what I'm talking about here...my name's credited with Ballistics, it's about to be credited with Bandits... )fusion_power said:I have no clue about these "libs" etc. But wasn't mentioned, that "Dynamic linking" can make applications faster compared to "static linking"? I thought there was such a theme in combination with the GP2X. And faster is better I think. But of course I also want my system "clean" and I can understand, why Craigix want to keep the NAND free. ".dll-chaos" like under Windows is the last thing we want .
What happens with .so files is that for any given version, they're loaded ONCE into system memory. It's not going to make things "faster" in the sense of the first load into memory, but subsequent loads will keep the code for the .so in RAM/Swap (if present) so that you don't load them again and again. If, for example, you've brought up a browser and need to bring up email at the same time, you don't want to be bringing up the hooks into the TCP stack twice, which is what static linkage would do. IF Pandora does the dynamic link thing with everything, you'll need to adopt the same philosophy that Angstrom and Maemo have adopted and constrain your usages of the .so's to the specific ones that are blessed and if someone updates, they may be clean on their own.
:lol:atomicthumbs said:.wtf, to appease the Internet
craigix said:Yeah they have to have an extension so it's easy to identify the (main) exe in a folder of files via a quick dir or just by looking.
Agree, it's easier for everyone even as you may make use of the x flag.
Whooooohooooo, I can't agree more with you. I was thinking about buying a GP2X F200 or a Pandora (reading this forums for about 2 months) but now I've made my choice (I'll wait for Pandora). Thank you very much.craigix said:And on the subject of installing things:
[...]
If I want to 'uninstall' something all I want to do is delete the folder the program made, not hunt around the NAND or other folders looking for files.
Which is fine on a standard Linux box, but can't be guaranteed when your using fat32 on an sd card. Does fat32 even have an execute flag? I thought they were just "HSRA - Hidden System ReadOnly Archive".A_SN said:huh? Wouldn't you rather rely on the executable flag?
For simpliciity, I'd say we just have a file with the same name as the executable, but with a .png, .jpg, or .bmp ending. Eg. prog.px.png. Yes, it could look neater having it stashed away somewhere else, but that alienates ease of use - people can't then create custom icons and use them as easily.Sphinxter said:Another question once you figure out how to identify the main program executable is how to associate it's icon.
But PE is the format Microsoft uses for Windows .Svartalf said:I'm keen on ".pe" if you're keen on having an extension type in the nomenclature.
Why that? "Pandora Executable". .PEX and .PXE have been used for other things, but if you're wanting a
three letter one, use .pex/.PEX as .PXE will be confused with the network boot framework for x86 class
workstations.
Aaaagh... Wash my mouth out with Dove dish soap... I can't believe I just said that!Orkie said:But PE is the format Microsoft uses for Windows .
Arrgh... FAT32! Make the nasty filesystem GO AWAY!Squidge said:Which is fine on a standard Linux box, but can't be guaranteed when your using fat32 on an sd card. Does fat32 even have an execute flag? I thought they were just "HSRA - Hidden System ReadOnly Archive".