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.
There's no point to these early Fuschia review attempts. I don't see how it demonstrates anything. It's like looking at the famous first email from Linus Torvald and figuring out what the os would be in the end. So it boots, it has windows, but not apps, and prints some things to the screen. It tells us nothing about real intentions, future capabilities, etc.
As somebody who read that famous first email and shared it around her lab: We were all tremendously excited, and spent days discussing it.
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 do share the excitement, but that's exactly why I found this video rather uninspiring. It doesn't say a thing about how Fuchsia is new or interesting. It just goes through a bunch of extremely unfinished screens in consumer product review style. Nothing much to see really.
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.
It's all written in C++, so from a security and reliability perspective, I'm sketical it's going to offer much improvement over Linux. I don't see any evidence yet of "new technology". I'm happy to be proven wrong.
Assuming your analogy has merit, I doubt very much this is true. Computer modelling, for example, has improved significantly over the years.
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.
In line with your reasoning, software development methodology has significantly improved over the years. One does not write C++ in 2018 as they would have written C in 1980.
>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.
If you state your criteria for 'safe' and 'secure', I can point you towards library implementations for each of your points.
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.
> You can not stop the users from shooting themselves in the foot, but that is not the goal here.
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.
Programming languages do influence how a problem is solved and this often affects architecture. This is especially true with respect to concurrency. However my main problem with C++ is security, not want architectures it inspires.
It's not news to anyone that C/C++ puts the burden of security and safety onto the programmer. And it's getting harder all the time, see for example Spectre mitigation. C was designed alongside Unix in the 70's, a very different era. It is time for a next generation OS, but it needs to be built using next generation tooling.
I have programmed C and C++ professionally on and off for over two decades, but I don't think that is relevant here. C++ shares many of the same security and safety problems as C, that is why they are often lumped together.
On the one hand I'm excited, but I ultimately hope this fails (commercially, anyways) because I don't think the world needs more devices loaded up with Google's spyware.
That seems rather pedantic. At this point I'm curious enough to watch these "reviews", but I don't care enough to try it myself. I happy reviewers are showing off the work, whatever they call it, review, sneak peak, preview.
Yeah, you can't "review" something that isn't even close to finished.
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 7 Series had the concept of hubs (e.g. People Hub). It was an innovative model, and having so much functionality built in eased the pain of missing or poor quality native apps for things like facebook/Twitter. It was helpful in an “information at your fingertips” sort of way, where everything was organized without solos between apps/platforms.
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.
It seems that the most useful OS/programming concepts have already been thought of, but all implementations are lacking in some ways, so I tend to agree.
I'm hoping it will be noticed by Linus and other Linux developers and help them address some of the shortcomings that Fuchsia aims to fix. It seems like this is how Google is exerting pressure on Linux to get what it wants...
Maybe - but it doesn't seem to me like the Linux community as a whole cares much about what Google wants.
And they don't have to: Google has their own capabilities to edit the kernel the way they want (they have done it before) or make their whole own kernel.
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.
Its sort of a "review" of an early preview. I think it demonstrates a lot especially what Fuchsia is and what it is capable of. The other point would be that Google gets free advertisements of their new OS.
I disagree. It allows people that are interested in Fuchsia, but don't have the skills, time or hardware to build it, an opportunity to visually follow its progression.
What is this supposed to become, exactly? Google hasn't said much about it and speculators are making big claims like how this will replace ChromeOS and Android. I don't see that happening any time soon considering how deeply entrenched both OSes are, but Google's dedication mixed with the lack of comments makes me think again.
Depending on the future direction they take this, it might end up replacing OpenBSD for me.
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.
Don’t hold your breath. The zircon API isn’t innovative in any modern sense. Additionally it’s bloated and not clean like L4. It’s just in house IP for Google.
(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.)
Fuchsia docs says POSIX lite and Web runtime, under Backwards compatibility.
More info at https://fuchsia.googlesource.com/docs/+/HEAD/book.md#zircon-...
You can fire up the fuchsia in qemu, as it requires hardware graphics, you can't run the desktop, but you can have multiple shell open. I've had a play and it has vim and sql_shell and a bare bones top.
Probably something more architecturally sound for future platforms in augmented and virtual reality among other things. One of the biggest issues with Android is managing permissions for apps to system resources. Proper sandboxing of 3rd party code is a big deal, especially if the next generation experiences are so much more immersive.
Given the amount of activity in porting Chromium to Fuchsia [x], my bet is on Fuchsia eclipsing Chromeos. A possible reason for this would be to get out from under the linux kernel; Fuchsia/Zircon enables google to make changes quickly.
well, based on the demo there, I'd almost only want it is a Google Assistant version of Amazon's Show where it could be an assistant for various users (and guests). Outside of that, I'm not sure.
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.
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.
How exactly is Google getting power here? The code is totally open. They just seem to be giving themselves more flexibility and potential to build better products.
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.)
Fuschia uses a BSD style license whereas the Linux kernel is GPL. Google or hardware vendors can modify the Fuschia code without sharing the changes with the public, for better or worse.
...and Amazon went ahead and forked it, in addition to CyanogenMod, Paranoid, Copperhead, "HALFB4kedMod 0.9Beta2(No camera)"[1] and so on. Android's openness is not just empty words.
1. Until the developer changes phones and loses interest. Nevertheless, thank goodness for XDA.
And by now not even the caller app, or the phonebook app, or the calendar, or Homescreen, or settings, or search are open anymore.[1]
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"?
________________________
[1] To disprove this, please find me the full current source code of the Google Dialer, Google Contacts, Android Nessages, Google Calendar, Pixel Launcher, and Google Search apps — all these used to be open source in Android 2.3.7, if you find me the full source code of their current versions, I'll take this point back.
[2] See the ongoing Antitrust case in the EU against Google
You can still go fully open; https://microg.org/ and https://f-droid.org/en/ I don't have Pay, and no cloud push notifications, and the GPS assist isn't quite as perfect, but the only real bugbare is no swyping keyboard.
Sure, but that's not the same. By that argument — the core of the OS is open, just everything on top isn't — you might as well call macOS open because Darwin is open.
Android was always "completely controlled by Google". It wasn't developed in the open - they would throw the code over the wall when it was ready. Does software have to be developed in the open for the result to be open? Answers to this vary depending on your perspective.
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...
> How many of the core devs don't work for Google? How much of the overall project direction is decided by people who have nothing to do with Google?
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.
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..
Can someone summarize the technical tradeoffs they made in developing this OS vs. say Windows and Linux for example? Also, anything that is just plain better and represents recent innovations in OS design?
Redox is not "Mozilla's operating system" in any way or form. It is an immature OS whose primary contributor works at System 76. The only thing Mozilla-related about it is that it's written in Rust.
Just want to point out that not that long ago redox-os (the microkernel OS in Rust) asked people to test it.
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 aftercompilation, so they check for undefined language constructs.))
Well, I mean, one of the issues listed is "getting a lockup with ls * on the default directory". Sure, Rust (or any other language, even something like Idris) is not a magic pill, but at that stage of development, you can't expect much. I would still say that it is, on average, a lot easier to shoot yourself in the foot in C than in Rust.
Because it's an easy indicator of someone who has no idea what they're doing in OS development. Choosing the wrong tool for the job is meaningful. Have you ever looked through Chromium's C++ codebase? The same people are working on this and it tells us that they haven't learned their lesson (or they want to tightly integrate Chrome with Fuschia, which is also a foreboding sign).
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.
> Because it's an easy indicator of someone who has no idea what they're doing in OS development.
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.
>Because it's an easy indicator of someone who has no idea what they're doing in OS development.
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.
>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.
That's an interesting kind of first year students... The kind I know flee before anything lower than C++.
Nah, writing a kernel in modern C++ or Rust is pretty rad. Higher level abstractions can be designed to avoid bugs (As evidenced by the explosion of macros in the Linux code base). Check out L4Ka::Pistachio https://github.com/l4ka/pistachio
>Because it's an easy indicator of someone who has no idea what they're doing in OS development. Choosing the wrong tool for the job is meaningful. Have you ever looked through Chromium's C++ codebase? The same people are working on this and it tells us that they haven't learned their lesson.
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
Someone said something similar earlier, but I chose not to respond to avoid getting deeper into an unrelated argument. The short of it is that I don't find BeOS (and Haiku) particularly impressive. WebOS is all userspace and I don't really care how Fuschia's userspace looks, and I have to admit I don't know much about QNX or Hiptop.
I know you're a prolific commentator here, so if you don't mind me asking ... Which operating systems have you designed (or worked on) to say that writing a microkernel in C is a symptom that they don't know anything about OS development?
You're probably missing their tradeoffs. Google has deep expertise in C++ within the company and integration with existing libraries / tools is a huge bonus. So if the goal is a market-ready product and velocity matters, then it makes sense not to adopt a new language that is still changing a lot. It's only your opinion that they've chosen the wrong tool. There isn't one right answer to nuanced product decisions.
As someone who has dabbled in OS development over the years, you'd be a fool to use anything other than C (I suppose you could use a restricted subset of C++ if you really don't want to write anything but a toy OS) or assembly if you have something to prove.
One drawback about Rust OSes right now is that they must use nightly Rust, and therefore, don't gain our stability guarantees. This is another form of immaturity.
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.
They do have some rust showing up in their repos. It looks like its mostly bindings needed to run rust on the OS. I don't know what their long term goals with it are. I'm guessing they want it for writing high performance user space daemons or whatever the fuchsia equivalent is.
Not OP but the reason I dislike Rust for OS/kernel development is that it's just too damn complicated. Kernels should be written in more conservative languages.
because
> Not OP but the reason I dislike Rust for OS/kernel development is that it's just too damn complicated
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 haven't personally looked into the Rust based OS (I know it exists), but I can guarantee that they're using inline assembly, fighting with language features, working around limitations, and forgoing safety.
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.
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.