Date: Thu, 24 Jan 2002 14:52:49 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Peter Jeremy <peter.jeremy@alcatel.com.au> Cc: Nathan Arun <nathan_arun@hotmail.com>, arch@FreeBSD.ORG Subject: Re: a suggestion Message-ID: <3C509041.7CFEA046@mindspring.com> References: <F88HOzyfyz5b6KZmcK80000ce69@hotmail.com> <20020125071750.F72285@gsmx07.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Jeremy wrote: > Question for you: Where would you put things like the compiler back > ends (currently in /usr/libexec), ld.so -> /windows/system/peldr.vxd (version clash) libc.so -> /windows/system/crtl42.dll > various datafiles needed by things like lint and perl > (currently in /usr/libdata) and general files (/usr/share). /windows/system/user.da0 (the registry) 8-) 8-) 8-) > What about /tmp? If all the system executables have been moved into > /sys, how does the system get from single-user mode (with only the > root filesystem available) to multi-user mode (with all filesystems > available). /windows/system/temproary\ internet\ files /windows/system/temp013987 8-) 8-) > >I'm suggesting this because it is confusing to have so many bin & sbin > >directories. > > The distinction between /bin and /usr/bin (& /sbin and /usr/sbin) is > now fairly arbitrary. Originally, the root filesystem was fairly > small due to physical disk sizes. This was continued after disk sizes > grew because a small (and mostly static) filesystem was less likely to > be damaged by a crash. The root file system (including /bin and > /sbin) included the utilities necessary to validate and recover the > system. On many modern Unices, /bin is a symbolic link to /usr/bin. > If you look back through the archives, you will find that this has > been discussed fairly recently. The intent was to allow "diskless" and "dataless" configurations using NFS servers to boot the OS, which leads to every machine in the building having an identical configuration, except for any local work areas. SunOS 4.x did this beautifully, and any stale organization here is a bug. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C509041.7CFEA046>