Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> That makes it impossible to properly implement POSIX on top of it

so don't implement posix. I don't know why people get so hung up on new oses being POSIX compliant.



Mostly because being POSIX compliant makes it far easier to port a lot of command-line and server-side software quickly. Most new operating system projects don’t have the manpower to rewrite the world - I think the last major one was probably Android.


You'd be surprised how generic most code is or how easy it is to port if it's POSIX-like. Out of the major consumer OSes, only OSX is POSIX certified (in 10.5 which is only 11 years ago). Hell, the majority of Android code is written in Java which has no POSIX roots at all so avoiding POSIX isn't a death knell you seem to imply. iOS, while it supports POSIX, most of the developers use iOS-specific APIs unless they're in shared code with another OS & not using something like Boost. Have you actually tried using POSIX networking APIs? They're god awful. POSIX threading primitives are terrible. etc etc.

POSIX is sometimes useful for writing cross-platform C/C++ code. It's extremely limiting though, out-of-date, & doesn't actually offer the write-once run anywhere you'd like with POSIX.

You can write POSIX code that will fail to build, fail at runtime, or even behave incorrectly when you run it on another "POSIX" system (at least as far as Windows/Linux/OSX/Android are concerned). Certainly a far cry from how a standard is supposed to behave.

POSIX also, for the most part, targets the lowest common denominator of platform features which means the POSIX API isn't as rich as makes sense for the majority of applications, doesn't have the same performance/security, and/or isn't as easy-to-use.

POSIX also leaves many subtle decisions to implementations' discretion which means that even if everything works in the happy path, it'll break in subtle corner cases. For example, PATH_MAX is defined as 256, _XOPEN_PATH_MAX is 1024, but Linux & OSX both have unbounded limits so a POSIX program can easily fail to be able to open all files on an OS; making this a build-time constant was the stupidest decision in the world & endemic of how POSIX is designed.

Most modern language runtimes these days (Rust, Go, Java, Swift) comes with a far richer, less bug-prone & more feature-full set of features in the standard library out-the-gate on all platforms (so you just need to port the 1 standard library) & most libraries build on that standard library so you usually get them for free.

Most platform vendors also provide custom APIs to interact more richly with their specific features for performance, battery, usability, security, etc. To take full advantage of a platform, which you're pushed to usually by market forces, POSIX doesn't help you.

* EDIT: Also, POSIX is gigantic. The majority of useful existing tools probably use 20% of the entire standard. Porting that smaller API surface isn't challenging.


Basically POSIX is the C standard library they didn't want to make part of ISO C.

As you well point out hardly significant when using other programming languages, even C++ standard library improvements are making it less relevant for C++ devs.


Well. They’re google.

Also the redox team knocked out rust versions of most of the standard utilities in a few months.


That is a recipe for a mono-culture stuck in the past.


Of course it is. It’s not a good thing - it’s essentially killed any possibility of a capability-oriented desktop OS for a number of years, for a start. But it’s the state of things - if someone can’t run at least most of their software on a new system, it’s a massive barrier to adoption.

The reason Android and iOS got away with it was that nobody was really running important software on their phones in the first place, so it was a brand new capability that didn’t need to be compatible with anything.


Symbian and J2ME phones were quite popular in Europe and Asia, lacking POSIX compatibility wasn't an issue. In fact, the PIPS library for Symbian was only introduced after the decision to buy Qt.

You also forgot about ChromeOS, which I bet hardly anyone on the US school system cares about POSIX.

Or the webOS running on LG televisions nowadays.

FreeRTOS, mbed and IncludeOS aren't POSIX as well.

Regarding Fuchsia, there is already support for ISO C, ISO C++, Rust, Go, Dart/Flutter, with Java/Android on the horizon.

So I doubt Fuchsia will miss POSIX that much.


My experience of J2ME phones (as someone living in India pre-iPhone) was that the Java functionality went unused, except as far as it was used to implement vendor-written apps.

ChromeOS benefits from the fact that it is just a web browser - if you want just a web browser rather than a generic operating system, Fuschia is of course unnecessary.

Nobody targets webOS, and I suspect people’s choice of TV has more to do with how it looks on the in-store display or how cheap it is than what apps you can run on it.

FreeRTOS, mbed and IncludeOS are not generic operating systems in the first place.

There are essentially no “pure” ISO C or ISO C++ programs - everybody uses system-specific libraries at some level.

Basically, Fuschia suffers from the fact that a large amount of userland will need to be rewritten for it, depending on what market segment it targets. (“Just” being an alternate Android runtime for phones, as an example, wouldn’t require this.) This is an obstacle - not an insurmountable one, but being non-POSIX is an obstacle for any OS, that the people behind it need a strategy to tackle. Whether or not people will code apps for Fuschia will depend on how excited developers get about it at first, and then how many people use it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: