Fuchsia: a new operating system

Dumb question, does this mean that it's limited to software rendering only? You need to go through the kernel to talk to the GPU, right?

Are there concerns on non-dedicated graphics cards, or running say an ARM-based processor.

Also I'm not sure what you mean by '...easy to compile...' How do you compile this? I'll have to read up on it. Get that checksum bruh.

I remember trying to use Slackware and for me that was a lot of work.

Edit: Oh I see at this time it is limited to three physical machines. Interesting on the Pi 3 part. I wonder if I could try it in Virtual box. But why try it in the first place?

Building user land OS's is a fascinating (if not new) idea that I really love to tinker with a myself. It really would be nice if they can pull it off.

Read through what I could find of the IPC code a while back. Currently it seems workable but a bit "baroque", then again if, as you say, it is working inside Chrome, I guess it is battle tested.

Messaging has always and still is the future for very loosely coupled systems, and driving it all the way down would be really great.

Been following this for a while and can't wait to give it a whirl. Plus everyone likes to root for shiny new OS design projects.

  > They aren't writing a new OS,
  > at least, not in the complete sense.

Neither was Unix. "The success of UNIX lies not so much in new inventions but rather in the full exploitation of a carefully selected set of fertile ideas . . . " --- Dennis M. Ritchie and Ken Thompson, "The UNIX TimeSharing System"

(This book is well worth reading...)

Side-tangent, but security enthusiasts need to calm down on the "world is ending" talk. Those of us who lived through Windows ME, where logging on IRC basically gave you a 25% chance of having your computer hijacked by some random script kiddie, think it's laughable to say that security is anywhere near as bad as it used to be. Night and day.

No one uses them. Security is useless if no one uses it. Capabilities are too hard, too complex, to manage.

Great idea. Horrible implementation.

Because if there was anything proven from years and years of using C, it's that it is woefully insecure and should not be trusted to write a kernel with.

You can still fuck up with C++, sure, but std::shared_ptr offers more guarantees than *.

EDIT: HN stop eating my stars

  Why do you want to implement something small with
  something that is large?

https://techspecs.blog/blog/2017/2/14/googles-not-so-secret-...

https://techspecs.blog/blog/2017/2/15/proof

I can see potential problems already from looking at the Magenta kernel docs. For instance, they say that all syscalls are non-blocking except for explicit wait and sleep calls, which means the kernel is very likely vulnerable to various DoS attacks, which aren't a problem for L4 kernels.

Things changed in hardware in last 20 years and maybe we've learned something about software as well.

Not to mention that sel4 is GPLv2, which is kind of problematic for a commercial company.

In the end, the micro-kernel is a very small part of the whole stack.

...but your parent, in turn, has limited permissions, because the only way it can get a handle is to ask its parent. And when you ask your parent for a filesystem handle, your parent doesn't have to give you the handle it has. Your parent might give you a limited filesystem handle which only allows writes to /tmp.

...and when you, in turn, start a subprocess --- say, an instance of sqlite for use as a database --- you have to give it handles for the things it wants to do on your behalf. But your filesystem handle only allows writes to /tmp. That means that your sqlite instance can only write to /tmp too.

There's more to it than that, because in real life you also want to forward capabilities to other running services as part of RPCs, but you tend to end up with a natural container system with multiple redundant layers of isolation, all running at minimum necessary privilege, and all hardware-mediated.

Another really interesting capability-based OS is Genode:

https://genode.org/about/screenshots

https://genode.org/documentation/general-overview/index

It'll allow you to run complete OS kernels as capability-restricted Genode processes, effectively allowing virtual machines as first-class citizens.

I thought they were just a bit like file-descriptors or X11 window ids, or indeed pointers. Such handles do have a kind of role in authorization: once a process has convinced the system to give it some resource, then the (handle, processid) pair is all the system needs to check access.

However you typically gain the handle through something like `open()`, i.e. an ACLed request for a named resource. But with true capabilities you just inherit authorisation from some other capability -- possibly one granted to you by a different process.

That said, the difference from existing systems might be small. Namespaces are really useful, and are probably here to stay. But as long as things can be accessed by names, the access will need to be controlled by something like an ACL.

