
Fuchsia: Google's modular, capability-based, non-Unix operating system - fanf2
https://fuchsia.googlesource.com/docs/+/HEAD/book.md
======
rossy
This seems good and bad. The prospect of a new, modern operating system is
exciting. The system call interface is sensible and it follows modern security
best practices (eg. deny-by-default.)

One practical disadvantage compared to Linux is that it's not GPL, so if
Google uses it to make a mainstream mobile phone operating system, other
vendors won't be compelled to release their kernel sources like they are with
Android today, which means a Fuchsia equivalent to LineageOS might not support
as many devices.

Also, capability-based security is fine as long as there's some way for the
owner of the device to acquire all capabilities. If there is not, it's
fundamentally anti-user, since it's treating the user as an adversary. Since
most Android devices require aftermarket modifications to get root access, I'm
not too hopeful about Fuchsia. If these bullet points are anything to go by
and DRM and verified boot are first-class features, it's likely that Fuchsia
will have built-in mechanisms that prevent the user from copying protected
video content, so it's unlikely that the average Fuchsia powered device would
grant the user full privileges.

~~~
gonyea
> it's fundamentally anti-user

I don’t get this sentiment at all. The vast majority of users don’t know what
root access is, let alone care about it.

~~~
michaelmrose
Its as simple as imagining any scenario where your interests are at odds with
the oem, the government, or literally any interested party with money and
time.

If Verizon wants to sell you a device with GPS but rent you the feature for 10
bucks a month.

If the government wants the privilege of censorship unobstructed by the
inherent technical impossibility of controlling every aspect of user owned
devices.

If you want to avoid planned obsolescence and use your device longer than 18
months.

If you are a keirig owner if you want to buy the coffee of your choosing.

If you want to refill your ink cartridges.

Any obnoxious thing that people would trivially bypass if they had full
control of their own stuff.

The fact that you an otherwise intelligent individual could ask such a
staggeringly ridiculous question is why the free market is a worthless answer
to any of the above.

There is a reason standards are developed by knowledgable parties rather than
hoping that buyers will navigate the quagmire of complicated topics to demand
sanity from merchants.

~~~
DanielBMarkham
_"...the free market is a worthless answer to any of the above..."_

Nit: it's not a free market if the buyer doesn't understand the transaction.

What we've seen, especially in the latter half of the 20th century and
afterwards, is companies using the complexity of the law to create
transactions in which the buyer thinks they're getting a good deal, but in
fact they're getting screwed over by lawyers. That's not a free market. That's
using government complexity as a club to beat senseless consumers when they
don't do things the way you expect them to. It's a form of rent-seeking using
the regulatory state.

It's important to understand what it is, otherwise you aren't able to propose
any reasonable solutions. For example, throwing even more complexity at the
problem in an effort to protect consumers would just make matters worse.

I'm in favor of your approach, just wanted to point out that 1) it's
incomplete, and 2) without an understanding of root causes we'll still be in
the same spot 20 years from now

------
Sir_Cmpwn
Each time this comes across my feed, there's a brief period of excitement -
"oh yeah, we're getting a new not-Unix microkernel backed by a major company!"
A few moments later I remember that it's being written in C++ and is basically
the evolution of Chrome OS and the mood dampens. I'm still be waiting for the
next truly innovative OS to show up and poise itself to become ubiquitous.
Unfortunately I don't have much faith in Fuschia, especially after poking
around in Chromium.

In the spirit of HN though this comment basically guarantees its success,
right?

~~~
pstuart
What language would satisfy you?

~~~
Sir_Cmpwn
Just C. Rust has a lot of problems for serious low level work imo and suffers
from a lot of the same classes of problems C++ does, and there aren't many
other candidates. A simple microkernel should be fairly straightforward to
write in C without any big security concerns, especially in the hands of a
multi-billion dollar company. You offload most of the security work to the
architecture.

~~~
bluejekyll
> Rust has a lot of problems for serious low level work

Could expand on where it suffers? I've been playing around with Rust in the
embedded space (nothing serious at all); I find it to be as elegant in a
nonstd situation as it is in standard high level app development.

