Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!mit-eddie!mit-amt!snorkelwacker!spdcc!merk!alliant!linus!mbunix!dsg From: dsg@mbunix.mitre.org (Goldberg) Newsgroups: comp.unix.wizards Subject: Re: What should the password/security/userinfo/login system include? Message-ID: Date: 7 Dec 89 17:36:37 GMT References: <4180@sbcs.sunysb.edu> <14652@boulder.Colorado.EDU> Sender: news@linus.UUCP Distribution: usa Organization: The Mitre Corp., Bedford, MA. Lines: 29 In-reply-to: bri@boulder.Colorado.EDU's message of 7 Dec 89 02:45:21 GMT In article <14652@boulder.Colorado.EDU> bri@boulder.Colorado.EDU (Brian Ellis) writes: > For one thing, the unix filesystem is not all that organized. I > would recommend gloming things like /bin /usr/bin /usr/local/bin > You might also eliminate the historical distinction between > /etc and /bin. General cleanup and unification would be great. > > -brian ellis (bri@boulder.Colorado.EDU) I agree that /bin and /usr/bin could probably be combined, although I understand why they were originally separated (keep root partition small and only have enough stuff in there so you could run in single user mode) and I have no trouble putting executables from /etc into /bin, but distinguishing /usr/local/bin and /usr/bin is something I find very useful. We try to keep everything delivered from the vendor in their own filesystems, so that when we upgrade, downtime can be minimized. It makes a huge difference in our environment to be able to mount /usr/local/bin with all the previous OS version binaries in it and tell our users that some or all *may* not work until we get to recompiling them as opposed to telling them that they *all will not* work until we get around to recompiling them. I suspect we are not alone in this... -- -------------------------------------------------------------------------- Dave Goldberg ARPA: dsg@mbunix.mitre.org The Mitre Corporation UUCP: linus!mbunix!dsg MS B020 Bedford, MA 01730 617-271-2460