I think my problem is the core concept. POSIX stands for Portable Operating System Interface (and X stands for Xtreme?). In an age where we spin up entire operating systems to start a single application, why are we defining portability at the operating system level when network portability works so much better?
Keep in mind, this is also an age where systems like Qubes OS can make separate VMs cooperate with each other.
The only sell for POSIX I can think of is performance, and I don't know if I buy it anymore. Why do programs have to be cross-compatible when the concept of an operating system no longer means owning the hardware?
A lightweight POSIX-capable system has real value today. Operating systems need to be in more places than just the data center. IoT devices don't have the resources to run a VM or any other fancy containerized environment. POSIX was designed to be used on systems with comparable resources to what many embedded processors now have. It makes sense to leverage the existing codebase where possible.
But not comparable environments. Most IOT environments are very small parts of very big systems, and POSIX defines a system with a teletype and a line editor.
I seriously doubt the value of the existing codebase. Saying code made for a server (like most existing unix code!) is fine for IOT feels wrong, and not just because IOT devices have kilobytes of memory and servers can have gigabytes/terabytes.
I don't think that a universal OS can work well when we know that universal programming languages, data transfer protocols, and everything else didn't. Imagine if we were still doing everything in PL/I. We recognize now that different programming tasks need different programming environments, but we still don't think that different programs need different program environments. It's just strange to me.
There was a time when people ran Linux/SunOS/Ultrix/etc. with tiny amounts of RAM and swap. It's not unusual for an embedded device to have 8, 16, 32 MiB, or more RAM available. Many traditional *nix programs can run unchanged on such hardware.
http://www.qnx.com/content/qnx/en/products/neutrino-rtos/neu...
Example of embedded product in case you wonder about performance cost of all that isolation, healing, and context switching:
https://youtu.be/vPo6gl8N0wM?t=1m20s
EDIT to add the QNX Desktop Demo that came on a single floppy. Throwing it in since you were mentioning resource-constrained systems further down. A floppy is 1.44MB with base QNX running in ROM's of embedded systems. Can scale such architectures it up or down however you wish. :)
http://crackberry.com/heres-how-qnx-looked-1999-running-144m...
The X in POSIX is for unIX. Kinda like a pun on all the *nix things that were floating around back then (Xenix, Minix, AIX, Sinix, Ultrix, IRIX, ...)
Curious - what are your main objections with POSIX? Is there another system you prefer?
But it carries a lot of (in retrospect) bad habits and decisions from the 60s and 70s as well as a tendency to redundancy due to some competing standards that were unified and need for some back compatibility.
Now not everyone agrees on what is good and what is bad, so some experimentation in this area is good for everyone. Examples of what bother me include the ludicrousness of ioctl(), messed up / redundant semaphore semantics, ditto for IPC, primitive memory mgmt semantics, fork() -- a great hack for its time but since it's 99.9999% of the time followed by exec() should be split into separate address space and thread management), outdated and simultaneously simplistic and baroque security model(s), and various IO issues to many to go into in a HN comment.
But my loathed feature is undoubtably someone else's sacred cow. As I said, letting more flowers bloom is in everybody's interest.
- (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.
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.)
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.
I think it's naive to think Operating Systems aren't going to fragment in order to offer "features" (and lockin), and then papering over all that fragmentation has to happen in the application anyway.
unless there's a standard, and if there's a standard the application itself can deal with it.
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... :-)
You're missing my point. The OS should provide a way to store bytes. That's it. The meaning of the bytes is up to the application. If, to the application, the bytes represent text with a certain encoding, then it's up to the application to figure out how to translate the bytes, possibly using other stored bytes to decide. The OS doesn't need to get involved in any of this.
> it does nothing to help applications ensure that they correctly interpret data created by a different application
This is already a solved problem, and it isn't solved by OS's. It's solved by standards. For example, every web browser constantly has to correctly interpret data created by a different application. It can do so because HTML, CSS, JS, etc. are all standards that define how the bytes sent from the server to the client are to be interpreted. The browser doesn't even have to care what OS it's running on; all the OS is doing is giving it network sockets and a place for local data storage.
> If you're going to give your platform official APIs to address the very real problem of handling string encodings
If "platform" means "OS", then no, I'm not. If "platform" means "application framework", then sure, but an application framework is not the same thing as an OS. The fact that many OS's insist on also being application frameworks does not make the two things the same.
As I said originally, we tried that, and it doesn't work. Even within the context of a single locale, .NET applications will happily emit UTF-16 to be consumed by a Python script expecting all strings to be UTF-8, and with only byte-oriented APIs there's no side channel to convey that there's a mismatch that needs to be reconciled. Extending this problem from file and pipe contents to filenames is moving in the wrong direction. Operating systems absolutely should get involved in helping applications safely and usefully exchange information; that doesn't destroy the concept of an application framework, it just means that your OS is more than a hypervisor.
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.
Hardware encode/decode often requires DMA capabilities. There are many optimizations that kernel mode can bring.
Of text?
- 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.
If we think of POSIX compatibility as something which is required in order for an operating system to be viable at any level, it means that there's a lot of energy in pioneering a new OS devoted to building up this compatibility simply so it can get some exposure.
If we really want to encourage a fresh approach and disseminate new ideas, we need to move away from criterion like this and look more specifically at the principles and work being put forth and whether or not those are objectively successful or have merit. That's a much better way to move forward.
The criteria is different if you're writing an OS for practical use with wide adoption, though. There, backward-compatibility is rightly considered a positive attribute - there is much existing software in the world, and the entire point of a practical OS is after all to run the software that people use.
Exactly the same situation exists with CPUs. If you come up with a new micro-architecture that you actually want to sell to customers, you'd better come to the party with a C compiler and a ported OS or three.
For the record, it did not ship built-in or as part of the kernel. Even within Microsoft, it seemed the project was in perpetual life-support-mode.
Still, I do feel a small pang of sadness. There was once a time in the early 2000's, where I would have loved to see this chimeral oddity succeed.
Mounting my sound card across the network sounds like a nice hack. It is more important that sound does not stutter though. That has soft real time requirements, which Plan9 does not address.
Actually, start QEMU with some special arguments and a directory path, and the Linux guest inside will be able to see the given directory as a read-write 9P filesystem, mountable with a single command. (New files get QEMU's UID unless QEMU is run as root.)
> Mounting my sound card across the network sounds like a nice hack. It is more important that sound does not stutter though. That has soft real time requirements, which Plan9 does not address.
An incredibly good point, and why Plan 9 has zero adoption. :(
Minoca OS has been around for a while, but the news is that they're GPLv3. I think that's a great thing! The MIT license is good for software that wants to permeate through everything, but for building a community, the GPL is a good idea.
It seems that for any operating system to be successful, it has to carry around POSIX compatibility like an extremely expensive entry pass. I wonder when we will leave that behind? Or if we ever will? I'm glad POSIX is just a layer in Minoca, and not the base of the system, because these days it really should just be treated like a big wad of glue.
PS: I love the object manager. I don't see any particularly ground-breaking networking stack, though. A plan9-inspired networked file system approach would have been amazing, but it seems this project is content with today's more typical approach. Perhaps it is just trying to be less opinionated about network structure than plan9 was?
PPS: I'm terrible at organizing a comment. Maybe I need a blog.