Guest post by Google has posted the beginnings of a documentation project around their microkernel based OS, Fuchsia. From the readme:
This document is a collection of articles describing the Fuchsia operating system, organized around particular subsystems. Sections will be populated over time.
In terms of the result, given how android’s going…
Here’s hoping there’ll at least be a fuchsia equivalent to vanilla AOSP for mainstream devices.
Google’s ethos seems effectively antithetical to GNU ( and Linux and *BSD… )
Freaking cool seeing a mainstream microkernel-based OS being born before our eyes though.
On Android the only GPL piece left standing is the kernel.
With Fuchsia that “problem” is gone.
Not true, Android uses OpenJDK which is also GPL.
Last I checked, Android uses Harmony, not OpenJDK. At least looking through the AOSP repo shows no signs of the latter.
It must have been a long time ago you checked, as Google switched to OpenJDK already for Nougat.
It is really not too hard to research that fact either, either by googling “Android OpenJDK” or by visiting https://source.android.com/setup/build/requirements
Edited 2018-04-13 16:01 UTC
To be fair to anevilyak, this is a fairly recent change. They used Harmony up until Nougat, at which point they switched because:
1. Harmony is now retired and is no longer updated.
2. It ensures Nougat and future versions of Android are safe from the threat of additional Oracle lawsuits.
Imo they never avoided OpenJDK because of the GPL… They simply didn’t see any need for it. It didn’t exist when Android was originally built, and they had no desire to be Java compatible from a TCK perspective so they just rolled with what they had. Nothing changed until the lawsuit – that is what prompted them to switch, not an avoidance of the GPL.
In fact the GPL is basically why they switched to it, as now they can actually claim compliance with a license specifically issued under the entity (Oracle) they are trying to gain protection from.
I agree with everything you say.
Nougat came out 18 months ago and the switch was announced Jan 2016. So I think it is a bit embarrassing to go so far to ‘dispute’ a simply stated fact this way without checking. Same with the people who vote on comments here^aEUR|
Edited 2018-04-13 19:53 UTC
Sorry if I came across wrong (not sure?)
I wasn’t trying to correct you or anything, everything you said was accurate. I was just trying to add a why to it, since it is confusing as hell and not everyone knows the sordid history of this mess.
Also realize my idea of “recent” is very relative. I just meant that for most of its life Android did use Harmony. They have been using OpenJDK for a few years now though, so yeah, not really that recent
Edited 2018-04-13 21:38 UTC
No sweat, I have to say sorry because I didn’t want to critizise your comment at all. I was just bummed out by the previous comment in the chain, and people voting down my factual stating comment down to zero.
So my critique was not about your comment.
Sorry for the confusion, I am happy with your comments adding detailed knowledge to the matter.
It uses cherry picked parts of OpenJDK, not all of it.
In any case, even if I missed it, that is not where Android’s value is.
The Java and native code related to what Android actually is, is under Apache license.
After pushing GCC out of Android, just like Apple did before, the kernel and Java runtime library are the remaining GPL components, all the other layers use a mix of Apache and MIT licenses.
No, it doesn’t use cherry-picked parts.
And the Java runtime is an extremly crucial part of Android. The virtual machine (ART) is only part of it.
Edited 2018-04-14 12:23 UTC
Sure it does, only blind Google advocacy without Android development experience can state such thing, easily demised with facts.
To make it easier on you, lets stay with OpenJDK 7, released in 2011, later versions are just too easy to find missing features.
These are the APIs available in OpenJDK 7,
https://docs.oracle.com/javase/7/docs/api/
These are the APIs actually available on Android
https://developer.android.com/reference/packages.html
If you wish I can provide you a diff tool that compares both sets of documentation.
To make it easier on you, here are some examples:
* java.nio.file (added in API level 26, 2017)
* java.nio.channel.FileLock::acquiredBy (added in API level 24, 2015)
* java.security.CryptoPrimitive (added in API level 24, 2015)
* java.util.BitSet::toByteArray (added in API level 19, 2013)
* java.lang.invoke (added in API level 26, 2017)
I can also provide some logs from Android Gerrit, that shows that Google just doesn’t take stuff from OpenJDK as is
https://android-review.googlesource.com/c/platform/libcore/+/364192
https://android-review.googlesource.com/c/platform/libcore/+/276617
https://android-review.googlesource.com/c/platform/libcore/+/616451
Plenty more to search for if you care.
Then you can git clone https://android.googlesource.com/platform/libcore/ and search for Android-removed: and Android-changed: entries.
What makes Android are the android.* packages, the Support Library and Google Play Services, not the pieces that they have taken from Java^a"c.
Did you really just call me a (blind) Google advocate just because I disagree with you in a technical discussion?
Do you think it is healthy for the discourse these days that people reduce each other to being aligned with big tech companies out of the blue?
Did you ever read me defending Google’s approach of proprietarizing core Android APIs with the Play Services? Or that I do not see the value of copyleft license models? I publish my software under GPLv3 myself. I also worked in my local communitys by organizing “Android rooting parties” to help people regain control of their devices and install libre software alternatives on them.
All I said is that (a) the Linux kernel is not the only software shipped with Android that is GPL-licensed, (b) Android’s current Java implementation is based on OpenJDK, and is not merely cherry picking some parts of it.
Is there anything “Google” in what I had said?
Now I don’t know how you define “cherry picking”. But I define it, in git fashion, as in taking small parts of code out of a larger codebase. This is not the case here. OpenJDK is the _foundation_ of the Android Java ecosystem. And a slightly incomplete JDK is not a “cherry picked” one to my understanding.
You go on to show proof that Android’s JDK is patched. Big deal. Did you actually read the patches that you linked? They are functional patches. One of them is reverting an older patch to vanilla OpenJDK. What is so special about patching the software you are using to fix problems? Isn’t this a crucial part in the free software model? Doesn’t it show, by the way, that Google is actively contributing GPL-licensed code?
The android.* packages are based on the JDK. They would not work without the primitives etc. defined in the JDK. You cannot write anything using android.* without having a JDK. Good luck using android.text.Editable without having java.lang.CharSequence. However, you can ditch the OpenJDK shipped with Android for vanilla OpenJDK and it will still work. It is even recommended to developers for Android versions where OpenJDK is not part of the distribution.
I don’t mind you shitting on Google or more precisely, on how they are evolving Android into a direction where they tighten their control on it and make other vendors depend on Google. I think your claim that Google is crusading against GPL is dubious, but well if you have good points about it I am inclined on reading them and getting convinced. However you should stick to the facts and if somebody corrects you on a technical basis, you should not go ad hominem paired with imputation.
Sorry if I offended you, that was a bit over the top.
I just get a bit out of touch given how Google has contributed to Java fragmentation.
I use cherry picking as in Oxford dictionary, not whatever it means with git.
https://en.oxforddictionaries.com/definition/cherry-pick
It is definitely the case with Android, given that they only have taken parts of OpenJDK, not 100% of it.
You cannot take a random Java application that runs without any issue on OpenJDK, and have 100% guarantee that it will compile without errors on Android.
Sure I did read them, if you go through the comments, or read the file diffs there are small hints of differences in behaviour.
Google’s actions prove their dislike for GPL, they created Bionic while “cleaning up” Linux kernel headers, dumped gcc out of the NDK, created their own patches to be able to compile Linux kernel with clang and now Fuchsia does not have any GPL piece on it.
Gcc was never IN android in the first place. You don’t compile on the device, and the license of the compiler doesn’t matter anywhere
Absolutely agree with you that it is fascinating watching this grow. I really hope it gets some traction, as we could really do with seeing a microkernel-based system in the mainstream.
Always seemed a shame to me that MS seems to have dropped there research with Singularity and Midori – which combined Microkernel design with managed code to give an architecture that could be really secure without compromising performance.
Never understood why Minix3 never got any traction, even though the millions injected by EU. They had to “migrate” to (net)BSD to start getting a little bit relevant.
It has got traction, it’s been used in the Intel Management Engine, which is the sort of target the research had in mind (deeply embedded, reliable OS).
Minix3 failed as a desktop OS because it didn’t fix a problem on the desktop. Linux was already there, and reliable enough that Minix’s uKernel design didn’t help. To be honest, I’ve tried Minix on the desktop and it hasn’t even been as reliable as Linux, with regular hangs as kernel processes crashed and didn’t seem to come back to life as promised. Which is not a problem, it’s nothing more hours couldn’t fix, and I went in well aware of the potential limitations.
Minix never failed as a desktop. It’s just that it was never given a chance. When Minix was first created it was proprietary and pretty expensive (I believe it was $65). On top of that you had to buy the books and there was a developers fee if you wanted to make software on Minix. Minix was mostly used for studies on operating systems, not necessarily to compete with others oses at the time. Even Andrew S. Tanenbaum said it himself he was content with 386BSD. But development for 386BSD was halted because of a copyright infringement and with Minix being closed source and expensive, the only option left was Linux. Linux was free and open source, there was no fee to make software for Linux, and it was not bogged down by litigation, so developers flocked to Linux. By 96 Linux popularity took off and it never looked back. Remember the operating system market revolves around network effects. Developers port their software on operating systems that are well known. The three most popular operating systems are Windows/MacOS/Linux and that’s where most developers and hardware manufacturers make their products on, although FreeBSD is getting up their in popularity. By the time Andrew S. Tanenbaum made Minix free and open source in 2000, most developers were pouring all their support towards Windows/MacOS/Linux. Also Andrew S. Tanenbaum hates Linux, he likes the BSDs.
What do you imply by specifying “hating Linux, liking BSDs” ? Licensing model ? Technological choices ? Architectural debts ?
MINIX 3 is relevant, just not in places you’re likely to realize it’s being used. The Intel ME uses it, and most of the other big applications are tight-embedded systems requiring very high reliability and usually soft real-time performance. In terms of competition, MINIX 3 is mostly competing against stuff like Contiki, RTEMS, and ITRON, not BSD or Linux, and definitely not Windows (except maybe the new Windows 10 IoT platform, but that’s not really prevalent enough to be considered competition, especially compared to ITRON or RTEMS).
Linux has never really been much of a competitor in that field actually (BSD has been for certain applications, but not much), just like MINIX has never really been targeted at ‘conventional’ computer uses, originally being a platform for teaching systems-level design (and having looked at the source code, it far exceeds Linux in this respect), and then evolving into a research project.
Are Contiki and MINIX really in the same category / competing with each other? The former runs on Commodore 64 / really low-power microcontrollers…
Probably because a pure microkernel with managed code WOULD compromise performance. It’s basically impossible not to. Any claim to the contrary is purely marketing spin.
Electrocom Automation supplies high speed letter sorting equipment to all major US Postal Service hub cities around the country (at least one per State). They’ve been running on QNX 24/7 since 1990. One such machine, the Delivery Bar Code Sorter (DBCS), can sort 35,000 to 40,000 letters per hour. I doubt that any .NET or Mono is anywhere in the stack, however, since these systems predate their managed code by over a decade.
Edited 2018-04-13 22:27 UTC
Correct me if I’m wrong, but isn’t Minix already a mainstream microkernel OS? It’s used in most, if not all, Intel CPU’s.
If you go down that path… What about update ability of those Intel chips with an open source implementation of the said firmware ?
A highly modified version of MINIX is run on many Intel CPUs. That’s not the same as MINIX itself being run by a user. Calling MINIX mainstream is quite a stretch.
Mainstream among companies (or company, in this case but Intel is a gigantic one so it counts for lots of market shre!) is still mainstream. Just like how Linux is mainstream on servers.
Edited 2018-04-13 15:27 UTC
Calling consumer technology mainstream is just as much of a stretch. Most technology is designed to do some sort of work, out of sight of the enduser. Software can have success without the consumer.
—
Perhaps it would be better to say that “Fuchsia is not Plan 9”
Edited 2018-04-13 11:27 UTC
Beauty of the current state of android was the ability to unlock and rebuild the system to remove all of the Google spying with this new kernel google can lock the phone OS tight and only ship it to OEMs killing the ability for custom privacy enhanced builds.
And people are calling this a good thing well played google, well played.
Now lets fuse this microkernel with AmigaOS4
And get a nice simple GUI and stuff !