7 ms·

I think the main issues with POSIX are: - (Correct) IO is ridiculously non-portable and painful in so many ways that it isn't even funny anymore - Locks are r

by dom0 10y ago

I think the main issues with POSIX are: - (Correct) IO is ridiculously non-portable and painful in so many ways that it isn't even funny anymore - Locks are ridiculously non-portable and painful to the point where you're better off just using "mkdir" - POSIX is stuck in the "everything is bytes and we slap an encoding on it some of the time" era thinking. This makes it painful and hard to implement proper text handling in many instances. This also leads to a lot of bad behaviours. - Memory management is IMHO lacking from a user space perspective. For example, it's practically impossible to implement a cooperative memory cache on this. To the best of my knowledge no OS has the necessary interfaces, though. - ioctl as you mentioned - SysV/POSIX IPC is so bad that no one ever bothered actually using it for anything - Personally I think it's a misleading API (conceptually, see above, the text example for example) almost to the point of deceptiveness. It's very easy to write correct looking programs that behave far from intended, especially in edge cases. IMHO code using it is practically unreviewable in everything but the most trivial cases. Non-portability is practically guaranteed, you have to test every platform. Portable code usually turns out to be quite ugly due to platform deficiencies and minor API incompatibilities.

pdonis 10y ago
> POSIX is stuck in the "everything is bytes and we slap an encoding on it some of the time" era thinking. I actually view this as a feature. Encoding/decoding of data should be an application level thing, not an OS-level thing. As far as the OS is concerned, data should be bytes. (Of course, it is true that, since POSIX defines a terminal spec, it has to at least specify how bytes are mapped to characters that print on the terminal. But I would rather see that removed altogether, so a terminal becomes just another application, than have an OS try to muck about with encodings.)
- wtallis 10y ago
  Applications have for the most part proven that they cannot be trusted to get text encoding and decoding right, especially not in any consistent way. Operating systems definitely should make it possible to deal with the raw byte streams, but the default and preferred method of text handling should be a standard higher-level interface.
  - pdonis 10y ago
    > Applications have for the most part proven that they cannot be trusted to get text encoding and decoding right, especially not in any consistent way. That's because text encoding and decoding is a mess. Operating systems doing it doesn't make it any less of a mess; it just inserts the mess deeper into everything. For example, look at all the quirks and edge cases in file name handling between different OS's, simply because nobody is willing to just admit that to the OS, file names should be sequences of bytes, which are easy to share between machines running different OS's. The basic issue is that text encoding and decoding exists because bytes have meanings. But unless/until we invent artificial intelligence, computers can't deal with meanings (because the meanings are not simple computable functions of the bytes). And OS's, particularly, should not even try. Applications might have to try, but the cost if they get it wrong is much less.
    - wtallis 10y ago
      Regardless of whether operating systems get involved in tasks like re-encoding text, they really should at least carry along the metadata about encodings whenever they're handling bytes that represent strings. Completely ignoring the problem and leaving it up to applications further up the stack just ensures that there will be incompatible competing standards for how to tell applications how to decode the string data they get from the OS. You don't want some apps trying to write filenames in UTF-8 while others use UTF-16, but allowing it to happen silently is even worse.
      - pdonis 10y ago
        > Regardless of whether operating systems get involved in tasks like re-encoding text, they really should at least carry along the metadata about encodings whenever they're handling bytes that represent strings. I have no problem with this as long as the metadata itself is just additional bytes. But if the metadata needs to be decoded in order to figure out how to decode it, we have a problem... :-)
        wtallis 10y ago
- mycall 10y ago
  > have an OS try to muck about with encodings Hardware encode/decode often requires DMA capabilities. There are many optimizations that kernel mode can bring.
  - pdonis 10y ago
    > Hardware encode/decode Of text?
    - braveo 10y ago
      but is it webscale?
  - john_reel 10y ago
    x86 has string instructions that do not require DMA. Nobody needs to hardware accelerate string decoding and encoding though...
