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