Playing around with the Fuchsia operating system

If Google or some similar company were to make a desktop OS, it would probably be packed with so many monetization "features" that the free software community wouldn't be very interested and may even see it as a threat. Chrome OS already demonstrated most of this pattern.

The elementary project has done some great work with their UI, but the limitations of a decentralized funding model mean that it just isn't as complete as the major OSes. Meanwhile the jousting between Red Hat and Canonical over control of the GNOME ecosystem alienates a lot of users. Meanwhile corporate control of Qt has limited KDE's popularity. In all three cases the organizational problems associated with developing a truly freedom-preserving OS in a profit-oriented world crop up in different ways. Google taking over doesn't sound like a solution to me.

Some kind of alliance between free software developers and hardware manufacturers has long been dreamt about but hasn't materialized over the last two decades. All too often, Linux OEMs attach a half-baked homegrown distribution and their hardware tries to rely on it. We've also hoped that democratic countries will decide that a free and open-source operating system would be good for national security and fund development. In practice, interest has mostly come from Russia and China, with user freedom off the priority list.

Google isn't a deity. They don't exist to serve humanity but rather their investors. The organization problem continues to be difficult.

Google is a web company; they want people to use the web. They made a laptop/desktop operating system built around their web browser, because they want everything to be on the web. It does most of the things you list, including synchronizing between devices since your data is all "in the Cloud".

As for market share, I'm not sure what power you think Google has, but getting 10% of the desktop OS market has got to be pretty difficult for anyone. I do not know what share of the market Chrome OS has.

Unfortunately, I don't believe that relying on a for-profit third party entity like Google is a good idea due to the conflict of interest, even if their OS is FOSS. Just look at what Google has done throwing its weight around as the big-man in browsers, even though the browser engine is FOSS.

Incidentally, this might be of interest to you:

https://github.com/probonopd/hello

Not much there yet, but I believe Probonopd's intent is to gather a community of people like ourselves.

- It requires a massive centralized investment. Microsoft/Apple/Google can do that. But Linux is run by amateurs (not talking about skills but rather guys who are not on a payroll).

- Linux is for people who have rather weird setups. Apple uses limited hardware (ie: You have few Macbook Pros, etc...). Windows is supported by manufactures because it is the standard of Desktop computing for most of the world (and still can be a mess). Linux, on the other hand, has to do all that work alone.

- Linux professional and profitable market is still in servers/deployment where you don't need a desktop space.

Developers flat out rejected it because of the smartphone-like sandboxing.

Is there any evidence google can pull this off or wants to? I’d think they would want you in a browser.

What would be the financial incentive?

Are iOS/Android SDKs good examples of stable platforms? They are just as much a moving target as anything else and the only thing certain about them is that they _will_ require maintenance.

I've got Plasma setup to take advantage of a decade of Mac muscle memory, and think it does "macOS" better than macOS itself.

> Apps are sandboxed, similarly to Android or iOS

Install firejail, and its wrapper scripts. The wrapper will automatically wrap common commands and apps in a sandbox, and you can use the firejail CLI to launch apps that it doesn't wrap.

I agree with your other points, however I lament that BSD-style licensing will prevent a lot of cool things from having their sources see the light of day or be upstreamed.

Linux really does miss an SDK though. Realistically if you target Ubuntu you'll reach the majority of Linux users but the community of power users (ugh, hate that phrase but can't think of a better one) and developers is scattered any number of desktops and Linux varients.

Sandboxed apps are a no-go on a productive desktop. Have you tried using Snaps? They're sandboxed by default, and it's extremely annoying having barriers in the way sharing data between them. Sandboxing is the sworn enemy of composition. It's like keeping all the interior doors of your house locked.

Clearly defined platform / guaranteed to work: Linux-the-kernel provides a binary-compatible ABI. This is entirely sufficient, if you bundle everything including libc. If you don't want to do that, well glibc is backwards-compatible so you can just build against some reasonably old version of glibc and it'll work on any recent distro. This isn't some obscure method - lots of software is binary-distributed this way (Firefox, Blender).

Easily make a commercial product: well, I'm currently using Pointwise and Mathematica on Linux, so it doesn't appear to be that hard.

Fuchsia appears to be really close to Chrome/Chrome OS - they even share the build system and many components.

IoT devices have a big problem with software updates. The people who make them are primarily interested in selling hardware, not supporting it for the many years it will probably be in your home. (You might replace a smartphone every two years, but how often do you replace a light switch or thermostat?)

Google says Fuchsia is built to be easy to update. Different components are able to be upgraded independently. There is a stable binary API for drivers.

