Re: [TUHS] If not Linux, then what?

[Bakul Shah <bakul@bitblocks.com>]

On Tue, 27 Aug 2019 16:33:38 -0700 Larry McVoy <lm@mcvoy.com> 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 <lm@mcvoy.com> 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.