28 Aug
2019
28 Aug
'19
6:21 a.m.
On Tue, 27 Aug 2019 16:33:38 -0700 Larry McVoy <lm(a)mcvoy.com> wrote:
Larry McVoy writes:
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.
On Tue, Aug 27, 2019 at 04:16:18PM -0700, Bakul Shah
wrote:
Hence the link to Presotto and Winterbottom's paper.
On Tue, 27 Aug 2019 15:40:02 -0700 Larry McVoy
<lm(a)mcvoy.com> wrote:
Larry McVoy writes:
I dunno. I can't look at that and know what it means. So it means I have 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 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.