:> But seriously, I think the problem can be fixed with a more transparent
:> interface for Linux programs. Rather than requiring Linux libraries to be put
:> in /compat/linux, it would be much easier if everything could be put in
:> /usr/lib. Which probably means having the SAME interface as Linux.
:
:That would also result in a highly undesirable mish-mash of binaries
:in one's /usr/lib, nor do I see the real advantage since the linux
:compatability shim will look in /compat/linux/usr/lib first anyway.
:
:Perhaps we should go just a bit further with that approach and make
:things _write_ into that hierarchy first as well, e.g. if you run
:/compat/linux/bin/bash and then install something with rpm, it will
:install (as far as it's concerned) into /usr/bin, /usr/lib, etc. but
:really be chrooted into the /compat/linux hierarchy and only affect
:things there.
:
:- Jordan
I see the ports system as being our saving grace here, at least in
regards to installing commercial linux applications.
I don't like the idea of 'writing to /compat/linux' first, if only
because the 'try reading from /compat/linux then give up and try /'
idea that we are already using doesn't have a good track record -- it
creates a lot of confusion already. The writing will create even more.
I think the best solution is to have the linux compatibility code
chroot to /compat/linux right off the bat (when a FreeBSD binary exec's
a linux binary), and then we get rid of all the 'try /compat/linux first'
junk from the kernel.
Things that we want to share, like /usr/home, we can mount under
/compat/linux... all it requires is a someone to finish cleaning up
the null device (I am not volunteering, I don't have time :-( ).
In any case, with just a few strategic directories shared like that,
in a chroot'd environment, I think the linux environment can be made to
work very nicely under FreeBSD.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
