Date: Tue, 1 Apr 1997 12:47:35 +0000 (GMT) From: Adam David <adam@veda.is> To: syssgm@dtir.qld.gov.au (Stephen McKay) Cc: syssgm@dtir.qld.gov.au, pst@shockwave.com, freebsd-hackers@freebsd.org Subject: Re: cvs commit: ports/security/ssh/pkg PLIST Message-ID: <199704011247.MAA28673@veda.is> In-Reply-To: <199704010947.TAA08980@ogre.dtir.qld.gov.au> from Stephen McKay at "Apr 1, 97 07:47:42 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> Originally, it was all quite simple with /bin /etc /lib /usr (for user home > directories), but then /usr started to bloat with /usr/bin /usr/lib and so > on. Config files and executables were thrown in /usr/lib "because there was > some space" (or some equally inane reason). > > Sun stired this all up and symlinked like crazy to try to support their > "Network is the Computer" idea, which benefited from machine independant > shared areas, and machine local writable areas, etc. This gave us /var and > an almost-good-enough-but-really-a-pain shared /usr. > > I think 4.4BSD came up with /usr/share and /usr/libexec to try to clean up > which bits of /usr should be machine independant sharable, and which bits > should contain support executables, leaving /etc for just config files. Oh, > and I left out /sbin and /usr/sbin somewhere in that -- some misguided attempt > to stop ordinary users running system administration programs. > > This is all a complete mess, and (after a good hard look) complete crap. > > What do we need? I don't really have a good answer yet. Partially because > I'm sure nobody will follow me into the desert for purification, even if > I promise a lot of milk and honey at the final destination. At a minimum, > you'd need: > > /bin - executables ... overlaid with /bin for (dynamic) executables that are not needed during minimal singleuser maintenance mode. Most static executables can be overlaid with their dynamic counterparts to save execution VM space in normal operation. > /lib - libraries (dynamic and static) > /var - local logs, run time databases, and other writable stuff > /share - architecture independant, machine independant, shared data > /etc - config files (though "etc" is a crap name) /etc = local stuff that doesn't belong anywhere else. > /src - system sources > /home - user files > > All except /var and /etc could be shared to some degree. Even some of these can be shared, but perhaps it is easier to copy the identical files than to overlay the ones that differ? > Possibly you would have a /local with all this replicated in it, to replace > our /usr/local. Possibly, each of these would have a 'local' subdirectory. /local/* makes better sense than /*/local Also some kind of distinction needs to be made between "standard", "site-local" and "host-local". Traditionally this has been done with a shared or replicated /usr and /usr/local, and host-local stuff in /local. Of course, local stuff (both sitewide and within a single host) could be overlaid on the main directory structure, but for installation purposes it would still need to be referenced in separate directories according to actual storage location. > I've never liked libexec. Put it all in /bin and don't run support progs > directly. We don't protect people from other innocent accidents. Long > names, or prefixes will be enough. What's wrong with a directory prefix, for instance /bin/exec/ ? (perhaps a better name could also be found for it) > Things that contradict what I've just written: I've always favoured a small > root partition with just enough tools to do system repair work. That doesn't > easily fit this unless we have some sort of overlay mount mechanism. So use an overlay mount :) > PS To answer your original query, if I think /usr will be shared, I use > /etc/local to store config files for /usr/local/bin progs. But some of those progs need host-specific configs (in addition to generic configs). > PPS If people think total filesystem reorganisation will get any support, > feel free to move this to -hackers. Moved to -hackers, but I'm not making any statement about the idea gaining any support. -- Adam David <adam@veda.is>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704011247.MAA28673>