
Fuchsia OS Introduction - Symmetry
https://bzdww.com/article/163937/
======
Svoka
My impression as game developer:

\- Vulkan first graphics interfaces. I mean, OK. Not that I'm in love with
this overly complex API, but fine.

\- No OpenGL support. I guess this is where world is moving

\- No POSIX support. Quite a bit of game engines rely on it, oh well, when
google cared about developers

\- Nothing about sound (my personal thing)

As game developer working with Android was unpleasant to say the least. For
example sound - android has like 4 sound systems, all of them (except simplest
one available from Java side) are not fully implemented, and swarming with
compatibility bugs across manufacturers and android versions. Oh, not to say
that they introduce new one once in a while, with new version adoption slower
than a sloth.

I get that Google engineers enjoy rewriting things they don't like, but, come
on. Fix existing first. Don't change APIs on us - not everyone has extra
million of $$$ to throw on a project to refactor it every time Google decided
that they want shiny new thing, which as result is broken too but in different
ways. OK. I admit, I exaggerate, but it seems like tough times for game
engines (besides super hyped ones like Unity or Unreal, which also has no
problem throwing tens of millions).

Note about OpenGL support: I'm pretty sure they'll drag it in by porting ANGLE
library which is currently actively worked on. Compatibility layers for Vulkan
are getting momentum, but I hope they'll join forces with MoltenGL/VK instead
of making their own worse analog.

~~~
klodolph
You may want to take a second impression.

\- OpenGL should be a library. This is just going to make OpenGL development
easier in the long run. Right now there are too many OpenGL implementations
and the differences matter. Running one OpenGL library on top of N different
Vulkan implementations is miles better than running on top of N different
OpenGL implementations.

\- POSIX can be a library too. It doesn’t have to be provided by the kernel.
People have been strapping POSIX layers on top of things for ages. This was
originally how Mach worked. You can still do weird things on iOS and macOS
“below” the POSIX layer (although most POSIX syscalls are just provided by the
kernel).

You talk about how hard it is to change APIs… and how much you hate to
refactor things every time Google decides they want the shiny new thing. But
POSIX is rooted in the 1970s. It sucks. It’s about time to try something new.
The entire POSIX model is based around the idea that you have different people
using the same computer and you don’t want them to accidentally delete each
others’ files. There are a ton of APIs in POSIX which are straight-up shit,
like wait(). Sandboxes are unportable and strapped-on, using arcane
combinations of things like chroot and cgroups.

Let’s give people a chance to try out something new. Unix is somewhere around
50 years old now. OS research is dying out. Make it easier to run untrusted
programs.

~~~
Svoka
I agree with you, but I do not believe in Google. Google provided worst
commercial platform I ever had experience developing for. I had a lot of
different platforms in my past - pretty much all consoles, desktop and fringe,
like smart TVs or various smartphones released since 99'.

Only Google changes rules of the game on developer. They do not realize that
they are make •a platform•, not a product. Stable, comfortable platform that
software runs on. I honestly don't give two cents about all their struggles to
make "a better OS". OS is to launch apps, and making those apps is a miserable
experience, where I have full time people just to keep up with Google
'improvements'. Somehow every other platform is fine. I hardly had to change
code written 10 years ago for iOS, for consoles or Windows - not at all! But
Google keeps making their own special PhD driven darlings.

~~~
xiphias2
> But Google keeps making their own special PhD driven darlings.

I'm really sorry that you have this feeling, but this has nothing to do with
PhDs. It's impossible to get promoted by bug fixes inside Google, and people
are promotion driven.

There were many people who tried hard to fix a lot of bugs, but they usually
burn out due to lack of recognition inside Google.

~~~
asark
It really, really shows. That and documentation. And some periphery work
related to larger efforts, especially on any platform that's not the Web. It's
the only explanation for how an organization like that can produce so much
broken and half-assed software—bad incentives, and probably a serious middle
management problem, in that they don't have leverage or motivation to make ICs
do "boring" and follow-through work.

Maybe it's working for them from a bottom-line perspective, but it's made
their brand as an engineering company _clownish_.

