It is a hard problem, at least if you want to achieve concision, make it parseable, and support schema upgrade.
> "Traditional POSIX threading models, IPC interfaces, and file system access are being replaced by platform and vendor-specific APIs and frameworks such as Grand Central Dispatch [18], Binder [29], DBus [25], and SQLite [1]."
And good riddance. File systems are almost universally terrible [1]. Threading with shared state is also a terrible idea because it's too general, not to mention the poor APIs used to manage them.
IPC is something that's still unfortunately undergoing constant revision, and the structured binary vs. text wars unfortunately both have merit. I think structured text output via a domain-specific language (DSL) is really the proper answer, somewhat like how a REPL works. This DSL is ultimately simple to construct within C since it would be lisp-like in its structure so it doesn't need an IDL compiler, although its textual syntaz shouldn't be lisp-like.
stdin can then nicely format DSL output for the user. Best of all worlds between text, binary, and structured formats.
Yes and no. There's significant utility to standardizing serialization in your IPC layer. IPC consists of exchanging domain-specific messages, so the message types can be specified in a header shared between endpoints, and data gets serialized in a standard format.
The IPC API then simply reduces to sending/receiving data to/from endpoints, like channels in CPS. And ideally it should be higher-order so you can send an endpoint to another endpoint.
So you don't need to standardize the serialization, but then you just get a plethora of incompatible formats.
Specially when the majority nowadays has the idea that GNU/Linux == UNIX and never tried to write an actual portable UNIX application.
In fact, Mac OS X is the most widely deployed UNIX-like system ever. What you're a claiming to be true probably more applies to Mac OS X than Linux.
I honestly haven't seen a recent package that was accidentally not portable in the long-term across the various modern UNIX-like systems because of confusion of Linux for POSIX.
I don't miss my days of writing portable POSIX code across DG/UX, Solaris, HP-UX, Aix, FreeBSD, Red-Hat, Debian and the respective #ifdefs.
You were asserting that the majority of programmers think Linux == UNIX and have never tried to write a portable application.
Thst is clearly false as the majority of programmers probably confuse Mac OS X for UNIX and most modern unix-like software is portable to at least Linux, Mac OS X, and FreeBSD. Portable is more general than "portable across every UNIX that has existed."
Increasing the specificity of your argument mid-way to avoid the incorrectness of your initial general argument isn't very genuine.
But yes, your revised second statement is probably correct: most UNIX programmers have never tried writing portable code across "DG/UX, Solaris, HP-UX, Aix, FreeBSD, Red-Hat, Debian" exactly because there is no practical reason for it.
But this paper makes a good quantitative case for POSIX not meeting the needs of modern computing: https://news.ycombinator.com/item?id=11652609
A good example is that Linux distros, Android, and OS X all have their own non-POSIX IPC mechanisms. Applications are somehow voting with their feet and not using Unix domain sockets and pipes.
It leaves me scratching my head because I don't think serialization is that hard a problem. But it seems that most people want IPC with structured data. Android is a bit of a special case because it's a single-language OS.
"Traditional POSIX threading models, IPC interfaces, and file system access are being replaced by platform and vendor-specific APIs and frameworks such as Grand Central Dispatch [18], Binder [29], DBus [25], and SQLite [1]."