
Posix Has Become Outdated (2016) [pdf] - pjmlp
http://www.cs.columbia.edu/~vatlidak/resources/POSIXmagazine.pdf
======
Animats
Reasonable enough. The article focuses on client-side programs, especially
Android, which have somewhat different requirements than the Posix model
envisions. Most of the things you need to do on headless servers can be done
through the Posix model.

The big weaknesses in Posix they point out are in interprocess communication
and parallelism. Both were afterthoughts in UNIX. UNIX/Linux land never had a
good IPC mechanism. (As a former QNX user, I've seen this done right; check
out MsgSend/MsgRecv there.) Posix thread-level locking primitives tend to be
too slow, but that's partly a hardware support problem. Async I/O now seems to
be popular; networks are so slow on mobile, and servers have scaled to the
point that dispatching overhead for all the running threads gets to be a
problem.

Yes, Posix doesn't do graphics. That's good; if it had a window API, everybody
would be complaining about it. Look at the KDE/Gnome wars, or the
OpenGL/Direct-X wars.

Here's what I'd change in Posix.

On the file system front, I occasionally argue that UNIX/Linux/Posix file
system semantics should be slightly different. There should be several types
of files. "Unit files", the normal case, can only be changed in their
entirety. Opening a unit file for writing should create a new file, and on
successful close (not program exit, abort, or system crash) the new version
replaces the old version for future opens. Today, you still have to jump
through hoops to do atomic file replace, and the hoops are different for
different OSs. Posix doesn't address this. This is something that should Just
Work as the default file semantics.

"Log files" should just extend. This is what opening for append should do. You
can't go back and overwrite. On an abort or system crash, the end of the file
should be at the end of some recent write, and correct out to the last byte of
the file length. Logging may be behind after a crash, but should never trail
off into garbage.

"Managed files" are for databases. You would get two async I/O completions -
one when the OS has accepted the write, and one when it's safely committed to
disk/flash. Rather than flushing, database programs would usually wait for the
commit completion. This would be a special mode asked for with an "ioctl"
call, used only by the few programs that really care about database recovery.
The database people would love to have well-defined semantics like this.

"Temp" files (in /tmp or some designated directory) would have only the
guarantee that after a crash, they're gone.

On the interprocess communication front, I'd copy MsgSend, MsgRecv, and
MsgReply from QNX. That's subroutine-call type IPC; send a message and wait
for a reply back. This is what you usually want for multi-process programs.
Connection setup could be improved over QNX; the mechanism for finding the
receive port in another process needs to be improved and there should be at
least one well-known port number (like stdin/stdout/stderr are 0,1, and 2)
that each process uses first. This needs to be integrated with the CPU
dispatcher, as it is in QNX, so that when you do a MsgSend, the sending thread
blocks and the receiving thread unblocks without going through the scheduler.
Otherwise, you go to the back of the line for the CPU on each interprocess
call.

~~~
qznc
I don't know QNX, but for IPC you should also take a good look at the L4
microkernel IPCs. It might be what you describe here. The point is that they
are fast. Nearly function-call-speed.

The should probably a more complex IPC layer on top or beside it. Something
like DBus with schemas, names, groups, broadcasts, etc because otherwise
people will reinvent it poorly.

~~~
wolfgke
> The should probably a more complex IPC layer on top or beside it. Something
> like DBus with schemas, names, groups, broadcasts, etc because otherwise
> people will reinvent it poorly.

People also tend to reinvent stuff poorly that they consider as "bloated" or
"unnecessarily complex for their use case". I just say C++ vs. Java (Java was
indeed also marketed at the beginning that C++ is unnecessarily complex;
besides the famous "write once, runs everywhere"), XML vs. JSON, CORBA vs.
SOAP (no, please don't start a flame war which of these is the better one ;-)
).

~~~
ethbro
I'd sum it up in terms of "standards bodies / enterprise would be perfectly
happy if everything were ossified in a form that encompassed all possible use
cases, regardless of complexity."

Whereas reimplementation in a lighter weight protocol is usually the result of
"devs don't want to deal with the above when it isn't needed for 80% of common
use cases."

