Live data from Hacker News

Posix Has Become Outdated (2016) [pdf]

cs.columbia.edu

41–50 of 246 posts

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

#41

Earlier quoted context omitted.

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…

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…

who thought Windows would replace Unix

Windows now runs all the workloads that Sun, SGI, DEC, HP, IBM yadda yadda workstations once ran. I don't remember the last time I saw a real Unix workstation outside my home office where I keep an Octane for nostalgia's sake, and the wife has her old SPARCstation.

But you are right about C and POSIX.

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

#42

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.

Colin I think you're being a little pedantic. You can use context to infer what they mean. This is their application list: https://github.com/columbia/libtrack/blob/master/workloads/o...

Looking at that list, I'm struck by the fact that it includes most of the applications users know they're using, but only a small minority of the processes running on an OS X system.

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

#43

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…

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

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.

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

#44

Earlier quoted context omitted.

Colin I think you're being a little pedantic. You can use context to infer what they mean. This is their application list: https://github.com/columbia/libtrack/blob/master/workloads/o...

Looking at that list, I'm struck by the fact that it includes most of the applications users know they're using, but only a small minority of the processes running on an OS X system.

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

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

#45

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.

Totally agree, the authors seem to be missing the point that these libraries are a new layer between the posix api's and the end result which is typically a GUI application. The fact these libraries also bring a walled garden to the table which bypass the posix api's also demonstrate how security is being bypassed. Plus with the analysis only featuring the 3 os's Android, OS X and Ubuntu, they would have noticed that Windows OS's pretty much mirror what POSIX does as well.

1 "usage is driven by high-level frameworks, which impacts POSIX’s portability goals.", that's the libraries/frameworks fault, plus have they heard of GCC? It works on many OS's.

2 "extension APIs, namely ioctl, dominate modern POSIX usage patterns as OS developers increasingly use them to build support for abstractions missing from the POSIX standard" Perhaps they have missed the point, that without the POSIX standard these extensions would not exist in the first place. They might just complain about procedural coding practices being outdated when comparing to OOP coding practices, even though OOP brings slow bloat to the table as well. Perhaps a better question to ask is, why has a framework/library got some functionality which could have used some of the POSIX api's but didn't? Was it expedient to keep it within the framework/library and bypass the Posix API's altogether?

3."new abstractions are arising, driven by the same POSIX limitations across the three OSes, but the new abstractions are not converging." So abstractions are a new name for libraries and framework and not the concept like OOP coding is an abstraction. Perhaps complaining to the authors of libraries and frameworks that don't port would be better? POSIX is like a foundation that allows creativity to take place. This is why we see the differences in libs/frameworks, different OS's have different parameters, different design ethos or objectives. Even in Windows, some API's are used more frequently than others, for example I cant remember when I last used the API's involved in getting a dial up modem to work, or using API's to print direct to a dot matrix printer. This paper just seems to be an analysis of API's not used as frequently as they used to be, sometimes because libraries/frameworks have rightly or wrongly replaced them for a myriad of reasons.

Qudos to them for downloading so many apps and analysing them though. Just what you need if you are looking for backdoors en-masse or exploitable bugs.

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

#46
post #35

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.

If I wanted to stay with CLI applications, MS-DOS would be enough. UNIX got X Windows in 1987.

CLI and GUI have different grammars and capabilities. If you think that CLI means "prehistory" and GUI means "future", then ask yourself why CLI has "survived" GUI for at least 30 years.

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

#47
post #43

Earlier quoted context omitted.

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

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.

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.

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

#48
post #39
post #23

Earlier quoted context omitted.

Are you developing those C++ applications for the enterprise? Can you disclose which type of full stack applications are those?

In my case a bunch of microservices. This included a rewrite of a legacy monolithic service written in Python. The C++ rewrite was not only more efficient and maintainable, but also ended up with a quite a few more features fitting in a smaller codebase. People do underestimate the value of rewrite from scratch, which when paired with a redesign trumps any language advantage. My wife's work was (she's full time paren…

Thanks for replying.

I would say that you could probably have gotten the same benefits from rewriting the Python system into any AOT compiled language, like Go for example.

We have been doing such rewrites to Java and .NET stacks, with some C++ only on "as little as possible" basis.

Frontend apps are only done in C++, actually QML, if they need to be native cross platform.

Otherwise they are either native to the OS (WPF, Android, Cocoa) or pure web.

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

#49
post #35

Earlier quoted context omitted.

If I wanted to stay with CLI applications, MS-DOS would be enough. UNIX got X Windows in 1987.

CLI and GUI have different grammars and capabilities. If you think that CLI means "prehistory" and GUI means "future", then ask yourself why CLI has "survived" GUI for at least 30 years.

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.

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

#50
post #30

Earlier quoted context omitted.

"There are literally dozens of us!" FWIW, I think C++ is killing it on mobile and many other platforms and disagree with the post you responded to. Just pointing out that 2 samples isn't statistically significant.

Where are the C++ killer applications on iOS and Android, besides game engines, written 100% in C++? Where is C++ on the iOS and Android documentation versus Objective-C, Swift and Java?

Clang, LLVM, WebKit, Chrome/Blink?
Post reply on HN