Posix Abstractions in Modern Operating Systems: The Old, the New, the Missing [pdf] • Hacker News Board

Re: Posix Abstractions in Modern Operating Systems: The Old, the New, the Missing [pdf]

#11

Post by gaius » Sun, May 08, 2016, 10:40 AM UTC

ZenoArrow wrote: post #7

gaius wrote: post #5

Earlier quoted context omitted.

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.

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 examp…

It's about the failure modes you anticipate. If a text file becomes corrupt a human can probably still make some sense of it. If a binary file does, you may well be completely out of luck. I mean try it for yourself, truncate a 4G core dump by a couple of bytes and watch GDB try to open it. Now imagine that all your system and application logs are vulnerable to this.

In a world where things are "fixed" by just blowing away a VM and spinning up a new one, you might not care but in that case why bother to log anything at all...?

Re: Posix Abstractions in Modern Operating Systems: The Old, the New, the Missing [pdf]

#12

Post by tmptmp » Sun, May 08, 2016, 10:50 AM UTC

digi_owl wrote: post #4

ktRolster wrote: post #3

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).

Frankly everything is a hack at some level or other.

Then we can say it is a rather poor hack.

Re: Posix Abstractions in Modern Operating Systems: The Old, the New, the Missing [pdf]

#13

Post by ZenoArrow » Sun, May 08, 2016, 10:54 AM UTC

gaius wrote: post #11

ZenoArrow wrote: post #7

Earlier quoted context omitted.

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 examp…

It's about the failure modes you anticipate. If a text file becomes corrupt a human can probably still make some sense of it. If a binary file does, you may well be completely out of luck. I mean try it for yourself, truncate a 4G core dump by a couple of bytes and watch GDB try to open it. Now imagine that all your system and application logs are vulnerable to this. In a world where things are "fixed" by just blowin…

> "truncate a 4G core dump by a couple of bytes and watch GDB try to open it"

This comes down to a failure of the binary design. It's possible to design a binary format that is uniform enough to handle truncation of a few bytes. To give you one example, you have a header for the binary with pointers to the start and end of each data block and you can keep multiple copies of this header. Another alternative is to specify that each block needs to specify where the data in that block ends. That way, even if you have partial corruption you can read the uncorrupted data blocks.

Re: Posix Abstractions in Modern Operating Systems: The Old, the New, the Missing [pdf]

#14

Post by gaius » Sun, May 08, 2016, 11:20 AM UTC

pjmlp wrote: post #9

gaius wrote: post #5

Earlier quoted context omitted.

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.

Not everyone agree those were the good old days. For me the good old days were the time spend with Amiga 500, discovering the world of Smalltalk, Oberon and all Xerox PARC research and other pioneers. I got into UNIX via Xenix, and used almost every commercial flavour of it, but don't consider it the good old days. The fact that POSIX is stuck in a PDP-11 world, is a proof that no big in the industry, with power to d…

It's not really proof of that tho', it's proof that they see advantages in less portability between Unix variants, which is not entirely the same thing. There's nothing in it for Red Hat or Canonical shareholders if you decide to run FreeBSD instead, so why would they support the standard?

Re: Posix Abstractions in Modern Operating Systems: The Old, the New, the Missing [pdf]

#15

Post by eru » Sun, May 08, 2016, 11:23 AM UTC

ZenoArrow wrote: post #7

gaius wrote: post #5

Earlier quoted context omitted.

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.

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 examp…

What does binary vs text have to do with object orientation?

Re: Posix Abstractions in Modern Operating Systems: The Old, the New, the Missing [pdf]

#16

Post by microtonal » Sun, May 08, 2016, 11:28 AM UTC

1_player wrote: post #8

ZenoArrow wrote: post #7

Earlier quoted context omitted.

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 examp…

> passing around all data as text is suboptimal POSIX is not Unix. Passing data around as text is a tenet of the Unix philosophy, while AFAIK POSIX doesn't mandate any of that.

Actually it does, POSIX also specifies many of the standard (text-based) UNIX utilities:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/co...

Re: Posix Abstractions in Modern Operating Systems: The Old, the New, the Missing [pdf]

#17

Post by lisivka » Sun, May 08, 2016, 12:54 PM UTC

ZenoArrow wrote: post #13

gaius wrote: post #11

Earlier quoted context omitted.

It's about the failure modes you anticipate. If a text file becomes corrupt a human can probably still make some sense of it. If a binary file does, you may well be completely out of luck. I mean try it for yourself, truncate a 4G core dump by a couple of bytes and watch GDB try to open it. Now imagine that all your system and application logs are vulnerable to this. In a world where things are "fixed" by just blowin…

> "truncate a 4G core dump by a couple of bytes and watch GDB try to open it" This comes down to a failure of the binary design. It's possible to design a binary format that is uniform enough to handle truncation of a few bytes. To give you one example, you have a header for the binary with pointers to the start and end of each data block and you can keep multiple copies of this header. Another alternative is to spec…

It is already invented by ASCII.

Re: Posix Abstractions in Modern Operating Systems: The Old, the New, the Missing [pdf]

#18

Post by Blackthorn » Sun, May 08, 2016, 2:53 PM UTC

ZenoArrow wrote: post #7

gaius wrote: post #5

Earlier quoted context omitted.

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.

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 examp…

Microsoft PowerShell does this, and it's pretty neat. Of course it's less popular than bash so now they're bringing bash and text-based pipes onto Windows! Ergh.

Re: Posix Abstractions in Modern Operating Systems: The Old, the New, the Missing [pdf]

#19

Post by agoodboy » Sun, May 08, 2016, 2:57 PM UTC

ZenoArrow wrote: post #7

gaius wrote: post #5

Earlier quoted context omitted.

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.

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 examp…

> 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?

Re: Posix Abstractions in Modern Operating Systems: The Old, the New, the Missing [pdf]

#20

Post by VLM » Sun, May 08, 2016, 3:21 PM UTC

ZenoArrow wrote: post #7

gaius wrote: post #5

Earlier quoted context omitted.

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.

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 examp…

Performance in an absolute number vs scaling.

The lowest hanging fruit gets picked. "Lets dump absolutely everything and NIH the whole thing for a single time 5% performance increase" doesn't sell well when that one time gain is expressed in the amount of time it takes hardware or network capacity to improve 5%, or fixing poorly scaling algos. Also insert the usual analogy of the ratio of the cost of microscopically faster hardware vs the labor cost of extremely expensive rockstar ninja programmers.

Also its assumed that change will lead to improvement because anecdote, or because change is always good. However, "the thing that won uses text, so naturally we gotta get rid of text" doesn't sound like a wise plan.