It will be very interesting to watch how Fuchsia evolves over the next couple of years. Especially what Google has planned for it.
It might be a small moonshot experiment to see if they can come with a sensible, modern OS.
It might also be the designated successor for Android/Chrome OS, and the future of the Google ecosystem.
Conceptually, Fuchsia is interesting. It's built on a microkernel (Zirkon) and a capabilities based system. Drivers are isolated elf binaries with a stable ABI, other normally privileged things like file systems are also isolated services.
On one hand, I find it promising as a application platform, both for mobile devices and desktops: while Linux sandboxing capabilities are evolving (cgroups , namespaces, ...) , very little of the ecosystem is built around isolation as a primary concept, leading to all kinds of half-baked sandboxing and permission solutions: chroot, Flatpack, firejail, SELinux, (Docker, mentioned hesitantly since it's mainly for server environments)...
All of which are somewhat tacked on an hard to use properly.
So a clean sheet design might be the best viable (practical) path.
On the other hand:
* this throws away decades of work on Linux
* many drivers will be closed source; open drivers are a major achievement of Linux
* Linux is a very collaborative effort with many stakeholders, while Google is known for keeping a very firm grip on their projects
No, Android (or rather, AOSP), is fully open source.
Most device makers fork AOSP and distribute binaries containing their modifications. These always come with source code for the GPL portions, and occasionally also the portions licensed under permissive licenses such as Apache and BSD.
The bad thing about fuchsia is how closed the development process is. There is no community around it, they don't advertise it, don't encourage broader use and adoption. The contribution process is quite centralized to.
It feels like it's google project and they and only they would decide its direction. So no spontaneous order, it's their way or no way.
Which is expected for their own funded project that's still under active development which they've explicitly decided against publicizing what its strategic purpose or intentions are for it.
> It feels like it's google project and they and only they would decide its direction. So no spontaneous order, it's their way or no way.
Of course they're going to have full discretion of this multi-year heavily resourced investment for which they've spent years developing and haven't officially released yet.
You can re-asses the merits of the project after they've released it, as to whether it's something you want to use or contribute to or not. It's clear at this stage they're not developing Fuchsia with reliance on external OSS contributions.
nah, it's MIT licenced. they're rebuilding, while redesigning, linux - without GPL. i think it's in a way that makes driver development less expensive for hardware manufactuters. stable driver apis mean a hardware manufacturers can care less about maintaining them while the kernel can still update without worrying as much about breaking drivers.
it doesn't really matter if it's currently in secretive development, or not - the result will be that fewer people have access to the code their phone/other device is actually running.
>Which is expected for their own funded project that's still under active development which they've explicitly decided against publicizing what its strategic purpose or intentions are for it.
Sure, the OP's question was what's bad about it. That's bad.
>You can re-asses the merits of the project after they've released it
There would be no merits. It's an OS. Who would write the thousands of drivers and layers for various purposes. If there will be no community, there would be no decent OS.
And no, google doesn't invest enough in it. It's either you hire a dev team of thousands people, as Microsoft does, or draw the community. Google did neither so far, and so Fuchsia has fewer drivers than Haiku. Most they want it to be a system working on a few selected phones, or maybe google doesn't even consider it seriously, and it's an initiative of a small group of enthusiasts within google.
> Sure, the OP's question was what's bad about it. That's bad.
Why exactly is it bad, bad for who? It's likely driven by a highly talented focused team, there are numerous high quality OSS projects that are commercially backed and developed internally - not relying on external OSS contributors is not an indicator of software quality. Apple/Microsoft/Google have already done quite well developing their own successful OS without relying on external OSS contributors.
> There would be no merits. It's an OS.
I don't understand what you're trying to say, that OS's don't have value?
> Who would write the thousands of drivers and layers for various purposes.
It doesn't need to support thousands of drivers, Apple has no problems getting drivers developed for their own hardware. It's not even clear it's going to be a general purpose OS, it could be for embedded / or a close knit of selected approved devices. Regardless it's not even released yet so any conclusions to this point is moot, after they're happy for it to have wider adoption they'll open their invitations to participate and add support for it then.
> And no, google doesn't invest enough in it.
How do you know how much Google has invested in it? You don't even know the purpose of it, how could you possibly know how much resources they need to accomplish what they want to achieve?
> Google did neither so far, and so Fuchsia has fewer drivers than Haiku.
So? It's still in active development, maybe they want it stable and battle tested before freezing public APIs and inviting others to build on it, maybe they only want to support selected devices/hardware. No one will know their intentions until after its released or what their plan for adoption will be. Given they already have experience developing and distributing the worlds most popular OS I'm sure they have a good chance at making a Fuchsia a success for their goals.
* many drivers will be closed source; open drivers are a major achievement of Linux
This is only partially true, simply having the source code for a driver doesn't mean you can fix anything given that overwhelmingly the hardware documentation isn't open or the drivers are talking to closed source firmware/binary blobs running on the hardware itself. It makes it easier to fix trivial problems caused by the OS changing, but it doesn't help when a problem is discovered in the underlying hardware/firmware/etc.
So, the open source doesn't help as much as you would like, given the original drivers are frequently written by the hardware provider itself, or some privileged contractor given the documentation under NDA. This has been a huge problem with the ARM soc's that are "supported" in the linux kernel. Frequently they don't actually work following any given update, and no one can fix them because if they have open documentation it frequently is missing large swaths of the actual registers and device theory of operation parts necessary to assure that any given peripheral works.
The source code of the Linux kernel portions is still a huge step in the right direction, even if it comes without detailed datasheets and and talks to proprietary firmware.
It still lets you continue to evolve the internal kernel interfaces without having to worry about the driver's existing ABI.
It still lets you fix most security holes, or remove anti-features that rely on interaction between the firmware and userspace.
Fuchsia, by means of facilitating real proprietary drivers, will take us back to the Windows era, where the OS must support 2 or 3 different driver models in parallel just to continue supporting existing hardware after it has been abandoned by the vendor (which typically means 1 or 2 years after its launch).
Yeah, my 10 year old laptop, bought with Windows 7, is now running Windows 10 latest, without any driver issues.
While my Asus netbook, bought with Linux on it, has lost the DX 11 GPU capabilities and video hardware acceleration thanks to AMD open source driver reboot.
Ah, Asus still pushes updates to Windows drivers on that specific model.
There is no rule that supercomputers cannot run on Android.
Let's just hope a new digital consciousness will be able to first observe something other than the Play Store or it's going have a very dim view of us.
Android's Application Sandboxing primarily relies on Linux's user security model. Each app is assigned a UID and run in that "user's" context. To quote the official docs:
> The sandbox is simple, auditable, and based on decades-old UNIX-style user separation of processes and file permissions.
SELinux is an extra layer of security that really benefited system services, drivers, and other exploit vectors. All apps remain sandboxed via normal user security on Linux, and then SELinux sprinkled on top for further hardening:
> Prior to Android 4.3, these sandboxes were defined by the creation of a unique Linux UID for each application at time of installation. Android 4.3 and later uses SELinux to further define the boundaries of the Android application sandbox.
Well, Android 4.3 is very old OS. Sandboxing is one thing, permissions are another. You can't deny Internet usage for application with unix permissions, for example.
Fuchsia has no real game changing new technology to offer. To me it looks just like a safety backup plan for the case that the Linux kernel can not be used anymore. For a similar reason Valve is pushing for Linux support in Games just in case Microsoft pulls them out of their Business by only allowing their own Appstore.
Google should have forked Inferno OS. The DIS VM looks a lot like Android/Dalvik VM, Limbo looks a lot like an early version of Go and per App namespaces would be a much better alternative to the current way Android sandboxes its Apps.
Imagine a scenario where Microsoft's moves into open source aren't genuine. They spend a decade or two working their way into the ecosystem using their ownership of GitHub to encourage Microsoft solutions. One day Google wakes up to find some key component has been replaced with something Microsoft controls, or at least primarily develops. No biggie. They'll just make their own. Until the next one.
I'm hopeful EEE[1] is a thing of the past, but I can see why Google would hedge for the possibility of Linux and open source in general being pod peopled into an ecosystem it can't keep using. They're worried Microsoft will do to Linux what Google did to AOSP. Golang's dependence on importing stuff from GitHub is already a threat.
As someone that follows Android development since version 2.1, when NDK became a thing, Google has been removing GPL component one after the other with each Android release.
With Q, the Linux kernel is the only GPL thing still standing.
No. Google has let AOSP die in the vine. It's nearly impossible to properly run Android without the play store. Most OEMs develop a lot in house to combat the rot that's occurred in the open source components.
> One day Google wakes up to find some key component has been replaced with something Microsoft controls, or at least primarily develops.
Then Google just doesn't take that patch and forks the kernel. Google already has its gLinux team with their own Debian-based Linux distro, and Google has a successful history of leading OSS projects.
You don't think having a stable driver ABI is game changing?
Have you seen the nightmare that is building monolithic pile of crap using lineageOS/etc every-time it gets an update? Even googles own devices (hammerhead/etc) have been known for having binary blobs that have to be extracted and custom wrapped to get them working with the latest versions.
The point I was trying to make: while you can build sandboxing solutions based on Linux, the entire ecosystem has evolved without sandboxing as a first class concept, leading to numerous half-baked, half-adopted solutions that are all quite cumbersome from a user perspective.
A new OS with sandboxing by default would probably produce a applicaton ecosystem that is more secure.
Also, isolating many normally privileged facilities (like drivers, file systems, ...) is not something that is reasonable on Linux.
I’ve read that, and I helped develop and troubleshoot it. It’s a rather complex solution to the problem that POSIX is not particularly amenable to sandboxing. A good capability-based design can be sandboxed with no fuss at all.
I could see myself using Fuchsia IFF we get the GNU userland and full Posix (including all the optional parts that Linux currently implements) on top of it. Closed drivers are a concession that doesn't sound too bad as long as the userland is proper GNU.
On the other hand, the mere existence of Fuchsia might lead to its best ideas being reimplemented in Linux itself, which would be a win as well.
Closed source drivers running in kernel address space ... realistically — by now we know that even open source drivers running in kernel space isn’t really that great an idea. MacOS/iOS are about to move the file system layer and any third party kernel extensions out of kernel space and into user space — it seems to me an inevitable necessity that the notion that “hardware interfaces need drivers in the kernel” is going to have to die ... the time has arrived where hardware components (other than cpu and memory) need to be viewed as user space programs that the kernel talks to when the kernel wants to...
Is there any chance they're developing Fuchsia for use in their data centers? As like the Kernel/OS for Google's servers? They already use a custom version of Linux, right?
What I've heard is that Fuchsia is designed to be a consumer OS. Apparently prototype builds of Fuchsia are being tested with Chromebooks and Google Home devices.
Microkernels are slower than a monolithic kernel like Linux,
Twenty years ago I might have agreed with the basic premise but argued the a properly designed system with a fast zero copy IPC mechanism was worth the small cost.
OTOH, Linux has become massively bloated as it attempts to fit into every nook and cranny. Optimizations that work in one environment simply don't make sense in others. Beyond that computing hardware has changed in 20 years. These days having a bunch of cores is normal, along with scattering them everywhere to manage power/clock or dedicate them for IO is common.
Further a very large number of the highest performing applications are utilizing some kind of kernel bypass. The "standardization" of DPDK despite its shortcomings has brought hundreds of applications out of dark and pointed out the folly of trying to fit everything into a posix view of the world.
UNIX clones, Linux and BSD variants are the surviving monolithic kernels.
On embedded space, most high integrity OSes are microkernel based, Apple and Microsoft OSes are hybrid variants, and as shown at this year's WWDC in a couple of years Apple OSes will only allow for user space drivers.
Even Android now uses a mixed model with userspace drivers (Treble compliant ones) and the standard Linux drivers (Treble legacy mode drivers).
It's not FUD. Measure system call latency on Fuchsia and Linux for a simple read(), and you'll see Fuchsia is slower. It's the context switch that kills you, not the copies. Of course you could use FUSE on Linux and it would be just as slow.
I will, because I am genuinely curious. However the original question was about Google data centers, which do not care about real time. Real time means timely not fast.
Yeah as a dev I am not touching this with a 5 foot pole. Google open source is not open source. It's a nasty tactic of pretending to be open source while not actually being open source as the speed of development is so fast that it's impossible to fork anything and then its laden with proprietary blobs where you have to "trust" Google which basically means tolerate them doing nefarious shit.
> ...as a dev I am not touching this with a 5 foot pole. Google open source is not open source.
I do not understand what this means, the code is open isn't it?[0]
This sounds very over exaggerated and alarmist, just like Android and for example Chromium people have forked it and removed all the Google proprietary stuff from it[1], I am sure you and other privacy conscious developers in the future will do the same for Fuchsia.
Yes, it's open source. I wouldn't try to claim it isn't, like the parent is doing. However Google being behind it still makes me nervous, specially since this might end up replacing the copyleft Linux kernel and contributing to furthering the locking-down and tivoization of Android.
I find the Fuchsia Interface Description Language (FIDL) interesting as a concept. It allows components written in different languages to easily cooperate:
I think it is an underappreciated concept in today's systems, which suffer an epidemic of monolithism, leading to GB-sized installations that do their own variation of.. nothing much.
The 'Pink' of the phrase "Pink + Purple == Fuchsia" is a reference to Taligent's Pink, and 'Purple' appears [1] to be a reference to 'Project Purple', the effort at Apple that culminated in the release of the iPhone.
At Google it's not uncommon to have common code "libraries" actually being separate process exposing a stubby rpc interface (similar to gRPC) over shared memory IPC. It solved several inter-language issues that plagued things like swig and counterintuitively it can also be as fast of even faster than direct cross-language integration.
Story
A user-facing logical container encapsulating human activity, satisfied by one or more related modules. Stories allow users to organize activities in ways they find natural, without developers having to imagine all those ways ahead of time.
Interesting. Does it mean that medules are able to declare their capabilities and the system then draws the UI around what the user wants to achieve?
For example, let's say I want to order pizza. Instead of having to download Domino's app, the system create a story based on the action of ordering pizza with all the relevant module that allows me to order said pizza.
Unfortunately almost every attempt to get a new OS out there has failed in one way or another. (as far as user adoptation). There are some pretty nifty things out there.
I hope to the higher powers that Linux, UNIX or WindowsNT is not the end of the line.
I think it was a very exciting time when you had Atari ST, Amiga, BeOS, NeXT, Solaris etc competing.
I fear monoculture is most things. Browsers, operating systems, politis.
What features do you feel that Linux is lacking (or could be improved if you were willing to start from scratch and say to heck with backwards compatiblity)?
I thought the only thing that had been confirmed about Fuchsia is that apps for it will be written in Flutter. Aside from that I've wondered if maybe it was Google's version of Microsoft's Midori project which was a microkernel operating system written in C# from which many lessons learns have been implemented in what we know today as Windows 10.
Or it could be a plan to abandon Android in order to avoid Oracle's Java API lawsuits.
Well, it's open source and build on the idea of interoperable components. So while Google may package data collection components it would be straightforward to build a version without them from source.
Whether you are able to put it on your phone in a working state is then the question though. You would need drivers for all parts which might be closed source and not compatible with your build.
Hopefully there's a stable driver ABI, or at least an ability to use multiple versions, so you're able to use these blobs however you want. Sad state of affairs is firmware.
Android is more of an open core project. AOSP is technically fully open source but when people say Android they mean the Android version of Google with the play store and play services.
The naming is confusing because what people call Android is not actually Android like what people call Linux is not actually Linux but a distribution.
Even with ASOP it tends to be more of a code dump than an open source development process. If you're an OEM you get to see it earlier in development (and get to dump your own OEM patches in there) but for most people the actual development is done behind closed doors.
AOSP style is true open source, not Android. There are not too many phones sold with AOSP, and Android is a closed platform built on top of open AOSP core.
Not saying I agree with the state of things, but very few people use open source apps other than a few high-profile ones (Chrome, Firefox, Telegram, et Al).
We need open source alternatives to everything for AOSP to be truly viable again.
LineageOS with F-Droid practically achieves this, but Google's contracts stop OEM from distributing this. The same situation from Microsoft and Linux a while back.
I think it is more if they will encourage any use outside of the control of Google. Or if they, like with Android where they illegally obstructed companies from doing so, will even discourage it.
That, plus they actively deprecated open source part in favor of their closed-source alternatives, and basically made the Android operating system useless (especially with regards to compatibility with the android SDK) without their closed-source parts.
So, it is technically "Open Source", but I am not sure I would call it "Free software" in the spirit. Especially the permissive license, which gives developers free reign over their forks.
I really like being able to get kernel sources from various phone vendors, and that's what enables projects such as postmarketos or lineage (though lineage is less concerned about getting the kernel sources/upstreaming, it seems). I just wish there was an anti-tivoization clause in the Linux kernel license.
I've always been conflicted about that. They started down that path in response to intransigent OEMs leaving people with year old phones full of vulnerabilities, but it's turned into a justification to load all the important userspace into apps they control.
On the one hand, it's great that old phones see some updates. On the other, it's terrible that Google used it as an excuse to reject and weaken the very ecosystem that propelled them to where they are.
They've made some efforts to improve the ease of updating older phones for both OEMs and users, but they keep key components locked down.
List on the left column behaves well if scrolled via scrollbar. It goes nuts when trying to use the entries at the bottom if scrolled with mouse wheel.
Though it is fun to rag on C++ every now and again, I believe Google's C++ style guide is a subset of features (classes, no exceptions, subset of boost,..).
Most C++ issues come from using every feature under the sun and accumulating loads of technical debt instead of picking one tool and sticking with it.
> Though it is fun to rag on C++ every now and again, I believe Google's C++ style guide is a subset of features (classes, no exceptions, subset of boost,..).
Which is the same thing Genode does[1], and it has served them well. Maybe a different language like ADA/SPARK or something else would have been better, but C++ was what they're familiar with, so they made it work. Although I like Rust, it's a bad argument here. Rust has been changing a lot and is still changing, and Fuchsia wasn't started yesterday. And with C++, you could even replace critical parts with formally verified LEAN[1], which has C++ code generation and should be even safer than Rust.
Super sane choice, C has had its time, Rust is an improvement over C++, but lacks higher kinded types and other niceties that are easy to implement in C++. C++ is also used in a large number of projects that fuchsia needs to interface with, such as skia, the graphics stack and so on. This is one of fuchsias competitive advantages. Moreover FIDL (fuchsia interface description language) allows for components to be implemented in a number of other languages.
I think most opponents of C++ for OS kernel development take their position because the simplicity of C results allows for pretty straightforward and direct reasoning about the static (asm, obj layout) and dynamic properties (memory allocations, procedure invocation, etc) of their code.
Both C++ and our tooling has come a long way — not to mention a change in the nature of the challenges of kernel development/performance. I think most of the old arguments against C++ have lost their edge.
They seem to see it the other way around. Most things are "hermetic C++" that export only a C interface. Which is to say they tame C++'s complexity not only by using a very restricted subset, but also by not letting ~any C++ stuff cross API boundaries.
Please don't respond to a bad comment with a worse one. That helps nothing. And especially please don't cross into personal attack, or introduce extraneous flamebait.
What kind of discourse is that leading to? It's just an unqualified, unsubstantiated attack on serious work undertaken by presumably top quality engineers.
In fairness though, it's kinda the stance taken by top quality engineers themselves when faced with the prospect of writing a kernel in C++.
The Google C++ style guide is pretty rigid, and is pretty upfront about the fact that the rigidity is in the interest of not allowing Google C++ projects to devolve into the mess that consumes most large C++ projects.[0]
Linus Torvalds has in the past said some pretty unkind things about the idea of doing kernel development in C++.[1]
Finally, Fuchsia's kernel Zircon is a microkernel. The engineers involved have elected not to attempt to write a monolithic kernel in C++ probably in part for the reasons that Torvalds described. Things like filesystems, drivers, and the networking stack are outside of the Zircon kernel in the Garnet layer and are implemented in languages like Rust (filesystems, drivers) and Go (the networking stack).
@pjmlp I am going to hijack this and ask you somewhat off topic question:
Most of the OS books teach in a very Unix centered way. Can you recommend some books or resources which describe non-C non-Unixy Operating Systems? I really liked the Blue Book of Smalltalk, and looking for more!
Linux developers, or rather its BDFL are hardly the best place to go to, when looking for sane, balanced opinions.
Considering all C programs are valid C++ programs (albeit some requiring minor alterations), it is possible to find a subset of C++ that is less painful to write than C, while also being as easy to grasp, simple, and maintainable, as C code. Google has an internal style guide that attempts to accomplish that, which I didn't agree with much, but oh well.
It might be a small moonshot experiment to see if they can come with a sensible, modern OS.
It might also be the designated successor for Android/Chrome OS, and the future of the Google ecosystem.
Conceptually, Fuchsia is interesting. It's built on a microkernel (Zirkon) and a capabilities based system. Drivers are isolated elf binaries with a stable ABI, other normally privileged things like file systems are also isolated services.
On one hand, I find it promising as a application platform, both for mobile devices and desktops: while Linux sandboxing capabilities are evolving (cgroups , namespaces, ...) , very little of the ecosystem is built around isolation as a primary concept, leading to all kinds of half-baked sandboxing and permission solutions: chroot, Flatpack, firejail, SELinux, (Docker, mentioned hesitantly since it's mainly for server environments)... All of which are somewhat tacked on an hard to use properly.
So a clean sheet design might be the best viable (practical) path.
On the other hand:
* this throws away decades of work on Linux
* many drivers will be closed source; open drivers are a major achievement of Linux
* Linux is a very collaborative effort with many stakeholders, while Google is known for keeping a very firm grip on their projects
Curios to hear other thoughts on this.