Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

cs.columbia.edu

Post reply on HN
Print view View original

21–30 of 52 posts

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

#21

Post by ZenoArrow »

lisivka wrote: post #17
ZenoArrow wrote: post #13

Earlier quoted context omitted.

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

No it's not. ASCII doesn't give you enough metadata to permit for efficient and reliable parsing of data, you can do a lot better without using ASCII.

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

#22

Post by ZenoArrow »

agoodboy wrote: post #19
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…

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

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

It's not as hard as you make out. Take a look at how PowerShell works for an idea about how a OOP-based approach can work for CLIs.

http://www.computerworld.com/article/2954261/data-center/und...

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

#23

Post by stepvhen »

Blackthorn wrote: post #18
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…

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.

Bash + coreutils is powerful. Putting that on windows is a very good thing. The "performance increase" is irrelevant compared to the ease of use, available documentation (man pages), interoperability, and maturity.

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

#24

Post by ZenoArrow »

eru wrote: post #15
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…

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

It doesn't, but it gets around the extra overhead you get with the added metadata.

OO on its own is slower to parse than plain text, but binary is faster to parse than plain text. If you combine the both can you get the best of both words, something that's both reliable and fast.

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

#25

Post by ZenoArrow »

gaius wrote: post #14
pjmlp wrote: post #9

Earlier quoted context omitted.

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?

Red Hat and Canonical rely on third party software to boost their software ecosystem, that's why it's in their interest to support POSIX standards.

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

#26

Post by woodman »

eru wrote: post #15
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…

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

It is a "enemy of my friend is my enemy" sort of thing, the minimization of a shortcoming. OOP stumbles on text (because of object methods) in a way that no other programming paradigm does. So obviously that means that text is stupid and we never really liked the benefits of text anyway!

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

#27

Post by Avshalom »

agoodboy wrote: post #19
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…

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

>>process needs to know how to communicate with other processes via very specific protocols

>>and is up to the receiver the responsibility to make sense out of the data

That is exactly the same thing.

Either way you're throwing bytes from one process to another and hoping the second one can do something useful with it.

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

#28

Post by ZenoArrow »

VLM wrote: post #20
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…

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…

> "However, "the thing that won uses text, so naturally we gotta get rid of text" doesn't sound like a wise plan."

I'd argue the Unix command line ecosystem has only 'won' in the sense that many developers are familiar with it. I don't think it is technically the best we could do if we were starting from a blank slate.

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

#29

Post by zvrba »

agoodboy wrote: post #19
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…

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

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

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

#30

Post by sethrin »

gaius wrote: post #5
pjmlp wrote: post #2

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.

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.

As far as I can tell, POSIX was an attempt to codify existing practice amongst Unix vendors, picking the best of the most widely supported features, as opposed to actually trying to come up with a good standard. From reading UHH, one might almost be tempted to say that the only thing worse than POSIX was leaving things up to the vendors. Either way, POSIX seems to have dealt with a lot of interop issues, but it has fallen so far behind the curve that it hardly even makes sense to talk about. The article compares Android, OSX, and Ubuntu. If you were going to have a conversation about interoperability between those platforms, would you be thinking about POSIX? Or perhaps some web standard?

Standards probably shouldn't sit still, especially if they hew more closely towards existing practice than ideal practice. I think POSIX is overdue for an update.

As an aside though, did people ever voluntarily use csh? Aside from committed masochists, that is.

Post reply on HN