Messages in this thread | | | From | (david parsons) | Subject | Re: Resource forks and such | Date | 10 Jul 1999 11:26:56 -0700 |
| |
In article <linux.kernel.99071002253402.19443@yogibear.penguinpowered.com>, Fred Reimer <Fred.Reimer@bellsouth.net> wrote: >On Fri, 09 Jul 1999, david parsons wrote: >> In article <linux.kernel.199907082146.RAA03078@speaker.kf8nh.apk.net>, >> <allbery@kf8nh.apk.net> wrote:
>> >NB: OS/2 will also get an icon for an executable file from a .ICO file >> >with the same root-name in the same directory. That one would work >> >fairly well on Linux. >> >> So have the default icon be in {self}/ICO, so if the UI can't find >> an icon anywhere else it will look there; this way you don't drop >> the icon on the floor when you move or rename the application.
. . .
>Is there any reason that this ELF header tag thigamajig would not work >for capabilities? I don't really know what I'm talking about (and >admit it) but it may be something that people could agree on.
It's restricted to ELF binaries, which won't do distributions like Mastodon very much good, and won't work with Java/Perl/Python/designer scripting language of the week executables.
As I think about it, the idea of a whole new kind of binary becomes more appealing, which is simply a little self-contained filesystem that can be loop-mounted when some application tries to access it. Most of the functionality for doing this already exists (modulo a volume manager for growing/shrinking the filesystem as the stuff inside it grows and contracts), so it might be doable with no more code than the hooks to binfmt_misc and whatever gross magic you'd need to have /usr/X11/bin/xdm start xdm, and /usr/X11/bin/xdm/. open the directory so you can muck around inside it.
____ david parsons \bi/ kpodfukd, anyone? \/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |