www. O S N E W S .com
News Features Interviews
BlogContact Editorials
.
POSIX has become outdated
By Thom Holwerda on 2017-02-13 22:57:41

The POSIX standard for APIs was developed over 25 years ago. We explored how applications in Android, OS X, and Ubuntu Linux use these interfaces today and found that weaknesses or deficiencies in POSIX have led to divergence in how modern applications use the POSIX APIs. In this article, we present our analysis of over a million applications and show how developers have created workarounds to shortcut POSIX and implement functionality missing from POSIX.

 Email a friend - Printer friendly - Related stories
.
Read Comments: 1-10 -- 11-20 -- 21-29
.
TL;DR
By franzrogar on 2017-02-14 00:10:24
POSIX can never be *outdated* as a Chair can't either.

POSIX can be *deprecated* at most, or, if there were a versioning system, it could get *new releases*.

Having cleared this, someone must be truly stupid to think the system was designed with *hassle-free, perfection, simplicity, etc.* in mind as such think will never exist (we can debate if it will be, but believe me, it won't as each program has different requierements from others).

So, we have something that can't be deprecated, something that (when designed) it was obvious that it had flaws.

Now, you're jumping because POSIX didn't take care/in mind during designing some hardware that weren't even dreamt about (GPUs for heavy 3D, VR, touchscreens, etc.) Hell, point me to one that can design something with *future* optimization that I will hire him/her right now!

So, POSIX can't be deprecated, it had known flaws when designed, and you're screaming it doesn't work perfectly with hardware to be designed in the future...

Resuming: nothing to see, move along.
Permalink - Score: 7
.
I can't read all the paper.
By DEF- on 2017-02-14 00:23:51
I stopped at
"IPC in Linux: The D-Bus protocol"

People who wrote the article have obviously no idea what the Linux IPC is.
Permalink - Score: 2
.
Posix
By Alfman on 2017-02-14 00:30:48
It was not so long ago many of us were complaining about posix, I guess it's about time we get an article about it :)


I agree with many of their assertions. We do see a lot of functional divergence from posix in several areas (ipc, aio, gpu, threading). Kernels, frameworks, languages have evolved but posix mostly has not leaving us to work around it with platform specific code.

Posix isn't going anywhere though, nobody wants to pay to rewrite all that software!
Permalink - Score: 3
.
RE: TL;DR
By kwan_e on 2017-02-14 00:37:52
POSIX has always existed as a few steps behind what had already been implemented, so really, it is, by design, outdated.
Permalink - Score: 2
.
RE: I can't read all the paper.
By Alfman on 2017-02-14 00:39:46
DEF-,

> I stopped at
"IPC in Linux: The D-Bus protocol"

People who wrote the article have obviously no idea what the Linux IPC is.


I believe they were talking about kdbus, which was supposed to be added to the linux kernel in order to support systemd.


Edit: I guess kdbus never got merged, or rather it did and then got pulled due to controversies.

http://www.linuxtoday.com/infras...

> kdbus is a somewhat contentious kernel patch that is intended to provide the dbus api in kernel space. It is a kernel implementation for dbus (user space), with the initial beneficiary of the merge the systemd software that is present on most recent distributions. With linux 4.3rc1 released (which does not include kdbus), linux-next has been made available, and it does indeed include kdbus.

https://en.wikipedia.org/wiki/D-B...
> kdbus was a project that aimed to reimplement D-Bus as a kernel-mediated peer-to-peer inter-process communication mechanism. Beside performance improvements, kdbus would have advantages arising from other Linux kernel features such as namespaces and auditing,[30][34] security from the kernel mediating, closing race conditions, and allowing D-Bus to be used during boot and shutdown (as needed by systemd).[35] kdbus inclusion in the Linux kernel was proved controversial,[36] and was dropped in favor of BUS1, as a more generic inter-process communication.[37]

http://www.bus1.org/
> Bus1 is a subsystem to provide object-oriented Inter-Process Communication on Linux. It is a lightweight and scalable way for services and operating system tasks to share signals, data and resources; while at the same time allowing modularization, privilege separation, information hiding and isolation.


Obviously the linux kernel (and other operating systems) also support the standard IPC functionality defined by POSIX, but the paper was looking at ways that applications are increasingly sidestepping POSIX.

Edited 2017-02-14 00:58 UTC
Permalink - Score: 3
.
Some nice ideas there
By zlynx on 2017-02-14 01:19:46
I like the ideas on asynchronous file write completions. That would be far more useful than waiting on fsync().

And it would be great if someone in POSIX made it a requirement that rename() be atomic always, on running systems and after crash recovery.
Permalink - Score: 2
.
Hum ..
By acobar on 2017-02-14 01:24:31
I was hoping for a bit more profound discussion about the shortcomings of posix when dealing with internationalization and IPC.

To expect that the complexity of modern graphics and input interactions to be covered by posix is, frankly, a bit naive. It is something that changed a lot on every OS and on Linux we are in the middle of a transition to Wayland. It is something better left to other standard bodies.

As noted by others, the article is not up-to-date when talking about the Linux IPC, perhaps because it was published on 2016 fall and many things ended taking a different path.

Last, someone should correct the funny assertion they left close to the end of the article: :p
> For example, the libglib, libQtCore, and libnspr all provide high-level thread abstractions based on the GNOME desktop environment.

Edited 2017-02-14 01:27 UTC
Permalink - Score: 3
.
RE: TL;DR
By ssokolow on 2017-02-14 01:39:09
> POSIX can never be *outdated* as a Chair can't either.

Did you read it all the way through?

Yes, they point out that graphics are one of the biggest non-POSIX things to do, but then they continue on to explore how the two runners-up are examples of things POSIX does provide which are being reinvented because the POSIX offerings are insufficient for modern uses. That sounds like the definition of "outdated" to me.

Those cases are:

* IPC: Using platform-specific in-kernel solutions like Binder and Mach IPC in place of pipes and UNIX domain sockets because the POSIX-specified ones scale poorly compared to modern zero-copy/handle-passing solutions.

* Async I/O: Replacing POSIX interfaces like select with non-standard but better-performing interfaces like epoll, kqueue, etc. and building event+threadpool abstractions which all work roughly the same way but have incompatible APIs.

Edited 2017-02-14 01:41 UTC
Permalink - Score: 4
.
KISS
By judgen on 2017-02-14 01:59:24
Next you are going to tell me that flat is beautiful and KISS is no longer valid as a design principle?
Permalink - Score: 4
.
RE: Posix
By Brendan on 2017-02-14 04:05:23
Hi,

> Posix isn't going anywhere though, nobody wants to pay to rewrite all that software!

We'll just end up with the equivalent of a "POSIX compatibility layer" within Linux (and other "*nix-like" OSs); where modern software bypasses most of POSIX, but it still exists (within a "POSIX standard shared library" that's implemented on top of the kernel's "not POSIX at all" kernel API) for old software.

- Brendan
Permalink - Score: 3

Read Comments 1-10 -- 11-20 -- 21-29

No new comments are allowed for stories older than 10 days.
This story is now archived.

.
News Features Interviews
BlogContact Editorials
.
WAP site - RSS feed
© OSNews LLC 1997-2007. All Rights Reserved.
The readers' comments are owned and a responsibility of whoever posted them.
Prefer the desktop version of OSNews?