7 ms·

POSIX compliance is important if you value portability - especially for business critical systems (e.g. you want your bank's transaction processing data to work

POSIX compliance is important if you value portability - especially for business critical systems (e.g. you want your bank's transaction processing data to work on IBM Z/Series's UNIX, whatever Linux distro they use, and say... SunOS). My main takeaway from the article is POSIX is too antiquated and anemic as a "system API" for modern-day use - however I'm surprised the article doesn't seem to touch upon POSIX shortcomings instead being a consequence of the UNIX design philosophy - a strong personal concern of mine regards UNIX-like's future development course - should we continue to uphold "everything is a file", ioctl(), and piping text-streams as the best way to build an OS? Curiously, the article chides POSIX for lacking modern abstractions (specifically, graphics) but I disagree - POSIX would be a disaster if it included anything like OpenGL or Cairo (case-in-point: Win32 is tightly coupled with GDI and now we're paying the price by being physically unable to do deep-color graphics in Win32 without serious hacks) - I think that (to paraphrase one of the UNIX philosophies) "small APIs that do one thing and do it well" applies to POSIX (as it does process and system management, and nothing else) and it has worked. Coming from a modern Windows developer experience - I think there's a great deal to be learned from the failures of the vaporware "object-oriented operating system" concepts of the mid-1990s and how the concept has been resurrected in the form of PowerShell object-piping and WinMD today and should be explored as the next possible step in OS design at a fundamental level - not just as a shim on top as it is with Windows. That said, UNIX and GNU/Linux have always evolved in small steps - pretty much every great-leap-forward is doomed to failure or endless ideological controversy (see `systemd`) so maybe UNIX-like OSes are not the right place to test new design concepts - but some new OS will - and eventually that OS will supersede Linux in the way many people believe Rust will replace C++.

milesrout 10y ago
POSIX is neither antiquated nor anemic. There's nothing antiquated about a hierarchical filesystem with a single root. There's nothing antiquated about 'everything is a file'. In fact, that's continually useful to me on a day-to-day basis. There's nothing antiquated about byte streams, which is all they are. They aren't text streams. A great example of how all of this turns out to be good design is that you can see how easily UNIX-based systems adopted Unicode. Say what you like about byte streams as a universal interface, but it sure was easy to switch from ASCII to UTF-8 when your system APIs weren't all built around the idea that everything would be encoded in a particular way. I don't think systemd is unpopular or controversial because it's a great leap forward. That's just buying into the propaganda. It's unpopular and controversial because it presents itself as a great leap forward while not being one. >but some new OS will - and eventually that OS will supersede Linux in the way many people believe Rust will replace C++. C++ hasn't even replaced C. Why would Rust replace C++? When has a popular, stable, architecturally-important language ever been replaced? The sort of people that think that Rust will replace C++ are the sort of people who thought Java would replace C++, who thought C++ would replace C, who thought Windows would replace Unix and who think that another system of opaque proprietary object-oriented APIs will replace POSIX. They're wrong, in every way.
- dbaupp 10y ago
  > Java would replace C++, who thought C++ would replace C, who thought Windows would replace Unix All of these have happened, for many use cases.
  - milesrout 10y ago
    No, they haven't. Stop believing everything you read on reddit. Java didn't displace C++, and C++ certainly hasn't displaced C.
    - dbaupp 10y ago
      Great example! I read reddit via a browser written in C++ on a Windows machine (written in C++) or on an operating system compiled by a compiler written in C++... or even an app written in Java. Software engineering still uses languages/tools from the first few years that it existed, so it's unlikely that anyone means "completely replace every single LoC inexistence" when they say "replace".
    - pjmlp 10y ago
      > Java didn't displace C++ C++ has become an infrastructure language on the enterprise. We write native libraries in it, like COM components, or plugins that interact with Python, Lua, Java, .NET, Node,... VMs. No one writes full stack applications in C++ any longer, other than maintaining the existing ones. Even game engines have moved into a mix of C++ + higher level language. On the mobile OSes, C++ only has GUI support via the Objective-C++ and C++/CX dialects. On Android it gets the JNI wall. > and C++ certainly hasn't displaced C. Your favourite C compiler is written in C++. The only place where C has an edge over C++ is the embedded space, *BSD, Linux kernel and the GNU tools.
      - lrem 10y ago
        > No one writes full stack applications in C++ any longer, other than maintaining the existing ones. That is not my experience. Somehow both me and my wife ended up developing new C++ applications for a living.
