Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!mit-eddie!genrad!panda!enmasse!drilex!maynard!campbell From: campbell@maynard.BSW.COM (Larry Campbell) Newsgroups: comp.bugs.sys5 Subject: Re: mvdir able to move /etc [Really S5 considered harmful :-)] Message-ID: <807@maynard.BSW.COM> Date: Sun, 18-Jan-87 12:22:48 EST Article-I.D.: maynard.807 Posted: Sun Jan 18 12:22:48 1987 Date-Received: Mon, 19-Jan-87 03:55:40 EST References: <376@oblio.UUCP> <1987Jan14.123035.20364@sq.uucp> Reply-To: campbell@maynard.UUCP (Larry Campbell) Organization: The Boston Software Works, Inc. Lines: 34 Keywords: S5 mvdir mv In article <1987Jan14.123035.20364@sq.uucp> ian@sq.UUCP (Ian F. Darwin) writes: > >In my humble opinion, the very *existence* of mvdir as separate >from the normal mv command is a bug. I agree completely. This, and the implementation of ulimit(2), lead me to wonder what AT&T were thinking of when they created S5. I've been trying for three months to convert from V7 to S5; so far the only advantages I can see in S5 are: 1) Greatly improved print spool mechanism (this is indeed a big win) 2) It's a "standard" Against this must be balanced: 1) Above-mentioned bug (yes, bug) in mv 2) ulimit (ok, the idea isn't so bad, but the implementation is wrong) 3) adb is missing 4) dbm is missing 5) It's bigger and slower 6) The uucp node name is COMPILED into the kernel! If it weren't for the impending arrival (S5R3) of streams and RFS, I'd be tempted to give up, buy a source license, and back-port the print spool stuff to V7. Although I suspect the reasons are political and not technical, I wonder if anyone at AT&T (or anyone else who thinks they know the real story) could comment on why so much in S5 is missing and/or wrong. -- Larry Campbell The Boston Software Works, Inc. Internet: campbell@maynard.uucp 120 Fulton Street, Boston MA 02109 uucp: {alliant,wjh12}!maynard!campbell +1 617 367 6846 ARPA: campbell%maynard.uucp@harvisr.harvard.edu MCI: LCAMPBELL