Date: Fri, 9 Feb 1996 09:20:39 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: phk@critter.tfs.com, julian@ref.tfs.com, terry@lambert.org, current@freebsd.org Subject: Re: FS PATCHES: THE NEXT GENERATION Message-ID: <199602091620.JAA10495@phaeton.artisoft.com> In-Reply-To: <20406.823877228@time.cdrom.com> from "Jordan K. Hubbard" at Feb 9, 96 06:47:08 am
next in thread | previous in thread | raw e-mail | index | archive | help
> It's also not a question of smart or not smart, it's a question of > upholding the Principle of Least Astonishment and also not opening the > can of worms any farther than it has to be opened. By preserving the > old semantics, all your various shell scripts and system admin hacks > survive and you don't have the "multiple incarnation of /dev (say for > chroots) initialization problem" to worry about, either. By this argument, we should restrict ourselves to strict SVR3 compatability; after all, there are more SCO boxes than any other UNIX or UNIX-clone system in existance. There is no better way to allow users to leverage existing software than to clone SCO's platform. Needless to say, I think "FreeSCO" would be a mistake... luckily such a mistake would be inherently self-limiting. Yes, this is a "reductio ad absurdum" argument. As is the argument that legacy software is a good reason to make a principle design decision, as you seem to claim above. Such legacy software can rely on an ABI environment, as SCO legacy software currently relies on such an environment. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602091620.JAA10495>