ori_b 10y ago
Ioctl is a deranged joke. The rest has held up surprisingly well, and I regularly find myself dropping down a few layers of abstraction to get away from higher level APIs. I can generally get more done faster with a binary pipe and some sort of generator for serialization than with higher level communication APIs.
skissane 10y ago
> should we continue to uphold "everything is a file" POSIX doesn't do a very good job of upholding that. POSIX is full of entities (e.g. notably processes and threads) which can't be manipulated via file descriptors. Some POSIX implementations do better – e.g. FreeBSD's pdfork – but that isn't standardised. By contrast, Windows NT in which "everything is a handle" actually provides a more unified interface to OS objects than POSIX does.
- AnthonyMouse 10y ago
  > POSIX is full of entities (e.g. notably processes and threads) which can't be manipulated via file descriptors. Well there is /proc
  - skissane 10y ago
    Which isn't a standard part of POSIX. It is an implementation-specific extension, which only some implementations have (OS X most notably lacks it), and even those who have it implement it in incompatible ways (e.g. /proc on Linux is quite different from /proc on Solaris). Also, Linux /proc doesn't really allow you to treat processes as file descriptors like FreeBSD's pdfork does. Sure, I can open /proc/123, but operations on the resulting file descriptor have no relationship with the process – if I pass the FD into a select() I won't get any notifications about the process lifecycle.
    - jstimpfle 10y ago
      I think this discussion misses the point what "everything is a file" is about. The standard way to exchange (read, write) information should be through the Unix file interface where possible. Note that "file" here means "FILE *", i.e. an "opened file" or "stream". Not a file on a filesystem which is just one way to make one kind of stream. In other words that mantra is about simplicity. Simplicity is what enables software to exist.
      - skissane 10y ago
        > I think this discussion misses the point what "everything is a file" is about. I don't agree. POSIX systems provide APIs to wait on events on file descriptors – select, poll, etc. I can use those APIs to wait on an event on a pipe, a network socket, a device file, etc. To wait on an event on anything which is represented by an file descriptor. But what if I want to wait for a child process to exit? I can't use select/poll for that since processes are not represented by file descriptors in standard POSIX – FreeBSD is a notable exception, but FreeBSD's facilities are non-standard. If I want to simultaneously wait on both a child process to terminate and a message to arrive on a socket, I am forced to use multiple threads. For example, I could have a thread to execute waitpid() and then have it write to a pipe, and have another thread select/poll on both that pipe and the network socket. If processes were represented by file descriptors, I could have a single thread doing a select/poll on both the network socket and the child process. > In other words that mantra is about simplicity. Simplicity is what enables software to exist. Yes, and POSIX fails to be simple here. By failing to sufficiently unify its abstractions, it forces application code to be more complex than it should be.
