When I was there I was baffled by its sudden rise and the support it seemed to have from senior mgmt.
My impression when it was announced was it started as a really neat personal project by some long-time OS development nerds (I mean that in a good way) that then escaped the gates and then it became a hammer in search of nails.
It ended up eating the project I was on, and was many many years late in the process of doing so, breaking schedule promise after schedule promise. I kept waiting for management to put a lid on it, but they seemed to have infinite headcount and budget, and patience from mgmt to support their mission to rewrite the world while we struggled to get time and resources to maintain the codebase we already had which was shipped as a profitable product and sitting in millions of people's homes with good reviews.
Google has OS politics dysfunction... especially in hardware devices where there are almost a half dozen Linux distributions fighting it out for marketshare. Fuchsia just added to that craziness.
The drivers situation for embedded Linux SoCs is awful. Fuchsia aims to fix that. Security model is better. Licensing I guess is easier to deal with. The OS structure is explicitly modeled for the kind of consumer hardware projects in question instead of, y'know, a PDP-11.
None of this changes that the rollout for these things could be done incrementally in parallel with the existing Linux based platforms, with an eye to produce shared components whenever possible instead of rewriting the world. The Fuchsia folks were notorious for their obsession with purity of essence, and because they had the headcount and $$, they just did what they wanted.
Fuchsia's driver handling is superior to what you get with linux. Because pretty much everything is pushed into userspace it makes it dead simple to keep a driver going forever.
Were I to guess, the prime motivation for Fuchsia would be to have a phone or IoT device which could regularly receive kernel updates without needing hardware vendor interaction. That's the biggest sore spot for linux. (not that I think Fuchsia's kernel would require a bunch of updates due to how simple it is).
This is an outsider's perspective. Definitely a big expensive project that reminds me of other big expensive google projects which seem DoA.
> Fuchsia's driver handling is superior to what you get with linux. Because pretty much everything is pushed into userspace it makes it dead simple to keep a driver going forever.
How does the lack of hardware vendor cooperation get improved by moving the problem into userspace?
You still need/want the hardware vendors to create drivers and update them, which they frequently don't.
I guess it's better because you're just going to be content with binary blobs?
Yes, that's exactly the point: unlike Linux, and like Windows, Fuchsia defines binary interface for drivers. As long as new releases of Fuchsia keep supporting the old interface, old driver blobs will keep working.
It's common to conflate the idea of source availability with problems encountered by lack of binary stable interfaces. One of the problems with the status quo on Linux isn't that drivers aren't released as source, but that they aren't upstreamed. This causes the drivers to no longer be valid very quickly. If you solve the validity problem, folks can continue to release drivers, alongside their source and they will continue to be valid even as the rest of the operating system evolves. Just because Windows drivers tend to not have source available doesn't mean that it's a given the same will be true for fuchsia drivers. It is ultimately product makers who use fuchsia as a platform who drive the incentives for what driver authors do with their drivers.
From the outside looking in I thought the security model could really help Google lower splash radius from zero days? The feature-set certainly sounds appealing just reading the marketing blurb. [1]
With any luck in the next iteration Google will create a Fuschia ISO or VMDK so people who want to give it a spin without building it can quickly get a taste of the environment. The fact you can at least run it in an emulator is definitely a step up from requiring dedicated hardware, which was the previous process. [2]
I believe Google can make a system that is secure from outside adversaries, but I'm less trusting that they would make an OS that isn't riddled with hooks for Google surveillance.
Certainly. Sad thing is how many won't make the switch. I'm not judging, I'd do the same prolly due to pressures(ease of use, bandwagon, specific pain point fixes vs Linux)
> The drivers situation for embedded Linux SoCs is awful. Fuchsia aims to fix that.
How can they solve that with software? It's an incentive/economic problem. Hardware vendors don't want to play nice, there's no incentive for them. It's better if they're jerks and never release their stuff or do it years after their hardware stops being relevant.
Replace and unify android, chromeos, their various iot devices. Eventually it becomes the base image for faas, app engine. Complete domination.
Now if they have Microsoft/apple level os penetration you can be damn sure it's gonna be only serving google search. Just to ensure/build more moat aroing Google search can justify infinite cost
Yea, but I'm excited to see what a modern kernel can do that's master planned with our current knowledge. I don't know too much about the Linux kernel. But I imagine there's alot of cruft and inefficiencies because it grew over a long period of time in an ad hoc manner
Plenty of money, but not enough discipline and focus to make that happen.
After years in this industry and seeing so many things like this just fail, my perspective is that the "right" way to do it (rewrites/replatforms) is build shared components and have teams that deploy to both and so live in both worlds.
This way the old gets the new, and the new has to live and breathe the reasons for the compromises that the old lived through the first time. And you don't end up with a "legacy" team and a "future" team.
Example: I tried (a bit half-heartedly and I was low-status so nobody cared) to pitch that we write a new screenreader for Home Hub rather than brutally kludging in the one from ChromeOS. A new screenreader that could be shared with Fuchsia, as they were writing one from scratch. If building from scratch why not build one as a component that can be shared? That approach was seen as a total non-starter by the people I talked to. Fuchsia got to write their shiny new thing basically in isolation and barely interacted with us poor folk who had to keep maintaining the actual-existing screenreader deployed on several million devices in people's homes. Mainly fell to my friend/coworker who was a hero.
If sharing this won't get you in trouble, I'm curious about why you believed that the ChromeVox screen reader wasn't a good fit for Home Hub. Was the Home Hub UI not HTML-based? Or did you see some design flaw in ChromeVox (which, if I'm not mistaken, is open-source so you should have no problem going into detail on that)? Feel free to email me privately if you prefer. Thanks.
From the user perspective, Chrome Vox on Home Hub feels... bolted on. It uses the assistant TTS, probably over the network, so lag is extreme (a thing you don't want in your primary interface to a device), and random portions of the UI don't reliably read.
As a totally blind Home Hub user who finds Chrome Vox completely unsuitable for the platform, I'm saddened (though not surprised) that a Fuchsia screen reader never could see the light of day.
Well, they say it's not intended to be an Android replacement, but I'm persuaded it's intended to be an Android replacement.
The main advantages over Linux are a clean room design, better security-by-design (having a microkernel means the attack surface is way smaller, capabilities means sandboxing-as-a-security-mechanism becomes possible), and more control over the project.
Honestly, I think the other commenters are being way too cynical about this. If this project gains traction, even if Google goes evil with it, forks and community distributions could still happen like they do for Linux, and be immensely beneficial. The sandboxing alone is a huge benefit.
Android already has a sandboxing-first design. Every app runs in its own sandbox done via different Linux users. It's a bit crude to use a different user per application, but it's effective & robust.
Android is also pretty unapologetically POSIX/Linux and doesn't shy away from exposing that to applications (eg https://developer.android.com/reference/android/system/Os ). So I don't think Fuchsia would replace the Linux kernel in Android. It'd have to be far more rewarding a migration to justify the massive ecosystem breakages that would result (for both apps & OEMS)
Windows XP proved you can do it, but that at least came with a massive (real world) improvement to things like security & stability that were appreciable upgrades to end users.
> So I don't think Fuchsia would replace the Linux kernel in Android.
How hard would it be to add a posix subsystem to Fucshia?
My outsider opinion is that the Oracle lawsuit increased motivation for alternatives to Java (the language), and Google decided to put more wood behind the Dart/Fuchsia arrow.
IMHO Fuchsia will be a massive (real world) improvement over Linux in security.
Also, 5 or 7 years from now, on which OS will Chrome or Chromium run better? Fuchsia or Linux?
For the past 12 months, I've been running Chrome "on Wayland" (without XWayland in between) and although it is definitely usable, there are many small bugs some of which has existed the entire 12 months.
(And will Firefox even be maintained 5 to 7 years from now?)
> Also, 5 or 7 years from now, on which OS will Chrome or Chromium run better? Fuchsia or Linux?
Linux's GUI layer is such a huge weak spot, and it doesn't look like Wayland's gonna fix that (it seems like it's not even set up to address the most serious problems, really).
If they put Fuschia on Android devices & Chromebooks, that'll be about the end of the story for consumer-facing Linux. Then if they can make it work well as a container-hosting server OS and decide to push it for that purpose... well, the year of the Linux anything might be behind us, then.
Neither ChromeOS nor Android use any desktop Linux software such as X, Wayland, Gnome, KDE, or otherwise. As far as I know Chrome still runs fine on Desktop Linux despite this.
> IMHO Fuchsia will be a massive (real world) improvement over Linux in security.
Exploits in the Linux kernel are very few & far between. How would Fuchsia represent a massive (real world) improvement in Linux over something that basically doesn't happen?
By contrast for the Windows 9x -> NT kernel transition, the 9x kernel (in Windows ME at the time) had rampant worm issues and was notoriously unstable in very significant & practical ways, like plugging in USB devices would trigger BSODs with some regularity.
These days the majority of kernels (Windows, Mac, and Linux) have vanishingly few exploits and are for the most part extremely stable. There's not much to improve on at this level.
> For the past 12 months, I've been running Chrome "on Wayland" (without XWayland in between) and although it is definitely usable, there are many small bugs some of which has existed the entire 12 months.
Note that neither ChromeOS nor Android use Wayland or X11. That compositor fight that desktop Linux can't move on from isn't something that plagues anybody else, so there's nothing for Fuchsia to "fix" there.
> Exploits in the Linux kernel are very few & far between.
That's an interesting take on multiple code execution bugs per year. And not via drivers, but userland-exploitable code in general subsystems.
Unless you're referring to remote code execution, which in the era of ubiquitous web applications (often running involuntarily through advertisements, etc) seems like a distinction without a difference.
Drivers are the commercial case for Fuschia. But in general, microkernels make it much easier to 1) implement privilege isolation for subsystems and 2) implement subsystems in a more secure manner, both of which absolutely improve security posture. A subsystem is just another type of driver. Though, it depends on how well Zircon makes use of this--i.e. avoids implementing all the most critical subsystems in the same process, or otherwise abuses too much unprotected memory sharing among them.
> 1) implement privilege isolation for subsystems and 2) implement subsystems in a more secure manner, both of which absolutely improve security posture.
Sure, but Android already has that via a user per application for app sandboxing & a very extensive selinux policy set[1]. Which makes the real-world benefit of that seemingly very negligible. There's a huge gap between desktop Linux & Fuschia/Zircon here, but there doesn't seem to be a particularly big gap between Fuschia/Zircon & Android Linux.
Sure but even still exploits in kernel modules are also extremely rare. The vast majority of exploits are in getting userspace to do something it has permission to do but in a way that it didn't want to do it. Sandboxing & permission systems help here tremendously, which Android already has a pretty robust & extensive system (not just the normal app permissions, but also a massive set of selinux policies controlling what a given system service can do).
Desktop Linux is pretty far behind the curve at this point, but Android/iOS aren't (and increasingly MacOS/Windows are fixing things up)
Fuchsia seems like it'd be an incremental improvement here at best, and "real world" improvements even less clear than that.
Firefox stems from mozilla back in 1998 only 5 years after Mosiac and 3 years after the original IE. It seems exceptionally likely that Firefox will continue in some form for the foreseeable future.
> And will Firefox even be maintained 5 to 7 years from now?
Hopefully! It would be a bummer to have to switch to some hipster browser like Suckless Surf (assuming browsers made by advertising companies are not candidates for obvious reasons).
What google is trying to do here is equivalent to getting everyone to switch from IPv4 to IPv6. Yes, it's superior. Yes, there'd be massive benefits. Yes, it isn't likely that google will go super evil.
However, google isn't the only player in this. They need to get all their vendors to rewrite drivers for their new kernels. They'd also need everyone using android, for example, to get on board writing drivers.
Meanwhile, one of the largest players, samsung, is looking at making their own OS.
For an already fractured ecosystem, it just doesn't seem like it's something that can be successfully pulled off. Maybe if google/android was more like apple it'd be doable. But not where there are so many players that need to be brought in the mix.
I agree - I think only a company with pockets as deep as Google could pull off creating a brand new operating system in today's world. I'm curious to see what comes of it.
I agree with the premise, although I disagree that only Google could do this. Honestly there are a low number, but greater than one, entities that could do this. Microsoft is an obvious one, for instance.
That said, to your bigger point -- I think the way to pull off a brand new OS in today's world is to write something that scratches an itch that a small-ish group of people have. Do it well enough, and it will grow into something bigger. In fact this is exactly how Linux got going. It will work again, guaranteed.
I would actually love to see a full, from-scratch rewrite of Windows. I'm not sure if it's ever been done before, but it definitely feels like it hasn't.
It was even on the verge of being a microkernel and it could run a super light weight virtualization (for the lack of a better word) system: OS personas.
It would be interesting to get Windows NT NextGen, true.
I believe the long-term goal is for it to replace Linux as the kernel in Android.
The technical reason, I'd say is that the access control model in Android is a kludge on top of the Linux kernel, and it is more difficult to sandbox apps. Fuchsia was made to support Android's model, and in a capability-oriented OS you get sandboxing by default.
A political reason is to not be dependent on Linux, but I'm sure that other people have opinions about there being more.
My first theory is they started it back when the Oracle lawsuit was happening over API copyrightability. They were probably worried that some Unix copyright troll would try to sue them, so having a backup OS was a good research project. Now it's just a make-work project to keep smart engineers from going to the competition.
My second theory is that it exists as leverage, to scare the Linux kernel maintainers into thinking that they could lose their biggest userbase (Android) and make them more compliant.
It's my belief that open-source maintainers usually become attached to the fame and importance they get, and they prefer to see the number of people using their project go up not down.
I agree with the sentiments expressed by various others. 1) They can get rid of needing to use Linux, whenever convenient. 2) Possibly even replace Android too, if feasible or eventually. 3) Way more control, to make sure open-source "politics" doesn't interfere with their money, business goals, and exploitation of users info.
One of the primary goals is to have a non-copyleft license so they can do more proprietary aspects without being forced to give back to the OS and community that made their company.
At least it wouldn't hurt to always have some flowers around for the next Google project entering the Google Graveyard ;-) (I don't expect that Fuchsia would end there any time soon.)
In theory if Fuschia fulfills it's purpose, google could have Android sit on top of Fuschia as opposed to a Linux Kernel.
This would give them far more control over the direction of the OS, far more control over millions of users, and allow far less tinkering by android users.
While Android users still tinker within their steadily shrinking degrees of freedom, their desire for software freedom has an escape route within the Android world. But what if Google succeeds in using Fuschia to lock down the consumer mobile ecosystem ? With nowhere left to go, won't users focus on some new space entirely outside of Google's reach instead of just fleeing Google around Android ?
My shot in the dark: try to keep up with Apple. They are never going to get Apple-levels of performance per watt from their current hardware and software choices.
Linux it's great, but it's far from perfect for all scenarios where could be bloated (think IoT, like Google home assistant). In those cases micro kernels like fushia, or GNU Mach make sense.
While QNX is mentioned, does anyone know of any materials detailing the implementation of MX tables in QNX? I've stumbled upon a brief synopsis[1] of what they do, but it lacked implementation details (such as: do the entries need to be aligned on page boundaries? how many copies are made at the end? etc. etc.).
You mean the binary footprint of a type 1 hypervisor that Linux requires when deployed in the same high integrity computing scenarios that QNX is usually used for?
I guess a mix of industry not wanting it until security is a legal liability, type 1 hypervisors, microservices and containers being used to tame monolithic kernels into pseudo-microkernels, hiring practices,....
They want an OS with a stable kernel ABI so they don't have to bug device manufacturers (non-FOSS friendly ones like Broadcom and Qualcomm) for source code, or updated binary-only Linux drivers every time there is an update to Linux.
Assuming there's a grand strategy behind this at all, it feels like more of a "steer the industry" play than a "spy even more" play.
If I'm right, the ones who should be worried are Red Hat(/IBM) and Ubuntu. Maybe Amazon, depending on what exactly Google's thinking and how much they weaponize the ability to refrain from open sourcing some of the code.