Imagine a world where IoT devices are built to some Fuchsia-based standard which allows them to continue to be updated even when the manufacturer inevitably abandons the devices and their users. You could get more out of the devices, and you could worry less about security.

It wouldn't solve 100% of the problem, though, because there would always be some device-specific code, including device drivers and any software that enables unique capabilities of the device.

> One person who has spoken to Fuchsia staff described the effort simply: "It’s a senior-engineer retention project."

https://www.bloomberg.com/news/articles/2018-07-19/google-te...

Fuchsia’s greatest value is letting senior devs solve fun puzzles without the burden of shipping anything customers want.

Strange argument. Maybe they will move all their devices to their own superior OS Tizen. Or maybe they tried and it did not turn out very well.

So whichever side Samsung is it does not affect Google. There are many phone makers not that many phone OS makes. And with chinese manufacturers already pounding them they have no leverage on Google.

What was the market for php when it came out ? It was just a few helpers to write web pages, simpler to use than perl that already existed at the time

What was the market for go when it came out ? Yes, it did have a few modern things built-in, but there were already tons of widely deployed languages.

And yet here we are. I don't need to tell you how successful each of those is today. I don't mean to say that Fuchsia will definitely be useful or deployed in any large fashion; just that "there is no market" is not a valid counterpoint to the development of a new project.

However, core components such as graphics, file systems, hardware devices, etc. are moved into userland, so in that sense it follows the microkernel idea of putting as little as possible in the kernel itself.

Personally, I love the design, and hope it takes off. We really need to get away from letting kernels and devices have elevated privileges in an OS.

As far as I'm concerned, Tanenbaum won the monolith/microkernel debate — Minix 3 is a true microkernel, and is currently a popular niche OS — and the success of Linux does not diminish the argument. (The infamous failure of GNU Hurd doesn't, either.)

The obvious thing for Google to do is to use this in Android, and this will solve a number of big problems for them (specifically, binary-only drivers and a better security model). They might even have some success in the server or desktop spaces as well.

I worry a bit that Linux will be the next Firefox.

Without a hate figure like Steve Ballmer net relative momentum will decline. It just happens that so many other big players joined the band wagon and contribute, that you don't notice that relative decline.

But in my opinion, the second most important feature of Linux is in fact its ability to change large parts of the kernel when and if needed. And do it very very quickly.

And this something microkernels cannot do. They are just slower when doing major changes that touch many parts of there OS.

Not only that, but other older operating systems are always going to have an advantage here anyway: they'll have support, ecosystems, documentation, and people with years of experience with them.

Google isn't even a monopoly in search for heaven's sake! Only 87% of people use Google Search. If they can't get a monopoly there - and you really can't get a monopoly in almost any industry without government help - what makes you think they can get a near-monopoly in operating systems?

Maybe they're just making use of the existing C++ talent pool at Google.

Or do you mean in terms of not using a "safer" language like Rust? I assume its because its not what the devs working on it know.

I don't think it made sense to use Rust back when they started. It wasn't mature enough for such a big project.

Note that zircon itself is not allowed to contain any Rust [0]. It's not exactly specified what they mean by the kernel, but it seems that this includes not just the microkernel but also everything that lives in the zircon top level directory, which is enough to boot the system. tokei says there is not a single line of Rust in that entire directory (but about 1 million lines of C/C++).

[0]: https://fuchsia.googlesource.com/fuchsia/+/cb20372465f875ff4...

That's a form of public denial on their side. Why would they upstream Chromium, LLVM, Rust and Android ART support then? It has first class support for Flutter as a way of running all Flutter apps from day 0.

Don't be fooled too easily by that statement.

"Midori was a research/incubation project to explore ways of innovating throughout Microsoft’s software stack. This spanned all aspects, including the programming language, compilers, OS, its services, applications, and the overall programming models. We had a heavy bias towards cloud, concurrency, and safety. The project included novel “cultural” approaches too, being 100% developers and very code-focused, looking more like the Microsoft of today and hopefully tomorrow, than it did the Microsoft of 8 years ago when the project began." [1]

Later some of this ideas became core features on Windows.

For a great overview about Mindori project: [1] http://joeduffyblog.com/2015/11/03/blogging-about-midori/

a) sell the product to their superiors and get their buy-in

b) drive their own resume for "being the guy who created X"

rather than any technological reasons or valid business reasons.

What Google says about their plans and what their plans actually are does not necessarily have to converge.

I think they made it pretty clear that Fuchsia is not "an experiment to test new OS ideas".

https://fuchsia.dev/fuchsia-src/concepts

Specifically:

