
Fuchsia: a new operating system - rbanffy
https://lwn.net/SubscriberLink/718267/206c8a5fbf0ee2ea/
======
kardianos
What makes Fuchsia different then so many other attempts at writing a new OS?
They aren't writing a new OS, at least, not in the complete sense.

They are using the IPC system developed in and extracted from Chrome. They are
drawing everything in userspace with fast graphics render but the logic for
all system components written in Dart from the Flutter project. They use musl
for the libc. They are using the little kernel for the core kernel.

As a long time Linux desktop user myself, I'm really excited about this
project. A secure desktop without tons of system calls? Userspace graphics?
Not HTML/JS based? But could still be used for development? Yes Please!

It's really easy to compile and get it running. Try it out!

~~~
desdiv
>They are drawing everything in userspace with fast graphics render...

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?

~~~
mankash666
No. GPUs typically work over the PCIE bus, and one can talk to PCIE via user
space as well. In legacy systems like Linux the mapping of virtual to physical
address and generation of scatter-gather-lists (SGLs) resided in the kernel.
If one moves the same functionality to the user space without loss in
performance (which is what magenta seems to do), there's no benefit to kernel
GPU drivers.

Then there's the whole "GPL mafia" in the Linux world who'd like to force
vendors to open up their drivers by moving as much of the critical pieces to
the kernel as possible. In theory, you cannot write a kernel driver without
violating the GPL. Fuchsia will have no such impositions. If someone wants to
open their driver up, they could. If they believe their offering is superior,
and a secret sauce needs protecting, they can keep it closed

~~~
michaelmrose
You make open source drivers sound like a bad thing.

~~~
mankash666
offering no alternative but "open source" on Linux is certainly not the most
business friendly way to go about it.

~~~
milesrout
Being business-friendly is not a goal, and shouldn't be a goal.

~~~
dragonwriter
> Being business-friendly is not a goal

Sure, it is, for lots of people. Even, apparently, the FSF, hence the reason
non-consumer products are _not_ subject to anti-tivoization rules in GPLv3.

~~~
petre
I wonder why the BSDs haven't caught on for embedded appliances and phones
while Linux did with a more restrictive and less business friendly license.
Sure some companies like iXSystems and Juniper adopted BSDs, but the vast
majority used Linux.

~~~
galacticpony
The manpower behind Linux is superior. Not sure if it's the "vast majority",
but for many business cases following the GPL(v2) rules simply is not a
problem.

Both the PS4 and the Nintendo Switch run on FreeBSD, by the way.

~~~
gribbly
>Both the PS4 and the Nintendo Switch run on FreeBSD, by the way.

Not exactly from what I've read, the PS4 runs 'Orbis OS' which is based upon
FreeBSD 9, meanwhile the Nintendo Switch is using the network stack from
FreeBSD, but also stuff from Android and the custom OS they wrote for 3DS.

------
VonGuard
Capability-based operating systems must be the future. If they are not, then
we are all doomed to continue to exist in a messy world where security
problems crop up every minute. Capability-based access controls are one of the
best options for getting out of our current mess, but they're also the type of
thing that must be implemented very low in the system in order to work.

Hopefully, when we start ripping out *nix before 2038, Fuscia and other
capability-based OS's can take over.

~~~
Touche
> If they are not, then we are all doomed to continue to exist in a messy
> world where security problems crop up every minute.

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.

~~~
naasking
> 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.

Those were people just messing around. Annoying and harmful to your local
machine certainly, but the harm that was caused was localized.

Security vulnerabilities are now industrialized, with large-scale public
attacks and widespread silent compromises used to gather and sell your
information for profit. The situation is still bad, it's just bad in a
different way.

~~~
milcron
Individually, computers today are more secure than they've ever been.

But there are zillions more computers, doing more things, with more
interconnections than ever before. So the problems are compounded and I think
the situation is worse overall.

~~~
bostik
> * Individually, computers today are more secure than they've ever been.*

Unfortunately, that only holds if you take the view that IoT appliance !=
computer.

Because let's be honest - those things are _dangerous_ to general network
hygiene and wellbeing.

~~~
milcron
True, IoT devices are less secure than their internetless predecessors. But
they're more secure than Windows 95 computers.

