Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!decvax!microsof!uw-beaver!cornell!vax135!ukc!root44!jmc From: jmc@root44.UUCP Newsgroups: net.unix-wizards Subject: Re: Any details on "the Newcastle Connec - (nf) Message-ID: <2290@root44.UUCP> Date: Fri, 27-May-83 17:34:52 EDT Article-I.D.: root44.2290 Posted: Fri May 27 17:34:52 1983 Date-Received: Sun, 29-May-83 07:59:33 EDT References: uiucdcs.2145 Lines: 34 We felt that the idea of the "Newcastle Connection" suffered from the following problems. 1. 'Chroot' not blocking 'cd /..' was a v7 bug fixed in System III and, I believe BSD. It is therefore arguably a retrograde step to reintroduce what people have deemed a bug and have dealt with. 2. You have to recompile every program you ever heard of (for every new release of the package, or where you want to change some network protocol) which MIGHT POSSIBLY EVER want to talk to a remote machine, to include the appropriate version of /lib/libc.a Obviously this must include your shell (on every machine), plus all the utilities. Personally, I prefer to hack the kernel. 3. I would require convincing that the right things get executed on the right machines with the right links when you do things like cd /../m1/dir1 ../../m2/bin/xyz | ../../m3/bin/lpr ../../m4/dir2/file I am sure that you need some kind of syntax to do routing. 4. Having everything in user space worries me - can you really recover happily from every interrupt/quit/kill -9? 5. Every path name and file descriptor has to be scrutinised - sounds rather expensive, but statistics required. All in all, a nice idea, but I think it's the wrong way to implement it. Any comments on my views? John Collins, Root Computers Ltd, ....!vax135!ukc!root44!jmc