> The architectures were all different, which meant that outside developers couldn’t actually do work and attack all the platforms Google was offering. You had to do bespoke work.
https://9to5google.com/2022/08/30/fuchsia-director-interview...
From an organizational-design perspective: That's the whole point.
Decentralization means they can all move more quickly — each team can cater to the needs of its local customers. In moving quickly and solving local problems, they end up repeating some work. That's the price of velocity. Good local leaders should counter-balance this by creating informal forums for idea exchange and cross-pollination.
Sadly, overly-ambitious office-politicians see this happening, flag it as "inefficient," and roll the headcount up into a centralized team. Centralization puts an end to all the local ideas and excitement, instead routing it through a centralized committee that "plans" and "decides" which customers are worthy of how much innovation.
In a way, this is the pendulum of life at a big company. But in another way... this pursuit of "efficiency" sure seems like it explains a lot of why Google moves so slowly.
There's more to it than that. Unlike most other projects, these kernel teams were working on the Linux kernel, which is an open-source project not under the control of any one corporation. These teams were simply maintaining their own kernel forks (which are undoubtedly optimized for their use-cases) and developing features/patches which they might try to submit upstream. And a lot of the work was undoubtedly device drivers for the particular hardware they used. Since they were working on very different projects (datacenters, Android, ChromeOS), with very different hardware, there was probably almost no overlap going on here.
Apple is legendary for not being first to adopt or invent technologies (outside some exceptions).
So they decided to build a bespoke OS that would take a decade to build and would require bespoke work from those devs anyway?
Yes it is. Not directly, of course, nobody cares about the OS. But in case of Android distributions, if they could exchange the Linux layer to Fuchsia, while keeping most of the Android userland in terms of UX, and deliver gains such as increased battery life, then suddenly people would be interested. It would be similar to Apple's development and adoption of ARM architecture.
Fuchsia and Dart are still big technologies though touching many other projects, so back-tracking on speakers doesn't quite mean fuchsia is a failure/not necessary.
See https://nypost.com/2023/07/21/leaked-google-pay-data-reveals...
L8+ would be more obviously.
Look at the TC numbers on levels: https://www.levels.fyi/companies/google/salaries/software-en...
The total is actually somewhat comparable to what's reported, but the breakdown from the article seems completely wrong.
I'm a user (and in particular a Linux user) and a new OS which has Chromium ported to it is compelling to me because I expect that Linux will never evolve to be secure enough.
And none of these things require Linux (the kernel) to change all that much. Hell, Android has decent security by running all apps with different user IDs and restricting the parts of the filesystem it can access.
Obviously your default Linux desktop install doesn't work like this, but some motivated individuals could do it, if they wanted. Writing an entire new OS is hardly necessary. Google just wanted something it could control, when it comes to Fuchsia. And they're the last company that I would trust to build an OS that doesn't end up being user-hostile.
(Qubes, OTOH, is interesting; I see it as one possible path to the future)
Would you? Linux is, in fact, quite modular, and perfectly happy to not load things until asked to (often as a result of hardware being discovered or plugged in).
Sandboxing is a much better approach to security than the Unix permissions model, which is nearly obsolete.
That's an incredibly low bar. They're a bad model because the Unix API surface is huge and underspecified; there are a zillion different ways apps could potentially interact with each other. Some of them are giant security holes. Some of them are vital to some obscure corner of app functionality. Most of them are both.
So when you download a game your threat model isn't that it might want to mess with the kernel, but that it's going to steal all your data from your browser cache. Dealing with that requires some sort of sandboxing.
Huh? No-one is advocating using user accounts for security.
> So when you download a game your threat model isn't that it might want to mess with the kernel, but that it's going to steal all your data from your browser cache.
Why do you think this contradicts anything I said? And what mechanism do you think it's going to use to do that? Maybe not syscalls in the narrow sense, but certainly via one of the "zillion different ways apps could potentially interact with each other".
> Dealing with that requires some sort of sandboxing.
Is this the "something must be done" fallacy? "We need some kind of sandbox, snap/flatpak are some kind of sandbox, therefore we need snap/flatpak".
Sure the problem cannot escape the sandbox, but in the end i'm more concerned with my data in the sandbox.
Both Mac and Windows just dump a whole bunch of libraries into the install directory.
I think on Flatpak you can update the base platform package and have the applications use that automatically, so there's that.
So it's either AppImage/Flatpak/etc or it's building a package per distro.
Superficially, that claim sounds reasonable, but I'd have a hard time substantiating it. There is exactly one secure microkernel ready for production use today, and zero secure monolithic kernels. There's not even a "here's how one could secure a monolithic kernel in principle" whitepaper.
I'd be interested to hear your definition of "secure", and why OpenBSD doesn't qualify.
Although professional security people are also rather bad at this and like to eg stack multiple cool-looking mitigations even if they break each other. (https://siguza.github.io/PAN/)
Functional programming, micro kernels, RISC (or, depending on the decade, CISC), cryptocurrency, etc.