Live data from Hacker News

Posix Has Become Outdated (2016) [pdf]

cs.columbia.edu

101–110 of 246 posts

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

#101
post #32

Earlier quoted context omitted.

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

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.

> That's what majority of computer users (smartphones included) use though.

Most computer users access countless sites which run on deep software stacks running on any flavour of linux.

...which run POSIX.

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

#103

Earlier quoted context omitted.

Just curious, can you give me some examples of GNU-isms/macOS-isms? I have a suspicion what they might be, but I'm not sure.

Asynchronous IO, hardly anyone uses the POSIX standard of select and poll anymore, and instead use kqueue (bsd/macOS) and epoll (Linux). I should add that this is for performance critical software.

I'll agree that a lot of people prefer and recommend things like kqueue+kevent over select/poll. But my experience is that the statement that "hardly anyone uses" select/poll is still erroneous.

On an out-of-the-box installation of FreeBSD/TrueOS, most processes listed by "ps" show a wchan of things like ttyin, select, poll, pause, uwait, wait, or nanslp. On the FreeBSD machine that I am typing at right now exactly one program is waiting in kqread, one of the inner processes of Chrome.

Install my nosh toolset, and a fair amount of that changes, because my programs use kqueue+kevent and suddenly the "ps" output is full of kqreads. But what's left is still not "hardly anyone", by a long chalk.

Would that it were! There's a nasty kernel panic somewhere in the innards of the kevent system on FreeBSD, where a sleeping thread holds a non-sleepable lock, that only manifests itself (at least for me) when there are a lot of programs using kqueue+kevent on a system that is doing a lot of stuff. If more people used kqueue+kevent in more programs, there would be more people wanting it fixed. (-:

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

#104
post #32

Earlier quoted context omitted.

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.

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.

Apache almost certainly uses epoll/kqueue.

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

#105
post #84
post #26

Earlier quoted context omitted.

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

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…

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

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

#106
post #24

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.

Try to write a modern iOS, OS X, Windows, Android, ChromeOS UWP with standardized POSIX interfaces .

It's the other way around, really. The OS is what provides the POSIX API to the higher levels of the stack. All of those are POSIX under the hood, and their middleware is dominated by POSIX code that is reasonably portable.

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

#107
post #84

Earlier quoted context omitted.

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…

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

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.

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

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

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

#109
post #95

Earlier quoted context omitted.

That's exactly the point of the report: Hardly anybody uses POSIX. Many people use frameworks on top of it though. If POSIX would go away many won't notice.

Isn't a nice common interface that those frameworks and higher-level language libraries and interpreters can be written for a nice thing? It's like a nice road network, you sure want to be in your car not on the road, but it's better if most of it is good for the common tire, you don't want to change your tires at every turn.

Yes, but the need for those shows that POSIX failed.

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

#110
post #95

Earlier quoted context omitted.

Isn't a nice common interface that those frameworks and higher-level language libraries and interpreters can be written for a nice thing? It's like a nice road network, you sure want to be in your car not on the road, but it's better if most of it is good for the common tire, you don't want to change your tires at every turn.

Yes, but the need for those shows that POSIX failed.

Just like CPU opcodes have failed... POSIX is a low level interface, that of the OS and the C library. It's another level of abstraction, necessary for the ones that are building other levels on top of it.
Post reply on HN