4 ms·

The author of this piece is a long time FreeBSD contributor[1]. Just maybe that person has relevant experience guiding their thoughts? He certainly is not "doin

The author of this piece is a long time FreeBSD contributor[1]. Just maybe that person has relevant experience guiding their thoughts? He certainly is not "doing nothing and whinging constantly". Posix is not a religion - it's ok to look at other ideas, to listen to critiques. I mean Linux does it all the time - io_uring, all the ebpf stuff, a dozen forms of kernel bypass suggest to me that the posix interfaces aren't sufficient, or right for modern hardware, at least not in all cases. [1] Here's his first commit: https://cgit.freebsd.org/src/commit/?id=026e67b69b612f90360a3c7b35be16f34bffd0c6 https://cgit.freebsd.org/src/commit/?id=026e67b69b612f90360a... with the most recent happening within the last year. edit: fixed link

nineteen999 4y ago
I'm sure you're right, but your link returns the following for me: Bad object id: 026e67b69b612f90360a3c7b35be16f34bffd0c6c
- sophacles 4y ago
  Thanks for the heads up. Fixed in the original.
PaulDavisThe1st 4y ago
and yet somehow, he barely manages to mention a single non-POSIX OS API in the entire piece, either existing or posited. he writes as if we're living under the spell of POSIX ("the elephant") when it fact it is perfectly clear that we are slowly, cautiously, prudently incrementally adopting new models, some of which complement the existing POSIX API and some do not.
- sophacles 4y ago
  All the things I listed are where one OS has gone away from posix for high-end server use cases. For some systems I work on, those have actually simplified a lot of stuff - I mean they are complex apis solving hard problems, but it doesn't feel like fighting OS to use them. The author is writing in context of people who use code very differently than I do - they think about it differently too. Perhaps there are different types of API for their use cases that are less "fighting with the OS" for them, or more likely the tool makers that build the intermediate code/frameworks?
  - PaulDavisThe1st 4y ago
    > For some systems I work on, those have actually simplified a lot of stuff - I mean they are complex apis solving hard problems, but it doesn't feel like fighting OS to use them. I am entirely in favor of domain-specific APIs that "make hard problems easier to solve". But it is important to recognize two things about this: 1. the "complex APIs" that are right for solving one set of hard problems are frequently not the right ones for a different set of hard problems. 2. POSIX never made any claim to universality in the domain of being the right API for a given problem class. As someone else noted here in the comments, it was a bunch of people & organizations simply agreeing on the low level stuff they could agree on. I'd make one additional point: unless the plan is to reimplement the kernel for every problem domain, which seems pretty crazy, the actual situation faced by many/most real world programmers even in a better world is going to be "APIs we want to use layered on top of APIs we (mostly) don't want to use". This is necessarily so, because the APIs that make it possible to implement the APIs that whiners like the author of TFA want to use, along with the APIs that domain specialists want, are generally APIs like POSIX that people don't seem to warm to very strongly.
    - sophacles 4y ago
      1. Yes, that's something i recognized explicitly above. 2. Sure, but that provided enough foundation for other ideas like epoll/kqueue to spread between OSes. It happened because everyone saw the strange non-posix thing (i think at Sun?) and made a similar system. Even though they aren't directly api compatible they were conceptually close enough, people ended up building nice layers on them (libuv, mio, etc). Maybe that would be enough. Perhaps even, the right answer to several of the points raised is in fact io_uring like apis spreading to other OSes too, so that a reasonable cross platform abstraction layer can be built. Perhaps it's something different. Perhaps is creating a new standard or a new posix version or addendum or whatever. All of this aside, I'm not here to champion the specifics. I'm pointing out that it's a reasonable discussion to have, there's no need to be upset at someone for pointing it out.

nineteen999 4y ago

I'm sure you're right, but your link returns the following for me: Bad object id: 026e67b69b612f90360a3c7b35be16f34bffd0c6c

sophacles 4y ago
Thanks for the heads up. Fixed in the original.

PaulDavisThe1st 4y ago

and yet somehow, he barely manages to mention a single non-POSIX OS API in the entire piece, either existing or posited. he writes as if we're living under the spell of POSIX ("the elephant") when it fact it is perfectly clear that we are slowly, cautiously, prudently incrementally adopting new models, some of which complement the existing POSIX API and some do not.

sophacles 4y ago
All the things I listed are where one OS has gone away from posix for high-end server use cases. For some systems I work on, those have actually simplified a lot of stuff - I mean they are complex apis solving hard problems, but it doesn't feel like fighting OS to use them. The author is writing in context of people who use code very differently than I do - they think about it differently too. Perhaps there are different types of API for their use cases that are less "fighting with the OS" for them, or more likely the tool makers that build the intermediate code/frameworks?
- PaulDavisThe1st 4y ago
  > For some systems I work on, those have actually simplified a lot of stuff - I mean they are complex apis solving hard problems, but it doesn't feel like fighting OS to use them. I am entirely in favor of domain-specific APIs that "make hard problems easier to solve". But it is important to recognize two things about this: 1. the "complex APIs" that are right for solving one set of hard problems are frequently not the right ones for a different set of hard problems. 2. POSIX never made any claim to universality in the domain of being the right API for a given problem class. As someone else noted here in the comments, it was a bunch of people & organizations simply agreeing on the low level stuff they could agree on. I'd make one additional point: unless the plan is to reimplement the kernel for every problem domain, which seems pretty crazy, the actual situation faced by many/most real world programmers even in a better world is going to be "APIs we want to use layered on top of APIs we (mostly) don't want to use". This is necessarily so, because the APIs that make it possible to implement the APIs that whiners like the author of TFA want to use, along with the APIs that domain specialists want, are generally APIs like POSIX that people don't seem to warm to very strongly.
  - sophacles 4y ago
    1. Yes, that's something i recognized explicitly above. 2. Sure, but that provided enough foundation for other ideas like epoll/kqueue to spread between OSes. It happened because everyone saw the strange non-posix thing (i think at Sun?) and made a similar system. Even though they aren't directly api compatible they were conceptually close enough, people ended up building nice layers on them (libuv, mio, etc). Maybe that would be enough. Perhaps even, the right answer to several of the points raised is in fact io_uring like apis spreading to other OSes too, so that a reasonable cross platform abstraction layer can be built. Perhaps it's something different. Perhaps is creating a new standard or a new posix version or addendum or whatever. All of this aside, I'm not here to champion the specifics. I'm pointing out that it's a reasonable discussion to have, there's no need to be upset at someone for pointing it out.