Live data from Hacker News

Posix Has Become Outdated (2016) [pdf]

cs.columbia.edu

11–20 of 246 posts

Re: Posix Has Become Outdated (2016) [pdf]

#11
post #8

Earlier quoted context omitted.

> Java would replace C++, who thought C++ would replace C, who thought Windows would replace Unix All of these have happened, for many use cases.

No, they haven't. Stop believing everything you read on reddit. Java didn't displace C++, and C++ certainly hasn't displaced C.

Great example! I read reddit via a browser written in C++ on a Windows machine (written in C++) or on an operating system compiled by a compiler written in C++... or even an app written in Java.

Software engineering still uses languages/tools from the first few years that it existed, so it's unlikely that anyone means "completely replace every single LoC inexistence" when they say "replace".

Re: Posix Has Become Outdated (2016) [pdf]

#12
post #8

Earlier quoted context omitted.

> Java would replace C++, who thought C++ would replace C, who thought Windows would replace Unix All of these have happened, for many use cases.

No, they haven't. Stop believing everything you read on reddit. Java didn't displace C++, and C++ certainly hasn't displaced C.

> Java didn't displace C++

C++ has become an infrastructure language on the enterprise.

We write native libraries in it, like COM components, or plugins that interact with Python, Lua, Java, .NET, Node,... VMs.

No one writes full stack applications in C++ any longer, other than maintaining the existing ones.

Even game engines have moved into a mix of C++ + higher level language.

On the mobile OSes, C++ only has GUI support via the Objective-C++ and C++/CX dialects. On Android it gets the JNI wall.

> and C++ certainly hasn't displaced C.

Your favourite C compiler is written in C++.

The only place where C has an edge over C++ is the embedded space, *BSD, Linux kernel and the GNU tools.

Re: Posix Has Become Outdated (2016) [pdf]

#13
post #5

I know people tend to hold up POSIX compliance as something that's of utmost importance, but from my conversations with Bionic's maintainers, there's an awful lot of cruft and poor designs in some of the POSIX APIs.

Google should have innovated or they should have complied. Instead they built on POSIX's shoulders and then diverged only enough to harm portability. Not cool.

> then diverged only enough to harm portability

How so?

Re: Posix Has Become Outdated (2016) [pdf]

#14

I know people tend to hold up POSIX compliance as something that's of utmost importance, but from my conversations with Bionic's maintainers, there's an awful lot of cruft and poor designs in some of the POSIX APIs.

One of the primary goals of POSIX was to standardize and encode existing behavior, but the behavior of Unices is sufficiently divergent that many APIs are uselessly underspecified. One especially hilarious case is close being impossible to use correctly in a cross-platform manner: on HP-UX, you must check for EINTR and try again; on Linux, close will close the file descriptor even if interrupted by a signal, so you must not try again [1]. Almost nothing is specified as being async signal safe. Tons of functions are thread-safe on bionic or glibc but not other libc implementations (e.g. readdir, which has a readdir_r counterpart which should not be used [2]).

Lots of APIs are fundamentally unusable in the presence of threads (e.g. there's no way to modify environment variables safely). This is a bit excusable, because pthreads were bolted on a decade after everything was already ossified.

Lots of APIs are a giant pain in the ass to use compared to alternatives provided in Linux/BSD (e.g. alarm vs timerfd or kqueue).

A few APIs are massive footguns that basically shouldn't ever be used. It's impossible to use POSIX shared memory without leaking. pthread_cancel is insane.

1: http://austingroupbugs.net/view.php?id=529

2: https://www.gnu.org/software/libc/manual/html_node/Reading_0...

Re: Posix Has Become Outdated (2016) [pdf]

#15

Sometimes I wish ACLs were better supported.

Combining both the ancestral and the ACL system was botched.

Both are good on their own. The hybrid model is complex and hard to manage, even though it can technically fulfill most requirements you can think of.

It's a real shame because it means ACL usage is not going to take off anywhere soon.

Re: Posix Has Become Outdated (2016) [pdf]

#16

I know people tend to hold up POSIX compliance as something that's of utmost importance, but from my conversations with Bionic's maintainers, there's an awful lot of cruft and poor designs in some of the POSIX APIs.

POSIX compliance is important if you value portability - especially for business critical systems (e.g. you want your bank's transaction processing data to work on IBM Z/Series's UNIX, whatever Linux distro they use, and say... SunOS). My main takeaway from the article is POSIX is too antiquated and anemic as a "system API" for modern-day use - however I'm surprised the article doesn't seem to touch upon POSIX shortc…

> should we continue to uphold "everything is a file"

POSIX doesn't do a very good job of upholding that. POSIX is full of entities (e.g. notably processes and threads) which can't be manipulated via file descriptors. Some POSIX implementations do better – e.g. FreeBSD's pdfork – but that isn't standardised. By contrast, Windows NT in which "everything is a handle" actually provides a more unified interface to OS objects than POSIX does.

Re: Posix Has Become Outdated (2016) [pdf]

#17
post #14

I know people tend to hold up POSIX compliance as something that's of utmost importance, but from my conversations with Bionic's maintainers, there's an awful lot of cruft and poor designs in some of the POSIX APIs.

One of the primary goals of POSIX was to standardize and encode existing behavior, but the behavior of Unices is sufficiently divergent that many APIs are uselessly underspecified. One especially hilarious case is close being impossible to use correctly in a cross-platform manner: on HP-UX, you must check for EINTR and try again; on Linux, close will close the file descriptor even if interrupted by a signal, so you m…

>> from my conversations with Bionic's maintainers

> jmgao

jesus, you guys come out of the wood work, huh? :D

Re: Posix Has Become Outdated (2016) [pdf]

#19
post #14

Earlier quoted context omitted.

One of the primary goals of POSIX was to standardize and encode existing behavior, but the behavior of Unices is sufficiently divergent that many APIs are uselessly underspecified. One especially hilarious case is close being impossible to use correctly in a cross-platform manner: on HP-UX, you must check for EINTR and try again; on Linux, close will close the file descriptor even if interrupted by a signal, so you m…

>> from my conversations with Bionic's maintainers > jmgao jesus, you guys come out of the wood work, huh? :D

Nothing better to do than rant about POSIX :-)

Re: Posix Has Become Outdated (2016) [pdf]

#20
post #8

Earlier quoted context omitted.

POSIX is neither antiquated nor anemic. There's nothing antiquated about a hierarchical filesystem with a single root. There's nothing antiquated about 'everything is a file'. In fact, that's continually useful to me on a day-to-day basis. There's nothing antiquated about byte streams, which is all they are. They aren't text streams. A great example of how all of this turns out to be good design is that you can see h…

> Java would replace C++, who thought C++ would replace C, who thought Windows would replace Unix All of these have happened, for many use cases.

When I look at large amount of Enterprise software: Yes that happened.... I see Java everywhere. Also think of Android (alone the amount of software). Of course it's seldom exclusively Java in a corporation.
Post reply on HN