Re: Resource forks and such

david parsons (o.r.c@p.e.l.l.p.o.r.t.l.a.n.d.o.r.u.s)
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/