Google’s Fuchsia OS on the Pixelbook
arstechnica.com
arstechnica.com
https://fuchsia.googlesource.com/
Key components:
## Zircon
Zircon is the operating system's foundation: it mediates hardware access, implements essential software abstractions over shared resources, and provides a platform for low-level software development.
For example, Zircon contains the kernel, device manager, most core and first-party device drivers, and low-level system libraries, such as libc and launchpad. Zircon also defines the Fuchsia IDL (FIDL), which is the protocol spoken between processes in the system, as well as backends for C and C++. The backends for other languages will be added by other layers.
## Garnet
Garnet provides device-level system services for software installation, administration, communication with remote systems, and product deployment.
For example, Garnet contains the network, media, and graphics services. Garnet also contains the package management and update system.
## Peridot
Peridot presents a cohesive, customizable, multi-device user experience assembled from modules, stories, agents, entities, and other components.
For example, Peridot contains the device, user, and story runners. Peridot also contains the ledger and resolver, as well as the context and suggestion engines.
## Topaz
Topaz augments system functionality by implementing interfaces defined by underlying layers. Topaz contains four major categories of software: modules, agents, shells, and runtimes.
For example, modules include the calendar, email, and terminal modules, shells include the base shell and the user shell, agents include the email and chat content providers, and runtimes include the Dart andFlutter runtimes.
Windows Phone was originally supposed to eschew apps for some sort of focus on views, I forget what they called it. Now Windows 10 Mobile is more or less just Windows 10, with apps. I won't mind if someone finally finds a new model and makes it not suck, but when you're early in the product design phase is when you try crazy ideas to see if they pan out, the final product ends up looking more normal.
Windows Phone 8.1 was the beginning of the end for hubs, with the OS feeling much more like iOS/Android, with winmo 10 basically killing it altogether.
Curiously much of the hub functionality seems to be coming back to Windows proper. For example, see ‘People’ integration in the taskbar that shipped with Windows 10.
Maybe it's a subtle signal of their plans/capabilities towards competitors/dart devs?
I don't think they're trying to push Linux anywhere.
Maybe they're trying to win over users from Linux, giving them some power in the software market & free contributions.
This is the same thing - it's exciting. It's trying to do things many of us have thought of, but never worked on. It's new technology. It's something that, in our hearts, we want to succeed just because the alternatives are all grungy and dusty and carry the compatibility fixes of generations.
Of course, if you don't really care about OS technology, or look at it from a consumer perspective, yeah, it's not giving you anything.
But for engineers who care about OSs? This is amazing and invigorating.
I found it interesting to browse some of the source code to get an idea of the roles that different language runtimes seem to play. But much more than that I would be interested in the driver model, the graphics stack, the IPC facilities and how it all differs from Linux/Android.
Are you an expert in C? or in C++?
Okay, so neither.
Please consider reading these links. [1] [2]
After all, it is developed with very similar tools compared to every other rocket in existence.
However, it is true that many high profile failures in aerospace have been due to software errors, so I would say that software tooling is certainly one area that they could also benefit from.
Languages like Rust and Haskell are an attempt to put such best practice into the language tooling.
Best practice often varies between projects and changes rather often, ..say.. in a matter of a few years. Most of what Haskell and Rust offer are a library away (yes, even compile time checks) for C++, but not vice versa. There is a reason new languages with baked in 'opinion' come and go.
You can not stop the users from shooting themselves in the foot, but that is not the goal here. We want to enable 'safe and secure' programming, not develop toy idiot-proof write-only languages that are useless for large projects.
It should be the goal. Even experts make mistakes. This is why static type systems exist. The logical thing to do is to strengthen the type system to prevent more classes of errors.
If the user avoids the analogous features in C++ and stick to modern conventions, it is not less safe/secure.
1. Your login is tied to your google account. Want to use the computer in any real capacity? Google account.
2. They think bringing back multi tasking from the 90s is important.
3. People will want to control their computer views.
4. They are making a new kernel.
5. They believe in the capabilities based security model.
6. They believe in micro kernels.
7. They don't have any NEW ideas yet (otherwise we would see them in early stages). Maybe they will come up with something, it's research right?
1. This is an open development effort, that's interesting.
2. It's moving very quick.
3. the code is really interesting.
How is the code interesting?
What features of this OS differentiate it from others?
Obviously, it has to be more with all of the aspects of it, but in its current state, that's the only thing I can envision.
Mac OS X and OpenBSD are my daily drivers, but at their core, they are BSDs, and less and less I find myself using the NeXTSTEP portion of Mac OS X and more and more time in BSD-land, which is leading me to move more and more of my overall computer time to OpenBSD which is a great operating system but is still largely a continuation of the UNIX/POSIX/BSD model which I appreciate like fine wine but do not love.
If Fuschia ends up being the answer to the question of what would happen if we built a new operating system from scratch today, taking the best lessons we were able to learn in the past 50 years, then I might be using it as my daily driver in 10 years.
Or maybe not. Nobody can really say what it will be right now.
(HN won’t let me directly reply to the comment below so here it is:
Nothing in zircon doesn’t already exist on Linux or any other modern kernel. Additionally it has bloat, like 3 distinct IPC mechanisms.
Even further, if it ends up being any technical person’s main driving OS it will surely sport a POSIX API and at that point it’s just another implementation of POSIX with similar a security model.)
I really do like the idea of a challenger to the linux monoculture (among devs)/the windows monoculture (among consumers), but I really hate the idea of google getting yet more power.
If it was pretty much anyone else doing this.
Sure, Google runs the core development, but everyone will benefit from this eventually.
Control the platform, control the market around the platform.
Sure it's 'open', but at the same time, heavily subject to the authority of the owners.
See also the systemd/gnome impact to linux ecosystem..
posix in general keeps unices and unix likes (including linux here) more open than other systems since the API is less fluid / under the influence of a single group..
this phenomenon won't occur here.
If anything, this will result in less power over the Linux kernel for Google. It seems like that’s something you’d appreciate.
(My response to s2g’s reply below because HN is terrible for commenting:
I see your point that they now unilaterally control how the kernel is engineered, but my counter argument is that I don’t think this meaningfully changes their control over the platform. They were already free to modify the Linux kernel at their whim. Having upstream control doesn’t make you emperor of derived applications.
As a separate point, don’t you think it just results in less efficiency and worst products if google isn’t free to steer the project in the direction that makes the most sense for the application? It seems they can more easily make zircon for their use case, and I think that will result in cheaper and better phones.)
Saying "it's open, so they don't really control it" is like saying Linus doesn't have control of the Linux kernel.
Maybe google will figure out how to make an Android style play and hold this OS hostage by withholding their services.
> If anything, this will result in less power over the Linux kernel for Google. It seems like that’s something you’d appreciate.
Yes.
This is why some developers are starting to hate open source. There's no technical excitement, it's all about community and governance and who has power and corporations and codes of conduct, etc... If not, you're going to fail. You get an army of experts scrutinizing your project and it's unexciting.
BSD-style means that anyone can do that, even Google's competitors, without any additional permission from Google.
1. Until the developer changes phones and loses interest. Nevertheless, thank goodness for XDA.
Everything now requires Google's proprietary services
Oh, and Google prevents OEMs from cooperating with Amazon.[2]
As result, Android is almost completely controlled by Google.
And you call that "open"?
________________________
[2] See the ongoing Antitrust case in the EU against Google
Android is nowadays proprietary, sadly.
If you're going to dismiss "open-core" and corporate-controlled open projects out of hand, I have bad news to tell you Gitlab, Red Hat, VS Code and hundreds of other projects the rest of us non-purists are grateful for providing their source under licenses that allow for modifications or forking...
They stopped updating most system apps code, and never continued even providing the code.
Originally, everything was open source at least.
Click on the comment’s link (the “x hours ago”) to reply.
Look at seL4, minix3, genode, helenos.
Edit: I should clarify that I think C is the only rational choice and that Rust is ill suited to osdev as well. I'm only talking about C++ here.
https://github.com/KnightOS/kernel
And I've worked on toy kernels here and there and studied more serious kernels in depth.
I should clarify that I agree with eddieh and think C is the only rational choice.
Actually suggesting Rust as some kind of magic bullet over C/C++ is a huge indicator "of someone who has no idea what they're doing in OS development".
It's similar to when first year CS students learn that assembly is "faster" (a hazy notion itself), and then want everything to be written in assembly.
>Edit: I should clarify that I think C is the only rational choice and that Rust is ill suited to osdev as well. I'm only talking about C++ here.
That's an interesting kind of first year students... The kind I know flee before anything lower than C++.
From appearances, the lead "someone" on at least the kernel appears to be Travis Geiselbrecht, who worked at the OS and/or kernel level on BeOS, the Danger Hiptop (Sidekick) OS, his own NewOS (now the basis for HaikuOS), and an embedded OS at Jawbone before joining Google and starting work on LK, which is being used as the basis for Zircon and the Android bootloader.
So I think maybe you mean
> Because it's an easy indicator of someone who does not have the same opinions about OS development than I do.
...because, y'know, that's fine! But "this guy obviously has no idea what he's doing?" Gonna agree to disagree there.
Have you looked into the backgrounds of the main developers working on Fuchsia OS? Because if you had you would have discovered that that they have a rather impressive resume who actually know what they're doing.
Travis Geiselbrecht - BeOS, iOS, Hiptop OS, Little Kernel
Brian Swetland - BeOS, Hiptop OS
Chris McKillop - a member of the original iPhone team, WebOS, QNX OS, Hiptop OS
Edit:
>eXperience the future.
I don't know what gets me more, the idea of a js os, the bad capitalization, the period at the end of a non sentence, the cliché expression...
I still wish they would have done it anyway, but oh well :)
On a technical level, there's nothing stopping you: we already have one serious project (Redox) and many, many hobby projects that exist.
https://github.com/fuchsia-mirror?utf8=%E2%9C%93&q=&type=&la...
isn't?
I'm also not sure why stating my opinion is a problem. If you can't handle someone not bother to pussyfoot around and preface any statement with an "IMO" disclaimer, that seems like your problem.
I'd be shocked if that isn't the case. I'm not saying that you can't build an OS in Rust or other languages, just that OS development is complicated enough without having to fight your language.
People were able to kernel panic it, get privilege escalations, and DDoS it. In short, it had the same same issues a C based kernel would get.
It's true that it's still heavily in development and doesn't offer any guarantees whatsoever, but I think that it should be pointed out that just because your language is good, doesn't mean that your end result will be good (and vice-versa, C based kernels like l4 and C based projects like SQLite have been formally verified (at least SQLite was verified after compilation, so they check for undefined language constructs.))
https://github.com/redox-os/redox/issues/1136
According to the Redox book, at last count they had 70 cases of unsafe across 4500 total lines of kernel code.