https://fuchsia.googlesource.com/magenta/+/master/docs/sysca...

It's early days. The API surface is still evolving.

The majority of embedded OSes have a microkernel design.

Also Windows and OS X have a kind of hybrid design, even if not a proper mikrokernel.

On Windows case,there are now a sandboxed kernel and drivers.

https://channel9.msdn.com/events/Ignite/2016/BRK4010

https://channel9.msdn.com/Blogs/windowsserver/Device-Guard-i...

So, I'd say evidence leans in favor of microkernels being better. The cutting-edge isn't that, though. It's hardware/software combinations that give more reliability and security with better usability & performance than microkernels. Lots of work in languages, compilers, and CPU extensions. CHERI and CHERIBSD is probably top example with Spin OS, JX OS or Redox OS on something like Watchdog-Lite CPU being representative of language-oriented work.

In general: it gives a process a huge amount of flexibility in terms of how it sets up its own address space, communicates with other processes, and in how it can communicate with the kernel.

https://fuchsia.googlesource.com/docs/+/master/getting_start...

https://www.engadget.com/2007/11/05/symbian-nokia-microsoft-...

Google certainly has the resources to do something like this. But neither of those projects (others mentioned Android) were started from scratch at Google.

(I work for open-source projects at Google, and don't see your claim being universally or even mostly true)

Good thing it's funded by someone who has lots and lots of money!

> Lets throw away the last 20 years development on the linux kernel by thousands of people, and rewrite our own.

To suggest that linux is as good as it gets is a mistake. Operating systems are challenging to write, but certainly not impossible. If you're Google, you see big security risks involved in Linux's design. Google tries to mitigate some of those by funding oss-fuzz and a ton of other great options that narrow the opportunity for exploits. But what if you could write your own OS and make particular security guarantees as a design goal?

Google has already designed and/or reimplemented almost every aspect of the OS excluding the OS kernel.

The biggest drawback for starting a new OS is generally the cost of porting existing software to the new OS.

On top of that, Linux essentially sucked all the air out of the UNIX development space by killing off all the commercial UNIXes. Carrying Linux forward rests largely on the shoulders of the kernel team and whatever contributions other businesses feel like making.

So where is the next major OS coming from? Google and Microsoft are the last two companies with the talent to build a future OS and enough resources and clout to push it enough to get traction. (In theory, it could also come from the community but people like Linus only come along once in a generation.)

Android is maybe using 10% of the functionality in the linux kernel but is paying all the overhead and friction of maintaining a branch for each and every device.

I think google wants to heavily encapsulate the hardware vendors drivers and customizations and provide a stable API so google can pretty much update devices with on its own without much interaction with the hardware manufacturers. (Which are very complacent about their updating)

Correct, they don't:

> From piecing together information from the online documentation and source code, we can surmise that Fuchsia is a complete operating system for PCs, tablets, and high-end phones.

Their baseline isn't hardware from 40 years ago, it's that of today and only a subset of it. That means that you can forego an enormous amount of things which are all potential sources of problems. The world has evolved a lot, new theories around OS design and security have come and gone.

Just because Linux serves us well doesn't mean we shouldn't explore other options, or that those other options need to support every old data exchange format and hardware port.

Your argument could have been used against almost every project Google's worked on. Email, search, Go, phones, Chrome, maps, etc. all had established proprietary and open source competitors.

It might be expensive, but it's cheaper, more practical, and more likely to succeed than something like self-driving cars or Google Glass.

Chrome has more code than the Linux kernel.

The numbers I see for 2012 (way back) are: "4,490,488 lines of code, 5,448,668 lines with comments included, spread over 21,367 unique files."

Linux, on the other hand, was ~ 200K lines of code for the kernel (the rest is 7 million for drivers, about which the new OS doesn't need to concern itself, as it will on custom hardware) and 2 million lines for various architectures (ditto).

Don't overestimate the complexity of building a complete kernel -- even teams as resource lacking as NetBSD can do it.

And with other parts of the stack, they already have tons of experience (e.g Skia for graphics etc).