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?
How do you feel, is there anything behind this claim?
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...
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.
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.
Where is the upstream support for HIDL IPC with kernel?
From what I've heard Fuchsia will feature a deeper integration of Google services than Android. Demo: https://www.youtube.com/watch?v=FhX6cANaJ6o
* 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.
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.
I have some bad news for you. They got their way.
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 user cares because it results in fewer bugs.
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.
> 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.
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.
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).
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.
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.
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?
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...
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.
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.
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.
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.
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.
Waiting directly on the resource like that would require exclusive access quite often though?
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.
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.
You should read [1] to understand how Rust achieves this.
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.
Maybe you should read a bit more on its docs [1]. I quote:
However Rust does not prevent general race conditions.
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).
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.
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 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.
The MIT license explicitly grants the right to sublicense.
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.
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.
Fuschia has a highly permissive license that would allow anyone to fork it and release the fork under a completely difference license.
Any project can be opensource but still under direct control.
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.
It's baffling that it has taken 30 years to trickle down.
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!
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.
either they or the organizations paying the bills just didnt care yet.
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.
But that does not mean that they dont target the same devices, the same market and the same use-cases.
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
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.
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.
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 a great senior engineer retention project though.
Are people really dumb enough to fall for this trick over and over again?
(Don't answer, that was a rhetorical question.)
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.