> and suffers from a lot of the same classes of problems C++ does,

What are those classes of problems? C++ never offered a safe alternative to C,
but did offer some eases of use and stronger typing over C.

Rust on the other hand has a _huge_ amount to offer over C. At no point in my
Rust work do I ever wish I was working with C, quite the contrary. But I like
strongly typed languages, Rust is definitely not for those that dislike types.

~~~
Sir_Cmpwn
>Could expand on where it suffers? I've been playing around with Rust in the
embedded space (nothing serious at all); I find it to be as elegant in a
nonstd situation as it is in standard high level app development.

By "the embedded space" do you mean "devices running Linux with Rust in
userspace?" Because that's much higher level than what I'm talking about, and
has very different design concerns from those of a general purpose operating
system.

My main beef with Rust for low level development is that Rust is _way_ more
complicated than it should be. IMO for serious low level programming Rust
should have 1/10th the featureset. It also has issues dealing with the weird
data structures that tend to come up in low level contexts in my experience.
Rust also has the shiny fad status working _against_ it IMO. If, say, 5% of C
hackers understand low level programming and/or kernel hacking, then maybe
0.5% of Rust hackers do (if that).

>What are those classes of problems? C++ never offered a safe alternative to
C, but did offer some eases of use and stronger typing over C.

It comes back to complexity and typing. There's nothing wrong with strongly
typed languages (of which C is a member), but I strongly dislike _object
oriented_ languages and paradigms. Especially in low level contexts it's like
forcing a square peg into a round hole. Other features C++ brings to the table
like operator overloading and templates are antifeatures, doubly so in a
kernel hacking context. Many of the same patterns of unnecessary complexity
introduced by C++ are also present in Rust.

C is boring, but it's also transparent and straightforward. Ergonomics takes a
backseat to simplicity in C, which is a compromise I'd take any day.

~~~
bluejekyll
> By "the embedded space" do you mean "devices running Linux with Rust in
> userspace?"

