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.

edit: misread your comment

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.

For instance, OnePlus and Sony publish these Android sources: https://github.com/OnePlusOSS https://github.com/sonyxperiadev?tab=repositories

That's what Google does as well and it's called "Android".

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.

> 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.

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.

in essence: there's still cause for concern.

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.

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.

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.

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).

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.

So much for the power of open drivers.

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.

Coming from someone that thinks houseflies are most likely sentient at some level.

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.

https://source.android.com/security/app-sandbox

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.

https://source.android.com/security/selinux

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.

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.

[1] https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

With Q, the Linux kernel is the only GPL thing still standing.

No need to worry about Microsoft.

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.

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.

I don't understand how is returning to Windows model of driver development is an improvement.

The Linux kernel itself has a unified sandboxing API, there are just a lot of clients using different parts of it.

And that's pretty nice, being able to pick what you need when developing an OS conceptually just barely above the kernel.

Cgroups is more of a resource constraining API, I wouldn't call it the exact same concern as sandboxing.

http://man7.org/linux/man-pages/man7/namespaces.7.html

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.

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.

Then what the hell would be the point?

   Microkernels are slower than a monolithic kernel like Linux,

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).

* Google is very likely to kill privacy enabling features

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.

[0] https://fuchsia.dev/fuchsia-src/development/source_code

[1] https://github.com/Eloston/ungoogled-chromium

https://en.wikipedia.org/wiki/Chromium_(web_browser)#Browser...

- Language: https://fuchsia.dev/fuchsia-src/development/languages/fidl/r...

- Wire-format: https://fuchsia.dev/fuchsia-src/development/languages/fidl/r...

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.

https://developer.android.com/guide/components/aidl

https://source.android.com/devices/architecture/hidl

And it goes back to ideas like DCE and Taligent.

https://en.wikipedia.org/wiki/Distributed_Computing_Environm...

https://en.wikipedia.org/wiki/Taligent

Also how XPC works on Apple platforms (IDL here are Objective-C protocols).

https://developer.apple.com/library/archive/documentation/Ma...

[1] https://spectrum.ieee.org/tech-talk/computing/software/a-mod...

https://chromium.googlesource.com/chromium/src/+/master/mojo...

The handles etc. have clear Windows analogues and Wire is basically COM.

Such as...? Genuine question. I was impressed a few years ago when I tried Ubuntu for Windows, but maybe that has nothing to do with the NT design.

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.

Not sure if I understand that correctly.

It is too early to tell how Fuchsia will do but at least they are trying.

I think https://www.qubes-os.org is interesting as well.

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.

Or it could be a plan to abandon Android in order to avoid Oracle's Java API lawsuits.

https://fuchsia.googlesource.com/fuchsia/+/HEAD/docs/the-boo...

And ART is being ported to run on Fuchsia.

https://android-review.googlesource.com/q/status:open+Fuchsi...

So it remains to be seen.

Fuchsia also supports C++ so I imagine you will be able to use Qt et al.

Will it be data collection free, and just push users to use Google services as the default, or will it have data collection baked in?

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.

We need open source alternatives to everything for AOSP to be truly viable again.

OEMs would never bother selling them in the first place, obligations or not.

For Facebook, you can make a custom Firefox bookmark, or one of those WebViews hard-coded to Facebook.

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.

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.

Heck, while we are dreaming: Why not buy the rights to Plan 9 and start improving on those ideas, now that would be interesting.

Maybe they think it has to do with javascript, and it does not for them either.

This is chromium on Linux.

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.

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.

[0] https://genodians.org/nfeske/2019-01-22-conscious-c++

[1] https://leanprover.github.io/

I see no issue in using a fair subset of C++ features in privileged mode.

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.

C can stay with classical UNIX.

https://news.ycombinator.com/newsguidelines.html

Discourses become much nicer when we don’t make/take such explicitly negative angles which are rife with hostile undertones.

What kind of discourse is that leading to? It's just an unqualified, unsubstantiated attack on serious work undertaken by presumably top quality engineers.

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).

[0]https://google.github.io/styleguide/cppguide.html [1]http://harmful.cat-v.org/software/c++/linus

