From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sam To: <9fans@cse.psu.edu> Subject: Re: [9fans] design clairvoyance & the 9 way In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Wed, 7 May 2003 18:33:31 -0400 Topicbox-Message-UUID: a32bf7c4-eacb-11e9-9e20-41e7f4b1d025 > Mk and rc are from Unix. You many not like them, but does that mean I like rc a lot. Shell naming diversity seems appropriate as the entire user interface changes. mk's new interface added pattern-matching vs. suffix-transformation metarules (per hume's paper). In the face of history (egrep, fgrep, troff, etc) it may have been better accepted would it were [A-Za-z]make. Quibbling about naming conventions probably isn't helpful, though, and I should have probably picked something more capricious like print vs. printf. > > 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 In retrospect, was this worth it? Sure, SMP machines are becoming more prevalent, but when I can get a 2GHz on my desktop the race with the back cpu server is pretty much over. Ron probably appreciates it in his cluster computing, but these days single processor systems are sufficiently cheap and fast for most needs. > 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. Really? What were the purposes of these endeavors? > 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... I think this assumes the 8+ edition kernels approached the complexity of linux, which I can't verify. Besides, your group is generally a touch sharper than your ``average bear.'' Thanks for the thoughts - I wasn't really trying to question the design decisions of the time as research motivated development should be open enough to permit any new path necessary. I'm more interested in your thoughts as designers now, looking back. What *could* have been done differently, or better? What does tomorrow's unix look like? I should have been more clear. I apologize. Sam