------
CalChris
I've been waiting for this to be released. I suppose everyone has been.

 _Capabilities_. Like fine grain locks, these are very powerful and very hard
to get right. That's the lesson from Hydra, the 432, .... No, it's not a hard
mechanism for the microkernel to get right; it's a hard policy for the
application programmer to get right. However, that's probably more of an
_opportunity_ rather than meant as a criticism. Our tools are massively more
evolved than they were in the 70s. It'll be interesting to see what happens
with capabilities.

 _C++_. Oh lord. Why are you writing a microkernel in C++? If there was
anything they learned from L4 (Xen, Linux, ...) it is that C is sufficient.
Why do you want to implement something small with something that is large?
This one is a real head scratcher.

 _Provably secure_. They did this with the SEL4 microkernel so this is a
doable thing. If they're going to hang their hat on security (capabilities,
microkernel, ...) there's no excuse for not having done this already and
delivered a provably secure microkernel out of the box.

~~~
pikzen
>C++. Oh lord. Why are you writing a microkernel in C++? If there was anything
they learned from L4 (Xen, Linux, ...) it is that C is sufficient. Why do you
want to implement something small with something that is large? This one is a
real head scratcher.

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

~~~
CalChris
Yes, we know that C is not secure. We also know that C++ is not secure and
moreover it definitely isn't _C, now with security_. It's just more bigger C.
So use your phrase, _you can still fuck up with C++_. You can just do it in
more clever and insidious ways.

seL4, a third-generation microkernel is 8,700 lines of C code and 600 lines of
assembler.

[http://web1.cs.columbia.edu/~junfeng/09fa-e6998/papers/sel4....](http://web1.cs.columbia.edu/~junfeng/09fa-e6998/papers/sel4.pdf)

So we also empirically know that you can formally verify a microkernel written
in C. Now if the Fuchsia folks had gone ahead and formally verified their
microkernel, this issue would be moot. But they haven't. So we are instead
left with _std::shared_ptr offers more guarantees than_ __*. While this isn 't
nothing, it isn't much either.

~~~
staticassertion
I wouldn't use SEL4 as an argument. It is completely unreasonable to build a
production kernel the way they did - it took them _ages_ to get what they had.
Google is probably looking to develop features/ move code a lot faster than is
possible using their technique.

Good coding practices take no time to implement, you learn it once and you
write that way. It is not bullet proof, neither are capabilities. Still, at
least they're practical.

~~~
nickpsecurity
How about Muen separation kernel in SPARK Ada with automated prover
eliminating many classes of undefined behavior? Or C with tools like Frama-C
and Astree Analyzer (like SPARK for C)? C++ can't reach the safety of its
competition due to more complexity and less tooling.

~~~
pjmlp
To be fair, if Frama-C is an option, as someone on the C++ side of the fence
(C vs C++) I would advocate High Integrity C++ is also an option. :)

[http://www.ldra.com/en/software-quality-test-
tools/group/by-...](http://www.ldra.com/en/software-quality-test-
tools/group/by-coding-standard/high-integrity-c)

~~~
nickpsecurity
I thought about it. The reason I left it off is a lack of static analysis,
automatic generation of tests, certified compilers, etc. There's tons of FOSS
and commercial vendors for doing such things in C with quite a bit for Ada.
Whereas, I could find only one or two products for C++ that seemed like it
would be _really_ helpful as opposed to just kind of. So, I pivoted my
recommendations to go with languages that have huge, tooling ecosystems in
academic R&D and commercial. You can certainly use it but might get less value
in long term.

Embedded, real-time Java could also be on the list since Java ecosystem has a
verification tool for about everything. CompSci loves Java for some reason
(probably mandated classes). Yet, verifiable C and SPARK are closer to the
metal than embedded Java plus no Oracle risk. So, left off Java as well.

~~~
pjmlp
I guess so, I just know it from reading about it, so it might be that when
using it won't be as suitable as I think it could be.

On the Java side you can probably check what Aonix used to do, they are now
part of PTC.

[http://www.ptc.com/developer-tools/perc](http://www.ptc.com/developer-
tools/perc)