No, I mean TockOS with the Hail dev board:
[https://www.tockos.org/blog/2017/introducing-
hail/](https://www.tockos.org/blog/2017/introducing-hail/)

> Rust is way more complicated than it should be

People often make this statement, but I don't know exactly what it means. The
type system is great for writing finite state machines, which I'm finding to
be a nice quality for the toy programs I've written on Tock.

> Rust also has the shiny fad status working against it IMO.

Rust is 2 years into it's stable life. It's young, will it ever exceed the
number of lines written than C or C++, almost definitely not, but I wouldn't
dismiss it off-hand because people like it, there might be a good reason for
that.

> If, say, 5% of C hackers understand low level programming and/or kernel
> hacking, then maybe 0.5% of Rust hackers do (if that).

I wonder about this statement. I've noticed quite a large number of people in
the community working with Rust in the embedded space. According to the people
who responded to the Rust survey this year, [https://blog.rust-
lang.org/2017/09/05/Rust-2017-Survey-Resul...](https://blog.rust-
lang.org/2017/09/05/Rust-2017-Survey-Results.html), it was nearly 17%.

> C is boring

I've met more undefined behavior that makes me not agree.

> and straightforward.

:/

~~~
geocar
> > Rust is way more complicated than it should be

> People often make this statement, but I don't know exactly what it means.

I can't speak for op, but you're right: people often make this statement. I'll
try to explain what _I_ might mean:

C is way more complicated than it should be.

The things we want in a language are tools that allow us to tell the computer
what to do, but because people are bad at that, language design is taking us
in the direction of telling the computer _what we mean_ so it can tell us
whether we're talking gibberish or not.

I don't need a type system. I don't need "warnings" about converting floats to
chars: I know what I'm doing and why. I have a good idea what kind of machine
code the compiler is producing, and yes: I often objdump to make sure.

If I need a FSM, I'll use erlang. If I need any kind of data processing, I'll
probably use K/Q where I can. I can write some fast stuff in C where I need
it. If I just need to bosh some stuff together I have perl. Maybe I want to
fantasize about a DSL? It'll probably be a lisp or a forth. If I wanted a
strong type system for units I want to get from some model nerds, I'll use
OCaml.

I don't see the point in Rust when doing these things takes more code and runs
slower, and worse:

> Rust is 2 years into it's stable life. It's young.

I got burned by Python when it was" two years into its stable life" sometime
around 1.5 and again around 2.2, and so I hesitate even looking at rust unless
in a decade it can still run and compile rust programs written today.

This whole "let's rewrite everything in rust" is good practice. I'm watching
you guys do it, and I know afterwards you'll try to beat the performance I'm
getting in other languages.

Once you're writing programs that are smaller and faster than me, then we'll
probably talk.

> C: I've met more undefined behavior that makes me not agree.

I don't write C like most people, so perhaps I don't have trouble with it like
most people. My C programs don't leak memory or crash, and I tend to use a
belt+braces approach to security that is very difficult in languages without
good multiprocess support.

~~~
hota_mazi
> I don't need a type system. I don't need "warnings" about converting floats
> to chars: I know what I'm doing and why.

No, you don't.

Regardless of your skills and seniority (I'm guessing pretty junior with this
kind of hubris), there will come a time where you will make mistakes that can
be caught by a good compiler. You want this compiler at your side, and the
more statically typed your language is, the more robust your code will be.

> Once you're writing programs that are smaller and faster than me, then we'll
> probably talk

What a strange metric. Assembly language would probably meet these
requirements but surely, you would not consider it.

~~~
mining
> I'm guessing pretty junior with this kind of hubris

If you check their profile their site suggests that have ~15 years of
experience.

~~~
geocar
That's just management experience.

I've been programming professionally for almost thirty years at this point.

That's admittedly long enough to get some peculiar ideas about programming,
but there's a certain kind of person that thinks "statically typing" is a
panacea for programming mistakes -- or even that there's a single solution for
anything at all...

~~~
hota_mazi
I wouldn't trust anyone who thinks a solution is a panacea in the software
field, but having type annotations demonstrably leads to not just more correct
code but also code that can be understood better by its surrounding tooling,
thereby enabling automatic refactorings, auto completion, smart browsing,
optimizations, etc...

Static typing is not perfect but it's better in all respects than dynamic
typing.

~~~
geocar
> I wouldn't trust anyone who thinks a solution is a panacea in the software
> field

... unless of course that solution is static typing.

> Static typing is not perfect but it's better in all respects than dynamic
> typing.

Except performance, of course: A dynamically-typed language is at the top of
the STAC-M3 benchmarks for time series data processing.

Oh and defect count: Qmail has the lowest defect count of any source-available
software in the last twenty years and it's written in C.

So I guess static typing is better unless you want correct code that runs
quickly, which unfortunately is important to me.

~~~
hota_mazi
Can you point to these Stac-M3 results and maybe at least mention that
language? I wasn't able to find it.

Static languages are universally recognized and demonstrated as faster than
dynamically typed languages, even if you claim to have found one rare
exception. This is not just an opinion, it's scientific and objective fact.

But please share with us that code that runs more quickly on a dynamic
language than a static language for you, I am genuinely curious (and equally
curious to find out if you just made this up).

~~~
geocar
> Can you point to these Stac-M3 results and maybe at least mention that
> language? I wasn't able to find it.

That makes sense, since your background isn't in high performance computing
and you can't use google:

[https://stacresearch.com/m3](https://stacresearch.com/m3)

The first item on the list is written in an interpreted language.

> This is not just an opinion, it's scientific and objective fact.

I've just demonstrated two counterexamples, so it's clearly not "scientific
and objective fact". Indeed I've never met anyone who even _thought_ Rust
would outperform an experienced C programmer in programmer speed, program
runtime, _and_ low program size.

~~~
ernst_klim
>The first item on the list is written in an interpreted language.

Could I see the code? Because I'm pretty sure you can't write a fast numeric
code without the knowledge of which type you will get on input. That's why
fortran still rocks and we do nat have anything beyond fortran, c and c++ in
the field of computation.

~~~
geocar
> Because I'm pretty sure you can't write a fast numeric code without the
> knowledge of which type you will get on input. That's why fortran still
> rocks and we do nat have anything beyond fortran, c and c++ in the field of
> computation.

You're not far off.

The first trick is that even though `x` can have any type, `x[4]` and `x[5]`
must have the _same_ type. This kind of array whilst uncommon in Python is
extremely common in array languages. Array languages tend to have a lot of
vector operators (and so therefore are very competitive users of the AVS512
instruction set) which tend to be very fast. Programmers of array languages
also tend to avoid things like loops and branches -- indeed you might enjoy
[http://nsl.com/](http://nsl.com/) if you want to expand your mind a bit on
that point.

The second trick is that an interpreter can be made very small. If you can get
your entire program and the interpreter into L1 then you do not stall the CPU
while your program fetches various parts of itself from memory. This is a
trick languages like Fortran and C and C++ don't miss per-se, a very
experienced programmer can usually identify the hotspots and optimise the
hotpath for these things, but it is very time consuming to do this when your
entire program is the hotpath!

~~~
geocar
That should have been AVX512. I blame autocomplete for the typo and myself for
missing it.

------
lobster_johnson
I'm pretty excited about Fuchsia. Just the fact that, if successful, it will
be the first true production-quality general-purpose microkernel-based OS in
the mainstream. (QNX and Minix are of course also successful microkernels, but
both are pretty niche at the moment; are there any others?)

The design also seems extremely sensible and modern: Everything is namespaced
and sandboxed (there's no default "/"), everything is an "object" (sounds
similar to Plan 9's file descriptors), capabilities from the ground up,
standard RPC between OS components (FIDL, similar to COM or XPC), built-in
package management (looks like apps aren't globally installed by unpacking
archives, but rather they're run directly from packages, and the process gets
the archive file system mounted in its namespace), etc.

While Google seems to be aiming for phones, I wouldn't surprised if this ends
up as an option on Google Cloud Platform in a few years' time.

~~~
eikenberry
> everything is an "object" (sounds similar to Plan 9's file descriptors)

The nice thing about Plan 9's everything-is-a-file setup is that everything
has the same file-like interface. Saying everything is an object does nothing
to convey any sort of standard interface.

~~~
pjmlp
Which is good in theory but fails flat when we put graphics and the required
performance into it, as Carmack argued about.

[https://marc.info/?a=111558719100068&r=1&w=4](https://marc.info/?a=111558719100068&r=1&w=4)

[http://rmitz.org/carmack.on.operating.systems.html](http://rmitz.org/carmack.on.operating.systems.html)

~~~
dullgiulio
I can't really find the failures you mention in the links you provided, can
you point me to a more definitive source?

Rob Pike replies here[1] that direct framebuffer access and networking are
easy to get as new devices, although they need to be made available by the
kernel. The "everything is a file" mantra doesn't fail, why would it?

In the second link, Carmack just notices that plan9 is pretty dead, and we all
know it is :)

[1]
[https://marc.info/?l=9fans&m=111558695515846&w=4](https://marc.info/?l=9fans&m=111558695515846&w=4)

~~~
pjmlp
It fails because it doesn't match the performance that other approaches are
able to achieve.

Everything is a file is how X Windows over network kind of works.

For real graphics performance that can match other systems, xshm and DRM had
to be developed.

------
TheAceOfHearts
Definitely suggest reading through their docs, it's fascinating. One of the
features I'm most excited about is storage management.

From "What is ledger?" [0]:

> Each data store is transparently synchronized across devices of its user
> through a [cloud provider]. Any data operations are made offline-first with
> no coordination with the cloud. If concurrent modifications result in a data
> conflict, the conflict is resolved using an app-configurable merge policy.

I'll note that although they use Firebase as the sync provider, it should be
fully possible to host your own if you wish to avoid the cloud.

Keeping stuff in sync can be a huge pain sometimes, especially when you're
just dealing with scattered files. I like having this functionality as part of
the core system, and getting developers to handle our multi-device world.

The Ledger design docs are worth reading, they're short and approachable.
Architecture [1] explains how it's implemented, and Conflict Resolution [2]
covers how to handle when things go wrong.

[0] [https://fuchsia.googlesource.com/ledger/#what-is-
ledger](https://fuchsia.googlesource.com/ledger/#what-is-ledger)

[1]
[https://fuchsia.googlesource.com/ledger/+/HEAD/docs/architec...](https://fuchsia.googlesource.com/ledger/+/HEAD/docs/architecture.md)

[2]
[https://fuchsia.googlesource.com/ledger/+/HEAD/docs/conflict...](https://fuchsia.googlesource.com/ledger/+/HEAD/docs/conflict_resolution.md)

------
filereaper
I'm curious to hear about the design principles going into Fuchsia... ie Unix
tried out X, but that inturn runs into issues Y and Z down the line.

i.e the "why" behind the design they've chosen.

~~~
nl
_Unix tried out X_

For a moment there I thought you meant the _X_ Windowing system.

------
gigatexal
If anyone was going to reinvent an OS I’d like google to do it. They’re
capable and have the cash to do it. I do think have this in conjunction with
buying HTC (rumored) could be them trying to iPhone and their lineup by owning
both the software (via fuschia) and the hardware.

~~~
norswap
Google can't get Gmail to sort mail properly. Amongst a thousand of small
grievances I have.

That may seem quite irrelevant, but if I'd like someone to reinvent the OS,
I'd like it to be people that have taken a stance in favour of stable, simple,
straightforward software (the people behind Pinboard, Tarsnap; djb... just to
name a few).

~~~
lamlam
I've never had any issues sorting mail in gmail. I'm curious what specific
action causes mis-sorting.

~~~
norswap
Basically, in some views the sorting is by the first message in the thread,
while in other views it is by the last message (that last one makes more sense
to me).

Even more surprisingly, Inbox (by Google) sorts everything by last message
(last time I checked, which was a long time ago).

------
0xbear
Their main problem is not the kernel. It’s their application APIs. What a
clusterfuck that is in Android. And now with tens of billions of LOCs written
for it they’re stuck with it forever.

~~~
HillaryBriss
i mostly agree. as a mere mortal android app programmer, i feel a significant
amount of pain when i build apps using the android SDK and the standard set of
tools. there's a lot of weirdness, confusion, unexpected behavior, anemic
documentation and irregularity. (it's getting better, but not fast.)

i guess Google's Fuchsia push is motivated by some other, internal concerns.

------
abrowne
The "Web runtime" is under the header "Backwards compatibility".

------
GorgeRonde
Why everytime a "new OS" comes around it uses the good old fashioned command
line with the GNU stack ?

~~~
X86BSD
Not every new OS does. The ones that do are using the GNU stack, at least
initially because they are there and it saves time. Even then down the road
some purge GNU from their OS in favor of better utils, more liberal licensed
code, etc.

------
omarforgotpwd
Seems cool that you can pass “handles” to resources like network connections
between processes. That could definitely make some server software easier to
architect.

~~~
naasking
Yup, everything old is new again. This was part of one of the first capability
operating systems in widespread operation back in the 70s: KeyKOS.

------
systems
why does the wikipedia page have Go, Rust, Python and Kotlin in the languages
list Fuchsia is written in?

~~~
topspin
That seems like a stretch.

When you look at the Fuchsia OS repositories in Github and select these by
language the overwhelming bulk are C++. Regarding the languages you cite:
there are some non-trivial parts in Go; the Fuchsia package manager, for
instance. There are several bindings to certain key parts of the OS provided
for Rust, but no actual Rust components that I can see. Python is used for
some build and packaging utility type stuff. Kotlin is provided with one
binding library with four whole commits.

Regarding two others mentioned in wikipedia; Dart is actually more prominent
than Go, Python, Rust and Kotlin combined. C has lots of binding libraries,
but only a pair of boot loaders appear to be core components, plus a fortune
stub.

~~~
bitmapbrother
The Fuchsia OS network stack is built in Go.

------
Kabie
They renamed the kernel(Magenta) to Zircon.

------
2_listerine_pls
Is it Linux?

------
cheez
Why?

~~~
Lutia
> Why?

Not having to deal with Linux's refusal of maintaining a stable driver API and
ABI for a start. The number one reason that stops Android from getting updates
on smartphones is that hardware manufacturers don't want the burden of
constantly making small changes to their proprietary drivers to follow new
linux kernel changes, something that they don't have to worry about when they
make drivers for, say, Windows PCs.

Even Google's own phones, like the Nexus and Pixel, are stuck because of this.
They receive updates faster than non-Google phones, but they do not receive
more than 2 years of feature updates (with an additional year of security
updates courtesy of Google backporting fixes from newer android builds to the
older kernel).

Fuchsia is not going to be burdened by Linux kernel dev policies of constantly
breaking APIs and their requirement for driver developers to open source their
stuff, obey the kernel coding preferences (like when they rejected AMD's
driver because of the HAL) to get them mainlined so that they can finally be
kept in a maintained state.

~~~
catern
>Fuchsia is not going to be burdened by Linux kernel dev policies of
constantly breaking APIs and their requirement for driver developers to open
source their stuff, obey the kernel coding preferences (like when they
rejected AMD's driver because of the HAL) to get them mainlined so that they
can finally be kept in a maintained state.

And as a result, its drivers will be far lower quality and much less stable,
and the system as a whole will pay the complexity cost of working around the
awful code that hardware vendors churn out.

~~~
quotemstr
> And as a result, its drivers will be far lower quality and much less stable

I don't buy it. Windows provides stable driver ABIs and works just fine. A lot
of the changes to the Linux driver API are gratuitous, and isolating driver
development from the whims of the core won't actually hurt.

If anything, a stable ABI will _help_ , since a smaller, well-defined boundary
between the kernel core and drivers allows for things like Vulkan-like
validation layers, better debugging, better sandboxing, and even transparent
thunking to userspace.

Will some drivers be shitty? Of course. But many drivers won't be, and drivers
will be less shitty overall when they can spend more time on being good
drivers and less time dealing with GFP_FOOBAR becoming GFP_BARFOO.

Conventional wisdom is that backward binary compatibility i some huge
unreasonable burden. This conventional wisdom is wrong; if anything,
maintaining a stable ABI imposes some discipline that focuses development
effort and that forces you to modularize your system.

~~~
mangix
I've seen a larger amount of instability in Windows than in Linux. Having a
stable ABI doesn't help much.

~~~
Lutia
I've personally never had any problem stemming from the lower levels of the
system ever since Windows 7. Whenever I've seen major bugs on Windows, it was
on user space stuff like the profile corruption that breaks the start menu and
metro/UAP apps in Windows 10 after the major updates which can be fixed by
deleting the user and creating a new one.

Windows also has a more robust architecture where it matters, like the fact
that a GPU driver crash doesn't kill the user session (windows can reload that
subsystem while keeping the user session running since Vista), whereas it can
either kill Xorg or just outright freeze the system on linux. A very useful
way to architect the OS, although I've only experienced it on Vista and had
more stable GPU drivers from 7 onward.

------
baybal2
It is not GPL, therefore it is bad.

If their main point was to get rid of GPL in kernel, and low level userspace,
their main point is bad.

------
nopacience
first they created google, then they created gmail. then orkut. then android.

when will google toilet arrive ?

trust them for everything

~~~
romanovcode
Android will be running on this OS.

------
davemp
Judging from google's track record with android, chrome, and youtube, I'm not
very excited for this project. As much as I would love some innovation in the
OS world, I find myself hoping that this system does not catch on.

Google has not proven themselves to be a developer/enthusiast friendly
company. It feels like they look down on the rest of the world while locking
systems behind restrictive(cumbersome) APIs to protect the unenlightened from
themselves. Maybe that design philosophy is okay for services/apps but it has
no place at the system level IMO.

Who knows maybe the fuchsia team doesn't share that philosophy, but I doubt
it.