His baby would be nowhere without the contribution of the likes of IBM, Compaq, Oracle and many other nameless contributors.

Linus opinion is his opinion, that is all.

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!

- MacOS (pre-OS X)

"Revolution in the Valley"

https://www.amazon.com/Revolution-Valley-Insanely-Great-Stor...

http://basalgangster.macgui.com/RetroMacComputing/The_Long_V...

- NeXTSTEP / Mac OS X

Debatable about non-C non-Unixy part, but it surely isn't the focus of the whole stack.

"Mac OS X Internals: A Systems Approach"

https://www.amazon.com/Mac-OS-Internals-Approach-paperback/d...

http://www.nextop.de/NeXTstep_3.3_Developer_Documentation/

- Oberon and its derivatives (1992 and 2013 versions, System 3, Insight ETHOS and A2)

https://inf.ethz.ch/personal/wirth/

https://inf.ethz.ch/personal/wirth/ProjectOberon/index.html

http://www.projectoberon.com/

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.472...

http://www.ocp.inf.ethz.ch/wiki/Documentation/Front

https://www.research-collection.ethz.ch/handle/20.500.11850/...

- Symbian

"Symbian OS Internals: Real-time Kernel Programming"

https://www.amazon.com/Symbian-OS-Internals-Real-time-Progra...

"Symbian OS Platform Security: Software Development Using the Symbian OS Security Architecture"

https://www.amazon.com/Symbian-Platform-Security-Development...

"The Symbian OS Architecture Sourcebook: Design and Evolution of a Mobile Phone OS"

https://www.amazon.com/Symbian-OS-Architecture-Sourcebook-Ev...

- Mesa and Mesa/Cedar

http://www.digibarn.com/friends/curbow/star/XDEPaper.pdf

http://worrydream.com/refs/Teitelman%20-%20The%20Cedar%20Pro...

- JX

http://www4.cs.fau.de/Projects/JX/

- SPIN OS

http://www-spin.cs.washington.edu/external/overview.html

- Singularity,

https://www.microsoft.com/en-us/research/project/singularity...

https://channel9.msdn.com/Shows/Going+Deep/Singularity-A-res...

https://channel9.msdn.com/Shows/Going+Deep/Singularity-Revis...

- Barrelfish

https://www.microsoft.com/en-us/research/project/barrelfish/...

- Midori,

http://joeduffyblog.com/2015/11/03/blogging-about-midori/

https://www.infoq.com/presentations/csharp-systems-programmi...

"RustConf 2017 - Closing Keynote: Safe Systems Software and the Future of Computing"

https://www.youtube.com/watch?v=EVm938gMWl0

"While never reaching commercial release, at one time Midori powered all of Microsoft’s natural language search service for the West Coast and Asia."

Source: https://www.microsoft.com/en-us/research/project/singularity...

- Helios

https://www.microsoft.com/en-us/research/wp-content/uploads/...

- Muen

https://muen.codelabs.ch/

- GenodeOS

https://genode.org/documentation/index

- Inferno

http://www.vitanuova.com/inferno/docs.html

- Minix 3

https://wiki.minix3.org/doku.php?id=www:documentation:start

- BeOS

"Be Developer's Guide"

https://www.amazon.com/Be-Developers-Guide-Development-Team/...

"Be Advanced Topics"

https://www.amazon.com/Be-Advanced-Topics-Development-Team/d...

- Windows

https://www.amazon.de/Windows-Internals-Part-Pavel-Yosifovic...

https://www.amazon.de/Windows-Internals-Part-Mark-Russinovic...

https://channel9.msdn.com/Shows/Going+Deep/Rob-Short-and-ker...

https://channel9.msdn.com/Shows/Going+Deep/Doron-Holan-Kerne...

https://channel9.msdn.com/Events/Build/2012/3-005

Not everything by a long shot, plenty more to re-discover like VMS,IBM i and Z, Unisys ClearPath, mbed,...

Just keep an open mind and don't idolatrize UNIX, yes it has a couple of good ideas, but they don't make it the be all end all of OS design.

http://harmful.cat-v.org/software/c++/linus

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.

https://www.kernel.org/doc/html/latest/process/index.html