~~~
xiphias2
The key question is the bottom-line, as you wrote. Management is really hard
to scale, but right now innovation is a better prediction of growth than bug
fixes, so I think it's not even clear how to improve the promotion process
without hurting growth of the company.

I think Google is too big at this point already, but that's an orthogonal
question.

~~~
asark
A non-"rockstar" hiring process and parallel job track (with potential for
cross-over) so they can get in people who are happy to do "boring" work on an
interesting product might do it. Probably can't be in the Valley or anywhere
else ultra-high COL. I think part of the problem is they (seem to?) only staff
folks who both _can_ and _are inclined to_ leave quickly if they don't get to
do the fun stuff.

Again, though, may not make sense for them from a $$$ perspective. Jank and
rough edges galore may be something they're willing to live with.

[EDIT]

How this works in my head:

Manager: Could you take a look at the Android developer documentation? Some of
it's badly outdated and have you actually tried using it? A lot of the advice
is... kinda bad. Also maybe look at a few of these UI components we had the
Summer interns make, they've got bizarre implementations and are difficult and
inconsistent to customize. Oh and god have you looked at our issue tracker?
Has anyone, actually? Like, ever?

Developer: Hey so have you heard of this place called Amazon?

Manager: Uh I mean how about we start a fourth greenfield instant messaging
product instead?

Developer: That's better. Amazon? Who's Amazon?

~~~
Joky
Actually there is little thinking about "Amazon" or other competitor: internal
mobility is easy. So replace "Amazon" by "this other team is doing a cool new
project", and you can get transferred in a matter of weeks, most of the time
without going through a heavy interview process.

And all of this isn't only motivated by "not doing boring tasks", but also
because this is what drives promotions / career advancement. So "launch a
feature/project, get rewarded, and switch team" seems like a trend, and it
does not encourage to think about long term maintenance / etc. (It isn't a
generality either, but it is a bit of a trend)

------
bayindirh
It's strange how my perception of Google and its software has changed over the
years.

When Android was first released I've put it to the same category with Open
Firmware & Debian. Now when I see Fuchsia, I reflexively categorize as a
pseudo-open source software, where you can see the code but cannot do anything
useful on the long run, because it's designed to be downloadable but unusable
for casual/research purposes.

Maybe "we put out the source for you to see and start to limit its free use
when it matures enough" model gets tiring for me.

~~~
eloisant
It's interesting to see that when Android was released, it was fully Open
Source.

But over the years they moved all the apps to closed-source, one after the
other, even some core elements (play services).

Pretty soon it will be no more open source than iOS (the kernel is open
source, yay!)

~~~
mav3rick
All of the framework is still open source.

------
zamalek
I really wonder about this kernel IPC hype. I watched a video on React+Redux
by Facebook engineers about a week ago, and the reasoning behind creating the
things in the first place. Feelings about React+Redux and how they are
overused aside:

Redux came first and it happened because the "interaction graph" between
various components on the website became virtually impossible to resolve
cognitively. The engineers (especially on-boarding engineers) faced troubles
understanding how everything worked in concert and, especially, the side-
effects of a single change. The nail in the coffin for the engineer was
Facebook chat and she was forced to use numbers, instead of lines, to depict
interactions because the graph was too dense. Redux forced interaction in one
direction, with "back interaction" happening one frame/tick later. Web
developers have praised and embraced this architecture.

If you look at the very first image in the article, it moves from a very
straightforward application -> VFS -> ext2 -> driver -> disk graph to a
[potential] rats nest. It runs counter to the hard lessons that Facebook have
learned with complex distributed systems.

Is this why nothing has really come from Mach/Hurd? Up until putting 1 and 1
together a few minutes ago, micro-kernels sounded so clean and elegant. They
now seem unwieldy. Perhaps there is exists another layer of architecture that
can tame the dependency/interaction graph; isolation really does sound like a
good idea, but we need a better way of doing it.

~~~
bluejekyll
> Is this why nothing has really come from Mach/Hurd?