Also there are the guys from MicroEJ.

[http://www.microej.com/products/device-software-
development/...](http://www.microej.com/products/device-software-
development/microej-os/)

There is no Oracle risk with Java, when companies play by the rules.

PTC, Aicas, IBM, MicroEJ, Excelcior JET, HP, Cisco, Ricoh, Azul, Red Hat and
so many other companies are selling JDKs with their own set of features,
without having had any issue with Sun or Oracle.

Only Google has an issue with Oracle, because they decided they were the cool
kid better than anyone else whose rules don't apply to.

------
tyingq
Are there enough clues to figure out if this is intended to eventually
displace Android, ChromeOS, the Ubuntu distribution most googlers use on their
company machines, or the Linux they run their data centers?

As far as I know, Google hasn't telegraphed the purpose of it. I can't tell if
it's targeted at all, none, or some of the above.

~~~
jasonvorhe
Your guess is as good as mine, but there are some clues:

[https://techspecs.blog/blog/2017/2/14/googles-not-so-
secret-...](https://techspecs.blog/blog/2017/2/14/googles-not-so-secret-new-
os)

[https://techspecs.blog/blog/2017/2/15/proof](https://techspecs.blog/blog/2017/2/15/proof)

~~~
techenthusiast
Thanks, but would sooner recommend my third article:
[https://techspecs.blog/blog/2017/3/15/fuchsias-
hypervisor](https://techspecs.blog/blog/2017/3/15/fuchsias-hypervisor).

~~~
tyingq
The link in the bottom of your first article was very helpful, and seems to
confirm ChromeOS and Android would be the likely targets.

[https://fuchsia.googlesource.com/magenta/+show/master/docs/m...](https://fuchsia.googlesource.com/magenta/+show/master/docs/mg_and_lk.md)

~~~
techenthusiast
Thanks. Yeah, they really could not be more transparent about that. Most of
the bring-up is on mobile + PC silicon as well.

There's no need to kill Chrome OS for the education, mind.

~~~
tyingq
Looked at it again, and it could be an old comment about magenta, and maybe
not applicable to fuchsia?

~~~
techenthusiast
Well, the OS is most strictly the kernel, right? It's honestly all together.
It's an SMP system that you can already run on normal ARM and x86 devices.

The team has stated that everything in the kernel is true, and that there's
quite a lot there to infer from. What they can't say publicly is the how and
why, e.g. how would they hypothetically implement backwards compatibility with
Android apps?

------
krisdol
I'd just like to interject for a moment. What you’re referring to as Fuchsia,
is in fact, GNU/Fuchsia, or as I’ve recently taken to calling it, GNU plus
Fuchsia. Fuchsia is not an operating system unto itself, but rather another
free component of a fully functioning GNU system made useful by the GNU
corelibs, shell utilities and vital system components comprising a full OS as
defined by POSIX.

Many computer users run a modified version of the GNU system every day,
without realizing it. Through a peculiar turn of events, the version of GNU
which is widely used today is often called “Fuchsia”, and many of its users
are not aware that it is basically the GNU system, developed by the GNU
Project. There really is a Fuchsia, and these people are using it, but it is
just a part of the system they use.

~~~
lern_too_spel
It's built with Clang and has a mostly BSD userspace.

------
bitmapbrother
People that question the existence of Fuchsia need only remember why Chrome
was created. A lot of people thought Google was wasting their time by building
a browser, including Eric Schmidt, and look how that turned out. Now, I'm not
saying that Fuchsia will have the same success as Chrome, but it's clear that
they think that having an OS that they can control the direction of is
important to them.

~~~
MBCook
Chrome was based on WebKit, and they bought Android (already based on Linux).
Neither one was made from scratch.

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

~~~
deno
They’ve build Webkit sandbox from scratch AFAIK. That’s not exactly
rebranding.

~~~
nickpsecurity
The security of Chrome was inspired by OP Web Browser and SFI schemes. Clever
but actuslly weaker than predecessors to boost speed.

------
jnwatson
If I had to guess, this looks to be a strong candidate for the embedded OS
market. There are still lots of folks running VxWorks, QNX, ThreadX, Mentor
Graphics' Nucleus, Green Hills' Integrity.

In fact, it looks _a lot_ like the same general design as Integrity, a
microkernel capability-based architecture with as much as possible in user
space.

~~~
bitmapbrother
Its modern rendering pipeline would suggest it has uses for far more than the
embedded OS market.

~~~
Klathmon
I'm not so sure. Perhaps "embedded" is the wrong term, but more and more
devices have full touchscreens on them, and if you are selling a high end
device like a refrigerator, having the UI be fluid and feel high end is
important as well. Not to mention TVs, car UIs, security system pads, and
more.

~~~
bitmapbrother
Its rendering pipeline uses Vulkan which requires a very capable GPU. I'm sure
you could put an expensive SoC into a refrigerator or TV, but it's going to
cost you.

~~~
remir
Can't wait to play games on my fridge!

------
Esau
The one thing that stood out to me is the name of former Be employee Travis
Geiselbrecht. If you are unaware, he created NewOS, which was forked years ago
and became the kernel for Haiku.

I didn't realize that he was working for Google.

------
cmrdporcupine
I don't understand what the value is in writing a new original microkernel
from scratch in this day and age when sel4* is free and open source,
performance tuned for 20ish years, is security hardened, and is provably
correct for both security and features?

This doesn't seem like a wise path to take.

* See [http://sel4.systems/](http://sel4.systems/)

~~~
kjksf
I know nothing about differences between fuchsia and sel4 but it would be
rather strange if something as complicated as a OS kernel wouldn't have many
parts where you have to make trade-offs. People compete fiercely in the field
of todo applications, I don't see why there shouldn't be competition in
microkernel space.

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.

~~~
nickpsecurity
I think author meant L4 kernels were performance tuned for 20 years to be the
fastest. Then, one using applying such lessons was mathematically verified for
correctness down to assembly. It's proprietary and open-source depending on
what your end product will be. They'd probably even add features to it for a
Google-specific version that leveraged as many proven compinents as possible.

~~~
qznc
SeL4 is still working on multithreading. It is probably not good enough for a
user interfacing OS yet.

~~~
nickpsecurity
That's true in its current state. Remember, though, that they're working on
multithreading in a way that ties into their proof from high-level spec down
to the code down to the assembly. Googles people are just putting together a
kernel with review & testing. They could take seL4, modify it for concurrency,
check it with concurrency-related tooling, and still get quite a bit of
assurance from original work. Proof no longer applies but most things it
applied to haven't changed. And model-checkers for concurrency are among
easiest tools to use in formal verification w/ TLA+ getting adoption even by
mainstream companies.

------
SCHiM
That whole handle idea of the 'capability' system, but especially its
implementation with 'handles', sounds exactly like Win32 to me. I haven't
looked at the source, can anyone confirm or explain what exactly is different?

~~~
david-given
Roughly put: in a capability based system, if you have a valid handle for a
service, then you can use that service. But the only way you can get a valid
handle is to ask your parent process for one --- handles are unforgeable. So
your parent gets to check that you're legitimate.

...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/about/screenshots)

[https://genode.org/documentation/general-
overview/index](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.

~~~
Klathmon
That's actually really beautifully simple.

Thanks for this explanation, it really helped the idea "click"

~~~
naasking
And for another beautiful convergence: nowadays most software development is
done in languages that naturally express capability patterns, namely memory-
safe languages. That is, if you have a reference to an object or value, you
have the authority to invoke any of the methods on that object or call any
functions that accept such a value. So object references are capabilities.

Most such languages only go too far by allowing "ambient authority", whereby
_any_ component in your program has the ability to turn a reference to a value
that carries little authority, into one that carries significantly more
authority. For instance, consider the file open API: you're essentially
turning a string, which exposes no unsafe or security-critical methods, into
an object that can literally destroy your computer. And literally _any_
library or component you use can open files. It's madness!

To make a memory safe language capability secure, you simply remove all
sources of ambient authority. This mainly consists of globals that permits
transitive access to mutable state, like file system APIs, global static
variables that can reference transitively mutable data, etc.

These insecure APIs are then replaced with equivalent object _instances_ which
you can pass around, eg. you can only receive the authority to open a file if
you're given an instance to the directory object which contains that file. The
entry point of your program would then change to accept various capabilities
instead of just string parameters.

~~~
catern
And as an even deeper correspondence: Once your language is memory-safe and
capability-secure, you don't even need a kernel, let alone a microkernel.
Rather than use hardware address spaces to separate and modularize components
(the primary idea behind microkernels), you just pass capabilities around to
your components. One component can't crash the whole system, because all it
can access is the APIs you pass in to it. If you want to add isolated
processes to your OS, just implement actors in your language: They're
equivalent.

Of course, you can always have a bug in your APIs that allows an attack or bug
to propagate. But that was always the case even without capability-safety.
Capabilities can't give you _everything_ for free. :)

~~~
nickpsecurity
JX Operating System does something like this within a JVM. It runs on a
microkernel but I think the mediation is app/language level.

------
MichaelMoser123
Lots of interest in Microkernels since everyone got tired of kernel
vulnerabilities. So who won the Tanenbaum–Torvalds debate? It is too soon to
say (Zhou Enlai said that of the French revolution - almost 200 years after
the fact)

[https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_deb...](https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate)

The article says that the focus is on 'PCs, tablets, and high-end phones'.
Wouldn't a more secure OS be relevant to server environment? Is the
performance cost of a microkernel considered to be too high for a server OS?
Is it too difficult to do?

~~~
pjmlp
Given the amount of shipped embedded systems and the hybrid designs from OS X
and Windows, I would say Tanenbaum won.

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/events/Ignite/2016/BRK4010)

[https://channel9.msdn.com/Blogs/windowsserver/Device-
Guard-i...](https://channel9.msdn.com/Blogs/windowsserver/Device-Guard-in-
Windows-Server-2016)

~~~
bonzini
Even with new features like Device Guard, Windows is all but a microkernel;
parts of the GUI high-level primitives (like fonts) are in WIN32K.SYS. Even OS
X moved a lot of drivers to kernel space, it's not a pure microkernel design
like the Hurd.

If anything, the closest thing to a microkernel that is in wide use is Xen, or
Hyper-V.

~~~
pjmlp
Which is why I said hybrid, I didn't say it is a mikrokernel.

In any case it is better than Linux will ever be.

Regarding Xen and Hyper-V, there is a systems paper that states hypervisors
are the revenge of mikrokernels.

~~~
bonzini
I am not sure what's left of the original microkernel design in the NT kernel.
You could say Linux is hybrid too because of FUSE and VFIO.

But yes, I was thinking exactly of that paper when I mentioned hypervisors. It
only applies to type 1 hypervisors though: not KVM, Beehyve, or OpenBSD vmm.
Even VMware ESX is more of a hybrid kernel.

~~~
pjmlp
Windows 10 thanks to UWP, Pico procresses taken from the Drawbrigde project
and the MinWin rearchitecture is probably more closer to that model than the
NT 4.0 descendants were.

Regarding hyperviors, actually I think only type 1 hypervisors make sense.

The type 2 were just a workound due to lack of hardware support.

------
sdegutis
The memory mapping model is really interesting, since it moves a lot of that
out of the kernel and into user-space, but it seems like it has more
disadvantages than advantages. What am I missing?

~~~
btian
Big advantage is better security.

~~~
iainmerrick
And it can be a lot faster. Jumping in and out of the kernel is slow, shared
memory is relatively fast.

------
mankash666
I see great advantages to offering a POSIX compatibility layer. It can be
sand-boxed to the app's context instead of making it a system wide dependency.
Getting existing apps to run out of the box, and then convincing them to adapt
a leaner, narrower set of system calls is probably more valuable than
requiring from-the-scratch development.

------
linschn
> The default Fuchsia filesystem, called minfs, was also built from scratch.
> The device manager creates a root filesystem in-memory, providing a virtual
> filesystem (VFS) layer that other filesystems are mounted under. However,
> since the filesystems run as user-space servers, accessing them is done via
> a protocol to those servers. Every instance of a mounted filesystem has a
> server running behind the scenes, taking care of all data access to it. The
> user-space C libraries make the protocol transparent to user programs, which
> will just make calls to open, close, read, and write files.

Plan 9 is not dead, it ideas live on in other projects.

~~~
zzzcpan
You are confusing things that derive naturally from a microkernel architecture
with Plan 9.

~~~
linschn
I dont understand your point.

I may be mistaken,but my understanding is that userspace servers accessible
through the use of the fopen/fread/fwrite, etc. system calls was an idea that
originated in Plan 9.

Furthermore, some people who worked at Bell Labs at the time now work at
Google.

~~~
nickpsecurity
I'm not sure Plan 9 was first with it. It was inspired by UNIX which was a
watered-down version of MULTICS. That was a microkernel-based system with
generalized I/O with open/read/write:

[http://multicians.org/rjf.html](http://multicians.org/rjf.html)

Now, the question is when was same concept applied to user-space servers? It
was possibly Mach that was UNIX-like with all processes communicating through
ports that were like standardized pipes.

[https://en.wikipedia.org/wiki/Mach_(kernel)](https://en.wikipedia.org/wiki/Mach_\(kernel\))

You got user-space components to open them, read them, write them, etc. That
was 1985 whereas Plan 9 hit universities in 1992. Both models had security and
performance issues that led reliability- and security-oriented OS's to go
different routes on purpose. Plan 9 was a step up from UNIX but a step down
from high-assurance (eg KeyKOS, NonStop) and high-flexibility systems (eg SPIN
OS, LISP machines).

------
bondolo
I know that I am excited that they will be providing soft realtime threads.
I've felt this is a necessary addition for consumer media operating systems
for a long time.

------
Touche
> This is a new take on open-source development where it is out in the open,
> yet secret.

Hasn't this always been the way Android operates? Developed in secret, source
thrown over the wall every release?

~~~
ZakTaccardi
I think this is more, that things are being developed without an explanation
of its purpose. There's no "here are the new features in Android O" blog post

------
ewrcoffee
I can see the major point of making a microkernel is to allow kernel or other
service (like driver) upgrade to be de-coupled; it would also allow much
easier integration of non-open source driver and service, which could be a
pain with Linux as it doesn't provide a clean way to do without rebasing
(which could explain why Android upgrade is much lag behind for existing
phone). But don't get me wrong, I totally support Linux philosophy.

------
phkahler
Fuchsia on RISC-V. That would be interesting.

------
gigatexal
Is there an ISO?

~~~
jrockway
It's relatively straightforward to build a bootable image:

[https://fuchsia.googlesource.com/docs/+/master/getting_start...](https://fuchsia.googlesource.com/docs/+/master/getting_started.md)

------
combatentropy
superb prose

------
throwayedidqo
Fuchsia sounds awesome. Allowing user space processes to do more of their own
work frees up the kernel from providing standardized interfaces to hardware.

This makes it significantly easier to build a closed platform with unbreakable
barriers between processes, and this is a great thing in terms of security and
fine grained access controls for each process. Individual process isolation is
extremely important for most of todays use cases where only a single user is
logged into each system at one time and most running code is trusted.

In practice this means you can prevent user space processes from accessing
anything you don't want them to touch while still giving them substantial low
level access. This will be a boon with device makers because it allows them to
preventing a users apps from compromising the carrier experience. Companies
like Google will also have less concern about users installing malware like ad
blockers. The movie and music industry will also greatly appreciate an
operating system finally designed for 21st century IP protection. This will
even be embraced by hardware manufacturers since they no longer need to
provide open source drivers for their hardware that could be ported to other
platforms. Overall a win-win for everybody.

In the end we can trust that this will result in a better user experience with
more secure apps and devices.

Did anyone hear the whispers of Xooglers a few years back talking about "big
changes" coming to Android that were absolutely horrible for users and done to
placate industry? Hmmmm... This Fuscia thing looks pretty suspicious.

~~~
gkya
This is a complete misunderstanding/misrepresentation of what a microkernel
is. Even GNU is developing their own microkernel, the HURD.

~~~
throwayedidqo
I may be overly paranoid, but the majority of what Fuscia is trying to
accomplish is extremely bad for open platforms.

The outcome of moving drivers to user space will be proliferation of binary
blobs and black box drivers. If you think binary GPU drivers are bad now,
imagine an "open source" OS where every single driver is a binary blob. It
will become impossible to run Fuscia devices on any other operating system
because you have no drivers, sealing off the Android platform permanently.

~~~
snvzz
>If you think binary GPU drivers are bad now, imagine an "open source" OS
where every single driver is a binary blob.

The current situation is they're tied to a version of the kernel, and
typically abandoned by the vendors. With userspace drivers and driver APIs,
the "android upgrade problem" would be solved.

It'd then be a matter of reversing these drivers, which should be far easier
when they're running in userspace and completely bounded.

------
thunder-ltu
I don't want or need any new OS or product from this company. Everything they
touch, initially looks super exciting and positive, until they grab you by the
balls once the competition is out.

~~~
krasin
Specific examples might help to evaluate this generic claim.

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

~~~
thunder-ltu
How many antitrust cases there are pointed at Google in EU alone? It's a one
thing to work for open-source projects, another is to orchestrate the entire
charrade that's about to be unleashed onto the users.

Everything at Google, from it's original product (search engine) to embedded
devices, medical research, entire Alphabet portfolio is aimed at __total
__dominance of every area in people 's lifes. It's an evil company in my eyes,
it's been a long time since I retained at least some trust in this company and
it's vision.

------
weitzj
I somewhere heard about a Google X OS? Is this it?

------
krebby
Was anyone else bothered by the passive voice in this article? I found it
really distracting.

------
swiley
Google has repeatedly prommised, and failed to build a lightweight open OS.
Every time they have produced one it was full of bizzare political constraints
and closed source spyware. I would be shocked if this time was any different.

~~~
riffraff
I don't recall this happening, are you referring to chromeos and android? Can
you share some links if you're not?

------
londons_explore
While this is a cool project, I can't really see it making financial sense...

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

> How much will it cost?

> Ooh - I dunno - If you lend me 1000 engineers, we should be done in about 10
> years, cos we're really smart and don't need to implement legacy SCSI
> support...

~~~
ThrowawayR2
UNIX, as a viable OS model, isn't the last word in operating system design. It
has too much design decisions and other baggage rooted in technology dating
back to the 1970s. As Rob Pike, one of the people who worked on UNIX, said "
_Not only is UNIX dead, it 's starting to smell really bad._"

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.)

~~~
jcoffland
> Linux essentially sucked all the air out of the UNIX development space by
> killing off all the commercial UNIXes.

Only because they have done a really good job.

~~~
cwyers
Eh. The biggest thing Linux had going for it in terms of winning market share
was running on commodity x86 parts in a time period when the commercial Unices
weren't touching it, and x86 made really strong gains in beating everybody
else at performance per dollar.

~~~
sedachv
> The biggest thing Linux had going for it in terms of winning market share
> was running on commodity x86 parts in a time period when the commercial
> Unices weren't touching it

From the 1980s to 1993 there were:

    
    
        v7 ports: Microsoft Xenix (later became SCO), Venix, Coherent
        System III ports: PC/IX (later 386/ix)  
        SVR3 ports: official Intel, ESIX from Everex
        SVR4 ports: Dell UNIX, Novell UnixWare, Microport

~~~
cwyers
Okay? Red Hat Enterprise Linux wasn't released until 2000, so I don't know
what Microsoft's late-80s UNIX distribution has to do with it. Google was
running Linux from the early days, and they launched in 1998, which is nearly
a decade after Xenix stopped being updated.

EDIT: Yes, Linux has its origins sooner, and if you want to know why Linux
beat the BSDs to mindshare, what was going on in 1993 is very important. But
Linux wasn't competing for mindshare with Xenix, it was stuff like Solaris
(which did have an x86 port, but was mostly running on SPARC), AIX (which was
mostly IBM big-iron and POWER), HP-UX (which was PA-RISC and IA-64), etc.

~~~
sedachv
If you want to talk about post-1993, saying that Linux won because there
weren't any commercial x86 Unices makes even less sense. Xenix did not stop
being updated, it became SCO UNIX. SCO bought and continued to sell UnixWare
from Novell in 1995. x86 Solaris came out in 1993, but Sun actually had an x86
Unix since 1991 when they bought ISC.

