
Posix Abstractions in Modern Operating Systems: The Old, the New, the Missing [pdf] - ryancox
http://www.cs.columbia.edu/~vatlidak/POSIXpaper.pdf
======
ktRolster
It shows that we need a better IPC api, and also some primitives for dealing
with graphics cards (Linux deals with it through ioctl, for example, which is
a hack).

~~~
digi_owl
Frankly everything is a hack at some level or other.

~~~
tmptmp
Then we can say it is a rather poor hack.

------
pjmlp
Yep, just the usual portability issues.

POSIX is stuck in the days when UNIX software was plain CLI or daemons, with
keyboards and teletype as devices.

~~~
gaius
The good old days, you mean. Long may they continue.

On a more serious note, this is not happening because POSIX is bad or
irrelevant but because people a) don't know about it and b) even if they did,
reinventing the wheel is more fun.

~~~
ZenoArrow
I would argue passing around all data as text is suboptimal, not only from a
performance point of view but also in terms of robustness. Parsing plain text
using regular expressions and suchlike can lead to some useful outcomes but
it's easy to derive false positives from this. On the other hand a binary-
based object-oriented approach can give better performance and make it easier
to parse data.

This is just one example of where the old ways aren't necessarily the best.
I'm fairly confident we could come up with something better than POSIX if we
were willing to make the effort.

~~~
agoodboy
> On the other hand a binary-based object-oriented approach can give better
> performance and make it easier to parse data

please, no. OOP approach means that my process needs to know how to
communicate with other processes via very specific protocols, which aren't
very well defined (any process could describe its type of object). This is the
exact opposite of flexibility. The usefullness of tools like grep or sed would
drop drastically, and we would fall back to big blobs of software.

Since I'm just passing data, do I really need the behavior attached to it? How
would state persistence be handled?

The text (bytes as ASCII until line ending) approach may seem ugly and dirty,
but in fact you can pass list, tuples, maps, trees or just text and is up to
the receiver the responsibility to make sense out of the data.

Need data from A but B can't understand it? Use C (which operate on text) to
format A's output as B needs. With object how many "translator" (C in the
example) would you need to acheive the same result?

~~~
zvrba
> OOP approach means that my process needs to know how to communicate with
> other processes via very specific protocols, which aren't very well defined
> (any process could describe its type of object).

That's why we have IDL -- interface description language for RPC calls. An
IDL-to-X (usually C) compiler generates the necessary glue so that anybody can
talk to the program in question. IDL is also the basis of MS COM, which I
quite like from the design standpoint.

> The usefullness of tools like grep or sed would drop drastically, and we
> would fall back to big blobs of software.

So you teach grep to take an IDL file, invoke an IDL compiler and dynamically
load the parser for the protocol in question. Also, if the broker were a
standardized, perhaps in-kernel component (dbus, kdbus), you could attach
"idlgrep" to _any_ process to trace its calls. You wouldn't be restricted to
pipes.

> Since I'm just passing data, do I really need the behavior attached to it?
> How would state persistence be handled?

The parent's wording was a bit unfortunate. You can have interfaces and
interface inheritance and versioning (the "OOP" part), but there's no behavior
send between processes.

> With object how many "translator" (C in the example) would you need to
> acheive the same result?

Exactly one: the IDL compiler.

~~~
gaius
Heh, you will only be able to openly advocate IDL once the last CORBA
programmer is dead. We've been down that route. It didn't work.

~~~
pjmlp
It is called REST and micro-services nowadays.

~~~
JdeBP
Actually, as noted parenthetically above, it's called DBUS (Desktop Bus) and
... erm ... IDL.

* [http://dwheeler.com/dbus/](http://dwheeler.com/dbus/)

------
vatlidak
Thanks for sharing this!

Here is our project site:
[https://columbia.github.io/libtrack/](https://columbia.github.io/libtrack/)

and our repository github repo:
[https://github.com/columbia/libtrack](https://github.com/columbia/libtrack)

