Seems to me like POSIX compatibility is actually a cheap pass that gives you access to a huge software environment. Right on the homepage they mention already having packages for Python, Ruby, Git, Lua, and Node... would that, and thousands of other packages, be feasible without a workable POSIX layer?
> would that, and thousands of other packages, be feasible without a workable POSIX layer?
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?
> why are we defining portability at the operating system level when network portability works so much better
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.
> POSIX was designed to be used on systems with comparable resources to what many embedded processors now have.
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.
> Saying code made for a server (like most existing unix code!) is fine for IOT feels wrong,
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.
I think the parent's comment was more along the lines of: just because an embedded device _can_ run a Unix doesn't mean it should have to adopt the semantics and history of the *Unix environment that POSIX mandates. In particular the model of TTYs, filesystems, Unix-style file/IO, Unix-style virtual memory / mmap, etc. It's not that this stuff is expensive on modern embedded systems (which as pointed out often have the hardware capacity of high end systems from 20 years ago), it's that these capabilities are either not needed, or impose a conceptual model of what a computer and operating system have to be that don't match up to what the machine is designed for.
There's a whole market of suppliers that's been going strong for decades. Especially for safety-critical embedded with untrusted, Linux/POSIX apps in separate partitions. QNX is one of best examples far as commercial adoption:
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. :)
I agree with you in general but IIRC Lua only depends on the C standard library and does not need POSIX to run. There are even versions of it that can run inside the kernel!
