Again my repost of Marcus Brinkmann post (he's good at it - ain't he?;-) so that it didn't get lost in the flamefest. This one is about /hurd (and a bit about translators, even if they're not any problem here) Read on. Grzegorz Prokopski ******************************************** <reposter_note> In the previous mail Joey Hess wrote: Happily we can override the FHS in policy. I for one would be happy to see a policy proposal from the Hurd people that explains why /hurd is needed instead of existing stuff like /boot or more generally FHS-acceptable stuff like /lib/something, from anyone involved in the Hurd who can refrain from calling the FHS people a pack of fools, and who is capable of carrying on a sensible conversaion. </reposter_note> On Sun, May 19, 2002 at 12:37:35PM -0400, Joey Hess wrote: > Happily we can override the FHS in policy. That's what I figured. It's so low on my personal todo list though, as it is only a cosmetic change, that I can hardly see it down there. Fixing the FHS directly has some appeal, too, though. Not sure which is harder to change ;) > see a policy proposal from the Hurd people that explains why /hurd is > needed instead of existing stuff like /boot or more generally > FHS-acceptable stuff like /lib/something, /hurd contains binaries that are usually not run on the command line (because they don't provide much useful features except argument checking and --help/--version output), but which are installed by users into the filesystem for automatic startup when that part of the filesystem is accessed (you can also start it immediately, before the access, when installing it). Say, you do # settrans -a ~/debs /hurd/ftpfs ftp.debian.org:/debian/pool/main # dpkg -i ~/debs/g/glibc/libc0.3_2.2.5-6.deb which then transparently downloads and installs libc0.3 (when it is there). The /hurd/ftpfs thing is a translator. It's a component of the Hurd system, a weird cross between a user program program and a system component, started automatically, but on the users behalf. You don't want to hide translators in /libexec (or even /lib/hurd), because they are not executables started by the system without user interaction. You don't want them to be visible in /bin because running them on the command line the normal way fails with "Must be started as translator." (actually, it is possible to have an executable to be a runnable program and a translator, that would be a cross over and should probably be installed in /bin and linked to in /hurd, or the other way round). /hurd contains the user space part of the Hurd system. It is not kernel or boot stuff (although some translators are started at boot time as well), nor is it a standard Unixish program or other file. That's why translators get a new directory. /hurd is what is between the C library and the microkernel. It has no equivalent in any type of traditional Unix. Thanks, Marcus
Attachment:
signature.asc
Description: PGP signature