On Jun 28, 2022, at 6:13 AM, Marc Donner
<marc.donner(a)gmail.com> wrote:
What I don't understand is whether Rob's observation about networking is
*fundamental* to the space or *incidental* to the implementation. I would love to be
educated on that.
And there it is! THAT was the sentence--well, ahort paragraph--that jogged my memory as
to why this seemed familiar.
If you go back to _The Unix-Hater's Handbook_ (I know, I know, bear with me), one of
the things I noticed and pointed out in my review
(
https://athornton.dreamwidth.org/14272.html) is how many of the targets of hatred, twenty
years down the line, turned out to be unix-adjacent, and not fundamental.
In the book, these were things like Usenet and sendmail.cf (indeed, those were the two big
ones).
But the current discussion: is the thing we don't like Berkeley Sockets? Is it
TCP/IP itself? Is the the lack of a Unixy abstraction layer over some lower-level
technology? To what degree is it inherent?
I mean, obviously, to some degree it's all three, and I think a large but fairly
unexamined part of it is that TCP/IP these days almost always at least pretends to be
sitting on top of Ethernet at the bottom...but of course Classic Ethernet largely died in
the...early 2000s, I guess?...when even extremely cheap home multiple-access-devices
became switches rather than hubs.
Some sort of inter-machine networking is clearly inherent in a modern concept of Unix. I
think we're stuck with the sockets interface and IP, whether we like them or not.
They don't bother me a great deal, but, yes, they do not feel as unixy as, say,
/dev/tcp does. But the interesting thing is that I think that is Unix-adjacent or, like
the UHH distate for Unix filesystems, it's at least incidental and could be replaced
if the desire arose. And I think we already have the answer about what the abstraction
is, albeit at an application rather than the kernel level.
To answer Rob's question: I think the abstraction is now much farther up the stack.
To a pretty good first approximation, almost all applications simply definte their own
semantics on top of HTTP(S) (OK, OK, Websockets muddy the waters again) and three-to-five
verbs. There's an incantation to establish a circuit (or a "session" if
you're under the age of 50, I guess), and then you GET, DELETE, and at least one of
PUT/POST/PATCH, for "read", "unlink", and "write". This
does seem to be a more record-oriented (kids these days get snippy if you call them
"records" rather than "objects" but w/e) format than a stream of bytes
(or at least you put an abstraction layer in between your records and the stream-of-octets
that's happening).
This is certainly not efficient at a wire protocol level, but it's a fairly small
cognitive burden for people who just want to write applications that communicate with each
other.
Adam