Hacker News new | past | comments | ask | show | jobs | submit login

I've heard the following opinion on the internet: "The sole reason Fucsia OS exist is so google can release GPL-free android sometime in the future"

How do you feel, is there anything behind this claim?




Google has been a Linux user since before it even existed [1], and has been almost exclusively a Linux shop since: Linux servers, Linux desktops (Chromebooks, Goobuntu, Whatever debian testing derived distro they are using now is called), Linux based phone OS.

So I'd say for most of its business activities, Google is actually okay with the GPL, otherwise they'd have rewritten it a long time ago. Given the size of Google and how important Android is to them, I think they'd have prioritized Fuchsia OS far more if their bottom line were really affected.

There is a point with drivers, as Fuchsia has better support for proprietary drivers than Linux and IIRC one of the Android modifications was to add HALs to the kernel to make proprietary drivers easier. But it's not a killer argument, after all they figured it out for Android.

Their business intent with Fuchsia is definitely not clear so it's a honey pot for speculation. I don't know. Maybe they wanted to diversify their approaches and have something if the Android kernel fork gets more and more patches and eventually backporting becomes impossible and they need to maintain it on their own now. Maybe they just want to be upstream as it involves a great deal or power that you have. Maybe it's part of a deal with a hardware vendor who wants their driver to become proprietary in the future.

[1]: https://web.archive.org/web/19971210065425/http://backrub.st...


They have been removing GPL parts from Android with each release, the only thing left is the kernel, which after Project Treble looks more like a pseudo-microkernel than traditional Linux.


None of this is even slightly true.

The kernel is still on the "vendor" side of Project Treble, and still controlled by the OEM as a result (not that it should be but it is). This is not against "traditional linux" at all anyway. Upstream linux doesn't exactly like having a bunch of stuff rammed in as kernel modules either, that's why for example FUSE exists.

As for "removing GPL parts" - Android started with minimal GPL parts in the first place but they haven't been actively removing GPL, either. Just look through AOSP for MODULE_LICENSE_GPL - you'll find a ton of components are still (L)GPL.


Ah so I am lying that GCC has been removed from the NDK.

Where is the upstream support for HIDL IPC with kernel?


HIDL ipc is built on top of binder, which is a kernel driver in mainline Linux.


My question was about the whole deal.


Agree, android drivers/blobs were not much use in linux space => hence, the whole premise of android==linux, backporting features from android to linux was never an option. The ones who used rpi, or even cheap chinese android tables wo/ linux support can relate.

Yes, google have nothing against GPL, but still GPL/agpl/lesser gpl are licenses that place specific limitations on a company modifying the original work. There are alternative licenses that do not.


> Their business intent with Fuchsia is definitely not clear so it's a honey pot for speculation.

From what I've heard Fuchsia will feature a deeper integration of Google services than Android. Demo: https://www.youtube.com/watch?v=FhX6cANaJ6o


There's other reasons why fuchsia is arguably better, such as using a micro-kernel and being "capability-based." The license is liberal enough to allow relicensing it as GPL, if anyone cared to fork it.


yes, I'll try to sum up the article as i understand:

* better process isolation

* stable hw/driver api (this is a huge mistake in linux, agreed)

* less historical craziness(who likes fork()?)

* more micro-kernel

some of the things I personally cannot buy:

* vulkan native. android is not vulkan-native, it provides both opengl es and vulkan, for your choice

* flutter. why bundling and bringing opinions to the system becomes a benefit? it was a major problem with android that you have to interact with java if you want any native ui => I would prefer more ways/languages/bindings to interop with the UI

* fidl ipc. cool, again, why bundling something with the os?

* vDSO. why is even vdso on the slides - vdso is important, but it already with us for a decade.

This article is great because its one of the first that breaks down Fuchsia on a tech level. But at the same time, its not an article that explains all the reasons the fuchsia is better that what google have now.


> * vulkan native. android is not vulkan-native, it provides both opengl es and vulkan, for your choice

