From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: From: David Presotto To: 9fans@cse.psu.edu Subject: Re: [9fans] design clairvoyance & the 9 way In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-mwtccewdfmpcfqpiqvnawimffd" Date: Wed, 7 May 2003 16:01:35 -0400 Topicbox-Message-UUID: a2d773b6-eacb-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-mwtccewdfmpcfqpiqvnawimffd Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Mk and rc are from Unix. You many not like them, but does that mean we're supposed to live forever with the original tools that existed under 5th edition Unix or wherever you've decided to freeze it? Is nmake any less different. If we'ld called it nnmake would that have been better. Before Plan 9, we were running lots of Unices held together by a few networks, a remote file system (different uid's on each Unix), and a bunch of remote execution commands. We hated it since it was much harder to manage and use than our old single mutiuser machine. We wanted an environment that not only put together a lot of boxes and made them look like one but which also would make use of the new technologies that were appearing (SMP's, heterogeneous architectures, juke boxes, ...). The thought was that the new environment wouldn't change from Unix except where we thought it would make our goal easier to build. The kernel had to go. The single monitor view of the Unix kernel was a real pain for making good use of the SMP's. Therefore, we started that from scratch. That didn't mean that the kenrel interface had to change though. That was a separate topic. Lots of others have rewritten the kernel from the ground up while maintaining something that looked more like a Unix. Ken and Rob thought up the idea of building everything around a single file system protocol. They also added the idea of a subjective namespace to try to unify all the binding ideas of Unix. This name space is the one thing underlying plan 9. We could have done the same thing to a Unix kernel (with an infinite amount of sweating) but the result would have been the same from the user standpoint, i.e., a system that looks very different. The ease which with it can be done can be witnessed by the number of failed/stalled attempts to add the plan 9 namespace to Linux... Also, we were tired of the general kitchen sink nature of Unix, especially of System V. If there were 3 projects or groups to do a single thing (like character processing, shared memory, networking, ...) they all eventually got jammed in. We wanted something simpler to work with. Lastly, we had all developed an extreme allergy to code filled with #if, #ifdef, #else, #elseif. Getting rid of that cruft by sticking differences into separate files/routines required a hell of a lot of rewriting. So the result was a different kenrel, with a different design philosophy, a similar but different interface, but mostly the same old commands. If you think that Unix was just a single track in comparison, you're sadly mistaken. We just made more of a bend than others did. We are guilty of rewriting commands just for the sake of doing it. The reason there was sometimes legitimate, to match our different kernel interfaces or whatever. However, ot was just as often so we wouldn't have to worry about Unix licenses. --upas-mwtccewdfmpcfqpiqvnawimffd Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Wed May 7 13:30:26 EDT 2003 Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Wed May 7 13:30:24 EDT 2003 Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.18.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id AA63B19BC3; Wed, 7 May 2003 13:30:08 -0400 (EDT) Delivered-To: 9fans@cse.psu.edu Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 14F6619BBE for <9fans@cse.psu.edu>; Wed, 7 May 2003 13:29:19 -0400 (EDT) Received: from athena (athena [12.34.136.114]) by athena.softcardsystems.com (8.12.8/8.12.8) with ESMTP id h47GXja9011746 for <9fans@cse.psu.edu>; Wed, 7 May 2003 12:33:45 -0400 From: Sam X-Sender: To: <9fans@cse.psu.edu> In-Reply-To: <3EB9352B.9060603@ameritech.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [9fans] design clairvoyance & the 9 way Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Wed, 7 May 2003 12:33:45 -0400 (EDT) > problem. Think about how many of these things could > have been eradicated if we had the fore-sight when > UNIX was being designed. Hasn't Pike been saying > this stuff for years? > ``Your conventional `good citizen' can be depended on not to be too thoughtful. His ideas, beliefs, and practices are those of other people. He loves and hates with them. He is unreflectively loyal to the institutions under which he lives, and to the men who administer them. But the really educated good man has no right to go along without question.'' - Henry Raymond Mussey While written with government in mind, this statement seems apropos as a starter to this thread. What design issues about plan9 made it unsatisfactory to consider reworking research UNIX? Why reimplement everything from the ground up? If, for example, mk isn't sufficiently better than make, why bother? I've heard the spirit in the labs was such that everything had to be written anew to be considered worth using. In retrospect, was this mantra taken too far? Compatibility was of no concern, but now that labs folks are getting disseminated into the non-labs world we see 9 libraries getting "ported" over for use on *nix. Is there any concern that maybe it would have been better to keep an eye on compatibility instead of running off in a direction claiming the one true path? I guess I'm just wondering what ``problems with UNIX were too deep to fix.'' We know why aspects of current unix systems are inferior to 9, but perhaps if more effort was given to redesigning the problem areas in place the *nix world wouldn't be stuck using hacked 20 year old technology and we'd all be better off. Thoughts? Cheers, Sam --upas-mwtccewdfmpcfqpiqvnawimffd--