I'm sorry but his "proof" is mostly just puns. Sometimes OSS projects are given pun names simply for laughs, not because of some deeper meaning. No doubt Google is researching new OSs, View Managers and development frameworks. (Every company that large does.) But I think it's too early to call it a potential successor; architecture takes a long time to change.
They've already replaced Dalvik with ART for bytecode and it was mostly transparent from what I understood.
But popping up with a completely new platform API without any backwards compatibility would be very bold and risky. There would have to be a good compatibility story there.
Also there is talk in the article about a POSIX layer. Now that's easier said than done. But it is Google we are talking about so they certainly have the manpower and resources to try.
It isn't too hard to do Linux ABI emulation. The interface there has mostly been stable for the last several years. That would enable just using the same userspace as Linux distributions like Android.
They did not. ART is here on-device architecture-specific and version-specific; Dalvik bytecode is still the portable bytecode used in all APKs. If they had replaced it, we wouldn't still be dealing with the 65k methods limit for example.
A new runtime is very different then a new framework/API/OS. The former doesn't necessarily require code changes (dalvik -> ART did not), the latter requires new everything.
Exactly. This sort of switch seems for me also a good way to increase the amount of bugs by a large scale. It may only work for very specific hardware I think.
Job security and Apple-ish custom OS may long-term reduce support burden because Linux is like OpenSSL: a giant refrigerator, stove, oven, typewriter, glass kiln, laundromat kitchen-sink. It will take a very long time to reinvent the wheel and also deliver a PG "quantum of improvement," but there are plenty of Alphabet employees to do it. Also, similar Apple, it's an OS they control so there's less rejection / ignorning of Google's desired direction as with FLOSS.
You grossly overestimate Googles ability to support an OS on multiple platforms. Do you remember the why Samsung Galaxy Nexus was abandoned?
Apple supports iOS on two platforms (32-bit and 64-bit A-series). Microsoft who has been in the OS business much longer than than Google only have resources to support Windows 10 Mobile on a handful of carefully chosen Qualcomm chips.
So basically the only way this could work is if Google would create their own SoC and mandate Android vendors to only use that SoC. I don't think Samsung would like that too much.
That's a given. Google also needs to control the hw platform to be successful. Open platform equals shoddy service/product because it would require adding a Microsoft-sized operation.
You wouldn't have to do it all at once. You'd emulate the Linux user space, and do everything incredibly gradually. Both APIs would be supported for many, many years. But they could stop advancing the Android API within a shorter timeframe.
I'm not sure the API can ever really be phased out due to the vast amount of legacy apps and libraries.
Besides I'm sure a lot of developers wouldn't be happy that their domain knowledge just went flying through the window. Even if that is a risk inherent in the job.
It was pretty obvious for some time, but it's good that the dots are connected and documented, for some kind of proof. Fuchsia OS will be huge, even if it's hidden in the background.
Samsung has its Tizen OS (previously Bada) for 6 years as alternative ready. If anything happens with Android that Samsung doesn't like the could ship new devices simply with Tizen and kiss Google good bye. It allowed them to get better agreements. I wonder why Samsung waited that long, they had a near monopoly around 2012 with Android devices, now several new chinese players entered the market.
Samsung TV and Gear, and some phones run already on Tizen and some older on Bada. (Tizen is Linux based, it's history is complex and some involvement was also from Intel and Nokia (before the MSFT inside job)).
The first iteration was not very impressive, but has since steadily improved.
If I had to choose between Android+Fuchsia and Tizen+Linux I might as well give Tizen a try. I am very impressed by their new watch, which IIRC runs Tizen.
That's not what 'fake news' means. It's perfectly clear the piece is speculative and it does not intentionally deceive (even if it turns out to be completely wrong).
It's in quotes. It even talks about the quotes. It's obvious from the tone of the thing it's not presented as real proof. And again, "I don't like the title" is not what makes "fake news".
Well this is quite a silly discussion then. If the author is using a title to mean something other than the words in the title in a manner such that the author still protects the veracity of the title, then what is the point of the title? All I can tell it is just a clickbait title.
And then I read the article and see that it is a bunch of speculation and making inferences from puns.
I don't think it's a great article or that great a title. But the fact that it's speculation is completely obvious. And that bit of punctuation is used to change the literal meaning of words, yes. It's just how English works.
I thought google would do something like this. They didn't want to fully embrace linux so they locked all the freedom of linux away behind restrictrions in android until they had a replacement and now they are going to try to drop gnu+linux anything GPL they can...
The new kernel is MIT/BSD... Welcome to Tivoization all over again.
I get the need for a better kernel, the gnu+linux kernel is out of control at over 14mil+loc, but why not put that effort into making a minix3 style microkernel that's gpl, or fix hurd?
I wish people understood the dangers of BSD style licenses, I hope this fails, the last thing we need is another proprietary OS on a device they built on the backs of the FOSS community but doesn't give back in a meaningful way.
We don't need another OSX, or android apps on your PC, we need someone with the money and will to fix the future of GNU!
> the last thing we need is another proprietary OS on a device they built on the backs of the FOSS community
If Google builds this kernel from the ground up and chooses to license it MIT, how is any binary derived from that "built on the backs of the FOSS community?"
They would likely keep a lot of the gnu userland. Let's not forget that google themselves are built on the backs of the FOSS community, without FOSS there might not be a google at all, certainly not an android.
There's nothing to keep, Android already doesn't use the GNU userland. They built their own libc (bionic) and the commands are all using busybox, IIRC.
The "danger" is BSD licenses are highly permissive, you can take BSD licensed software, modify it and sell it and never return the changes to the community or release the source to customers.
This means all the work of the OSS community is 'free' for corporations to take.
Eh you are not losing control with GPL. If you choose not to contribute back (when using a non copy left license), you are choosing to not provide control to anyone else.
This is a pretty simplistic explanation, but the BSD license doesn't require you to provide the source to customers. Essentially the argument is that companies will consume FOSS software without contributing back improvements to the determent of the community.
It is the norm because most FOSS is not licensed under the AGPL.
In any case, even AGPL does not require you to create a pull request, you only have to make the source available to your users, i.e. everyone who connects to your patched server.
This is true for GPL too if the copyright holders (authors or rights holders if signed over) decide to relicense. It has happened many times before. An example would be Nessus.
This wouldn't retroactively change already released code however.
Only the copyright holder can turn a FOSS project non-FOSS. This is true even for the strictest of copyleft licenses (and in fact has happened before).
"The new kernel is MIT/BSD... Welcome to Tivoization all over again."
1) Linux doesn't prevent tivoization, either; it uses the GPLv2, whereas anti-tivoization language was introduced in the GPLv3.
2) If Google wanted to make this proprietary, they could've made this proprietary. Why bother releasing it under an absurdly-permissive license if they wanted it to be proprietary?
"I wish people understood the dangers of BSD style licenses"
I wish people understood the dangers of copyleft licenses, particularly strict ones. The same exact rules preventing reuse in proprietary products apply to other FOSS projects as well. The GPL's "compatibility" with other FOSS licenses is a one-way street.
BSD-style licenses are literally as free as you can get (short of a license that's functionally equivalent to a public domain dedication). Any other license adds restrictions and reduces freedoms. Absolutely nothing about this project indicates "proprietary"; the license choice indicates the exact opposite.
Even if someone with the money and will somehow wanted to sponsor the development of GNU, why would that fix it? The same story will just play out again.
If you want this fixed, get someone with the money and the will to end the copyrightability of software. Or find a different solution to let users have control over their computing even when they don't have control over the OS - there's no fundamental reason why this should require legal solutions, as opposed to, say, cryptographic ones.
Will it be lightweight ? Will it have a shell ? Will it be customizable ? Will it have loads of third party applications ? Will it support non-Google hardware ? Will it finally bring serious OS innovation to the consumer desktop market ? Here is to hoping yes!
Googlers reach out him and confirm his guess is largely right? I can't believe it. The Googlers, please reach me and tell whatever you told the author. I can sign you an NDA.
