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 <[email protected]> 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