Mach 3.0 was the kernel used in NeXT and the original Mac OS X release. It was
quite a bit later replaced with a rewritten kernel XNU, that’s basically a
hybrid. The reason as I understand it, message passing in the kernel is
expensive when crossing user space so often.

I wouldn’t call that nothing coming of Mach, it did really well!

Also, I’d say that micro-kernels are closer to the paradigm of react/redux
(redux the message bus, react the user space servers) than to a monolith
design like Linux.

~~~
zamalek
You're completely right, I shouldn't have mentioned Mach.

------
altmind
I've heard the following opinion on the internet: "The sole reason Fucsia OS
exist is so google can release GPL-free android sometime in the future"

How do you feel, is there anything behind this claim?

~~~
ocdtrekkie
Regardless of what you think of Google, the reality is Fuchsia and Android
have little to nothing in common. While they would certainly rather have a
permissive language from the bottom up, they certainly wouldn't have written a
whole new OS with that as the primary goal.

Android's platform design would arguably have been considered modern in 2007
or 2008, but it is 2019, and the cracks in Android's capabilities have been
widening for a while. Sometimes people still think of Android as "newer" in
the operating system space, but it's a decade old!

~~~
kkarakk
If you're an android dev, you know google basically rewrite the whole SDK for
every major OS release. Android 1.0 is unrecognizable compared to Android 28.0
to the point where supporting devices running 1.0 from a 28.0 is a tedious and
time-expensive operation.

~~~
distances
There aren't any API level 1 devices out there though. Supporting, say,
Android 4 (level 14, from 2011 so almost eight years ago!) is very
straightforward. The fragmentation argument doesn't hold water for most apps.

~~~
kkarakk
maybe if you have a simple text app, try implementing background sync, modern
UIs even db stuff gets really convoluted really quickly. forget about
camera/audio support

my current company supports down to only api level 19 and even then it's like
having to maintain multiple apps to support apis <23

------
jillesvangurp
I would not be surprised if Google decides to never launch this. They
currently have two consumer facing operating systems and linux (presumably) on
their servers. On the server side they use containerized services, are
involved with Kubernetes, etc. None of that stuff probably is even close to
working on Fuchsia and I don't think server side is a priority with that.

On chrome os, the most significant feature is the newly added ability to run
linux applications via crostini. Containerization is of apps is a big topic in
general in the linux world with e.g. things like snap.

On Android, they have an extremely large installed base, enormously slow
upgrade cycles, and a huge legacy development ecosystem. This ecosystem
overlaps with ChromeOS as well since it can run Android apps. And Android can
do linux apps as well (though that mostly makes less sense).

Fuchsia would need to play nice in that ecosystem or it will face an empty
room problem where all of the key apps have not been ported yet, they have a
tiny marketshare initially (thus removing the incentives for fixing that), and
OEMs will likely vote with their feet by sticking to the old platforms. Part
of that is supporting linux based stuff; which especially on Chrome seems
increasingly important.

So, kind of pessimistic that Google has a strategy for making this work. This
makes sense as a research project but not as a product strategy currently. Yes
Android has issues. Maybe fixing those might be easier than replacing it
entirely?

~~~
stdcli
"are involved with Kubernetes, etc. None of that stuff probably is even close
to working on Fuchsia and I don't think server side is a priority with that."

actually the networking stack in Fuschia, or more particularly zircon the
kernel it is optimized around, is written in Go.

Kubernetes is written in go, which is essentially a system for implicitly
defining scaled linux boxes on a giant network, and now in the most recent
release is allowing for declarative architectures as well, much like how user
space services for graphics drivers in Zircon will enable more declarative and
optimized use of expensive resources as well (in this case, modular hardware
architecture for mobile operating systems, which is what Fuschia was
originally envisioned for.)

I'm also pretty sure Google also has experience with mobile operating systems
(android), and Fuschia is literally a response of now over a decade of trying
to interface android on POSIX in conjunction with multiple chains of
monopolized and closed source hardware architectures, being intimately
familiar with the evolution of trends in the mobile hardware architectural
space, and trying to rewrite a kernel to optimize for that.