IMO vulkan-native is the right choice because opengl (or opengles, or anything else) can always be reimplemented on top of vulkan anyway. Layering opengl on top of vulkan means you're no longer at the mercy of hardware vendors to provide a bug-free opengl implementation. And if you're calling a userland opengl library running on top of vulkan, you can actually debug into graphics system and much more easily tune performance. (Debugging through into opengl calls is almost impossible when the opengl implementation is hardware-specific and part of the graphics driver itself).


Case in point. Google's ANGLE library has a in-progress Vulkan back-end. (Used for WebGL in Chrome and Firefox). ANGLE does only provide OpenGL ES, but then so does Android. I wouldn't be surprised if an upcoming android version required Vulkan suppport and Android shipped with ANGLE for OpenGL.

https://github.com/google/angle


In reality this is entirely moot and comes down purely to driver development cost. Nothing in the OS is designed around the idea of being "vulkan native" or not. That's just not a system architecture thing at all.

But what is a thing is whether or not the GPU driver bothers to have an OpenGL ES path or not. It's obviously simpler if the driver doesn't, but a quality driver implementation will also obviously always beat something like ANGLE in every way.

So take a hypothetical Nvidia Shield 5 running Fuchsia in 5 years or whatever. If games are still dominantly in OpenGL ES, then you can bet your ass Nvidia will be shipping a first-class GLES driver and not use ANGLE-on-Vulkan.


FIDL is used extensively through the OS, and looks like it will be the primary means of communication between processes, not too different from macOS's XPC (which is used for a lot of services as well as very low-level stuff like talking to the T2 processor, apparently). Fuchsia being a microkernel, it makes sense to make this part of the OS. The alternative of inventing ad-hoc RPC mechanisms for each area of the system would be worse.


If I remember correctly Android also has IPC in the kernel, using it to enforce permissions and the security model between apps.


Moreso after Project Treble, now Android Linux behaves a bit like a micro-kernel.


> stable hw/driver api (this is a huge mistake in linux, agreed)

Not to get into a flamewar over this, but there are real benefits to Linux's rolling driver ABI (the "API", however, is mostly stable, contrary to what you say). It encourages mainline collaboration, and greatly improves the quality and compactness of the drivers.

