10 ms·

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

bluejekyll 10y ago
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.
- JdeBP 10y ago
  POSIX wasn't designed, per se. It's a standard, a lot of which was the codification of existing practices on operating systems where the C language was the primary language. Also note the existence of FORTRAN language bindings, and the low level but persistent rumbles about C++ language bindings that have continued for the past 20 years or so. Then note the number of languages where the doco tells you all about how "we wrap the C library", but what is actually there is in effect a language binding for POSIX for that language.
  - bluejekyll 10y ago
    Yes, you are completely correct. And 'designed' was perhaps a poor word choice. In terms of wrappers of POSIX, I'm definitely not saying that POSIX is dead and not used. It's great that it is a beginning point for porting to various platforms. What I was more pointing out is that as a developer, its your stdlib's portability that is key. For example, many languages use POSIX interfaces where they can, and then switch to platform specific interfaces where necessary, for performance or other reasons.
  - nickpsecurity 10y ago
    "POSIX wasn't designed, per se. It's a standard, a lot of which was the codification of existing practices on operating systems where the C language was the primary language." That's what I was going to say about UNIX, C, and POSIX. The UNIX and C languages' made tradeoffs specifically oriented around the weak hardware they had. We no longer need those. POSIX evolved from a bunch of competing vendors doing a mix of justifiable and weird stuff with a standard trying to abstract it all. It's inherently going to be worse than a clean design over the smaller number of modern UNIXen without all the politics that went into POSIX. And then we have fact that many portable apps need to run on Windows, Mac, iPhone, etc POSIX ranged from useless to lacking platform-specific capabilities on these. So, a clean-slate design covering each of these platforms is the obvious solution. Fortunately, we have a bunch of them with varying styles and tradeoffs to choose from. :)
- geezerjay 10y ago
  > Isn't the point that those are the most prolific platforms You're confusing popularity with being technically antiquated or obsolete.
  - bluejekyll 10y ago
    I think your reading more into my comment than is there. If you're trying to write a portable app between all of those platforms, would you choose POSIX or would you instead pick a framework or language that has a better high level abstraction?
    - geezerjay 10y ago
      Again, you're confusing popularity with being technically antiquated or obsolete. The thesis presented in the article is that POSIX is outdated. The popularity of a platform, particularly one which was forced upon the world through a de-facto monopoly, is entirely irrelevant in any argument on the technical merits of a technical standard, particularly when some of those platforms were designed with the express purpose of locking out virtually all standardized programming languages.
      - bluejekyll 10y ago
        Hm. The point of POSIX is to support cross platform development with a single standard. If you find that it is not keeping pace with the most modern and popular platforms, is it not outdated? Technically speaking I think the standard is great, especially around having consistent definitions for thing like close(). But there are better options on all platforms to the select() and poll() interfaces. In terms of my desires for open platforms that support open standards, I'm completely with you. If anything what we should be debating is how to update the POSIX standard such that it is worthwhile to target during development. I don't see how it's helpful to ignore what is popular out in the world.
        geezerjay 10y ago
        > Hm. The point of POSIX is to support cross platform development with a single standard. No, the point of POSIX is to specify a set of interfaces that software vendors should provide and target if their goal is to provide an UNIX variant or develop UNIX-compliant software. The key issue is that the main requirement is willingness on behalf of the software vendors to comply with the standard, and offer/target the standardized interface. If a software company is blatantly hostile regarding interoperability, and bases their business model on vendor lock-in strategies then it's quite obvious that those companies are particularly are not willing to play ball with others regarding interoperability. Yet, somehow you're presenting those companies, and the consequences of the actions taken by companies that are openly hostile regarding interoperability, as some sort of proof that a specific interoperability target suffers from technical problems.

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.

JdeBP 10y ago
POSIX wasn't designed, per se. It's a standard, a lot of which was the codification of existing practices on operating systems where the C language was the primary language. Also note the existence of FORTRAN language bindings, and the low level but persistent rumbles about C++ language bindings that have continued for the past 20 years or so. Then note the number of languages where the doco tells you all about how "we wrap the C library", but what is actually there is in effect a language binding for POSIX for that language.
- bluejekyll 10y ago
  Yes, you are completely correct. And 'designed' was perhaps a poor word choice. In terms of wrappers of POSIX, I'm definitely not saying that POSIX is dead and not used. It's great that it is a beginning point for porting to various platforms. What I was more pointing out is that as a developer, its your stdlib's portability that is key. For example, many languages use POSIX interfaces where they can, and then switch to platform specific interfaces where necessary, for performance or other reasons.
- nickpsecurity 10y ago
  "POSIX wasn't designed, per se. It's a standard, a lot of which was the codification of existing practices on operating systems where the C language was the primary language." That's what I was going to say about UNIX, C, and POSIX. The UNIX and C languages' made tradeoffs specifically oriented around the weak hardware they had. We no longer need those. POSIX evolved from a bunch of competing vendors doing a mix of justifiable and weird stuff with a standard trying to abstract it all. It's inherently going to be worse than a clean design over the smaller number of modern UNIXen without all the politics that went into POSIX. And then we have fact that many portable apps need to run on Windows, Mac, iPhone, etc POSIX ranged from useless to lacking platform-specific capabilities on these. So, a clean-slate design covering each of these platforms is the obvious solution. Fortunately, we have a bunch of them with varying styles and tradeoffs to choose from. :)
geezerjay 10y ago
> Isn't the point that those are the most prolific platforms You're confusing popularity with being technically antiquated or obsolete.
- bluejekyll 10y ago
  I think your reading more into my comment than is there. If you're trying to write a portable app between all of those platforms, would you choose POSIX or would you instead pick a framework or language that has a better high level abstraction?
  - geezerjay 10y ago
    Again, you're confusing popularity with being technically antiquated or obsolete. The thesis presented in the article is that POSIX is outdated. The popularity of a platform, particularly one which was forced upon the world through a de-facto monopoly, is entirely irrelevant in any argument on the technical merits of a technical standard, particularly when some of those platforms were designed with the express purpose of locking out virtually all standardized programming languages.
    - bluejekyll 10y ago
      Hm. The point of POSIX is to support cross platform development with a single standard. If you find that it is not keeping pace with the most modern and popular platforms, is it not outdated? Technically speaking I think the standard is great, especially around having consistent definitions for thing like close(). But there are better options on all platforms to the select() and poll() interfaces. In terms of my desires for open platforms that support open standards, I'm completely with you. If anything what we should be debating is how to update the POSIX standard such that it is worthwhile to target during development. I don't see how it's helpful to ignore what is popular out in the world.
      - geezerjay 10y ago
        > Hm. The point of POSIX is to support cross platform development with a single standard. No, the point of POSIX is to specify a set of interfaces that software vendors should provide and target if their goal is to provide an UNIX variant or develop UNIX-compliant software. The key issue is that the main requirement is willingness on behalf of the software vendors to comply with the standard, and offer/target the standardized interface. If a software company is blatantly hostile regarding interoperability, and bases their business model on vendor lock-in strategies then it's quite obvious that those companies are particularly are not willing to play ball with others regarding interoperability. Yet, somehow you're presenting those companies, and the consequences of the actions taken by companies that are openly hostile regarding interoperability, as some sort of proof that a specific interoperability target suffers from technical problems.