From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id ddc172d1 for ; Wed, 28 Aug 2019 00:22:13 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 31BF89BC81; Wed, 28 Aug 2019 10:22:12 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 2C0BB9BC01; Wed, 28 Aug 2019 10:21:58 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 0E3AA9BC01; Wed, 28 Aug 2019 10:21:56 +1000 (AEST) Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8]) by minnie.tuhs.org (Postfix) with ESMTP id 85D819BBFD for ; Wed, 28 Aug 2019 10:21:55 +1000 (AEST) Received: from bitblocks.com (localhost [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 40BE41570CE9; Tue, 27 Aug 2019 17:21:34 -0700 (PDT) To: Larry McVoy In-reply-to: Your message of "Tue, 27 Aug 2019 16:33:38 -0700." <20190827233338.GM13570@mcvoy.com> References: <20190827003013.GS13570@mcvoy.com> <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net> <20190827024511.GU13570@mcvoy.com> <20190827145556.GD13570@mcvoy.com> <20190827224002.GB15511@mcvoy.com> <20190827231625.55E991570CEA@mail.bitblocks.com> <20190827233338.GM13570@mcvoy.com> Comments: In-reply-to Larry McVoy message dated "Tue, 27 Aug 2019 16:33:38 -0700." From: Bakul Shah MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <63900.1566951694.1@bitblocks.com> Date: Tue, 27 Aug 2019 17:21:34 -0700 Message-Id: <20190828002141.40BE41570CE9@mail.bitblocks.com> Subject: Re: [TUHS] If not Linux, then what? X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On Tue, 27 Aug 2019 16:33:38 -0700 Larry McVoy wrote: Larry McVoy writes: > On Tue, Aug 27, 2019 at 04:16:18PM -0700, Bakul Shah wrote: > > On Tue, 27 Aug 2019 15:40:02 -0700 Larry McVoy wrote: > > Larry McVoy writes: > > > and I can tell you that sockets are WAY WAY better. I get the "it > > > should have just been file I/O" except that I don't. I tried to > > > write a library that let you open up /net/tcp/$host:$port and do > > > I/O like it was a file descriptor. That works for a lot of stuff > > > but I ran into problems quickly. A networking connection is not > > > a file handle. You can make some stuff work but I couldn't figure > > > out how to do all of it. You end up having to do ioctls to handle > > > the stuff that doesn't fit well into the file system name space. > > > I think plan 9 did this sort of thing, maybe Rob can prove me wrong > > > or remember where it didn't match. > > > > Plan9 does a decent enough job. > > > > cpu% ls /net/tcp > > /net/tcp/0 > > /net/tcp/1 > > /net/tcp/2 > > /net/tcp/clone > > /net/tcp/stats > > > > cpu% ls /net/tcp/1 > > /net/tcp/1/ctl > > /net/tcp/1/data > > /net/tcp/1/err > > /net/tcp/1/listen > > /net/tcp/1/local > > /net/tcp/1/remote > > /net/tcp/1/status > > I dunno. I can't look at that and know what it means. So it means I have Hence the link to Presotto and Winterbottom's paper. > to toss (by the time this came out) a decade or more worth of knowing how > to use sockets and learn this new model that may or may not go anywhere. It's a simper model. It is no big deal. I was intimately familiar with sockets and the BSD networking stack (worked in a router startup from the beginning where we rejiggered the FreeBSD network stack to support N forwarding tables, additional protocols, interface types etc. etc.). > > plan9 would've been a big improvement over *BSD or Linux. But > > I think a conceptual merge was needed between some sane > > version of Unix and plan9 so as to not throw out all the dusty > > decks. > > That would have made a huge difference. The problem with Unix is it > is largely good enough. All sorts of warts appeared over the years > but you can get your job done. Plan 9 was such a big departure that > it never gained traction. Having it conform to Posix or pick the > most popular Unix (SunOS? BSD?) and conform to that. I'm biased but > even if I wasn't I'd have picked SunOS, virtually all open source back > in the day compiled out of the tarball on SunOS. Everyone else had > to tinker or run configure or whatever. I believe not having to be compatible with Unix meant plan9 could evolve unimpeded. But IMHO it was not so far out that a merge would have been impossible. plan9 had "ape" (ansi/posix environment) for compiling posix compatible programs but that didn't go far enough. The result might've been a worse plan9 but a better Unix. The last version I used SunOS3.5 on a 4MB Sun 3/50. It was very nice in its day. Once I got a 386 (or was it 486) with 16MB of memory & BSD, the Sun machine saw less and less use.