> Fuchsia's goal is to power production devices and products used for business-critical applications. As such, Fuchsia is not a playground for experimental operating system concepts. Instead, the platform roadmap is driven by practical use cases arising from partner and product needs.

The reason we don't see new OSs is pretty simple: there is entirely too much hardware you have to accommodate to be usable. There are klocs of actual kernel code in Linux, and Mlocs of driver code.

Even for the big three I'd like to see some shared container runtime or something.

I actually don't think it's that uncommon to see people who think the NT kernel is a superior implementation than the Linux kernel. There does seem to be a sentiment that the Linux kernel has a history of adopting features later than other OSes, and often using a worse implementation (epoll is one of the more infamous cases).

>I'm a developer in Windows and contribute to the NT kernel. (Proof: the SHA1 hash of revision #102 of [Edit: filename redacted] is [Edit: hash redacted].) I'm posting through Tor for obvious reasons. > >Windows is indeed slower than other operating systems in many scenarios, and the gap is worsening. The cause of the problem is social. There's almost none of the improvement for its own sake, for the sake of glory, that you see in the Linux world. > >Granted, occasionally one sees naive people try to make things better. These people almost always fail. We can and do improve performance for specific scenarios that people with the ability to allocate resources believe impact business goals, but this work is Sisyphean. There's no formal or informal program of systemic performance improvement. We started caring about security because pre-SP3 Windows XP was an existential threat to the business. Our low performance is not an existential threat to the business. > >See, component owners are generally openly hostile to outside patches: if you're a dev, accepting an outside patch makes your lead angry (due to the need to maintain this patch and to justify in in shiproom the unplanned design change), makes test angry (because test is on the hook for making sure the change doesn't break anything, and you just made work for them), and PM is angry (due to the schedule implications of code churn). There's just no incentive to accept changes from outside your own team. You can always find a reason to say "no", and you have very little incentive to say "yes". > >There's also little incentive to create changes in the first place. On linux-kernel, if you improve the performance of directory traversal by a consistent 5%, you're praised and thanked. Here, if you do that and you're not on the object manager team, then even if you do get your code past the Ob owners and into the tree, your own management doesn't care. Yes, making a massive improvement will get you noticed by senior people and could be a boon for your career, but the improvement has to be very large to attract that kind of attention. Incremental improvements just annoy people and are, at best, neutral for your career. If you're unlucky and you tell your lead about how you improved performance of some other component on the system, he'll just ask you whether you can accelerate your bug glide. > >Is it any wonder that people stop trying to do unplanned work after a little while? > >Another reason for the quality gap is that that we've been having trouble keeping talented people. Google and other large Seattle-area companies keep poaching our best, most experienced developers, and we hire youths straight from college to replace them. You find SDEs and SDE IIs maintaining hugely import systems. These developers mean well and are usually adequately intelligent, but they don't understand why certain decisions were made, don't have a thorough understanding of the intricate details of how their systems work, and most importantly, don't want to change anything that already works. > >These junior developers also have a tendency to make improvements to the system by implementing brand-new features instead of improving old ones. Look at recent Microsoft releases: we don't fix old features, but accrete new ones. New features help much more at review time than improvements to old ones. > >(That's literally the explanation for PowerShell. Many of us wanted to improve cmd.exe, but couldn't.) > >More examples: > >* We can't touch named pipes. Let's add %INTERNAL_NOTIFICATION_SYSTEM%! And let's make it inconsistent with virtually every other named NT primitive. >* We can't expose %INTERNAL_NOTIFICATION_SYSTEM% to the rest of the world because we don't want to fill out paperwork and we're not losing sales because we only have 1990s-era Win32 APIs available publicly. >* We can't touch DCOM. So we create another %C#_REMOTING_FLAVOR_OF_THE_WEEK%! >* XNA. Need I say more? >* Why would anyone need an archive format that supports files larger than 2GB? >* Let's support symbolic links, but make sure that nobody can use them so we don't get blamed for security vulnerabilities (Great! Now we get to look sage and responsible!) >* We can't touch Source Depot, so let's hack together SDX! >* We can't touch SDX, so let's pretend for four releases that we're moving to TFS while not actually changing anything! >* Oh god, the NTFS code is a purple opium-fueled Victorian horror novel that uses global recursive locks and SEH for flow control. Let's write ReFs instead. (And hey, let's start by copying and pasting the NTFS source code and removing half the features! Then let's add checksums, because checksums are cool, right, and now with checksums we're just as good as ZFS? Right? And who needs quotas anyway?) >* We just can't be fucked to implement C11 support, and variadic templates were just too hard to implement in a year. (But ohmygosh we turned "^" into a reference-counted pointer operator. Oh, and what's a reference cycle?)