- zeveb 10y ago
  > As far as the OS is concerned, data should be bytes. If the OS knows the type of those bytes, it can do things like implement global garbage collection, intelligent caching, intelligent snapshotting &c. It can also enforce invariants across all user code.
  - pdonis 10y ago
    To me this means you have an application, not an OS--or perhaps an application that also happens to be an OS. (Emacs comes to mind...)
    - zeveb 10y ago
      Well, I think that OSes could do a lot more (and kernels a lot less … but that's a different story). Why _shouldn't_ an operating _system_ do an awful lot to ensure user safety, resource utilisation &c.?
marcosdumay 10y ago
I'll also disagree on the "everything is bytes and we slap an encoding on it some of the time"... But add there: - User level security, instead of app level or task level, or whatever. - Aged IPC primitives that assume too much to the point that modern hardware has to be built around it (and slower because of that). - Added later, non-core network support, leading to bad integration. - Added later, non-core, or sometimes never added encryption support, leading to bad integration.

by dom0 10y ago

pdonis 10y ago

> POSIX is stuck in the "everything is bytes and we slap an encoding on it some of the time" era thinking. I actually view this as a feature. Encoding/decoding of data should be an application level thing, not an OS-level thing. As far as the OS is concerned, data should be bytes. (Of course, it is true that, since POSIX defines a terminal spec, it has to at least specify how bytes are mapped to characters that print on the terminal. But I would rather see that removed altogether, so a terminal becomes just another application, than have an OS try to muck about with encodings.)

wtallis 10y ago
Applications have for the most part proven that they cannot be trusted to get text encoding and decoding right, especially not in any consistent way. Operating systems definitely should make it possible to deal with the raw byte streams, but the default and preferred method of text handling should be a standard higher-level interface.
- pdonis 10y ago
  > Applications have for the most part proven that they cannot be trusted to get text encoding and decoding right, especially not in any consistent way. That's because text encoding and decoding is a mess. Operating systems doing it doesn't make it any less of a mess; it just inserts the mess deeper into everything. For example, look at all the quirks and edge cases in file name handling between different OS's, simply because nobody is willing to just admit that to the OS, file names should be sequences of bytes, which are easy to share between machines running different OS's. The basic issue is that text encoding and decoding exists because bytes have meanings. But unless/until we invent artificial intelligence, computers can't deal with meanings (because the meanings are not simple computable functions of the bytes). And OS's, particularly, should not even try. Applications might have to try, but the cost if they get it wrong is much less.
  - wtallis 10y ago
    Regardless of whether operating systems get involved in tasks like re-encoding text, they really should at least carry along the metadata about encodings whenever they're handling bytes that represent strings. Completely ignoring the problem and leaving it up to applications further up the stack just ensures that there will be incompatible competing standards for how to tell applications how to decode the string data they get from the OS. You don't want some apps trying to write filenames in UTF-8 while others use UTF-16, but allowing it to happen silently is even worse.
    - pdonis 10y ago
      > Regardless of whether operating systems get involved in tasks like re-encoding text, they really should at least carry along the metadata about encodings whenever they're handling bytes that represent strings. I have no problem with this as long as the metadata itself is just additional bytes. But if the metadata needs to be decoded in order to figure out how to decode it, we have a problem... :-)
      - wtallis 10y ago
mycall 10y ago
> have an OS try to muck about with encodings Hardware encode/decode often requires DMA capabilities. There are many optimizations that kernel mode can bring.
- pdonis 10y ago
  > Hardware encode/decode Of text?
  - braveo 10y ago
    but is it webscale?
- john_reel 10y ago
  x86 has string instructions that do not require DMA. Nobody needs to hardware accelerate string decoding and encoding though...
zeveb 10y ago
> As far as the OS is concerned, data should be bytes. If the OS knows the type of those bytes, it can do things like implement global garbage collection, intelligent caching, intelligent snapshotting &c. It can also enforce invariants across all user code.
- pdonis 10y ago
  To me this means you have an application, not an OS--or perhaps an application that also happens to be an OS. (Emacs comes to mind...)
  - zeveb 10y ago
    Well, I think that OSes could do a lot more (and kernels a lot less … but that's a different story). Why _shouldn't_ an operating _system_ do an awful lot to ensure user safety, resource utilisation &c.?

marcosdumay 10y ago

I'll also disagree on the "everything is bytes and we slap an encoding on it some of the time"... But add there: - User level security, instead of app level or task level, or whatever. - Aged IPC primitives that assume too much to the point that modern hardware has to be built around it (and slower because of that). - Added later, non-core network support, leading to bad integration. - Added later, non-core, or sometimes never added encryption support, leading to bad integration.