3 ms·
I don't know what you're referring to with that distinction. AFAICT they weren't testing for POSIX compliance but rather where the POSIX layer was being used in
by mwfunk 10y ago
I don't know what you're referring to with that distinction. AFAICT they weren't testing for POSIX compliance but rather where the POSIX layer was being used in practice, which statistically was by system-level frameworks rather than the applications themselves on the OSes they tested.
The notable change between now and 25 years ago is that the POSIX layer tends to be used at the lower levels of system frameworks, while the programs that run on those OSes tend to be written on top of higher level frameworks and do not directly use the POSIX APIs.
This is fine and makes sense given how much has changed in the last 25 years, but given that the POSIX layer is no longer being used (statistically speaking) for what it was originally designed for, it raises questions about to what degree that design is still valid, and whether or not it should be revisited to better suit what it's actually being used for.
I don't think anyone has any answers, but it's always good to question assumptions and never let anything in tech become a sacred cow. Maybe POSIX is fine for its current role, but that doesn't mean people shouldn't think about it.
Disclaimer: I skimmed the article pretty aggressively, so I may have misunderstood something.
- yarou 10y agoI'm a little confused by the distinction. For example, if I use a framework that abstracts away pthreads from me, but still uses pthreads in its implementation of threading, is the application I write still POSIX-compliant?
- mwfunk 10y agoNo, the application would not be POSIX-compliant, but it would be running on a POSIX-compliant OS. I was confused by the comment I replied to because it sounded like he was saying that POSIX compliance was more likely in "modern" applications, but if anything the opposite is the case. POSIX compliance is much more common in consumer OSes nowadays, to the point that every major desktop and mobile platform is built on a POSIX-compliant kernel and runtime except for Microsoft's offerings. In that sense POSIX has taken over the non-Microsoft world, but now it's being used as a much lower-level compatibility layer for system-level frameworks rather than what it was originally designed for. Even Windows has had multiple POSIX implementations over the years, they were just built as compatibility layers on top of the native APIs. So POSIX-compliant operating systems are almost universal at this point, but POSIX-compliant applications/daemons/etc. (all the programs that run on those POSIX OSes) are rarer than ever.
- cperciva 10y agoit sounded like he was saying that POSIX compliance was more likely in "modern" applications Yes. Part of this is because more operating systems are approaching POSIX-compliance; but the number of patches we need to port random Linux code to run on FreeBSD has dropped tremendously over the past 20 years.
- coldtea 10y ago>is the application I write still POSIX-compliant? Obviously not, since you can't go and compile it on another POSIX system -- you are "abstraction compliant" (or rather "abstraction dependent" now.
- deleted 10y ago[deleted]