------
notacoward
They managed to write an entire article about POSIX and never mention the
filesystem parts? Even the section about "asynchronous I/O" seems to have more
to do with locking than actual I/O. Nothing about directory operations,
permission models, consistency/durability requirements, and all the other
things that make _that_ part of POSIX the most egregiously out of date. I
wrote a bit about this ([http://pl.atyp.us/2016-05-updating-
posix.html](http://pl.atyp.us/2016-05-updating-posix.html)) and barely
scratched the surface. I wish they'd dared to go there too.

~~~
JdeBP
There's a whole lot of POSIX that they didn't mention. They concentrated upon
the system call API and left out all of the concepts (character sets, locale,
environment variables, regular expressions, command line conventions), the
filesystem, the shell, and the utilities.

~~~
notacoward
They didn't even cover the system call API.

~~~
gens
Yep, only libc. And only for some popularly installed (after system install)
programs.

>We selected these apps from the official marketplaces for each OS: Google
Play (45 apps), Apple AppStore (10 apps), and Ubuntu Software Center (45
apps). We chose popular apps based on the number of installs, selecting apps
across nine categories, ..

So mostly GUI programs. Not to mention that probably all those "apps" call
into libc eventually (even android ones).

Only thing this made me think about is "why is this taken seriously here?".

------
cperciva
_The original goal of the POSIX standard was application source code
portability. However, modern applications are no longer being written to
standardized POSIX interfaces._

Speak for yourself.

~~~
pjmlp
Try to write a modern iOS, OS X, Windows, Android, ChromeOS UWP with
_standardized POSIX interfaces_.

~~~
cperciva
You (and the authors of the article) seem to be assuming that "modern
applications" are by definition applications with graphical user interfaces.

~~~
kccqzy
That's what majority of computer users (smartphones included) use though. As
for developer-oriented CLI tools, I've also seen more and more GNU-isms and
macOS-isms creeping in.

~~~
tmalsburg2
Counter example: Almost everyone uses the Apache webserver when they browse
the web, but hardly anyone even knows what that is. We could easily compile a
long list of similar crucial infrastructure software that virtually everyone
is using and that doesn't have graphical user interfaces.

~~~
gm-conspiracy
_Almost everyone uses the Apache webserver when they browse the web_

No.

[https://news.netcraft.com/archives/category/web-server-
surve...](https://news.netcraft.com/archives/category/web-server-survey/)

~~~
tmalsburg2
Reading comprehension. I did not say that people only visit pages that are
served by Apache. Even if Apache has just 20% market share there is a very
high chance that you will hit some pages served by Apache. Plus, the same
argument really applies to most alternatives to Apache.

------
MrTonyD
Glancing at the article I think it misses an important aspect. I lived through
the creation of the POSIX spec and reported to a CEO involved. POSIX is a
political spec.

Customers were complaining to DEC, SUN, IBM, etc about how confused they were
using UNIX (think of the same Linux fragmentation today.) Major customer
groups got together and said they would switch to Windows if the companies
didn't create a stable environment for UNIX work. So the company CEOs got
together before the "official" POSIX meetings to decide how little they could
standardize (and cut their own costs) while still allowing them to have their
important differentiators for sales. They decided that integrating the
programming API and some minimal administration aspects would be the right
approach. So they then got staff involved in the series of POSIX meetings to
decide the spec (not telling them explicitly about the initial agreements
between the CEOs)

Really, there is a lesson here. Customers (us) need to force the Linux vendors
to create a more uniform experience for us. It doesn't "just happen". There is
too much arbitrary variation (with no real benefit) and the learning curve is
just absurdly hard for working with Linux (which is old enough that all the
basic operations should be quite stable - and mostly quite simple.)

~~~
derekp7
Whatever happened to Linux Standard Base? I don't ever see any apps compiled
against that specification. Is this simply because it is out of date, or
incomplete?

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

~~~
DaiPlusPlus
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 shortcomings instead being a consequence of the UNIX
design philosophy - a strong personal concern of mine regards UNIX-like's
future development course - should we continue to uphold "everything is a
file", ioctl(), and piping text-streams as the best way to build an OS?

Curiously, the article chides POSIX for lacking modern abstractions
(specifically, graphics) but I disagree - POSIX would be a disaster if it
included anything like OpenGL or Cairo (case-in-point: Win32 is tightly
coupled with GDI and now we're paying the price by being physically unable to
do deep-color graphics in Win32 without serious hacks) - I think that (to
paraphrase one of the UNIX philosophies) "small APIs that do one thing and do
it well" applies to POSIX (as it does process and system management, and
nothing else) and it has worked.

Coming from a modern Windows developer experience - I think there's a great
deal to be learned from the failures of the vaporware "object-oriented
operating system" concepts of the mid-1990s and how the concept has been
resurrected in the form of PowerShell object-piping and WinMD today and should
be explored as the next possible step in OS design at a fundamental level -
not just as a shim on top as it is with Windows.

That said, UNIX and GNU/Linux have always evolved in small steps - pretty much
every great-leap-forward is doomed to failure or endless ideological
controversy (see `systemd`) so maybe UNIX-like OSes are not the right place to
test new design concepts - but some new OS will - and eventually that OS will
supersede Linux in the way many people believe Rust will replace C++.

~~~
milesrout
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 how easily UNIX-based systems adopted Unicode. Say what you like about
byte streams as a universal interface, but it sure was easy to switch from
ASCII to UTF-8 when your system APIs weren't all built around the idea that
everything would be encoded in a particular way.

I don't think systemd is unpopular or controversial because it's a great leap
forward. That's just buying into the propaganda. It's unpopular and
controversial because it _presents itself_ as a great leap forward _while not
being one_.

>but some new OS will - and eventually that OS will supersede Linux in the way
many people believe Rust will replace C++.

C++ hasn't even replaced C. Why would Rust replace C++? When has a popular,
stable, architecturally-important language ever been replaced?

The sort of people that think that Rust will replace C++ are the sort of
people who thought Java would replace C++, who thought C++ would replace C,
who thought Windows would replace Unix and who think that another system of
opaque proprietary object-oriented APIs will replace POSIX. They're wrong, in
every way.

~~~
moby_click
> There's nothing antiquated about a hierarchical filesystem with a single
> root.

Unfortunately the hierarchical structure is lost in the name. It's one flat
string and '/' and NUL have special meaning.

In a way, containers show that there is a legitimate need for multiple roots.

~~~
gaius
Containers are to a large extent a solution to an artificial problem. It your
app is a single binary file + a single text configuration file with no
dependencies apart from system libraries (i.e. libc POSIX) then you don't need
a container, you're just a process. Containers are necessary because
applications now consist of hundreds of small files with complex inter- and
external dependencies.

~~~
qznc
You still want the additional security, if your daemon gets compromised.

You still want to restrict resources (number of cores, memory, etc).

Nevertheless, I agree that containers are often a cut through Gordian Knot.
Just put everything in its own box instead of resolving dependencies.

~~~
milesrout
Containers don't provide additional security, nor do they provide additional
ways to restrict resources. If you want to restrict resources or sandbox
programmes, you can do so without containers.

------
vatlidak
Thanks for sharing it guys.

Here is our project site:
[https://columbia.github.io/libtrack/](https://columbia.github.io/libtrack/)

and our github repo:
[https://github.com/columbia/libtrack](https://github.com/columbia/libtrack)

------
maxlybbert
The paper talks about a very small portion of POSIX. I thought they'd mention
things like
[http://pubs.opengroup.org/onlinepubs/009695399/functions/hse...](http://pubs.opengroup.org/onlinepubs/009695399/functions/hsearch.html)
.

For the record, I'm always sad when I can't do everything I want in POSIX and
need to use, say, Apache APR (to support Windows), or the C++ standard library
(to support Windows), especially in cases where I don't stray far from what
POSIX supports. (I am not sad when I use something that actually adds value
over POSIX; e.g., I like using C++ regexes instead of POSIX regexes because I
don't have to guess how many matches I might have; and I'm happy to use
std::unordered_map -- or the APR equivalent -- because I can have more than
one at a time).

------
gens
First i looked at who made the paper (since it is right there on the first
page) and thought "oh, this should be detailed and objective". But alas it was
neither...

Android cares about POSIX about as much as Windows. Programs that were tested
were from "app stores", based on the popularity of downloads from same. POSIX
equals only libc in this study. Actually i could poke holes in this study all
day. Just want to say that it is very much not an objective one.

PS I even went above the first sentence that talks about age as if it matters.

------
JdeBP
Actually, _this paper_ is outdated. What it states about kdbus and its
prospects is wrong, for example.

------
fortytw2
POSIX has been outdated since the day it was released. Talk about binding OS
development to the absolute lowest common denominator, (requiring the presence
of a fortran compiler -
[http://pubs.opengroup.org/onlinepubs/9699919799/](http://pubs.opengroup.org/onlinepubs/9699919799/)
\- really?) and every additional release simply adds more bloat.

------
chetanahuja
> The original goal of the POSIX standard was application source code
> portability. However, modern applications are no longer being written to
> standardized POSIX interfaces.

This is a weird claim to make. The three OS's that they're talking about
(desktop Linux, iOS and Android) all have plenty of popular applications
written directly at the Posix API level.

Heck, when we were architecting our mobile-network-enabler stack that had
client side and server side components (all in user-space), it was a no-
brainer for us to just pick the posix API as our base and we designed and
wrote a lot of native level code that "just worked" on all three platforms.

Even if there's any sort of framework layer between the application and the
system, the Posix semantics are so deeply embedded in the culture of
programming today that frameworks can say things like "this API opens a new
file for write" without having to explain what all that means. The very
language we use to architect a solution has deep, unspoken assumptions built-
in, and it's more or less based on what Posix semantics allow.

------
dfox
I don't think that the articles addresses the real problem with POSIX/SuS. The
fact that SuS does not deal with GUI is feature, also there are no OS
implemented complex syscall multiplexers on top of ioctl() for that, such
multiplexing happens in hardware. (Try stracing glxgears, with my radeon it
calls ioctl quite heavily, but only uses two functions, both of them are
essentially "wait for interrupt from hardware")

What I see as biger problem is that current Single UNIX Specification is that
it essentially has nothing to do with UNIX. On the list of certified
conforming systems, there is Solaris (which does not implement all the
optional modules one would expect from something that _IS_ derived from SysV),
z/OS and bunch of embedded RTOSes noone ever heard about. And if you look on
what is required and how underspecified some things are, you can make
"Certified UNIX" out of MS-DOS by rewriting the userspace tools and writing
libc with "POSIX-ly correct" syscall names.

------
kazinator
Though the article begins by noting that POSIX was first developed over 25
years ago, that opener is actually misleading and sets the wrong tone for the
article's content.

POSIX has been continuously developed since the first version was ratified.

The POSIX of 25 years ago didn't have threads or async I/O, for instance.

Then what the article criticizes is precisely the lack of use _of mostly the
newer stuff_ from POSIX, not of what was developed over 25 years ago.

Nowhere do I see the claim that functions like open, unlink or chdir are being
replaced by something home-spun in Java or what have you.

So the argument boils down to this TL;DR: _" new activity in POSIX over the
past quarter century has been increasingly bloating the specification with
committee-designed cruft that few applications use."_

------
planteen
This article is biased towards desktop environments, but misses embedded.

Lots of RTOSes are POSIX compliant for things like Pthreds and file systems.
Off the top of my head, VxWorks, RTEMS, INTEGRITY, and QNX all have POSIX
compatability.

------
jonathankoren
Sometimes I wish ACLs were better supported.

~~~
ndesaulniers
Isn't that what SELinux is for when they say it's Mandatory Access Control? Or
are those two different things?

~~~
LukeShu
MAC and ACL are two different things.

On Linux, ACL is the "facl" family of functions functions (and the set/getfacl
programs). These supplement the traditional owner/group and mode bits.
Essentially, it allows you to set a separate set of read/write/execute bits on
a file for an arbitrary number of specific users or groups, rather than being
limited to simply "owner", "group", "everyone-else". If anything is set beyond
the normal owner/group/world, GNU `ls -l` indicates this with a "+" next to
the normal mode bits. I'm unsure how much this changes for other kernels.

~~~
rleigh
Linux supports POSIX.1e DRAFT ACLs. These are a de-facto standard by
implementation, but were never formally standardised by POSIX. They are also
supported by other kernels.

However, other systems support the more modern and featureful NFSv4 ACLs.
NFSv4 ACLs are supported by the NFSv4 filesytem and also used by ZFS. They are
part of the NFSv4 formal specification. On systems supporting ZFS (other than
Linux), you get the full NFSv4 ACL support. Linux doesn't have VFS support for
NFSv4 ACLs, and doesn't expose them even for NFSv4 mounts. In contrast, a
FreeBSD mount of an NFSv4 filesystem served from ZFS exposes the full
permissions model to the client. FreeBSD has a separate set of richer acl_*
functions rather than the get/setfacl functions on Linux.

Linux:

    
    
      % getfacl ~/.zshrc 
      getfacl: Removing leading '/' from absolute path names
      # file: home/rleigh/.zshrc
      # owner: rleigh
      # group: rleigh
      user::rw-
      group::r--
      other::r--
    

FreeBSD:

    
    
      % getfacl ~/.zshrc 
      # file: /home/rleigh/.zshrc
      # owner: rleigh
      # group: rleigh
                  owner@:rw-p--aARWcCos:-------:allow
                  group@:r-----a-R-c--s:-------:allow
               everyone@:r-----a-R-c--s:-------:allow
    

Linux really needs to get proper support for NFSv4 ACLs.

~~~
vetinari
> Linux really needs to get proper support for NFSv4 ACLs.

Not to nitpick, but: why would it need to do that? Nobody (in Joel Spolsky
definition of nobody) cares about NFSv4. The only place where ACL matters for
Linux users is Samba. And Samba works fine with Linux ACLs as it is.

~~~
rleigh
Most people aren't aware of what they are missing and how it could bring a
great deal of benefit.

This isn't about NFSv4 (the filesystem), it's about the rich permissions model
it standardised which is now used by more than just NFS. It's used by ZFS, and
it's used by the FreeBSD and Solaris VFS, and likely others as well. It's the
only rich ACL model in real use today on open platforms, and being a superset
of both POSIX.1e DRAFT and Windows ACLs, it's needed for full interoperability
between platforms.

Samba doesn't "work fine" except for the simple case. Using it with groups and
group permissions can be exceedingly painful. When I export a ZFS filesystem
on FreeBSD over Samba, it exposes the full ACL model to the Windows client
which is accessible and manipulable via the standard security properties as
well as the command-line on the server or and NFSv4 clients.

When working with group permissions locally or over NFSv4 or CIFS, you aren't
restricted to the pitiful group and setgid permissions offered by the standard
UNIX permissions or even POSIX.1e ACLs. You can add an @group ACE detailing
the group access permissions and their inheritance, or custom ones per user,
which can make working on shared data much simpler. No more pain when someone
with a broken umask adds something and strips off the group permissions, or
they drop the setgid bit and the inheritance is lost, or they access it via
samba and it sets the wrong group ownership or permissions. All of which I see
regularly on shares exported from Linux. We often have to export the same
share multiple times with different configuration to work around the
limitations (read-only, group and group perms), where if it was using proper
ACLs just one would work for all cases.

~~~
vetinari
Thank you for your detailed answer.

However, your first sentence is valid for many things, not just ACLs. For
example, there are people (ehm, me) who value being able to have Kerberos
tickets for multiple principals from multiple KDCs at the same time. This is
something that the most popular OS (Windows) is not able to do - and nobody
minds. Because for most people, being part of one domain is good enough.

With ACLs, I find it similar. For most people, the complexity is too high, the
reasoning about them so complicated, so there's no benefit to have them
available, they won't use them anyway. Also, in our case, we just have
multiple groups at the root of samba share and that's it. It is good enough.
So maybe it is yet another case of worse is better.

------
kitsuac
Yes as usual everything the world is built on top of is totally wrong. POSIX,
C++, any conservative principle, any majority race or sexuality etc.

It's easy to criticize everything endlessly, much more challenging to make
things better without tossing out the babies with the bathwater.

------
peterwwillis
POSIX was outdated 10 years after its invention. But nobody wants to make
another POSIX.

------
gaius
Those who forget POSIX are doomed to reinvent it, poorly.

