I think if Google drops Linux for Fuchsia, there's a chance Microsoft picks up Android development. That would be incredible.

Android will still be Android, but running over a Fuchsia kernel instead of the Linux kernel.

Fuchsia is an OS not a kernel, the kernel running under Fuchsia is called Zircon.

Linux is the last GPL component of Android. Dropping it would enable Google to close up Android source whenever they want.

That doesn't make sense to me at all - you can have a closed source system running on top of Linux, today.

Isn't that exactly what Android is?

edit: misread your comment

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.

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

> Most device makers fork AOSP and distribute binaries

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

If that was actually Google's intent, then it seems silly to release Fuchsia under any semblance of a free software license.

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.

in essence: there's still cause for concern.

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

So much for the power of open drivers.

Would be kind of a shame naming-wise if the first sentient devices end up running Fuchsia instead of Android.

How do we know which devices are sentient? The first ones could have ran GM-NAA I/O for all I know.

Not how we'll know, how they'll know.

“i OS” also works, and they may process their thoughts in their own bodies instead of receiving them remotely.

Well, the first sentient device will probably be some supercomputer, so it won't be either of those. ;)

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.

No rule that I know of that sentience necessarily requires a supercomputer, either.

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

I thought that Android fully leverages SELinux? That's how it implemented permissions AFAIK.

SELinux wasn't added until after Android 4.3.

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

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.

You can with iptables.

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.

How would they not be able to use Linux anymore? With it being GPL and everything?

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.

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

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 need to worry about Microsoft.

For each GPL component removed, do Google open source the replacement?

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.

Yes the new kernel is open source; it's the play store and perhaps other bits of the full OS they'll hang on to.

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

Mainlining the driver is the correct solution, but most Android drivers don't pass the smell test.

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

Read NAMESPACES(7)

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

I mentioned namespaces.

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.

If you read NAMESPACES(7) and thought to yourself "that's a unified API", we have radically different definitions of "unified".

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.

> I could see myself using Fuchsia IFF we get the GNU userland and full Posix

Then what the hell would be the point?

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

Or we could wait for Hurd, and it is not a joke.

Fuchsia doesn't implement dot dot to traverse to the parent directory. POSIX doesn't seem likely.

Then keep using a UNIX clone.

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.

Never say never but it's unlikely. Microkernels are slower than a monolithic kernel like Linux, and speed is money for Google's data center software.

   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.

Ah the typical microkernel FUD.

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.

Now go do same with INTEGRITY, QNX, L4 and plenty of others used in production on real time scenarios where Linux is found lacking.

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.

One other con for ya:

* Google is very likely to kill privacy enabling features

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.

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

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

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.

Chromium doesn't match with this description. It has a ton of forks and derivative works, both open source and commercial.

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