bestorworse

Sure, like you said, having control of the endpoints you could communicate anything if you can transmit bits. That’s unavoidable.

But don’t lose the perspective on the benefits of such an architecture. Considering the networking access example:

* If your process gets compromised it won’t be able to access the attacker’s C&C server. It wouldn’t have access to any other stuff that the process didn’t already have for that matter.

* You wouldn’t be able to use http. It would be https only.

* Your process wouldn’t need a lib to talk HTTP. It would just need to talk the IPC protocol (whose wire-format and related details are standardized in Fuchsia which allows for the binding code for (de)serialization to be auto-generated).

* You wouldn’t be able (for better or worse) to mess with SSL certificates, proxies, DNS resolution, etc.

Consider another example -- file access. Say your app wants to access a photo. It doesn’t have access to the filesystem nor to the user’s folders -- it only has access to, say, an “app framework services” capability (eg. services from an UI-capable OS like Android) whose one of the “sub-capabilities” is requesting a photo. When your app does that request the ‘system’ opens a file selection GUI for the user to pick a photo. Note that the photo picker GUI is running on a different process and your app doesn’t know and can’t access anything about it. All that matters is that your app will receive an opened file handle in the end. The opened file handle is a capability as well. The file handle would be ready-only and wouldn't need to actually exist in any file system. In this example, before handing the file descriptor to your app, the “system” (or whatever process is implementing the ‘photo-picking’ capability) could process the image to remove metadata, blur faces, offer the user to edit the image (and maybe actually save it to a persistent store), log that access for reviewing later, etc.

(We already have something kinda similar in Android, but the implementation is not from first principles, so it’s very complex and prone to issues (requires an obviously non-POSIX Android userspace using lots of security features from the Linux kernel to sort of implement a microkernel/services like architecture)).

EDIT: adding the detail that Fuchsia's IPC lang ecosystem has autogen features due to its standardization.

Yeah, it's brand new as far as you would consider in practice (they use existing libraries and the like).

The answer is not much time. The real question is how long to develop good quality drivers for a give platform (say, an x64 laptop)? How long to port/develop applications so that the OS is useful? How long to convince OEMs, app developers and such folks to start using your brand new OS? It's a bootstrap problem.

The joy of having a properly implemented capability system is that, well, you can create arbitrary capabilities.

You don't need to give a process/component the “unrestricted network access capability” -- you could give it a capability to eg “have https access to this (sub)domain only” where the process wouldn't be able to change stuff like SSL certificates.

EDIT: and to be clear, fuchsia implements capabilities very well. Like, apart from low-level stuff, all capabilities are created by normal processes/components. So all sorts of fine-grained accesses can be created without touching the kernel. Note that in fuchsia a process that creates/provides a capability has no control on where/to who that capability will be available -- that's up to the system configuration to decide.

Yep. It's anyone's guess what's been going on there. Lots of theories out there. IMO Google doesn't consider this a high priority and the cost to keep the development going on considering the engineers working on it is low enough.

Also note that swapping the core of a widely used comercial OS like AOSP would be no easy feat. Imagine trying to convince OEMs, writing drivers practically from scratch for all the devices (based on a different paradigm), the bugs due to incompatibility, etc.

It's technically a general-purpose OS. They had a workstation build target sometime ago which was used for the desktop use-case. They've shipped only for an IoT device so far (Google Nest Hub).

Main goal would be to replace the core of AOSP considering the main work that's being done, but it seems like Google isn't convinced it's there yet.

But that seems to be exactly what they are doing. They're surely porting the Android runtime to Fuchsia, or even already ported it.

Remember there are Android APKs containing native Linux banaries (made with Android's NDK) that you should be able to run. That is the whole main point of Fuchsia' starnix. I think this is even mentioned on starnix's RFC.

Isn't this growth pattern a straightforward consequence of disorderly growth?

When microorganisms divide, the children "appear" in the same location. Our species growth dynamics kind of has this same property in that it's easier to build something closer to the already established region than far away.

So, in the end, looking from far away, the growth pattern is the same.

"And you exist only because of us" - Neo

I think this pattern of exponential growth of human beings is a curse of their intelligence. All other animals end up being controlled by these large ecosystem dynamics because they can't adapt and/or do group work sufficiently. Species with this property are easily influenced/controlled by large scale dynamics.

Maybe, a species with more intelligence than us wouldn't grow so fast and unorderly because they can see the future consequences of their own dynamics more easily. We just happen to not deal with large temporal scales very well.

This can be done with a proper capability system.