Backwards compatibility at any cost?

Posted Nov 10, 2024 21:31 UTC (Sun) by intelfx (subscriber, #130118)
In reply to: Backwards compatibility at any cost? by lunaryorn
Parent article: The trouble with struct sockaddr's fake flexible array

> If we go that way we might just as well deprecate the entire socket API right away and invent an entirely new networking API, because frankly, the socket API is not a great by modern standards.

How would you do one better? (Architecturally, not just minor C technicalities like the one discussed in the article.)

Backwards compatibility at any cost?

Posted Nov 23, 2024 18:15 UTC (Sat) by anton (subscriber, #25547) [Link]

How would you do one better?

By looking at what Ken Thompson did, i.e. Plan 9. The Berkeley socket API appears totally alien to Unix, and was probably designed to have as little to do with the rest of the kernel as possible. E.g., send() instead of write() and recv() instead of read(); at least that was corrected later, but we still have send() and recv().