Hi Jeff,
Jeff Licquia wrote on Mon, May 09, 2011 at 11:33:27PM -0400:
> (Sorry if this isn't the proper list for this discussion. If not,
> please point me in the right direction.)
Since your enquiry is not backed up by a patch proposing specific
changes to the OpenBSD operating system, this will hardly be
considered a technical discussion round here, so <m...@openbsd.org>
might have been more apropriate. On the other hand, i see that
thib@ considers tech@ fine, so it may be an edge case.
Most importantly, do *not* cross-post.
> The Linux Foundation's LSB workgroup has taken over maintenance of
> the Filesystem Hierarchy Standard, and is working on a number of
> updates needed since its last release in 2004.
>
> Despite all the "Linux" in the names above, we're wanting to make
> sure that the FHS remains independent of any particular UNIX
> implementation, and continues to be useful to non-Linux UNIXes.
I have briefly looked through it and found the following things
you might wish to consider, if - as a first step - you want to make
the FHS more accurately describe reality in more operating systems,
in particular including OpenBSD:
- Consider changing /boot to optional. Our boot loader does
not require any additional files, and i guess many people
round here would consider one that does as excessive complexity.
- Consider changing /lib to optional. In OpenBSD, we consider
it as very important that all binaries outside /usr are
statically linked on all architectures, in particular that
none of the binaries in /bin and /sbin use the run-time linker.
We also consider kernel modules more of a nuisance than an
asset. Thus, /lib would be pointless in OpenBSD.
- Consider changing /media to optional. We do not use it,
and i cannot remeber anyone explaining a need for it round
here.
- Consider changing /opt, /etc/opt, and /var/opt to optional, and add
a note that some UNIX systems are using other locations for the same
purpose. For example, OpenBSD is using /usr/local.
- Consider changing /srv to optional. We do not use it,
and i cannot remeber anyone explaining a need for it round
here. For the web server, we use /var/www, for example.
- Consider moving chown, mount, and umount to /sbin. They are not
user commands, but root-only commands for system administration.
- Consider moving dmesg and mknod to /sbin. Even though they are
not root-only, they are mostly relevant for system administration
and hardly ever for users.
- Consider deleting false, more, sed, true, and uname from the list
of required commands in /bin. They are not fundamental commands
and can happily reside in /usr/bin.
- Please delete su from the list of required commands in /bin.
Using it would be utterly pointless in single-user mode.
- Consider deleting the requirement that gzip, gunzip, zcat, and
netstat be in /bin. They can happily live in /usr/bin.
- Consider deleting the requirement that ping be in /bin.
It can be considered a system administration tool and reside in /sbin.
- Consider removing the restiction to use /mnt by the installer.
The OpenBSD installer does use it, and i don't see any problem
with that, nor any need for standardization: What is a portable
installer?!
- Consider allowing /fastboot as an alternative to /sbin/fastboot.
Actually, the former is a more logical placement, as it is related
to boot, not to system administration binaries.
- Please remove getty from the list of programs required in
/sbin. It is not a utility at all, not used for system
administration, and pointless in single-user mode. In OpenBSD,
it resides in /usr/libexec.
- Consider removing the requirements for /usr/bin/X11, /usr/lib/X11,
and /usr/include/X11. If any system needs them, fine, let it
use them, but i really don't see the point in requiring them
everywhere.
- Consider deleting python, tclsh, wish, and expect from the list
of commands required to be in /usr/bin. According to the rest
of the FHS, they should be in /opt, and agreeing with that, we
place them in /usr/local.
- Consider deleting the requirement for /usr/lib/sendmail,
it really seems obsolete by now.
- Consider marking /usr/local/etc, /usr/local/games, and /usr/local/src
as optional. Some systems may use them, but i don't see a point
in requiring them.
- Consider allowing /usr/local/libdata, /usr/local/libexec, and
/usr/local/info as optional directories.
- Consider removing the requirement for /usr/local/share/man.
/usr/local/man is required anyway, and that seems sufficient.
- The requirements regarding the internal organization
of /usr/share/man should be relaxed. Look here:
$ man -w cat troff
/usr/share/man/cat1/cat.0
/usr/local/man/man1/troff.1
In particular, locale subdirs should not be required.
Usually, translations are of inferior quality anyway,
so i think the requirement to cope with translated manuals
should be removed.
- You might wish to add an optional "man9" for kernel manuals.
- You should remove the requirement to append an X to the file
names of X windows manuals. File naming is out of scope for
a document describing hierarchy layout, and not all systems
use that suffix anyway.
- Consider marking /var/lib, /var/local, and /var/lock as optional.
- Consider allowing /usr/libdata for miscellaneous utility data files,
in particular perl modules. These do not belong under /usr/lib
because they are not binaries, and they don't belong under share
because part of them cannot be shared across systems.
- Consider allowing /usr/libexec for system daemons and utilities
executed by other programs. This is the standard place for
executable stuff that is not called interactively and must never
be in the PATH.
- Consider allowing /usr/obj to be a companion directory to /usr/src,
as an architecture specific target tree.
That list is probably still incomplete, but i think it includes most of
the points where the FHS does not match OpenBSD. I feel this list is
surprisingly short, and nearly all of the items are surprisingly
trivial. So, it guess we are less far apart than some people seem
to think.
Several people talked about the ugliness of /lib64. I do not
see any problem with that; it is optional.
Actually, i found at least one minor point we might learn from
the FHS: We should consider moving /etc/magic to /usr/share/misc/magic.
It's in the base, not the etc set, so editing it by hand will quickly make
the admin unhappy anyway.
> My question to you is: do you consider the FHS to be relevant to
> current and future development of OpenBSD?
Not very much. I suspect patches to OpenBSD following the single
purpose of making OpenBSD better conform to the FHS would be considered
"change for changes' sake" and hence rejected. However, as shown by the
example of magic(5) above, the FHS might provide a few useful hints
here and there, where it agrees with what we want to do anyway.
If the FHS can be made less Linux-centric and if software maintainers
listen to it, that might also simplify porting software now and then,
but that are a lot of ifs, and i'm not a porter myself, so i'm not
sure whether file system layout issues are really that annoying in
porting practice to make any significant amount of work on the standard
worthwhile.
Personally, i'm interested in documentation (among other subjects),
and i tend to regard hier(7) and the FHS mostly as documentation
projects. However, directory layout is a relatively minor issue in the
field of documentation and i will hardly focus on it - but maybe provide
some feedback now and then.
> If not, is this simply due to lack of maintenance; would your interest
> in the FHS be greater with more consistent updates?
>
> If you are interested, consider this an invitation to participate.
> We've set up a mailing list, Web site, etc., and are reviving the
> old bug tracker.
Uh oh, starting a "project" by setting up a web site and a mailing list
is generally regarded with lots of suspicion round here. ;-)
> More details can be found here:
>
> http://www.linuxfoundation.org/collaborate/workgroups/lsb/fhs
I fear opening tickets for all of the above would cause an
awful amount of work. Any better ideas how to handle this?
Yours,
Ingo