"Fuschia will need to play nice...Part of that is supporting linux based
stuff; which especially on Chrome..." Chrome had to have an entire team
dedicated to resandboxing their tabs to mitigate for spectre and meltdown,
which are both results from the unquestioned but growing obscurity due to
unquestioned implementations between hardware and Linux integration, which is
something that Fuschia attempts to take a step back from, and by doing so
simultaneously make it easier for open source development on hardware
architectures while optimizing for them.

Still, total site isolation is still an advanced option in chrome that results
in a 10% degradation in memory performance so people don't turn it on, if they
even know to check for it/what that means (most people don't).

~~~
jillesvangurp
Crucially kubernetes uses docker, which uses a lot of low level linux and
posix stuff. Kind of an issue if that stuff isn't there. Kernel virtualization
on fuchsia could of course become a thing (like it is on Windows and OSX) but
so far I've not seen much on that topic. WASM on chromium might become a way
out as well of course.

But the bottom line is: Empty room. beautiful OS with an empty app store is
kind of a non starter in the current market. Windows Phone found that out the
hard way. Also, several other mobile operating systems that did not quite make
it or continue to struggle. Sailfish, WebOS, Firefox Mobile, Ubuntu Mobile,
etc. Even ChromeOS struggled until they added android support and Crostini.

~~~
pjmlp
ART will run on top of Fuchsia, it is already being ported, you can check the
merge commits.

As we always need to remember Linux fans, the fact that Android uses a Linux
kernel is irrelevant to userspace.

~~~
jillesvangurp
I have no idea what ART is but I doubt it addresses all concerns I listed
above. On Android, there are plenty of native libraries and apps these days as
well. I'm pretty sure these don't work as is without a compatibility layer
that essentially replicates a lot of linux/posix stuff, which Fuchsia does not
implement.

In any case, it wouldn't be the first time that Google walks away after
putting lots of development in something. In general, I think they are closer
to merging Android and Chrome OS than they are to replacing either with
Fuchsia (not to mention convincing OEMs like Samsung to actually use it).

~~~
pjmlp
ART is the Android RunTime, basically the large majority of Android's
userspace.

Those native libraries are forbidden to use Linux specific features, only
these APIs are sancioned.

[https://developer.android.com/ndk/guides/stable_apis](https://developer.android.com/ndk/guides/stable_apis)

Since Android 7, Google has been claping down NDK users that try to used
anything that isn't part of that list.

Since Android 8, APKs are only allowed to reach for their own internal
filesystem and use SAF for anything else. Something that will be further
enforced on Android Q, so no luck trying to peek into /dev, /share and
similar.

------
gvand
I don't know if it's just me, but lately the amount of interesting stuff
(articles, software) i come across that sadly is only available in chinese
keeps increasing.

If it wasn't for these groups of volunteers that translate them to english
(and the other way around, also useful) these projects would be completely
unaccessible.

~~~
ManuelKiessling
Guess we the westerners now experience what other parts of the world
experienced for decades.

~~~
gdy
English is much simpler than Chinese.

~~~
cromwellian
Reading and writing the alphabet, yes. The grammar and pronunciation rules for
speakers (not the pronunciation itself)? English is quite a bit more difficult
than most people realize.

You can learn Pinyin in a few days, which is sufficient for you to pronounce
any Mandarin Chinese romanized into Pinyin. Chinese grammar is fairly simple
compared to Latin languages. Whereas English is a rats nest of special-need-
to-memorize pronunciation rules.

Most of the real difficulty people experience with Chinese comes from the
shock of learning the characters.

~~~
lucb1e
Coming from Dutch, I found English easier than German. Some people say German
is so close, it's mutually intelligible with Dutch: not only is it not, I even
find it much harder than English.

At least from my perspective, someone who knows a language very close to
another and still found English easier than this other language, English is
easy.

Pronunciation is indeed quite a lot of learning by heart, but it's not hard to
get used to if you got the rest down. Of course, this might be much harder for
Chinese, I wouldn't know.

~~~
larkost
Two things: 1\. As an English-native-speaker who also learned German I find
that I can mostly understand spoken and written Dutch through my German. I
think part of your difficulty there is that it is closer to your native
language where you have very tight internal rules about how the language
should be, so get caught up in those differences. On my side my internal rules
on German are relatively loose, so Dutch mostly fits in there.

2\. One good-sized chunk of the messiness of English pronunciation (vs.
written words) is actually the fault of the Dutch. Prior to the printing press
spelling was more an art than a science, and the same transcribed book could
be found with different spellings (especially true in different regions).
Since the Dutch were the first ones with the printing press, many English
books of the time were printed there, and the Dutch printers made some pretty
arbitrary decisions on how they thought English should be spelled (e.g. the
'h' in 'ghost'). There was a similar effect from French scribes when they
invaded England.

Now my no means were they they only ones to mess up English (read up on "The
Great Vowel Shift" if you want a headache), but they did their part.

------
marssaxman
Oh, yes, this is a very carefully thought out project and I love it. I have a
hard time trusting Google, but this is clearly the result of some very
straightforward, competent, well-directed thinking, and I hope it succeeds.

~~~
roymurdock
What type of device would you use this in?

~~~
marssaxman
This architecture sounds like one I would want to use for all of my personal
computing devices. I believe this because I did a bunch of experimental
hacking three years ago with the objective of designing an operating system
with usability and security characteristics that would suit me better than
Linux or Android currently do. I didn't make a huge amount of progress toward
a working system (you can see what I did here:
[https://github.com/marssaxman/fleet](https://github.com/marssaxman/fleet)),
but I spent a lot of time reading and thinking as I tinkered. The people
working on Fuchsia have clearly thought deeply in similar directions, gone a
lot further in the work, and resolved a lot of the uncertainties I
encountered.

I won't let Google manage my data for me, but if they can keep their fingers
out of the pie I would gladly use a Fuchsia-based system as described here for
my laptop, phone, and home desktop.

------
kevin_thibedeau
Wonder if the permissions model will make it harder to circumvent DRM that
takes away functionality like screenshots. If a super user can't imbue child
processes with their capabilities then control won't ever be fully in the
owner's hands.

~~~
Andrex
Would the sole "solution" to that be recompiling the kernel yourself with that
functionality enabled/coded in?

~~~
kevin_thibedeau
We have Android devices that can't be unlocked today. They can carry over the
same mechanisms.

~~~
bubblethink
That is a different beast that even the linux kernel doesn't touch since the
kernel is GPL v2. So even the exact same license as the kernel would not have
changed the status quo; only something like GPL v3 would have, which obviously
a company like google would not touch with a 10 foot pole.

------
analognoise
"The Unix successor, Plan 9, released the last version in 2002, and its waste
heat has been integrated with Go."

I'm not sure if this is a translation gaffe or not, but I'm using it as a new
sick burn for sputtering projects.

~~~
hrdwdmrbl
I'm not familiar with Go or Plan 9 to know if there is any connection or not
but I am curious.

~~~
stonogo
It's my understanding that the Plan 9 compilers were ported to linux and used
to compile early versions of Go. Past that, the only connection is that one of
the Go project leads used to work for Bell Labs.

~~~
slackenerny
Plan9 was a network operating system, and with a focus on concurrency a new
language Alef was designed with coroutines based on CSP formalism (Hoare's
communicating sequential processes). That was redesigned in Limbo language on
Dis garbage collected virtual machine in plan9's replacement Inferno OS. Go's
goroutines and other choices are next incarnation of these ideas designed by
many the same Bell Labs people, not just one incidental lead. Shopping for a
light compiler to bootstrap from is peripheral to the design story here.

Fuchsia doesn't share as much of the story but does pick up where in Dante's
Inferno the original Unix people tried to abandon the root user to redeem
themselves almost 30 years ago. Combined with capability based model last seen
deployed in the wild with OS/400 and Burroughs machines before that, it would
be the first truly new OS in decades.

------
dralley
Can someone with knowledge on the matter explain how Fuschia compares against
other microkernels such as RedoxOS and QNX?

~~~
sansnomme
A lot of performance problems will magically go away with enough money backing
it. A comparison with NT (hybrid but shares a lot of similarities) is more
apt.

~~~
dralley
I meant structurally, not in terms of performance

~~~
sansnomme
NT is pretty similar to Fuchsia in a lot ways

------
mapcars
>File and file system becomes a partial concept (limited to each file system
process), so there is no file in the process kernel data structure

>"/" -> root vfs service handle, "/dev" -> dev fs service handle, "/net/dns"
-> DNS service handle

Just resurrect Plan 9 already?

~~~
DC-3
This strikes me as an approach quite similar to that of Redox:

> "Everything is a URL" is a generalization of "Everything is a file",
> allowing broader use of this unified interface for schemes.

It makes sense to me - not every resource can reasonably be shoehorned into
the file-folder abstraction.

[1] [https://doc.redox-
os.org/book/design/urls_schemes_resources....](https://doc.redox-
os.org/book/design/urls_schemes_resources.html#what-does-everything-is-a-url-
mean)

~~~
mapcars
When you have everything as a file - to add URL just to point to that file is
a simple feature.

------
lostgame
I'm not sure of this need to remove, or not support, OpenGL these days.

It's not like OpenGL is the greatest graphics API, it's just that it's been
used for decades - I personally learned 3D graphics rendering in GL and I
still think in GL when I'm compositing a scene in my head.

If I'm going to prototype something, I have historically loved that no matter
what platform I'm on, I can pretty much just hit 'compile' and I'll have the
same result.

Which leads me to my second complaint - Metal. When Vulkan has come out as the
clear choice for next-gen multi-platform graphics technology, Apple, once
again, decided to completely invent a proprietary system instead of using the
low-hanging fruit that was already there.

~~~
monocasa
With Android Q, they updated ANGLE to run on top of Vulkan. OpenGL's rapidly
becoming a library, and that's a good thing.

------
rixrax
VirtualBox bootable .iso would be nice.

Especially since I thought of trying it out and followed Fuchsia
instructions[0] only to run into exactly same problem building it that others
have reported >3 months back[1].

Also, instructions to download and install jiri with curl under Fuchsia docs
don't work either[2] and curl returns '404 not found' instead. Got around this
using instructions here [3] only to fail soon after as per above.

[0]
[https://fuchsia.googlesource.com/docs/+/a40928d45b43dbf72d5e...](https://fuchsia.googlesource.com/docs/+/a40928d45b43dbf72d5e67244308fd552597849c/getting_started.md)
[1]
[https://www.reddit.com/r/Fuchsia/comments/a56rg7/issues_when...](https://www.reddit.com/r/Fuchsia/comments/a56rg7/issues_when_update_the_fuchsia_code/)
[2]
[https://fuchsia.googlesource.com/docs/+/a40928d45b43dbf72d5e...](https://fuchsia.googlesource.com/docs/+/a40928d45b43dbf72d5e67244308fd552597849c/getting_source.md)
[3]
[https://fuchsia.googlesource.com/jiri/#Bootstrapping](https://fuchsia.googlesource.com/jiri/#Bootstrapping)

------
calvinmorrison
> The Unix successor, Plan 9, released the last version in 2002, and its waste
> heat has been integrated with Go.

I feel attacked. Glad they're picking up seriously on the idea of namespaces.

------
wyldfire
This is some great detail, thanks for sharing.

> A channel has 2 handles, h1, h2, write messages from one end, and read
> messages from the other.

This seems like it's bound to be a critical section for many operations. So
for one/some of the supported target architectures, what's an example of how
channel write/reads look in detail? Do I need to trap or can I write
"directly" into pages that the recipient can read? Can messages span cache
lines?

I believe that Fuchsia sounds ambitious and it's only through the dedication
of mega-tech corps like Google/etc that ambitious efforts like this can
succeed. But the world in general, even the tech world, is loathe to accept
change. Backwards-compatible layers to emulate the linux syscall layer would
probably be a critical transition feature. This allows consumers to phase in
the work required as they can stomach it, rather than suffer it all-at-once-
or-nothing.

How hard is it to port Fuchsia to a new target? Can anyone point me to a
series of commits for a target that does this?

~~~
irq-1
The kernel switch for channel communication seems like a big performance hit
just to stop "sharing memory". Why not allow shared memory with negotiation on
the communication protocol? The OS software could share memory, but only use
protocols that are strict, simple, secure, etc...

------
MayeulC
I really like fuschia, Redox and the other microkernels. However, I am highly
concerned about the license change.

About the only upside of the Android ecosystem was the kernel's license,
forcing kernel drivers to be open-sourced. This allows mainlining back devices
into the Linux tree, which enables a variety of user projects, such as
postmarketos.

On the other hand, some of these drivers already acted as a shim to a
userspace blob, and having an IPC would at least provide isolation from the
blobs themselves, and allow tapping a clear IPC interface for reverse-
engineering those. So all might not be lost.

On the sustainability of open source, since this seems to be debated much in
this thread, I personally think (and it is a debatable viewpoint) that this
ought to be incentivized at a government level (by taxing software/technology
sales, and sponsoring open source projects with the proceeds). This would
provide a much more robust base on which to provide (proprietary if you want)
services upon.

------
rob74
Ah, ok, "introduction" as in "Introduction to Fuchsia OS". Which is
interesting too, but I initially thought that Google is actually introducing
Fuchsia OS now, i.e. presenting plans to replace Android with it. Wishful
thinking ;)

------
Solar19
Any ideas on why they use:

1\. MessagePack (instead of, say, FlatBuffers – am I wrong to think that
FlatBuffers are more efficient? (and the format was created by Google))

2\. ELF binaries (instead of, say, taking a clean-sheet approach to executable
formats)

Also, on ELF they say: "The loading position of the ELF is random and does not
follow the v_addr specified in the ELF program header."

(They're talking about ASLR.) This just highlights for me that a more
efficient format is possible, one that doesn't have a virtual address in its
headers. Perhaps there are even bigger wins possible with a clean-sheet
format.

~~~
oscargrouch
For ELF i would say because its easear to reuse a lot of tools that already
deal with the format. Debuggers, linkers, compilers, etc..

My guess is also because its easear to have a bridge with Linux executables,
so you can run the same ELF and emulate the linux syscalls somewhere like
FreeBSD and now Windows .

I bet they were thinking about running Android stuff more easily, and i dont
think there will be much more to gain in designing a whole new executable
format, when you compare how much of free tools, code and compatibility with
Linux you will have in the end.

------
bogomipz
I had a question about:

"Global file system

In Unix, there is a global root file system"

Why night this be seen as a shortcoming, especially with mount namespaces now?
Can anyone say?

~~~
kbd
See the top couple comments on this thread (from within the past month) by
q3k:

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

That should be impossible in Fuchsia.

~~~
jhasse
Also with mount namespaces ;)

------
dmitrygr
This power management code could use some work:
[https://fuchsia.googlesource.com/zircon/+/refs/heads/master/...](https://fuchsia.googlesource.com/zircon/+/refs/heads/master/kernel/syscalls/system_arm64.cpp)

------
roymurdock
It seems like the main point of this redesign is modularity for security's
sake. Curious to hear who is asking for this OS, where Google will use it, and
what type of system any of the HN crowd would consider putting Fuchsia OS
into. Can't shake the feeling that it's somewhat...uncalled for by the market?

------
siffland
On the server platform..... On the desktop platform.... On the mobile
platform.....

Pick one. Have we not learned from the past that there really is not a one
size fits all operating system for all use cases. I am probably alone in
thinking this, but bad decisions can be made when trying to get a server OS to
run on a phone.

~~~
jzoch
Hence the microkernel with pluggable modules. That's the whole point

------
cannonedhamster
This basically just came across as a GNU/linux hit piece. In my admittedly
really limited knowledge wouldn't multiple vectors into the kernel introduce
more surface area for attackers? The other problem with this is when is Google
going to get bored with it and move on to something else? If they are willing
to jettison Android they are willing to jettison anything. Also the line about
GNU/linux only caring about servers seems to ignore the amazing amount of work
that's gone into KDE, Gnome, Ubuntu, Kali Linux, Mint, etc. all of which are
desktop focused and in the past few years have really started to catch up
feature wise. Yes obviously there are still issues, and realistically there
always will be issues. Windows and MacOS/iOS have issues with thousands of
paid programmers why wouldn't a distro built by hundred of part time workers
with only a portion of them paid to work just on the OS?

~~~
im_down_w_otp
Microkernels are often used in high-security/high-criticality use cases
because the kernel's facilities are very limited and the surface area is very
small (thus easier to reason about and assure). Most complex functionality is
performed in isolated processes/tasks with known IPC boundaries (i.e. a random
thing can't clobber or inspect the memory of everything else).

We build on top of seL4 for these reasons (among others).

~~~
microcolonel
> _We build on top of seL4 for these reasons (among others)._

Who's we? I too am down with OTP, especially OTP on seL4. ;- )

~~~
shakna
I believe they're PolySync [0], and I believe they might be referencing "fel4"
a Rust-atop seL4 [1] that they've developed which is very cool stuff.

[0] [https://polysync.io/](https://polysync.io/)

[1]
[https://github.com/PolySync/libsel4-sys](https://github.com/PolySync/libsel4-sys)

~~~
im_down_w_otp
Formally of, yes. Now some folks are doing all new things.

~~~
sansnomme
Can you elaborate?

------
hrdwdmrbl
Countdown until someone adds JavaScript support (~ Atwood's law)

~~~
kkarakk
it already has dart support so it does have js support in a round about way

~~~
hrdwdmrbl
Good to know. I had actually forgotten about Dart. Feels like Google should
probably throw in the towel on it, but I haven't been following it.

~~~
skavi
Dart is the basis of the primary UI framework, Flutter. Flutter is also cross
platform, and can be compiled for Android and iOS.

[https://flutter.dev](https://flutter.dev)

~~~
pjmlp
Flutter is being downgraded to an UI Framework among many, after Scenic's
instroduction.

------
pknopf
I wonder how Fuchsia will manage in the regulated world's (medical, aviation).

A micro kernel is a big sell for regulators/QA. Also, being a RTOS.

This would disrupt many big players in the field, such us QNX.

------
bfrog
I wonder if a big part of Linux success story comes from it's relatively
simple to hack on code.

------
wiremine
Does anyone have any good links to comparisons between Fuchsia and Linux (or
other OSs?)

------
Solar19
Anyone know what programming language the kernel is written in?

~~~
skavi
C++. If you want to read through a huge argument on HN regarding the merits of
that decision, check out this thread:
[https://news.ycombinator.com/item?id=16813796](https://news.ycombinator.com/item?id=16813796)

------
waspoza
How do you guys feel about kernel written in C++? Seems strange to me.

~~~
mtgx
Seems like a wasted opportunity to write a new kernel and OS that might last
another 30+ years in the mainstream in C++. Who knows how many million-man
hours will be spent fixing memory bugs in this new OS because of this
decision.

------
cat199
all part of the master plan to destroy unix and therefore steal control of
computing from the people

------
gcb0
Speaking English as second language, which was a requirement to be a software
engineer, i assumed i had some other 5years to learn Chinese before being left
behind. Guess I am late already.

~~~
pova
It's becoming more and more important, especially in the embedded world,
because a lot of hardware vendors are based in China.

------
mtgx
I'm confused, is this an OS for China? That alone doesn't inspire too much
confidence, if it was "designed for China", because we all know what that
could mean, especially with Google being so eager to please dictator Xi lately
for a chance of a few search engine market points in China.

~~~
ssnistfajen
You couldn't have searched Fuchsia OS using a search engine before writing a
comment shoehorning completely irrelevant polics?

------
Zardoz84
> Zircon: microkernel, underlying service process (device manager, core device
> driver, libc, interprocess communication interface library fidl) Garnet:
> System-level system services: software installation, communication, media,
> graphics, package management, update systems, etc. Peridot: The
> infrastructure layer of the user experience: modules, users, storage
> services, etc. Topaz: The basic application of the system, Web, Dart,
> Flutter These names are from Steven Universe.

Nice!

