31–40 of 246 posts
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 .
Earlier quoted context omitted.
Try to write a modern iOS, OS X, Windows, Android, ChromeOS UWP with standardized POSIX interfaces .
You (and the authors of the article) seem to be assuming that "modern applications" are by definition applications with graphical user interfaces.
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…
> should we continue to uphold "everything is a file" POSIX doesn't do a very good job of upholding that. POSIX is full of entities (e.g. notably processes and threads) which can't be manipulated via file descriptors. Some POSIX implementations do better – e.g. FreeBSD's pdfork – but that isn't standardised. By contrast, Windows NT in which "everything is a handle" actually provides a more unified interface to OS obj…
Well there is /proc
Earlier quoted context omitted.
Try to write a modern iOS, OS X, Windows, Android, ChromeOS UWP with standardized POSIX interfaces .
You (and the authors of the article) seem to be assuming that "modern applications" are by definition applications with graphical user interfaces.
This is their application list:
https://github.com/columbia/libtrack/blob/master/workloads/o...
Earlier quoted context omitted.
Try to write a modern iOS, OS X, Windows, Android, ChromeOS UWP with standardized POSIX interfaces .
You (and the authors of the article) seem to be assuming that "modern applications" are by definition applications with graphical user interfaces.
UNIX got X Windows in 1987.
Sometimes I wish ACLs were better supported.
Isn't that what SELinux is for when they say it's Mandatory Access Control? Or are those two different things?
Earlier quoted context omitted.
> should we continue to uphold "everything is a file" POSIX doesn't do a very good job of upholding that. POSIX is full of entities (e.g. notably processes and threads) which can't be manipulated via file descriptors. Some POSIX implementations do better – e.g. FreeBSD's pdfork – but that isn't standardised. By contrast, Windows NT in which "everything is a handle" actually provides a more unified interface to OS obj…
> POSIX is full of entities (e.g. notably processes and threads) which can't be manipulated via file descriptors. Well there is /proc
Also, Linux /proc doesn't really allow you to treat processes as file descriptors like FreeBSD's pdfork does. Sure, I can open /proc/123, but operations on the resulting file descriptor have no relationship with the process – if I pass the FD into a select() I won't get any notifications about the process lifecycle.
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…
How did you come to that conclusion? The bulk of the controversy I've seen about systemd has nothing to do with hype, the controversy I've seen has largely been focused on its invasiveness.
Earlier quoted context omitted.
> No one writes full stack applications in C++ any longer, other than maintaining the existing ones. That is not my experience. Somehow both me and my wife ended up developing new C++ applications for a living.
Are you developing those C++ applications for the enterprise? Can you disclose which type of full stack applications are those?
My wife's work was (she's full time parent now) on some gargantuan backend for ticket selling service. Afaik frontend to that is also C++.