Live data from Hacker News

Posix Has Become Outdated (2016) [pdf]

cs.columbia.edu

71–80 of 246 posts

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

#71
post #44

Earlier quoted context omitted.

> only a small minority of the processes running on an OS X system. Which are anyway not POSIX. https://www.amazon.de/MAC-OS-Internals-Amit-Singh/dp/0321278...

POSIX is an application interface. How OS X is implemented under the hood is irrelevant. It does present an application interface mostly conformant to POSIX standards, so it is some way POSIX.

>so it is some way POSIX.

That's hardly encouraging, when all the basics and all the newer OS X abstractions are based things other than POSIX standards, and ask programmers to connect to them with non-POSIX interfaces.

The fact that it also supports a POSIX layer is about as relevant to what we're discussing (whether POSIX is fit for today's needs and used in today's mainstream development) as the presence of some X Windows translation layer is in Wayland.

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

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

Arguably, you listed the projects that went out of their way heavily to restrict and lock-in users.

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

#73
post #49

Earlier quoted context omitted.

Has it? Sure it is down there on the OS tooling, but how many people outside UNIX devs, do actually bother using it? Personally it doesn't offer me any benefit over an higher level programming language REPL.

At the end of the 80s and throughout the 90s, a common belief was that the CLI could be completely replaced by the GUI, one just hadn't yet figured out how. The GUI, however, never delivered those last 10-20% that you need in automation or in a context that requires reproducibility. Windows NT was designed towards those promises, but eventually Microsoft realised their mistake and created - ten years ago - Powershell…

>At the end of the 80s and throughout the 90s, a common belief was that the CLI could be completely replaced by the GUI

And it has, except for backend programmers. Most Windows programmers stay all day in Visual Studio and the like, for example.

But as far as end users as concerned, that is the 99% of computer users, the CLI might as well not exist.

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

#74
post #49

Earlier quoted context omitted.

Has it? Sure it is down there on the OS tooling, but how many people outside UNIX devs, do actually bother using it? Personally it doesn't offer me any benefit over an higher level programming language REPL.

At the end of the 80s and throughout the 90s, a common belief was that the CLI could be completely replaced by the GUI, one just hadn't yet figured out how. The GUI, however, never delivered those last 10-20% that you need in automation or in a context that requires reproducibility. Windows NT was designed towards those promises, but eventually Microsoft realised their mistake and created - ten years ago - Powershell…

Microsoft didn't have a mistake to realize. From very early on, one of the must-have toolsets for Windows NT was the Windows NT Resource Kit, with a whole bunch of command-line tools -- provided by Microsoft. There was in fact a whole load of command-line tooling for Windows NT, well before PowerShell and back to version 3.1 .

Far from this being the reversal that you propound, actual history is even more in favour of your argument. (-:

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

#75
post #24

Earlier quoted context omitted.

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

Arguably, you listed the projects that went out of their way heavily to restrict and lock-in users.

Isn't the point that those are the most prolific platforms, where a common API to the system, POSIX, would be most beneficial to us as developers? But it's simply not possible to do?

From what I can tell POSIX has been replaced by per language stdlibs, with the portability of your software tied to the portability of a languages stdlib.

POSIX was mainly designed for C, most other languages have a higher level abstraction.

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

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

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.

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

#77

Sometimes I wish ACLs were better supported.

Who has put ACLs to good use anyway? Even the old model usually forces one to overspecify one's intent. It's too easy to shoot in your foot, and too hard to figure out what you need in the first place.

I doubt there is a good general purpose permission model that's more complex than Unix modes.

Collaboration on filesystems just doesn't work very well. It could work for many small groups if files had no users associated and everybody had just R and W bits for a whole repository.

For special problems there are specialized solutions. For example distributed models like git, or complex client-server solutions.

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

#78
post #73

Earlier quoted context omitted.

At the end of the 80s and throughout the 90s, a common belief was that the CLI could be completely replaced by the GUI, one just hadn't yet figured out how. The GUI, however, never delivered those last 10-20% that you need in automation or in a context that requires reproducibility. Windows NT was designed towards those promises, but eventually Microsoft realised their mistake and created - ten years ago - Powershell…

> At the end of the 80s and throughout the 90s, a common belief was that the CLI could be completely replaced by the GUI And it has, except for backend programmers. Most Windows programmers stay all day in Visual Studio and the like, for example. But as far as end users as concerned, that is the 99% of computer users, the CLI might as well not exist.

Ok. I'll bite. You're speaking from the perspective of someone locked into a way of doing work through the GUI, limiting your development experience to that of what the GUI developer (MS in this case) has provided you.

The CLI offers an infinitely combinable and customizable development experience, where huge ammounts of innovation have been occuring. You can see this in modern web development toolchains and new build tools for new languages, which simply would not happen if you restrict your Dev experience to just the GUI. I keep going back to just creating Makefiles for simple automation tasks.

Even the GUIs are starting to learn from this, which is why I think VSCode and Atom are becoming popular; they make it very simple to integrate new CLI tools into the GUIs workflow.

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

#79

Sometimes I wish ACLs were better supported.

POSIX ACLs, nee TRUSIX ACLs, are one of several ironies of the world of international standardization. Whilst the attempt to produce a formal standards document for them failed, they actually got implemented in many operating systems anyway with a fair degree of consistency. So whilst they are not de jure standardized, one can enjoy the de facto existence of tools like getfacl and setfacl across multiple operating systems today.

That said, I agree that it would be most welcome if there were fewer niches where ACLs are still wholly unavailable: OpenBSD, tmpfs filesystems on FreeBSD, and so forth.

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

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

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

Post reply on HN