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

31–40 of 52 posts

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

#31

Post by pjmlp »

sethrin wrote: post #30
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.

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

For me POSIX always looked like the C runtime part that vendors didn't want to make part of ANSI C, thus creating a separate standard instead.

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

#32

Post by thwarted »

ZenoArrow wrote: post #28
VLM wrote: post #20

Earlier quoted context omitted.

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.

Maybe many developers are familiar with it because it is text and thus accessible. Technical excellence matters not if no one is using it. Although I think that accessibility to humans is a major contributor to technical excellence.

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

#33

Post by gaius »

zvrba wrote: post #29
agoodboy wrote: post #19

Earlier quoted context omitted.

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

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.

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

#34

Post by ZenoArrow »

thwarted wrote: post #32
ZenoArrow wrote: post #28

Earlier quoted context omitted.

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

Maybe many developers are familiar with it because it is text and thus accessible. Technical excellence matters not if no one is using it. Although I think that accessibility to humans is a major contributor to technical excellence.

Look at how Bash scripts are used. You can hack together something quick with them, but at the time you want to do something harder or better people end up using a language like Python or Perl.

Now look at what happens on Windows. Devops can use PowerShell to hack together something quickly, but if they want to do something more complex you have the option to easily add new PowerShell commands and data types because it's all based on .NET so you can pull in any .NET code you want, whether that's something you write yourself or from an existing library.

You could do the same with Bash, but people don't do as often, I would suggest this is because it would tend to rely on plain text and regular expressions, and programmers tend to prefer using better specified data types.

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

#35

Post by jschwartzi »

stepvhen wrote: post #23
Blackthorn wrote: post #18

Earlier quoted context omitted.

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.

It's worth noting that the traditional UNIX text-based utilities are designed for reporting to a user. Using text to generate reports is the most intelligent thing they could have done, because humans universally process text. It's not a superior programming environment, but it's a superior reporting environment, which is helpful when you're trying to reverse-engineer some third-party ELF binary or debug why your shared memory object sometimes causes clients to crash. That we sometimes take strings from our reports and pass them into our shell is accidental.

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

#36

Post by gaius »

ZenoArrow wrote: post #25
gaius wrote: post #14

Earlier quoted context omitted.

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.

Yes and no. They both have the resources (money, engineers) to do alot in-house, and the market share that vendors will support them specifically. They can't not do this, they are under the same commercial pressure as other OS vendors.

If you want proof, just look at the systemd fiasco. Red Hat's way or the highway.

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

#37

Post by majewsky »

sethrin wrote: post #30
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.

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

> I think POSIX is overdue for an update.

POSIX is being updated constantly. It is just not as noticeable because POSIX is, as you say,

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

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

#38

Post by majewsky »

gaius wrote: post #36
ZenoArrow wrote: post #25

Earlier quoted context omitted.

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.

Yes and no. They both have the resources (money, engineers) to do alot in-house, and the market share that vendors will support them specifically. They can't not do this, they are under the same commercial pressure as other OS vendors. If you want proof, just look at the systemd fiasco. Red Hat's way or the highway.

> If you want proof, just look at the systemd fiasco. Red Hat's way or the highway.

What kind of proof is this? systemd is the new standard across all major distros (except for stuff like Gentoo or Slackware, which is irrelevant in the targeted enterprise market anyway). And in the process, systemd steam-rolled over lots and lots of bizarre inconsistencies between distros.

If that's Red Hat's version of EEE, I'm very happy with it.

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

#39

Post by ktRolster »

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…

Yeah, I feel like there was a golden age between 1975 and 1985, and then things got stale.

Things started picking up around Linux time, though that age of goodness started getting stale around 2006 (maybe because linux started to get commercialized? Or maybe because everyone started getting interested in handheld devices for their 'fun' programming?)

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

#40

Post by pjmlp »

jschwartzi wrote: post #35
stepvhen wrote: post #23

Earlier quoted context omitted.

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.

It's worth noting that the traditional UNIX text-based utilities are designed for reporting to a user. Using text to generate reports is the most intelligent thing they could have done, because humans universally process text. It's not a superior programming environment, but it's a superior reporting environment, which is helpful when you're trying to reverse-engineer some third-party ELF binary or debug why your sha…

The same can be told of the REPL environments of Smalltalk, Interlisp-D, Lisp Machines, Mesa/Cedar and Oberon.

All more powerful than UNIX shell languages while using structured data.

Coming from Spectrum, MS-DOS and Amiga, the UNIX shell seemed powerful until I discovered how the development workstation should look like, from the eyes of Xerox PARC.

Post reply on HN