discreteevent 10y ago
" the vaporware "object-oriented operating system" concepts” COM is Windows and COM is about as purely object oriented as you can get. It's not vaporware.
- DaiPlusPlus 10y ago
  COM can be said to be overly complicated (at least not as bad a CORBA). I think WinMD is a step in the right direction, but both COM and WinMD are userland constructs and neither particularly pervade the OS (e.g. you can't pipe COM objects)

milesrout 10y ago

POSIX is neither antiquated nor anemic. There's nothing antiquated about a hierarchical filesystem with a single root. There's nothing antiquated about 'everything is a file'. In fact, that's continually useful to me on a day-to-day basis. There's nothing antiquated about byte streams, which is all they are. They aren't text streams. A great example of how all of this turns out to be good design is that you can see how easily UNIX-based systems adopted Unicode. Say what you like about byte streams as a universal interface, but it sure was easy to switch from ASCII to UTF-8 when your system APIs weren't all built around the idea that everything would be encoded in a particular way. I don't think systemd is unpopular or controversial because it's a great leap forward. That's just buying into the propaganda. It's unpopular and controversial because it presents itself as a great leap forward while not being one. >but some new OS will - and eventually that OS will supersede Linux in the way many people believe Rust will replace C++. C++ hasn't even replaced C. Why would Rust replace C++? When has a popular, stable, architecturally-important language ever been replaced? The sort of people that think that Rust will replace C++ are the sort of people who thought Java would replace C++, who thought C++ would replace C, who thought Windows would replace Unix and who think that another system of opaque proprietary object-oriented APIs will replace POSIX. They're wrong, in every way.

dbaupp 10y ago
> Java would replace C++, who thought C++ would replace C, who thought Windows would replace Unix All of these have happened, for many use cases.
- milesrout 10y ago
  No, they haven't. Stop believing everything you read on reddit. Java didn't displace C++, and C++ certainly hasn't displaced C.
  - dbaupp 10y ago
    Great example! I read reddit via a browser written in C++ on a Windows machine (written in C++) or on an operating system compiled by a compiler written in C++... or even an app written in Java. Software engineering still uses languages/tools from the first few years that it existed, so it's unlikely that anyone means "completely replace every single LoC inexistence" when they say "replace".
  - pjmlp 10y ago
    > Java didn't displace C++ C++ has become an infrastructure language on the enterprise. We write native libraries in it, like COM components, or plugins that interact with Python, Lua, Java, .NET, Node,... VMs. No one writes full stack applications in C++ any longer, other than maintaining the existing ones. Even game engines have moved into a mix of C++ + higher level language. On the mobile OSes, C++ only has GUI support via the Objective-C++ and C++/CX dialects. On Android it gets the JNI wall. > and C++ certainly hasn't displaced C. Your favourite C compiler is written in C++. The only place where C has an edge over C++ is the embedded space, *BSD, Linux kernel and the GNU tools.
    - lrem 10y ago
      > No one writes full stack applications in C++ any longer, other than maintaining the existing ones. That is not my experience. Somehow both me and my wife ended up developing new C++ applications for a living.

ori_b 10y ago

Ioctl is a deranged joke. The rest has held up surprisingly well, and I regularly find myself dropping down a few layers of abstraction to get away from higher level APIs. I can generally get more done faster with a binary pipe and some sort of generator for serialization than with higher level communication APIs.

skissane 10y ago

> should we continue to uphold "everything is a file" POSIX doesn't do a very good job of upholding that. POSIX is full of entities (e.g. notably processes and threads) which can't be manipulated via file descriptors. Some POSIX implementations do better – e.g. FreeBSD's pdfork – but that isn't standardised. By contrast, Windows NT in which "everything is a handle" actually provides a more unified interface to OS objects than POSIX does.

AnthonyMouse 10y ago
> POSIX is full of entities (e.g. notably processes and threads) which can't be manipulated via file descriptors. Well there is /proc
- skissane 10y ago
  Which isn't a standard part of POSIX. It is an implementation-specific extension, which only some implementations have (OS X most notably lacks it), and even those who have it implement it in incompatible ways (e.g. /proc on Linux is quite different from /proc on Solaris). Also, Linux /proc doesn't really allow you to treat processes as file descriptors like FreeBSD's pdfork does. Sure, I can open /proc/123, but operations on the resulting file descriptor have no relationship with the process – if I pass the FD into a select() I won't get any notifications about the process lifecycle.
  - jstimpfle 10y ago
    I think this discussion misses the point what "everything is a file" is about. The standard way to exchange (read, write) information should be through the Unix file interface where possible. Note that "file" here means "FILE *", i.e. an "opened file" or "stream". Not a file on a filesystem which is just one way to make one kind of stream. In other words that mantra is about simplicity. Simplicity is what enables software to exist.
    - skissane 10y ago
      > I think this discussion misses the point what "everything is a file" is about. I don't agree. POSIX systems provide APIs to wait on events on file descriptors – select, poll, etc. I can use those APIs to wait on an event on a pipe, a network socket, a device file, etc. To wait on an event on anything which is represented by an file descriptor. But what if I want to wait for a child process to exit? I can't use select/poll for that since processes are not represented by file descriptors in standard POSIX – FreeBSD is a notable exception, but FreeBSD's facilities are non-standard. If I want to simultaneously wait on both a child process to terminate and a message to arrive on a socket, I am forced to use multiple threads. For example, I could have a thread to execute waitpid() and then have it write to a pipe, and have another thread select/poll on both that pipe and the network socket. If processes were represented by file descriptors, I could have a single thread doing a select/poll on both the network socket and the child process. > In other words that mantra is about simplicity. Simplicity is what enables software to exist. Yes, and POSIX fails to be simple here. By failing to sufficiently unify its abstractions, it forces application code to be more complex than it should be.

discreteevent 10y ago

" the vaporware "object-oriented operating system" concepts” COM is Windows and COM is about as purely object oriented as you can get. It's not vaporware.

DaiPlusPlus 10y ago
COM can be said to be overly complicated (at least not as bad a CORBA). I think WinMD is a step in the right direction, but both COM and WinMD are userland constructs and neither particularly pervade the OS (e.g. you can't pipe COM objects)