4 ms·

(Sorry, mini-rant incoming...) Before I get all negative, I'll say that this looks very good for education[1], but I'm really curious about why the word "moder

(Sorry, mini-rant incoming...) Before I get all negative, I'll say that this looks very good for education[1], but I'm really curious about why the word "modern" was used. POSIX is ancient, is overspecified in very important areas (which, thankfully, many/most implementations ignore/work around), is underspecified in very important areas, holds us to a C-based API/ABI, doesn't even have sane "atomic" file operation semantics, etc. etc. POSIX is not something to aspire to, IMO. We tolerate it because we have to, AFAICT. (Rant over. I can only apologize, I just sometimes get a little angry that we're held back technologically because of this nonsense.) [1] Even given the limitations, which are very clearly acknowledged. Kudos to the project people for that!

sortie 9y ago
Author here. I'll probably omit the word 'modern' in the next release. Not for the reasons listed here, but because a bunch of stuff purports to be modern while forgetting the lessons of the past. I implement POSIX not for the sake implementing POSIX, but because it allows me to port a lot of the software that's already written. The core POSIX specification is fairly alright and not that intrusive in my design, the worst parts of POSIX are in optional sections like XSI that I simply omit implementing. I implement a lot of extensions found in Linux and BSD that enhance upon POSIX, while also providing a few of my own. POSIX doesn't say anything about the ABI and doesn't prevent other languages. Atomic file operations are dear to my heart and something I'd like to extend upon in Sortix. Note that POSIX does specify rename(2) is atomic. I implement POSIX when it's convenient and omit doing so when not. I'm happy to acknowledge the limitations of Sortix up front. It's important to establish this level of honesty early on to set the right expectations and establish trust. I warn up front about the security problems in Sortix (that exist at this time). If you follow the documentation, you should get predictable results with no nasty surprises. I think Sortix is suitable for education projects. There's some more clean ups that can make it better. But it's of a reasonable size, it doesn't have that many dirty hacks, and it's fairly well organized.
LukeShu 9y ago
> holds us to a C-based API/ABI This shows a bit of a misunderstanding about what POSIX is. It isn't about operating systems, it (IEEE 1003.1) is about source-code compatibility for 2 languages: C99, and Shell. POSIX doesn't say anything about an ABI, and there's nothing holding the system as a whole to a C-based API. It's specifying C compatibility, of course it's talking about a C API! If you want a different language API, POSIX (1003.1) isn't relevant to you. Totally non-UNIXy systems like z/OS are POSIX certified, because they have source-code compatibility with C99 and Shell programs written against POSIX; that doesn't mean it is held to a C-based API.
- lomnakkus 9y ago
  OK, I was technically wrong about ABI. Still, the ABI is (effectively) mandated by C which is (effecitvely) mandated by POSIX. Do we still have any quarrel over wording?
- lomnakkus 9y ago
  > POSIX doesn't say anything about an ABI, and there's nothing holding the system as a whole to a C-based API. It's specifying C compatibility, of course it's talking about a C API! If you want a different language API, POSIX (1003.1) isn't relevant to you. (Double-replied because I wanted to separate this bit out.) Effectively, it seems you're saying: "Ok, you don't want to implement a C API"[1], well, jolly good luck to you, then. The premise of this whole conversation was that POSIX was a dominating force, and now you're saying you don't have to participate...? [1] A C API, obviously, requires an extreme amount of either 1) being C, or 2) being compatible enough with C that it doesn't matter either way, or 3) giving up entirely on the POSIX ecosystem. So... how is that not being absurdly badly influenced by POSIX?

sortie 9y ago

Author here. I'll probably omit the word 'modern' in the next release. Not for the reasons listed here, but because a bunch of stuff purports to be modern while forgetting the lessons of the past. I implement POSIX not for the sake implementing POSIX, but because it allows me to port a lot of the software that's already written. The core POSIX specification is fairly alright and not that intrusive in my design, the worst parts of POSIX are in optional sections like XSI that I simply omit implementing. I implement a lot of extensions found in Linux and BSD that enhance upon POSIX, while also providing a few of my own. POSIX doesn't say anything about the ABI and doesn't prevent other languages. Atomic file operations are dear to my heart and something I'd like to extend upon in Sortix. Note that POSIX does specify rename(2) is atomic. I implement POSIX when it's convenient and omit doing so when not. I'm happy to acknowledge the limitations of Sortix up front. It's important to establish this level of honesty early on to set the right expectations and establish trust. I warn up front about the security problems in Sortix (that exist at this time). If you follow the documentation, you should get predictable results with no nasty surprises. I think Sortix is suitable for education projects. There's some more clean ups that can make it better. But it's of a reasonable size, it doesn't have that many dirty hacks, and it's fairly well organized.

LukeShu 9y ago

> holds us to a C-based API/ABI This shows a bit of a misunderstanding about what POSIX is. It isn't about operating systems, it (IEEE 1003.1) is about source-code compatibility for 2 languages: C99, and Shell. POSIX doesn't say anything about an ABI, and there's nothing holding the system as a whole to a C-based API. It's specifying C compatibility, of course it's talking about a C API! If you want a different language API, POSIX (1003.1) isn't relevant to you. Totally non-UNIXy systems like z/OS are POSIX certified, because they have source-code compatibility with C99 and Shell programs written against POSIX; that doesn't mean it is held to a C-based API.

lomnakkus 9y ago
OK, I was technically wrong about ABI. Still, the ABI is (effectively) mandated by C which is (effecitvely) mandated by POSIX. Do we still have any quarrel over wording?
lomnakkus 9y ago
> POSIX doesn't say anything about an ABI, and there's nothing holding the system as a whole to a C-based API. It's specifying C compatibility, of course it's talking about a C API! If you want a different language API, POSIX (1003.1) isn't relevant to you. (Double-replied because I wanted to separate this bit out.) Effectively, it seems you're saying: "Ok, you don't want to implement a C API"[1], well, jolly good luck to you, then. The premise of this whole conversation was that POSIX was a dominating force, and now you're saying you don't have to participate...? [1] A C API, obviously, requires an extreme amount of either 1) being C, or 2) being compatible enough with C that it doesn't matter either way, or 3) giving up entirely on the POSIX ecosystem. So... how is that not being absurdly badly influenced by POSIX?