
Fuchsia overview - farmerbb
https://fuchsia.dev/fuchsia-src/concepts
======
catern
>Fuchsia aims to provide drivers with a binary-stable interface. In the
future, drivers compiled for one version of Fuchsia will continue to work in
future versions of Fuchsia without needing to be modified or even recompiled.
This approach means that Fuchsia devices will be able to update to newer
versions of Fuchsia seamlessly while keeping their existing drivers.

This is a massive step back for open source. The fact that Linux doesn't have
a binary-compatible driver interface is a good thing: It means hardware
vendors have a very strong incentive to get their drivers upstream into the
kernel. And indeed, on servers and laptops and desktop machines, this has
largely happened. But on mobile platforms, with Android, it has not happened.
For various reasons, but nothing fundamental.

We would all benefit if Android hardware drivers were upstreamed. This would
allow for a much more competitive, and higher quality, software and hardware
ecosystem on mobile platforms.

But Fuschia is going in the exact opposite direction: It makes it possible to
build proprietary drivers. It's for this reason that I hope Fuschia is not
successful. We already have a high quality kernel: Linux. If Fuschia is "not a
science experiment", but instead intended to use proven ideas, then any
improvement that could be added to Fuschia could be added to Linux. We don't
need a new operating system whose only advantage is that it's easier to write
proprietary drivers.

~~~
ptomato
> For various reasons, but nothing fundamental.

"Hardware vendors being unwilling to make the drivers they write open source"
is a pretty fundamental reason.

Which is worse, a phone where you can't update kernel because of the closed
drivers or a phone where you can update the kernel, with closed drivers? I
don't think that realistically there's a third option. The open source
community is not, for example, going to make their own high performance gpus.

~~~
cycloptic
I would not say that is a fundamental reason. They have been willing to do it
when the proper incentives are there. The incentive to keeping it closed
source is primarily part of a strategy to sabotage their competitors, which I
hope is not a behavior that anyone here is complicit in. Please don't work for
hardware companies that do this, there are plenty of companies out there that
know how to spend their money in other ways.

>Which is worse, a phone where you can't update kernel because of the closed
drivers or a phone where you can update the kernel, with closed drivers?

Neither of those are good options because even in the second case, there are
still vast swaths of code that upstream is not going to touch out of fear of
breaking things, the end result being that you still get stuck with unfixable
kernel and driver bugs.

>The open source community is not, for example, going to make their own high
performance gpus.

The open source community includes a lot of companies. The high-performance
GPU companies are welcome to join this community any time they like.

~~~
fluffy87
This claim is wrong. It’s not about sabotaging competitors, it’s about being
afraid that your competitors would steal your IP they gives you an advantage.

Every Nvidia and Intel competitor (AMD) is probably already reverse
engineering their binary drivers and binary libraries trying to steal their
IP, so Intel and Nvidia’s fears are imo justified.

If NVIDIA or Intel could easily protect their open source code from being
stolen from AMD, the story would be different. But you can’t prevent somebody
from reading even GPL code, being “inspired” by it, and writing something
different enough that does the same thing with the same ideas. Like just look
at the LLVM project were people look at what GCC code does every now and then
for “inspiration”.

~~~
AsyncAwait
> Every Nvidia and Intel competitor (AMD) is probably already reverse
> engineering their binary drivers and binary libraries trying to steal their
> IP, so Intel and Nvidia’s fears are imo justified. If NVIDIA or Intel could
> easily protect their open source code from being stolen from AMD, the story
> would be different.

Intel's GPU drivers are free software, they even contribute them themselves,
same goes for AMD.

I think NVIDIA's different because they have the Apple mentality of them being
the real innovators, (regardless of fact) and building their internal culture
on secrecy, closeness even to other teams within the company etc. I think they
consider it as part of their 'coolness factor', together with the CEO being on
stage dressed like a rock star from the 80s.