On Windows (and to some extent macOS), you'll find whole classes of driver where each driver has its own proprietary internal implementation of something that should have been in the API and ABI, but is not (or just was not when the driver was written). Linux has great, up to date drivers for the vast majority of devices you'd want to use†, and all of the best ones are built (compactly!) right in to the kernel, so it is more or less moot at this point whether a stable ABI is a good thing (at worst, it didn't matter in the long run; at best, it made the system better).

The level of integration and standardization in the Linux kernel is spectacular, and absolutely would not have been achieved if vendors were empowered to link ABI-compatible binary blobs into end user kernels. There is tremendous value in the fact that I can manage, consistently, every LED, every DVFS controller, every fan controller, every GPIO pin, etc. on each supported system in a consistent fashion. Left to their own devices, each vendor would use their pet interface (as seen with NVIDIA putting their foot down and demanding EGL surfaces be used with their driver on Wayland, despite the fact that no standard software supports it); NVIDIA insists that this is the way it's meant to be played, and I'm glad that the answer is a resounding no.

† Outside of the Android ecosystem, which, through what could maybe be called poor stewardship on the part of Google, inexplicably refuses to develop against the mainline kernel, so is constantly fighting to maintain literally thousands of vendor-, OEM-, model-, SKU-, country-, and carrier-specific kernel trees for absolutely no recognizable benefit, and against the clearest and most consistent advice of the highest experts on the subject.


> It encourages mainline collaboration

I feel like this is demonstrably a false promise by looking at the billions of mobile devices never getting any updates because of vendor neglect.

> and greatly improves the quality

Compared to what?

> and compactness of the drivers

Which no user has ever cared about.

> up to date drivers for the vast majority of devices you'd want to use†

I notice that you excepted billions of devices in order to make this claim.

> inexplicably refuses to develop against the mainline kernel

It's not inexplicable. It's easier and cheaper.


The Linux model definitely encourages mainline collaboration. It just happens that the Android vendors are fighing against this encouragement, and Google has caved in to their demands.

> Compared to what?

Compared to what happens on Windows and Android, where individual drivers have to reimplement common functionality, often in inconsistent ways.

> Which no user has ever cared about.

Users care that their drivers work and that they continue to be supported in the future. Less compact code is larger, and therefore buggier. Drivers which are provided as proprietary userspace blobs are invariably unmaintained and stop working with future kernel versions.


> feel like this is demonstrably a false promise by looking at the billions of mobile devices never getting any updates

Third-party firmware like CyanogenMod exists only because in-kernel GPL parts can be ported to new OS versions.

With Fuchisa there won't be anything like CyanogenMod anymore.


> Third-party firmware like CyanogenMod exists only because in-kernel GPL parts can be ported to new OS versions. With Fuchisa there won't be anything like CyanogenMod anymore.

I think you're confused. If the interface for the drivers stays stable, then you can just carry over the same exact binary blob and it will keep working perfectly, which is exactly what Microsoft does. Windows 7 drivers still work just fine in Windows 10.


If third parties can update the OS despite an unstable driver API then it all boils down to the laziness of the vendors.


> Which no user has ever cared about.

The user cares because it results in fewer bugs.


Which paper proves such correlation?



Thanks.


Android devices not running mainline kernels is a direct result of the Linux development process.

If an Android device launches with a new CPU or device, the OEM has to go through the process of up-streaming the changes to mainline before they can launch their phone? not going to happen.


> Android devices not running mainline kernels is a direct result of the Linux development process

That's a wishful thinking. Majority of Android drivers are userspace blobs. Linux kernel development process is completely irrelevant for them.

Device vendors don't update already sold devices because they don't care (and because average consumer also does not care).


> Device vendors don't update already sold devices because they don't care (and because average consumer also does not care).

You should consider why the hardware vendors are in the critical path for OS updates in the first place. Dell doesn't get to decide whether you can apply Windows updates.


Turning that notion on its head, Pinephone could be one to watch.

They more or less intend to supply the hardware only. This avoids the pretence of vendor updates entirely, by both the company (Pine64) and the ARM licensee (Allwinner).

The software stack is up to you, with mainline Linux support courtesy of the A64 [0] powering a number of 'RPi-killer' boards. Device updates will be supplied by the likes of Ubuntu Touch, LineageOS, postMarketOS et alia mobile distributions.

[0] http://linux-sunxi.org/A64


> Turning that notion on its head, Pinephone could be one to watch.

Maybe. Except that for me (and I know I'm not alone) the second most important part of my pocket computer after web searching is the camera, and they're unlikely to have anything great in there.

> Allwinner

Hah. The repeat GPL violator?


i think in the end, this whole divide boils down to a divide in philosophy between free software and corporations that support “open source” but don’t want it free (as in gpl)

thereby we get the constant tension between google and hardware makers that want to keep their jewels secret, and the linux/foss community that wants to keep their freedom to install their (open) software on any device... by keeping the drivers in with the kernel, linux can foster that end, but it causes no end of frustration to google et al...

i think that’s probably the reason we get fuchsia: google can be open source, and with the hw makers, keep the proprietary parts proprietary... the result being, we have open kernel and os bits but no guarantee (or much hope at least) we could ever run it on our devices...

i think that’s the biggest cultural divide: freedom to change and replace the software vs freedom to look at the code (and maybe run it in an emulator...


>NVIDIA insists that this is the way it's meant to be played, and I'm glad that the answer is a resounding no.

I have some bad news for you. They got their way.


This is so untrue.

There's a whole class of devices that will never be in linux mainline kernel - experimental filesystems(remember those years wher FUSE was a patch?), propietary hardware(embedded devices), kernel bypass hardware(onload), security hardening mechanisms(remember PaX?), commercial software who basically sell the driver(intel studio profiler).

All this breaks every time linux releases a major rewrite. If the vendor is out of business or no longer interested in a product - you are left with the drivers that do not work.

Moreover - in a case of major api breakage - its kernel contrubutors who are left with re-writing every driver for a new api, delaying the kernel releases.


Very well put.


Windows doesn't even have a standard driver-ABI anyway - if it did, we wouldn't have hardware losing driver support when switching the system to a different Windows version (XP/Vista/7/8+/10).


> Windows doesn't even have a standard driver-ABI anyway

It does to a very significant degree. Windows 7 drivers from 10 years ago still work today with Windows 10. Windows 95 user software from 23 years ago will still work today in Windows 10. Microsoft cares strongly about maintaining compatibility and only removes functionality when necessary.


I don't understand why they didn't want to base it on the formally-verified, capability-based micro-kernel called seL4.

Formal verification is the difficult but necessary next step for security-intensive applications.

Also, any new kernel should only be written in a memory-safe language. Rust would be the best, since it is also safe from data races, outside of unsafe blocks.


Well... it's non-trivial to use seL4 correctly. It has all of the facilities to build something great and very little rails to ensure that you actually do. CAmkES, the component framework to help you do that, is... challenging in all the wrong ways.

The proof evidence is very hard to extend meaningfully for new platforms, and you're limited to environments which have a sufficient MMU.

We're starting with seL4 and building a whole Rust-based userland around it, and creating a whole pile of compile-time assurances along the way to make sure we're not inadvertently doing something dangerous or stupid with the rope seL4 gives you.

It's worth it for us. However, it is a colossal pain in the ass. That said, in the coming months we're likely to open source some of our progress in making it easier and more reliable to work with, integrate with, and otherwise leverage seL4 for certain use cases.


I'm super interested in the work you're doing. I spent a couple of weekends building bindings and trampolines to get Rust binaries linked into Chibi/OS and FreeRTOS and it worked really well. I've always wanted to work with seL4, so I downloaded the source and started working through the tutorials and... oh dear. There ended my experiments trying to add Rust into the mix. So if there's any way I can subscribe or otherwise keep abreast of the work you're doing, I'd love to do that.

As an aside, I wonder just how much async/await in Rust will obviate the need for small kernels in deeply embedded applications. If I can do blocking IO with my peripherals and use the async state machines to do "task" switching, well... who needs tasks and capabilities? It'd land somewhere on the "language OS" side of an embedded OS almost.


At the moment we're light on marketing materials & outreach. We've been heads down bootstrapping and working with early customers.

When we open source things in the coming weeks & months they'll all land on GitHub, https://github.com/auxoncorp, so that's probably the lowest touch way of observing what we're up to as things mature.


async/await in embedded is actually an interesting thing, that i also evaluated. I think it can't be an alternative to preemptive RTOS kernels, since the cooperative nature doesn't allow to process things within guaranteed deadlines. Therefore I think async/await might end up more as an add-on to RTOS: All time-critical things are run within independent RTOS tasks. And all the remaining and less critical stuff could potentially be run inside a single-threaded async/await scheduler.

While Rust seems to be promising here, I'm not sure whether the current async/await implementation will really allow for this. I experimented a bit with it, and found lots of issues where async/await lead to severe memory bloat (composing 3 async functions that do not a lot things requiring a 20kB task allocation). The compatibility with Futures and the requirement to move async fns to compose them before using them (which requires extra stack - which again ends up as extra heap/task memory) plays a bit against it. But these things are also worked on, so let's seee how it works out.


>If I can do blocking IO with my peripherals and use the async state machines to do "task" switching, well... who needs tasks and capabilities? It'd land somewhere on the "language OS" side of an embedded OS almost.

Waiting directly on the resource like that would require exclusive access quite often though?


Deets would be appreciated. Sounds interesting.


Rust isn't safe from race conditions. It is not a guarantee. It is free from memory errors, that is true, though.


Rust is safe from race conditions, because race conditions are memory errors.

You should read [1] to understand how Rust achieves this.

[1]: https://doc.rust-lang.org/nomicon/send-and-sync.html


Quoting some more relevant stuff from the nomicon. The linked article is short and sweet.

A data race has Undefined Behavior, and is therefore impossible to perform in Safe Rust.

...

However Rust does not prevent general race conditions.

This is pretty fundamentally impossible, and probably honestly undesirable. Your hardware is racy, your OS is racy, the other programs on your computer are racy, and the world this all runs in is racy. Any system that could genuinely claim to prevent all race conditions would be pretty awful to use, if not just incorrect.

Source: https://doc.rust-lang.org/nomicon/races.html


not true - you can have a program that is free of data races but still contains race conditions. Rust prevents data races.


No, Rust isn't.

Maybe you should read a bit more on its docs [1]. I quote:

However Rust does not prevent general race conditions.

[1] https://doc.rust-lang.org/nomicon/races.html


Regarding Fuschia only having an option for vulkan and not opengl, it doesn't seem like that would necessarily stop opengl software from working on fuchsia, right? There are opengl implementations on top of Vulkan like MoltenVK. I don't have a great understanding of this stuff, but assuming that this is true, I imagine that it has upsides like eliminating potential driver bugs which have plagued opengl in the past.


MoltenVK implements vulkan itself, on top of metal, and its counterpart, moltengl is closed-source. There do exist projects to implement opengl on top of vulkan, but I don't think any of them are mature yet.


Google does not mix well with stable api. They love the shiny new stuffs and break things often.


How tied to the internet will it be? How many callbacks to google will it have? Will it rely on google DNS?


> Will it rely on google DNS? You bet!


As default, that makes a lot of sense. I guarantee there will be a lot of pushback from enterprises if they can't change the DNS servers to their own.


not


> capability-based

For anyone wondering what that means, here's a good place to start:

http://erights.org/elib/capability/overview.html

> Modern capability security theory comes mostly from the work of Norm Hardy, Charlie Landau, Bill Frantz and others...

I worked with Norm and Bill at Tymshare in the '70s. Alas, Norm passed on last year, but I got to see Bill at his memorial. If you're in the Bay Area and into ham radio, you might run into Bill on the N6NFI repeater.


IBM's OS/400 of 1988 was, I think, the first widespread capability-based OS. Certainly it was my introduction to the concept.

It's baffling that it has taken 30 years to trickle down.


I wonder how much it will take for the safe systems programming and TIMI part though.


The copyright owner can alway relicense no matter what license they use initially. Unless you mean others, in which case what license do they use that allows relicensing?


Linux has no singular copyright owner, so nobody can relicense it.

Fuschia has a highly permissive license that would allow anyone to fork it and release the fork under a completely difference license.


But you cannot change the copyright or license of the existing code. You can add GPL code that cannot be merged back, but nothing gives you permission to change the copyright of the original.


The MIT, BSD, and Apache licenses, which Fuchsia uses, have almost no restrictions aside from attribution. Anyone would be able to fork Fuchsia and re-license as GPL.


How exactly does that work, what stops anyone from maintaining a 1:1 branch, the "fork", with upstream and claiming it's GPL?


You can relicense MIT source to GPL. Nothing is stopping anyone from maintaining a relicensed fork like you described. The real question is, would anyone even use or contribute to that fork? (probably not)


That's not a correct statement.

Nothing in the MIT license says that you can claim credit, ownership, or restrict licensing terms on someone else's code.

What you can do, of course, is include the original MIT licensed work in a larger project with other GPL'd pieces. That does not "relicense" anything, and I'm only constrained by the GPL if I use the GPL'd part of the codebase.

I can download X11 from Redhat and still use it under the original terms from MIT.


What everybody needs to learn is the concept of 'derivative works'.

When you combine MIT code with GPL code you are creating a derivative work of involving at least 3 sets of copyrights. Your copyright (since I am assuming you did more then just copy paste), the MIT licensed copyright, and the GPL copyright.

Anybody using that code is subject to those 3 sets of copyrights combined. It's a derivative work of all 3 code bases so it has all 3 copyrights and depend on the original licenses for anybody else to legally copy.

Since the GPL is the most restrictive and disallows any additional restriction then the code base is _effectively_ GPL licensed.


You can view GPL as a bunch of restrictions on top, as I don't think the GPL grants any freedoms the MIT doesn't grant. So why shouldn't you be able to say "you can use my version, but only if you also adhere to the GPL terms"? After all the MIT gives me the right to distribute without any stipulations under which terms the distribution has to take place.


> Nothing in the MIT license says that you can [...] restrict licensing terms

The MIT license explicitly grants the right to sublicense.


That’s different from relicensing the code https://writing.kemitchell.com/2016/09/21/MIT-License-Line-b...


Seems people are talking past each other.

The world "relicensing" doesn't exist in copyright, nor in the linked article. Instead there are some similar situation being bunched together and faulty used interchangeably.

A copyright author can redistribute a work they own under new terms. This would be the case when they have offered a work under say MIT and change the copyright license for any future offer under the GPL. It is similar to a merchant changing the price, ie in the past the product cost X but now it cost Y. Naturally past customers don't suddenly have to pay more for something they already paid for, but buying more (or getting updates) applies the new price.

The copyright author can also dual license it. In this case they would offer the work but under two different licenses at the same time. This would be like a merchant offering a product under two payment plans, one where you pay up front and an other more expensive method where you pay a small amount each month for a bigger total. In both cases the product is the same but the condition of sale is different.

The MIT license itself also allows for something similar to resellers, ie people who take a copy and apply their own additional set of conditions when they distribute it. This doesn't change the original offer, but those getting a copy from the reseller has to honor the resellers term and condition in addition to the original conditions of the author. This is similar to going to a store where you pay both the product original price and the margin of the reseller. You can always go to the original manufacturer and only pay the original price, but you may miss out on features that the reseller include in their package.


It kind of defeats the purpose of GPL too. You can't keep future changes to the codebase public and open source since anyone who wants to do so will just not use your fork, so why bother?


Once somebody contributes to the fork the fork contains code that can't be backported to the MIT licenced version. The hope would presumably be that the GPL version grows faster since the GPL version can merge any change to the MIT version but not the other way around.

In practise it wouldn't work all that well unless you pay a development team to push the GPL version significantly ahead, but it's a possibility.


Nothing stops you. These licenses are philosophically very different from the GPL. They tend to be designed to provide literal freedom to do what you want with the code, basically as long as it doesn't interfere with the original use and provides acknowledgement. This includes relicensing it and including it in proprietary products.


As AOSP have shown us - having an opensource license is one thing but having a control over the course of the development, control over what features get implemented and merged - is something very different.

Any project can be opensource but still under direct control.


Almost all big open source projects are under direct control of a person or entity.


Anyone can fork. But with the way android works vendors will no longer have to release their kernels for their android versions. This is one of the main reasons projects like lineage can exist as you can build and modify a kernel for almost every device on the market.


Regardless of what you think of Google, the reality is Fuchsia and Android have little to nothing in common. While they would certainly rather have a permissive language from the bottom up, they certainly wouldn't have written a whole new OS with that as the primary goal.

Android's platform design would arguably have been considered modern in 2007 or 2008, but it is 2019, and the cracks in Android's capabilities have been widening for a while. Sometimes people still think of Android as "newer" in the operating system space, but it's a decade old!


> it's a decade old

Windows NT came out over 20 years ago, in 1993. The first public release of Linux was in 1991. And the BSDs trace back even longer, you could say back to the original Unix from 1969. So a decade is recent I'd say.


Windows NT development started in 1989. It was lead by Dave Cutler, who also lead VMS which started in 1975.


A decade isn't much for an operating system...


It is when you start thinking about our approach to security in 2019, versus our approach to security in 2009. And sometimes the baseline assumptions about how software is written makes it exceedingly hard to, in flight, rebuild for our new understanding of what is needed for good security.

Attempts to do so often entail more or less, tacking on a whole different environment, as Microsoft has attempted with UWP. To a certain degree, it'd be easier to just start over from scratch, as Google is attempting to do.


We mainly changed our focus from protecting multiple users from each other to protecting multiple applications from each other. But Android always had the latter model. Apart from that I don't think a lot has changed from 2009 to 2019?


given that capabilities were considered by many the future of security in the 1970s, you could say that the community understood full well how to provide a fine-grained policy machine with good enforcement guarantees.

either they or the organizations paying the bills just didnt care yet.


Microsoft is still at it, just from the other side, by merging Win32 and UWP containers.


It took me some time to form the argument. I dont really see how fuschia targets linux on the server or windows on the desktop, it is never mentioned to be the on the backend and no features are ground-breaking for the backend. All the usecases are for mobile platforms - the android. Ok it may be the case android and fucsia have no common code, no common architecture and no common people.

But that does not mean that they dont target the same devices, the same market and the same use-cases.


No arguing with that - yes, selinux/uid permissions were somewhat wonky. But google did the job and paid its price isolating the programs and it works right now. Can we consider the problem of android app isolation aldready solved?


If you're an android dev, you know google basically rewrite the whole SDK for every major OS release. Android 1.0 is unrecognizable compared to Android 28.0 to the point where supporting devices running 1.0 from a 28.0 is a tedious and time-expensive operation.


There aren't any API level 1 devices out there though. Supporting, say, Android 4 (level 14, from 2011 so almost eight years ago!) is very straightforward. The fragmentation argument doesn't hold water for most apps.


maybe if you have a simple text app, try implementing background sync, modern UIs even db stuff gets really convoluted really quickly. forget about camera/audio support

my current company supports down to only api level 19 and even then it's like having to maintain multiple apps to support apis <23


Did you mean SDK 28? There was no Android 28.0 as this was posted.


>Stable drive interface, hardware manufacturers can independently maintain hardware drivers (hardware)

For me this reason is enough to justify linux replacement. I think it's one of the main reasons for google to, they want to deal with vendors' blobs in a more stable and ease manner.


The point of being GPL free is you don't need to release source code.

If you combine this with the other point of Fuchsia, hardcore security, the final combined result is that nobody can audit what Google is actually doing on "your" devices. And that's why.


Assuming Google doesn't need to hide anything, being GPL free could be so that others (like device drivers) don't need to release source code.


I think it's a valid concern, look at how many originally open-source Android APIs and frameworks Google has pushed out in favor of their proprietary one's. Similar concerns I've seen voiced is there being a inseparable integration with Google services, like how Google has pushed Gapps dependency onto Android, but now baked into the OS-level.


>How do you feel, is there anything behind this claim?

A glance at the design will tell you that no, there's nothing to that claim.

Fuchsia's only competitor is Genode. Linux is basically obsoleted by its design.


It’s not that important to them I think.

It’s a great senior engineer retention project though.


Embrace-extend-extinguish.

Are people really dumb enough to fall for this trick over and over again?

(Don't answer, that was a rhetorical question.)


What exactly are they embracing by creating a new OS?


SoC vendors who write the device drivers in the end probably couldn't care less. Why should they opensource their drivers for a new OS?


There are plenty of kernels they could've started with, so I'm willing to say that the motivations are probably at least somewhat technical.


I'd say it's more likely someone had a hobby of making microkernels, and when they joined Google they managed to twist the arm of someone senior to assign a few people to their hobby full time.


A few? There are more than a hundred contributors in https://fuchsia.googlesource.com


The only GPL left on Android is the Linux kernel, everything else GPL related has been replaced.


That's very much my feeling. Linux has a history behind and some design decisions made for a wide range of devices a long time ago. Google has the kind of money necessary to build an OS from scratch in order to power their devices (Android, Chromebook, Google Home), whilst other mortal beings have to put up with one of the existing choices.


It is irrelevant. Running Android apps is no longer tied to AOSP. Chromebooks run Android apps.

There is an app ecosystem composed of Google Mobile Services and the Play store, today it runs on Android and on ChromeOS, and it seems that it will run on fuchsia too.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: