Google clearly has a LOT of cash to play with. They could have refactored/re-used the permissively licensed BSD core, but ended up re-inventing the wheel, breaking a TON of POSIX based software.
For what benefit exactly?
For what benefit exactly?
Newer is rarely better. Besides, in computing, so many "new" things are just rehashes of old (and not so old) ideas.
I really wish we could get away from the "that software is old" meme in this industry.
New software, otoh, hasn't been through a 40-year shakedown cruise.
Neither of these things has any bearing on the quality of Linux, or lack thereof.
Also their goal is not to run 100% of POSIX or Linux specific software, rather achieve a good enough compatibility to run majority of well known projects and utilities.
A lot of security-interested programmers think it easier to secure a small microkernel like Fuchsia than to secure the older generation of operating systems and the baggage they have acquired.
Google want everyone to trust the Internet. If consumers are scared to shop online, Google dies. This is why they put so much effort into securing it.
The other huge Google OS (Android) doesn't benefit from POSIX either at all - the POSIX interface isn't even exposed to the user applications.
ANSI C and POSIX do overlap, but aren't the same thing.
Nevertheless, vast majority of applications will never include NDK code and even if they will, they probably won't really talk to POSIX calls directly either. For the type of OS Android is, it doesn't really gain anything by being POSIX compliant far away from developer APIs. And Fuchsia, if anything, is trying to be an Android type OS.
Not being POSIX doesn't mean it's going to be entirely foreign or that it will have no compatibility with software that is already written for POSIX-like platforms. It just means that the basic process management, IPC mechanisms, permissions handling, and so on uses a model which is akin to a cleaned-up subset of POSIX; everything is done via handles, which are a lot like file descriptors but work in a somewhat more uniform way, there is cleaned up management of resource allocations to jobs, memory mapping of processes, and thread management, and so on.
It's not terribly hard to build a POSIX-like layer on top of this; said layer isn't necessarily going to support some of the real warts of POSIX, like the really broken way signals work in POSIX, so some software that intimately depends on this may have to be factored out to support the way that Fuscia handles signals, but for most software this will be a big improvement. Software on POSIX systems nowadays has to jump through hoops to make signals play well with event loops, frequently allocating a pipe that gets written to in a signal handler, so the event loop can pick up that notification later, while in Fuscia that's how signals already work, it's just a state change on a handle that can be waited for in Fuscia's equivalent of select/poll. So in cases like this, Fuscia will add a new code path that is simpler and more maintainable than the one on POSIX-like systems.
How small this POSIX interface can be depends on how much of POSIX legacy you want to reimplement.
It has some convenience functions for decoding files given a path or FD, but I'm sure Fuscia's limited POSIX compatibility layer will support that, basic file access is relatively easy to provide in a POSIX library wrapping Fuscia's file handling.
Likewise, I'd be willing to bet that curl and Git would mostly work on top of the limited POSIX compatibility layer; they might need a few tweaks, but likely not much more than the tweaks needed in porting to the various BSDs and OS X, and likely a lot less than is needed to provide them natively on Windows.
$ git diff --stat origin/upstream/master origin/master
BUILD.gn | 438 ++
include/curl/curlbuild.h.fuchsia | 198 +
lib/curl_config.h.fuchsia | 1034 +++++
src/.gitignore | 1 -
src/tool_hugehelp.c | 9000 ++++++++++++++++++++++++++++++++++++++
5 files changed, 10670 insertions(+), 1 deletion(-)
So it looks like they have had to make zero actual source changes to cURL; the POSIX compatibility layer and setting the appropriate defines in cURL's config files are sufficient.
Many Android apps drop down to the NDK, where POSIX does matter.
> Linux isn't fully posix anyway
It's close enough that the difference really is just an issue of not getting certification.
Everything else on the NDK has nothing to do with POSIX.
Wouldn't surprise me if the unofficial reason is because it's more fun.
That would seem like a massive slap in the face to the cause of freedom, if so.