The fact that they benefit from Linux massively and that having an open driver
would win them massive goodwill is not directly measurable in terms of their
balance sheet, at least in the short term, plus it would remove some of the
secrecy.

~~~
pjmlp
They do so by using different teams, and their open source variants always lag
behind what their closed source drivers are capable of doing across Windows,
Apple and game consoles.

~~~
AsyncAwait
The drivers are decent enough nonetheless. I think having an open driver done
by a different team and maybe a bit less optimized is still preferable to not
having an official open driver at all.

~~~
pjmlp
I used to enjoy my OpenGL 4.1 driver on Radeon HD 6250, which was still short
of OpenGL 4.4/DX 11 on Windows, but still quite ok I guess, all it does now
with open source drivers is OpenGL 3.3.

So no that isn't decent enough, and I only keep it like this, because it is
just a little travel laptop that I keep on using until it eventually dies.

~~~
AsyncAwait
Why even mention a fairly ancient GPU when AMD has really only gotten their
act together fairly recently with amdgpu, but that supports Vulkan as I would
expect.

I don't get this constant obsession with mentioning how 8 years ago this and
this on Linux sucked. Yes, it did, things improved considerably since then.

If you're only willing to run Linux on ancient, underpowered hardware and then
complain about the experience, be my guest, but I think you'd be better served
by a Mac.

There's a whole class of people who run Linux on shitty little laptops and
then compare the experience to their brand new iMac. I guess somewhere there's
still the mentality that since one's not paying for Linux, it's not for my
serious hardware, only second hand.

As much as I'd have liked for AMD to get their shit together sooner, I am glad
they eventually did and are improving amdgpu at a decent speed.

~~~
pjmlp
That was just one example, I can provide more up to date ones as well.

Indeed, that is why this Linux laptop is the surviving one that still runs
Linux on bare metal, everywhere else I just VMs, if at all.

------
loeg
> Fuchsia's goal is to power production devices and products used for
> business-critical applications. As such, Fuchsia is not a playground for
> experimental operating system concepts. Instead, the platform roadmap is
> driven by practical use cases arising from partner and product needs.

This is an interesting statement given how many relatively unpopular OS
concepts it integrates. I am interested in seeing this succeed. I hope that
Fuschia helps drive capability-based sandboxing of end-user software.

~~~
goodthenandnow
Yes. That is what we as users most need.

Application sandboxing from first principles and the very bottom

------
jpm_sd
Sounds a bit like a modern, open approach to the problems that were solved by
QNX. Excited to see how it evolves!

~~~
Animats
Not really open. If you submit code, you grant a license to Google to use it
in non-proprietary code.[1] So, at some point, once users and developers are
locked in, Google can make later versions closed and proprietary enough to
stop clones.

Like they did to Android with Google Play Services.

