>> In addition, the admin's life would only be made easier.
> "Let's see where is perl stuff....of course: /usr/perl"
Of course it looks easier if you only ask one question.
"Where are the operating system binaries that should go in users'
paths?"
"Where are the standard C++ libraries? Where is the termcap library?"
"If I want to export all architecture-independent read-only
application data via NFS to both Intel and Alpha machines running
Linux, what directories do I need to export?"
> How is this any different from 300 files in /usr/lib. ld.so finding
> the libs is a detail. Adding lines ld.so.conf would fix most
> problems.
/etc/ld.so.conf lives on client machines; libraries may live on a
server. It's bad to force people to update configuration files on all
of their clients due to operating system changes.
>>> I think that the user should have the possibility of specifying the
>>> window manager at the startx prompt such as:
startx already takes command-line arguments. "startx fvwm" already
has a meaning.
> Don't see why these files would have to be changed on a constant
> basis. Individual users could easily do it in ~/.xsession. System
> admin could remount /usr read-write when he does the
> changes. Negliably harder.
It is not acceptable to put materials under /usr which you expect the
system administrator to need to change in order to configure their
system. In particular, it means the system administrator can never
know what parts of their system are from the stock OS and what parts
are configuration information they may have modified.
Scripts make a poor configuration language, but if a script is
intended to be modified by the administrator, it belongs under /etc,
not /usr. "The system admin could remount /usr read-write" misses the
point.
While I'm here, Bruce Pixar wrote:
> How about /usr/lib/i386-elf and /usr/lib/i386-aout?
> That lets you support multiple architectures more easily.
The assumption behind the FHS is that the filesystem is generally
architecture-dependent except for /usr/share and parts of /var (the
parts Thomas Bushnell wants to move into /com). It makes no sense to
create architecture subdirectories for random things under /usr, or
you'll find tourself with architecture subdirectories of /usr/bin,
/usr/games, /usr/sbin, and so on.
If you're thinking about cross-compilation, then you haven't proposed
a complete solution (you need a place for include files and tools as
well), and the FSF has an existing standard (/usr/<bfd
name>/{bin,lib,include}) which is being used on Linux systems for
building a.out binaries on ELF machines.
