Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mailrus!iuvax!rutgers!mcnc!rti!dg-rtp!larrybud.rtp.dg.com!goudreau From: goudreau@larrybud.rtp.dg.com (Bob Goudreau) Newsgroups: comp.unix.wizards Subject: Re: Stupid man pages Message-ID: <1990Jun13.201529.13307@dg-rtp.dg.com> Date: 13 Jun 90 20:15:29 GMT References: <2281@ariel.unm.edu> <1831@pyrltd.UUCP> <618@modus.sublink.ORG> <1990Apr22.083636.9250@lsuc.on.ca> <8591@goofy.Apple.COM> <1990Jun8.162656.14993@nbc1.ge.com> <1990Jun12.145231.25545@nbc1.ge.com> Sender: usenet@dg-rtp.dg.com (Usenet Administration) Reply-To: goudreau@larrybud.rtp.dg.com (Bob Goudreau) Organization: Data General Corporation, Research Triangle Park, NC Lines: 57 In article <1990Jun12.145231.25545@nbc1.ge.com>, scott@nbc1.ge.com (Scott Barman) writes: >>> >>>In addition to error message, Sun continues to move things around to >>>the point they it is getting real annoying. Like /usr/spool being a >>>symlink to /var/spool? Why not just keep /usr/spool as it has always >>>been? Another one would be to load SunOS 4.* and cd to /usr/lib/uucp >>>and not find everything there because THEY decided the configuration >>>stuff belongs in /etc/uucp after it has live in /usr/lib/uucp for all > >... > > You're right, users do not notice the change. But I am not a full time > systems administrator and I have better things to do (including meeting > deadlines) than to hunt down things that have been in a "standard" > place since I learned Unix under v7. I still would like to know the > motivation! Actually, the motivation is fairly reasonable, and the implementation makes a lot of sense. Files and directories weren't moved gratuitously, but only in pursuit of specific goals. The most important capability gained by reorganizing files in this manner is the ability to save disk space and make release management easier by sharing most of the OS release files among multiple hosts. In particular, a server machine and all its diskless clients can mount the same /usr file system (the clients mount it read-only over NFS, in fact) with no need to give each host its own copy. The important dichotomy here is "shared & read-only" versus "private & read-write". Shared stuff was moved to /usr; the (much smaller) set of private files and directories that distinguish the "personality" of one system from another were grouped together in the root (mostly in /etc and /var). Under this setup, adding a new diskless client doesn't cost much disk space on the server, since the only *new* space he needs is for his own root and swap. To give a concrete example of the differences between shared-RO data and unshared-RW data, consider lpr and uucp. The actual *programs* used for printing and for uucp communication stay in /usr (because they're shareable); actual print jobs and uucp messages are private to a particular system, so they belong in /var/spool. Likewise, /usr/etc/termcap is shareable; /etc/motd is not. Of course, symlinks can be used liberally to ease the transition. Just remember that while many hosts may share the same symlink, the *target* of that symlink is usually host-dependent. For example, several diskless clients can mount the same /usr and thus share the same /usr/spool symlink, but the target of that link (/var/spool) will differ depending on which host the pathname is getting resolved on -- each host gets its *own* /var/spool. ------------------------------------------------------------------------ Bob Goudreau +1 919 248 6231 Data General Corporation 62 Alexander Drive goudreau@dg-rtp.dg.com Research Triangle Park, NC 27709 ...!mcnc!rti!xyzzy!goudreau USA