[1] [https://cla.developers.google.com/about/google-
individual](https://cla.developers.google.com/about/google-individual)

~~~
mbrukman
Disclosure: I work at Google (but not on Fuchsia), and I contribute quite a
bit to open-source projects.

Disclaimer: I'm not a lawyer, this is not legal advice, etc.

I'm not sure what you mean by "you grant a license to Google to use it in non-
proprietary code" — was that a typo and did you mean "proprietary"? In any
case, Apache/BSD/MIT licensed code can _already_ be used in proprietary code,
the CLA does not change that.

The Google ICLA you cited [1] is basically the same as the ASF ICLA [2]; the
gist is that you retain copyright of your contributions, you're not giving up
your copyright — i.e., it's a copyright _license_ , not a copyright
_assignment_ (as some other CLAs are).

And, naturally, _anyone_ can fork it if they wish, or distribute proprietary,
non-open-source versions of an Apache/BSD/MIT-licensed project, subject to
appropriate attributions, if required, by the relevant licenses.

However, neither you (nor Google) can claim copyright over the entire project,
because the copyrights are held by the relevant contributors. Changing the
license for the entire project requires agreement from all copyright holders —
for example, see what LLVM had to do when they chose to add a clause to their
license [3].

[1] [https://cla.developers.google.com/about/google-
individual](https://cla.developers.google.com/about/google-individual)

[2]
[https://www.apache.org/licenses/icla.pdf](https://www.apache.org/licenses/icla.pdf)

[3]
[https://llvm.org/foundation/relicensing/](https://llvm.org/foundation/relicensing/)

~~~
choppaface
The point is that when a non-Googler contributes code, it’s non-proprietary
since the non-Googler is by definition a non-Googler. What the CLA does not
prohibit is proprietary use—- your lengthy answer. The OP makes the point that
Google will find a way to use public contributions for Google’s own profit.

The sheer size of the response above, let alone content, is what creates the
tone of “talking past the customer” which is what has alienated so many people
from Google. The problem I’ve repeatedly experienced in Google open source and
as a Google Cloud customer (contract with Google FDEs on-site) is that
Googlers just don’t listen. You can’t trample the customer with your own
narrative no matter how correct and elegant it is. You can disagree, but you
can’t deny the feelings of others. It just doesn’t work that way.

~~~
mbrukman
Disclaimer: I'm not a lawyer and this is not legal advice.

I've added a clarification separately, please take a look there first:
[https://news.ycombinator.com/item?id=23365469](https://news.ycombinator.com/item?id=23365469)

> _The point is that when a non-Googler contributes code, it’s non-proprietary
> since the non-Googler is by definition a non-Googler._

I think we are using different definitions of "proprietary". I'm using it to
mean "non-open-source" [1], and you're using it to mean "employed by a
specific company" (or something else); can you please clarify what you mean or
rephrase what you're trying to say?

> _What the CLA does not prohibit is proprietary use—- your lengthy answer.
> The OP makes the point that Google will find a way to use public
> contributions for Google’s own profit._

That's not the purpose of a CLA; that's the purpose of a project's license.
That was the point of my post. Anyone can take a project with an
Apache/BSD/MIT license (whether or not the project has a CLA, it's
orthogonal), make a proprietary product from it, distribute it, sell it, etc.
and they would be just fine doing it, without also sharing any of the source.

To put it another way, a CLA cannot restrict proprietary or commercial use of
a patch or contribution, if the underlying project license is Apache/BSD/MIT,
because all those licenses already allow commercial use, incorporating
software into proprietary / closed-source products, etc. Such a CLA would be
incompatible with the project's license.

I've never seen an Apache/BSD/MIT project where the _CLA_ (and only the CLA)
prohibits commercial / proprietary / closed-source or any other use cases — if
you have an example or two, could you please point them out? I'm very curious
to see how this would work in practice, because this seems like a strong
contradiction, so I would be interested to see how this plays out in practice.

[1]
[https://en.wikipedia.org/wiki/Proprietary_software](https://en.wikipedia.org/wiki/Proprietary_software)

~~~
afiori
I think a nice example that could help clarify the situation is the CLA that
Canonical uses; if I remember correctly they reserve to themselves the right
to change the license of community contributions.

~~~
mbrukman
Looking at the Canonical CLA [1], you're right that it _allows_ Canonical the
right to relicense contributions under any other license:

> _2.3 Outbound License_

> _Based on the grant of rights in Sections 2.1 and 2.2, if We include Your
> Contribution in a Material, We may license the Contribution under any
> license, including copyleft, permissive, commercial, or proprietary
> licenses. [...]_

However, please note that my original comment [2] was asking for a CLA which
_prevents_ usage in a proprietary setting, while the project is under a
permissive license like Apache/BSD/MIT (emphasis added):

> I've never seen an Apache/BSD/MIT project where the CLA (and only the CLA)
> _prohibits_ commercial / proprietary / closed-source or any other use cases
> — if you have an example or two, could you please point them out?

[1]
[https://ubuntu.com/legal/contributors/agreement](https://ubuntu.com/legal/contributors/agreement)

[2]
[https://news.ycombinator.com/item?id=23365535](https://news.ycombinator.com/item?id=23365535)

~~~
afiori
It was not directly a reply to that case, it was meant to say that even if the
license was GPL so that a proprietary fork was forbidden, a CLA could make it
so that only the owner of the project is allowed to use your contributions as
proprietary.

It was an example of a case where a CLA could have caused what was imputed by
the original comment.

~~~
mbrukman
That's a fair point, thanks for the clarification.

------
jccalhoun
>Fuchsia's goal is to power production devices and products used for business-
critical applications

People have guessed that Fuchsia is some successor to Android or unification
of Chrome OS and Android. However, this statement makes me wonder if it is
meant to run their backend hardware and not consumer products.

~~~
qmarchi
Actually quite the opposite, Fuchsia already runs on production devices
manufactured by Google. The (ridiculously long named) Google Nest Home Hub and
Home Hub Max both can run Zircon and Fuchsia on device, although it's very
much for development.

~~~
jeffbee
They probably cut it down from the original “Play Home Hub All Access by Nest
by Google”.

~~~
dragonwriter
The original sold-as product name was Google Home Hub, the announced rename
was the shorter Nest Hub, though it seems to be fully Google Nest Hub (that's
the title of the Google Store product page, though the page itself only ever
used Nest Hub.)

I can't find anything from Google using both the “Nest” and “Home” bits as
part of the same product name, though some third party sites seem to have
mixed the old and new names that way.

------
gman83
Sounds like Google's version of Darwin.

~~~
plerpin
You mean Mach?

~~~
Godel_unicode
Please see the below diagram from Wikipedia explaining the difference between
Mach and Darwin. I agree with OP that Fuschia is much closer to Darwin than
Mach.

[https://en.m.wikipedia.org/wiki/File:Diagram_of_Mac_OS_X_arc...](https://en.m.wikipedia.org/wiki/File:Diagram_of_Mac_OS_X_architecture.svg)

------
butterisgood
I really like Fuchsia design wise... it’s got a great build system and folks
on IRC have been nothing but friendly and excellent! Travis and team are doing
a great job!

------
cletus
I can't help but think that if microkernel architectures were such a good
idea, that would explain why every popular OS is a microkernel architecture
(oh wait...). Snark aside, this is a serious debate since the inception of
Linux [1].

It's important to look at Fuchsia through the lens of what problems it solves
in Android/Linux because that tells you a lot.

As we know, receiving updates in Android is, well, a clusterfark. There are
two key problems:

1\. Phone manufacturers need to write or update drivers essentially with each
Android release; and

2\. Those drivers are by nature of Linux being a monolithic kernel, written in
kernel space. Kernel space code by third-parties is going to be inherently
more unstable to your device than if they were written in user space.

So when Google talks about Fuchsia having a stable binary ABI for drivers,
they're talking about solving both of these problems (at least as they see
them).

So the question I've always had about the justifications for pouring billions
of dollars into Fuchsia (I mean that quite literally) is: could this really
not have been solved in Linux, even if it's just the limited context of
Android?

I'm not a driver or Linux expert by any stretch of the imagination. I'm sure
there are people here who are so this is my question to you: could you have
created a system for ideally user space drivers with a stable ABI in Linux and
avoided all the costs of completely reinventing that wheel?

My other question about Fuchsia is: does Google foresee themselves adopting
the same vertically integrated solution that, say, Apple does? It's worth
noting that Apple by not providing iOS to third parties is somewhat
paradoxically immune to antitrust investigations (I mean really... how does
that work?).

Evidence against Google adopting the Apple model is the fact that Fuchsia is
open source, which is a curious decision. This seems to imply that Google
either wants to maintain an Android-like ecosystem or they simply see it as
their only viable option.

I don't know how anyone can expect that Samsung is going to move to Fuchsia.
Samsung already chafes under the yoke of their Google dependence with Android.
They've tried to get out from under it (ie Tizen) but luckily for Google,
Samsung is terrible at software (at anyone with Samsung crapware on their
Galaxy can attest; Bixby anyone?).

Maybe Google thinks the insurance of Fuchsia being open source is necessary
for third-party adoption to have any chance but still, the only way I see
Samsung going along with this is that there's absolutely no other alternative.

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

~~~
pjmlp
Android Linux also has it since Project Treble.

Linux drivers are considered legacy on Android, all new drivers should follow
the Project Treble architecture, which is basically the genesis of how Fuchsia
drivers work.

Every driver has their own process and uses Android IPC to talk with the
kernel.

The stable ABI is Android HIDL, similar to Fuchsia FIDL, a protocol buffer
based IPC for fast communication with the kernel, that also allows for passing
references to hardware buffers across processes.

You can read all about it at AOSP web site.

------
jokoon
It's been 4 years and it's still being developed? Apparently android v1/v2 was
released about 1 year later after the first iPhone.

It doesn't seem so easy to make a new OS/kernel.

The linux kernel is not perfect, but at least it works well, it's mature, and
developers know how to work on it.

~~~
oseityphelysiol
>It's been 4 years and it's still being developed? Apparently android v1/v2
was released about 1 year later after the first iPhone.

I'd say they learned a lot from Android, the use cases and problems arising
from supporting such a giant project on so many different devices (and non
cooperating vendors). So it's not a surprise they're taking their time. I
imagine there must have been a long and in-depth analysis at Google of Android
and other operating systems before Fuchsia came to be, considering the money
they're going to spending on it.

AFAIK Android was a quick hack and the ecosystem, if you know anything about
it, you know it's a mess.

~~~
goodthenandnow
Yep.

It's not always that appears a new software that is very well thought out and
designed. In general things are hacked together and made in somewhat a hurry
and it ends up causing a lot of problems afterwards.

It's also not everyone, meaning companies in practice, that could aford time
to analyse, design, test and iterate such a software like an operating system
and all its needed subsystems for the modern needs...

------
drtse4
Haven't checked Fuchsia in a while, very glad to see that they have extended
the documentation.

Did they improve the initial steps to get up and running too?

(I remember it took hours to clone all the subprojects and most of the times
something failed along the way, even worse than downloading the Android
sources)

------
dzonga
everything in userspace == high security. programs, software won't clash like
they do on *nix, windows due to isolation. same benefits of snaps | flatpaks.
but now you've a microkernel which is 1. fast 2. easy to patch 3. stable ABI
something Linux doesn't have.

~~~
michaelmrose
In what way does software "clash" on *nix? The isolation provided by snaps and
flatpaks is 99% about isolating devs from having to worry about deps and
different platforms.

~~~
lsofzz
flatpak/snap applications can run on its own confined sanboxes

~~~
michaelmrose
Which are complete and total garbage insofar as actual isolation. If you think
you can run malware in a snap and not be pwned you are kidding yourself.

------
axegon_
I've been eyeing Fuchsia for some time now and wanting to give it a spin but
I've been holding back just to make sure it doesn't get abandoned(despite
having a well maintained fork already). Real shame they pulled the plug on the
raspberry pi support.

~~~
nmcain
What fork are you referring to?

~~~
axegon_
DahliaOS.

~~~
nmcain
Haha, I thought there was another fork going around. Don't worry, we are
actively working on Pi4 support, Fuchsia dropped the 3 because they changed
the graphics stack to one that used Vulkan, but the Pi4 has experimental
Vulkan support.

------
tempodox
I was trying to find out from that site who's behind this and if that
information is in there it must be really well hidden. Apart from other
concerns, I'm not going to touch an OS from a group that doesn't clearly state
who they are.

~~~
SSLy
It's GOOG's GPL-less replacement for the Linux kernel, made so they can
control the phones even more.

~~~
tempodox
Now I understand why much of the language in there looks more like foggy
marketing hype than a comprehensible explanation.

~~~
SSLy
Besides, the page's CSS is (besides colours) very alike to their other
properties. [https://cloud.google.com/kubernetes-
engine/docs/tutorials/he...](https://cloud.google.com/kubernetes-
engine/docs/tutorials/hello-app)

And, well "For details, see the Google Developers Site Policies."

------
killjoywashere
Has anyone tried installing this on a ThinkPad? Like an X201 or X230?

------
sam1r
What is the cheapest fuschsia supported hardware device?

~~~
michaelmrose
Logically an emulator [https://fuchsia.dev/fuchsia-
src/getting_started#set_up_the_e...](https://fuchsia.dev/fuchsia-
src/getting_started#set_up_the_emulator)

Regarding supported platforms

"Fuchsia has good support for a few different hardware platforms including the
Acer Switch 12, Intel NUC, and Google Pixelbook (not to be confused with the
Chromebook Pixel). The install process is not currently compatible with ARM-
based targets."

Looks like the 2 laptops can be had used/new for between 660-1k+ while the NUC
can be purchased as a bare board with cpu for as little as 290

[https://www.intel.com/content/www/us/en/products/boards-
kits...](https://www.intel.com/content/www/us/en/products/boards-
kits/nuc/boards.html)

------
stewbrew
I still think its strange to create an OS that officially supports only 2-3
languages for development. Sounds rather 1980s to me.

~~~
TulliusCicero
2-3 languages? It has support for C, C++, Dart, Rust, and Go. And I think some
level of support for Swift.

~~~
stewbrew
I wouldn't be so sure about Go. Anway, I found certain remarks somewhat
irritating in this respect. I'm happy if it turns out I misunderstood
something.

~~~
abraham
Go is listed as a language [https://fuchsia.dev/fuchsia-
src/development#languages](https://fuchsia.dev/fuchsia-
src/development#languages)

~~~
stewbrew
I see they pulled their language policy from a few months ago. Good.

------
dang
Please don't editorialize titles. This is in the site guidelines:
[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html).
Lots of explanation here:
[https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...](https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=by%3Adang%20%22level%20playing%20field%22&sort=byDate&type=comment)

(Submitted title was 'Fuchsia overview – “Fuchsia is not a science
experiment”')

~~~
phreack
I'm sorry if this isn't the place to ask (and please let me know), but how
should we correctly title something like a tweet, that has no obvious title?

~~~
dang
I'd use the text of the tweet or the most representative substring of it that
will fit the 80 char limit.

------
matchbok
Another Google project that will end up being abandoned. Flutter, Dart,
messaging, etc.

They need to just fix Android.

~~~
plerpin
Ah, the HN hivemind Markov chain is mired in another infinite cycle.

[https://hncynic.leod.org/](https://hncynic.leod.org/)

~~~
mathgladiator
It's a pretty big idea because it's pretty neat, but why not simply run an
algorithm to figure out where the "random" random sequence is?

Then figure out which random sequence is a good fit for what's happening, as
opposed to just looking for it in a random chain.

------
dilandau
Given Google's penchant for abruptly canceling platforms, I hope that
implementors and vendors will be careful with this.

~~~
cobookman
to be fair, there's a large graveyard of OSs which failed to gain traction,
especially on mobile.

I'd be surprised if any vendor adopts Fuchsia thinking it has anything better
than a 10-20% chance of being mainstream.

Today we have Android and iOS as the dominant Mobile phone OSs. Don't forget
about all the attempts to dethrone those two by: Symbian, WebOS, Windows
phone, Blackberry, Tizen, Ubuntu Touch, kaios, firefox os, PureOS,
LiteOS,...etc.

------
tarkin2
I have mixed feelings. This brings invitation to the operating system world.
But it will track user behaviour from its core.

