Android removes much of Fuchsia-related code as Starnix project progresses
9to5google.com
9to5google.com
I see NIH is growing even stronger at Google. Why not build on gVisor, rather than re-implement everything from scratch?
[1] https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/s...
[2] https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/s...
I'm not sure it's strong logic to re-use something else because it implements linux syscalls, the hard part is what it does after it receives the syscall.
gVisor provides a linux syscall interface to the guest, but ultimately calls a linux syscalls when it needs to invoke something in the host. That obviously doesn't work for a linux-on-fuschia compat layer. I guess you could re-use the guest side, but if gVisor wasn't written for pluggable backends it's probably more work to do that refactor than just build a separate tool.
This isn’t actually true. gVisor contains full implementations of Linux syscalls and only relies on host syscalls being the same for some interoperability features between sandboxed and host applications. It would be completely possible to port gVisor to a non-Linux operating system.
When the host isn't Linux...
gVisor is used in a lot of places[1] that require more performance than a clock. I'm not saying you can't achieve more performance with C++/rust, what I'm saying is that this probably isn't the primary concern.
1. https://cloud.google.com/kubernetes-engine/docs/concepts/san...
https://gvisor.dev/docs/architecture_guide/performance/#netw...
Network performance in gvisor is awful and, by gvisor's own documentation, this is a matter of "implementation costs" ie: it is how gvisor is written, not gvisor's fundamental constructs, that makes it slow.
The rest of the benchmarks are notable as well, there are a few other places where the implementation is called out as being a problem.
1. It's designed to run on Fuschia, not Linux
2. Go FFI is very inefficient, you can't just "extend" a Go project with native bindings and get the same performance wins
3. Hopefully the gvisor team learned the obvious lesson that Go is not suitable for this kind of work
You mean you'd like to read a source to back up that statement.
Nothing is required...
There are links between Silicon Valley, Google, Rust and their ideology.
The core of the technical leadership on Fuchsia were, I believe, Android refugees so they had a very Android-centric way of looking at the world. The two premises for Fuchsia seemed to be:
1. There is no way to remove devices drivers from the Linux kernel. That goal was seen as desirable in terms of improving reliability, how long devices were supported for and the time taken to roll out updates. Upstreaming driver changes was something phone manufacturers just didn't do and didn't want to do. Linux has no stable ABI for device drivers; and
2. The Android ecosystem itself needed a reboot. This one is harder to define but, for example, you had duplication of services between the all-but-dead AOSP and Play services.
Remember these are statements of fact. These are my impression of the beliefs of Fuchsia technical leadership.
Google had always had hopes that there would be a healthy ecosystem of phone manufacturers. For awhile there were but now? Now it's really just Samsung. Samsung and Google, much like the Wintel alliance of Microsoft and Intel years ago, was an unhappy marriage of convenience. Samsung had tried (and repeatedly failed) to make their own OS. And Google didn't like Samsung being the consumer face of Android.
So the question I raised was: given that Samsung in an unhappy spouse in a loveless marriage of necessity, how are you going to convince Samsung to switch to Fuchsia? I still see no answer to that.
Maybe something interesting and useful will come out of Fuchsia eventually. I for one am not holding my breath however. It screams of being the pet project of some very high level engineers.
Confused, aren't there a ton of phone manufacturers? Sony, OnePlus, Asus to name a few off the top of my head. In what sense are they all "unhealthy" except Samsung?
> For the first time in company history, OnePlus passed the $1 billion mark in revenue and became profitable. (2018)
[1] https://www.androidauthority.com/oneplus-profitable-830348/
Obviously this is not the case at all in the android market.
Apple 44%
Samsung 16%
BBK Electronics 16% (Oppo/OnePlus/Realme 8%, Vivo 8%)
Xiaomi 8%
Others 16%
That's according to Counterpoint Research [1]
Profitability appears to be even more skewed in favour of Apple but I don't know the exact numbers.
It would be interesting to know what's included in that 16% others category as that's where any challengers would be coming from.
[1] https://www.counterpointresearch.com/global-smartphone-reven...
https://web.archive.org/web/20160423202414/http://www.dg.gov...
Unfortunately, I don't know what the authoritative source for company information is in China. It can't be blog posts and media reports I suppose.
Samsung is at about 35%, BBK is next at about 23% (Oppo+Vivo+Realme are subbrands of BBK as is Oneplus).
BBK is a bit the 'Luxottica of Android' if you will with several brands under them: https://en.wikipedia.org/wiki/BBK_Electronics
Plenty of other people care about market share (not to mention you're deliberately ignoring all the non-phone Android ecosystem that has established).
Apple doesn't dominate the number of widgets, they dominate in money.
(Sure they're owned by the same people, but Apple and Google are also owned by the same people - American 401k providers.)
What Desktop Mode in Android are you referring to, and what parts of it came from Samsung DeX code? There's nothing really in AOSP that resembles DeX.
>WearOS is finally merged to Samsung's OS
Wear OS is closed source.
This seems true of so many Google projects lately, big promises that don't deliver and get shelved in a few years.
I can guarantee you that somewhere in google is a team of 3 getting shut down for making 100MM a year with a boring tech focus. Meanwhile Fuscia continues unquestioned.
The problem with creating a new OS is getting people to write apps. It's not really justifiable if your new OS doesn't take a very different approach to how apps are written and yield much better results as a consequence. If you build a new OS and rely too heavily on emulated Linux apps, then what is your value proposition? You're effectively admitting defeat up front by saying there's no real reason to write a native app; that running Linux apps is good enough.
With Fuschia this problem is especially apparent because it's not really obvious from reading the docs what its value prop really is, or how the UX of a native app differs from any other platform. Successful operating systems don't normally have this problem. You could argue that Linux was an exception, but there the value prop was being an open source PC UNIX and that price/compatibility point was enough. Other platforms though, like macOS or Android, needed to have a very clear offering up front to get developers to care, as well as a large library of first party apps.
I agree with you though that people are mostly writing to abstraction layers. That's where the action is, which is why it's curious that Fuschia's approach isn't clearly a ChromeOS style "portable abstraction layer + shell to invoke abstracted apps". They use Dart and Flutter for the UI so in some ways it is, but then they have the whole component model and Fuschia specific APIs.
Jeff came to me one day with a mapreduce he'd written and was very proud of. I spent a few months working on it and ultimately realized it was worthless. But he did make us patent it.
> Upstreaming driver changes was something phone manufacturers just didn't do and didn't want to do.
This is absolutely true. However - and this makes no sense to me - Chromebooks apparently do upstream everything, even for ARM models. Any idea what went right there?
> you had duplication of services between the all-but-dead AOSP and Play services.
My understanding from the outside is that Google likes to pretend that AOSP is sufficient for antitrust reasons but really wants to control everything directly; you can't solve that by creating a new product unless the hope is that nobody cares that the "new" ecosystem doesn't get examined by the same standards.
> Remember these are statements of fact.
I'm assuming you meant to type "not" there?
> Google had always had hopes that there would be a healthy ecosystem of phone manufacturers. For awhile there were but now? Now it's really just Samsung.
Samsung is certainly the biggest, but it's hardly the only name in town; https://www.appbrain.com/stats/top-manufacturers puts them at ~34% with the rest in the long tail.
> This is absolutely true. However - and this makes no sense to me - Chromebooks apparently do upstream everything, even for ARM models. Any idea what went right there?
>> you had duplication of services between the all-but-dead AOSP and Play services.
> My understanding from the outside is that Google likes to pretend that AOSP is sufficient for antitrust reasons but really wants to control everything directly; you can't solve that by creating a new product unless the hope is that nobody cares that the "new" ecosystem doesn't get examined by the same standards.
This might be why Chromebooks upstream and Android doesn't. ChromeOS doesn't have the same market context as Android, so Google doesn't have to play the game of avoiding anti-trust. They can be deeply involved in defining the acceptable hardware and requiring things get pushed upstream or not used. Android hardware on the other hand is more chaotic, and Google doesn't want to get hit with the anti-trust stick, so they're not willing to do very much to disturb the ecosystem. So they're stuck with this patently absurd system where SoC makers deliver an android build with a custom kernel to device manufacturers, and the kernel never gets updated, but Android keeps requiring new kernel features for their userland updates, so nobody can get those anyway; and there's a new project to make updates feasible for longer every two to three years, but it never actually drives the marketplace forward, because it only addresses new phones, but will be abandoned in three years anyway.
At least, that's what I can gather as an outsider.
Google is making money hand over fist from so many different angles that they can simply afford to.
Google Play makes them more profit than some major phone manufacturers do off all their devices sold.
So if there are engineers at Google who are willing to own something like getting high quality Chromebook support in the larger Linux ecosystem, the money is there.
Compare that to traditional phone manufacturers that are:
- reluctant to spend a single dime where they don't have to
- actually benefit from obsolete devices
- have trouble attracting in-house talent causing them to outsource work in a way that is not conducive to high quality upstream-able code...
At the end of the day it's money.
If intel, amd or others can make it so that their very complicated silicon can run on top of open source code, it should be possible for them as well.
Granted, the phone manufacturers would probably further customize the kernel, however, the phones could still run on top of code that is 99 percent upstream, and they could both spare a lot of dev resources and stay closer to upstream.
No, the problem is with other companies not upstreaming drivers, not Google. Like Qualcomm, which has a phone chip patent/monopoly, and used forced obsolescence (refused to update drivers) to prevent Google-cobranded phones from working with new OS versions.
I never worked at Google either - but having an evergreen Google Play service seemed necessary to overcome the greatly exaggerated Fragmentation problem by back-porting what had been OS features to older Android versions. Previously, Android OEMs and their vendors - especially Qualcomm - had no incentive to provide driver updates for already-sold units, so that tended to never happen. Cue the tech press, Apple and developers loudly bemoaning "Fragmentation!!1!"
Isn't the ChromeOS HW platform support built at Google? At least in many cases they seem to first add support for a HW platform (board + SoC) under a codename to the tree and then various vendors ship products based on that HW platform.
Could an open-source QNX accomplish all of Google's goals?
Given that QNX cannot be killed, and the cost to Google in attempting to do so (or enacting major change for legacy customers) would be catastrophic...
Why not buy a working microkernel? Are there other commercial microkernels that are more attractive?
https://en.m.wikipedia.org/wiki/QNX
Maybe Samsung should buy it, and put themselves in the driver's seat on Android. (They did buy Joyent, and SmartOS seems fine.)
QNX is in 215 million cars.
They've made less than 10 $B acquisitions, with Motorola Mobility being the most expensive at 12B and was for patents.
I think if Google acquired BB for the QNX business that they wouldn't give it adequate attention and would run it into the ground.
As in do they charge per unit sold? Or have a flat license? Do you know what would be aprox costs per unit for a startup say for QNX Neutrino?
Which cars is it deployed on? It would be good to keep an eye on recalls and reported software issues.
Why?
Everything which needs hard-real time in a phone already does that at the firmware level. I fail to see what is that latency sensible in the rest. If what you want is a faster phone, a hard-real time kernel is not going to give you that. Hard real-time just means you have strong garanties on time of execution (either through return or through failure) it does not necessary means these times are short.
Java on Android is not slow anyway.
Or maybe a clean slate from the mistakes of existing legacy devices and not inheriting the old cruft found in kernels like Linux or in full OSes like QNX that are not designed or optimised for use cases such as smart-devices, IoT, desktops, etc.
It seems like Google has had enough of tolerating the giant contraption that has strangled them for years with using Linux in Android, and ChromeOS and would want to purse a new approach similar to Windows, and macOS with Fuchsia and creating an ecosystem of apps written in Dart, and using Flutter.
Nobody really knows, as Wear OS remains closed source.
So Samsung did what Samsung does best and saved face by convincing Google to say WearOS 3 was a collaboration between Google and Samsung. Samsung probably did contribute code, but there is no Tizen in WearOS nor were these OSs "merged" like some people claimed. Samsung abandoned Tizen because they saw the writing on the wall. They were spending millions developing an OS that wasn't growing for an app ecosystem that was dead.
For example, even Nokia branded phones get more updates.
Samsung is pretty good with security and even OS updates nowadays.
The problem IMHO isn't driver source code availability itself, rather their often shoddy quality and the fact that SoC vendors drop support for updates very fast.
What happened instead was that, at least in the embedded world where the customers are not the mass market directly that votes with their wallets but "suits" without much technical knowledge, SoC vendors came up with bundling a private fossilized fork of the Linux kernel, u-boot and a bunch of tooling and calling it a "BSP" (board support package).
Ashmem is especially great example because upstream, having refused to take it for so long, ended up pulling their own NIH when they made the exact same thing but called it memfd.
At least with a new kernel they could also fix various mistakes that have long since been enshrined in Linux. Like the dreadful approach to permissions & sandboxing. Not that Linux has anything it could easily do here, that's the curse of legacy. But still, it's a fundamentally wrong approach to how systems are used today vs. 50 years ago when many of these semantics were established.
Android's Project Treble was already supposed to (partly) fix that, and it didn't. Partly because of OEMs sure. But, and most importantly, because Google removed the support for versioned RPC merely 3 years after its introduction (audio HAL 2.0 introduced in Android 8, got removed in Android 12, simply reverting the deletion commit is enough to "fix" it).
What does this tell? This tells that Google themselves aren't structurally ready to support hardware for more than 3 years. Why would Fuchsia be any different? In all likelihood, they'll also deprecate versioned ABI every 6 months, and drop old support after 3 years, which will lead to the exact same state.
At this stage, this is a managerial issue, not a technical one anymore. If Google wants to do this (upgrade devices independently from OEMs), they first need to stop obsoleting code every time someone gets a promotion, and they need to actually try what they make, not just do things that are theoretically perfect [1]. (to the best of my knowledge, there is exactly one Google team who managed that, which is androidx/jetpack/android-compat)
> Upstreaming driver changes was something phone manufacturers just didn't do and didn't want to do. Linux has no stable ABI for device drivers;
Chromebooks have most/all drivers upstreamed, and yet they never upgrade their kernels in production.
[1] And I could go on how Project Treble is architecturally beautiful, but is missing few small points that would make it actually usable, which is what my opensource project does, but I feel my message is already too diluted
What makes you think Samsung is a "unhappy spouse"? They save billons by having Google develop Android and spoon feeding them security updates each month all for free. Samsung can leave this relationship any time the want and they've probably though about it. Then they saw what happened to Huawei and Samsung fell in love with Google all over again. Samsung doesn't want to be Huawei-d, but they will be if they ever leave Android and the Android ecosystem.
>how are you going to convince Samsung to switch to Fuchsia? I still see no answer to that.
Why wouldn't Samsung switch to Fuchsia? If Fuchsia really is the next generation of Android then it seems logical to hop on that train or be left behind and trying to maintain a sunset OS with limited, if any, support from Google.
My only two use cases are photo album and playing YouTube music. Both of them are features, fully integrated with whole google ecosystem and TBH, just embarrassing.
https://9to5google.com/2022/06/23/google-fuchsia-nest-hub-ma...
So this looks more than likely that Fuchsia is progressing to first replace ChromeOS, and then in the next couple of years to replace Android, as I predicted years ago. [0]
Far from an 'experiment' as wrongly predicted by many others 4 or 5 years ago. [1]
It also wouldn't solve the fundamental problem of ChromeOS which is that it doesn't have it's own apps (there were Chrome apps but they were deprecated) and only offers a somewhat imperfect experience for linux and android apps.
To overcome that, Google would have to already have worked out a new approach for native Fuchsia apps to commit to it (which would probably mean committing to Fuchsia replacing android) and I'm not convinced Google is capable of making that type of decision in its current state.
Microsoft attempted to do it with WSL.
Then abandoned the idea and went with a VM called WSL v2.
I have no solid proof but I believe at least one of the factors were https://github.com/microsoft/WSL/issues/2028 https://github.com/microsoft/WSL/issues/3031 -- the ptrace() syscall is not a single syscall but more like the infamous rabbit hole which you have no idea the depth of.
It's functional enough that it's hard to tell at a glance.
Almost certainly yes. Microsoft almost never fully abandons projects, but they keep them in limbo for years and have no qualms about claiming they are still working on them. I bet they never officially stopped working on WinForms either.
> I presume this is wontfix for WSL1?
> Yes WSL2 won't help your use-case presently. A feature requestion along the lines of "hardware clock passthrough" could be submitted under a different cover.
It’s likely the feature freeze started even earlier and I just never noticed.
Also see WSLg (GUI), which only works on WSL 2. I think it’s clear that WSL1 is in maintenance mode.
For other issues, well, I'm willing to believe it either way, but I think the last couple comments on your example link make it clear that this feature doesn't really exist on WSL1 or WSL2.
WSLg was launched over a year ago
> I think the last couple comments on your example link make it clear that this feature doesn't really exist on WSL1 or WSL2
They made it clear that this syscall will not be implemented at all in WSL1. With WSL2 on the other hand, they are willing. That’s what a feature freeze looks like.
The "fixed in wsl2" tag would be more damning but it's not on many newer issues and looking at a few it didn't seem like it was generally used as a resolution, I think? I found one issue directly saying they weren't dismissing it because they're done with WSL1 but because it's a minor TCP difference that the code should be less fragile about.
[1] https://fuchsia.googlesource.com/fuchsia/+/2940d6f300031e852...
> Unfortunately, WSL1 was hampered by the performance characteristics of NTFS, which do not match the expectations of Linux software.
This is true but whether this was the cause or one of the causes to abandon WSL is impossible to know unless Microsoft tells us. Back in the day they said they are working on NTFS improvements but it needs assistance from the Windows side. Who knows.
And for things like ptrace they don't have to support it at all. As long as Android Studio knows how to launch GDB or whatever on a Fuschia-based device, they're good to go. It's not like any app is going to be relying on ptrace otherwise, particularly since of course the ability to attach to anything else already isn't allowed.
> What is the Starnix IT website? > Searches “Starnix” > Oh no, the first result isn’t what I’m looking for > I’m such a dum dum that I won’t search “Starnix IT”
By the way, they have 2 employees.
...lawsuits
> By the way, they have 2 employees.
What difference does that make?
We've been advocates of free and open source software and active members of the community since the early 90s. We co-founded the non-profit Linux Professional Institute in '99 and are still actively engaged daily with the organization and its mission. Feel free to reach out to our info@ if you'd like to open a dialogue.
As for our website, well... that's what you get with a tech company run by tech folks :)
-The Starnix Inc team
This line is hilarious to me because when SV learned that HarmonyOS could run Android OS/apps, the common refrain was "HarmonyOS is a literal android clone!!!" But when a SV corp does it, it's "ambitious". And one can only imagine the hagiographics if Apple was the one running Android apps natively on iOS...
SV needs some deep, deep introspection if it is ever going to get ahead of the curve again.
The end result isn't what's ambitious. Linux can do this today, and run Windows applications at the same time. What's ambitious is getting different APIs to work together well on a system that's designed radically differently. The overlap lies in Flutter (the "we'll ship our own GUI toolkit with the application code" approach), not in the underlying framework.
I imagine Apple could quite easily get Android apps to work on iOS if it wanted to. They need a wrapper for Linux calls, which they can borrow from Google in this case, and they need part of the Android framework, which can be made to run on the wrapper. It wouldn't take more than a year for the first proof of concepts to come out, I'd reckon. Apple just has no reason to want to run Android apps because they're not the ones that are in desperate need of market share like HarmonyOS.
While in this case, they are rewriting the kernel (but I agree that it looks like it'll remain normal Android for the upper layers)
Why is native android support required, when for example they could be emulated?
Are developers going to really release apps for a fuschia phone without testing? Recall this is a space where every device is different. If developers and going to test and modify their code, is too hard to ask them to recompile using a fuschia tool chain?
Google has the same issue Microsoft has now, where everything needs to be compatible with ancient apps written for Win95.
Another g project in the grave.
Dart itself is another example: it started similar to Typescript, but Typescript quickly grew to surpass it in every way. Because Typescript eagerly learned from modern programming language theory, while Dart stuck to Google's "try to make everything like 1990s OO" approach.
Dart is one trick pony.
Chrome didn’t even include the Dart VM. It was only available in special “Dartium” builds because the Chrome team didn’t want it either.
https://news.dartlang.org/2012/04/dartium-for-windows-now-av...
How exactly? Is Dart, and Flutter right now getting sunsetted?
I think it is even clearer that your comment is total nonsense.
Yes, in Bizarro world.
If they only wanted to cut ties with Oracle Java and have an unrelated OS, they'd adapt Linux. A number of companies are already working on it. But, that won't let Google own the entire chain from hardware to software in order to screw over customers.
Zero innovations in the mobile world for easily a decade. Because companies like Google are too busy running VMs on mobile.
a) Linux doesn't have a stable driver ABI.
b) Manufacturers will not upstream their drivers. It's been years and they simply won't.
Google have been beating against this for years and getting absolutely nowhere. It's the same thing that Linux has ongoing issues with, and have made significant inroads with, for things that aren't tablets or phones. But manufacturers do not want their drivers to be public.
The reasons no longer matter, decades of compromise has resulted in the hardware partners shifting not a single ioata.
Doesn't modprobe/insmod of a driver bring it into a strict GPLv2 environment?
If so, the Software Freedom Conservancy needs to "busybox" the recalcitrant OEMs.
I can dump a bunch of ugly driver code into an old version of Linux, backport some features that I care about from newer kernel versions, and then give you a tarball with the sources and a GPLv2 license. Is that compliant? Yes. Is it gonna get upstreamed? No.
Not better because I don’t think the drivers should be upstreamed, to be clear. Better because it leads the manufacturers to that conclusion on their own.
Google has suggested that they were leaning in that direction in the past, and the response was not encouraging. Think about how many manufacturers don't ever release updates. The software is seen as a neccesary evil, not as part of the marketing equation.
Consider the usual suite of apps that need SafetyNet to work (Snapchat, Netflix, Pokemon Go, Super Mario Run, McDonald's, etc.), then throw in a few more that need Google Play Services for some reason, and don't even work with microG (Hyundai BlueLink, EnelX JuicePass, Lime, PayPal, Roblox, etc.), and there'd be a lot of unhappy customers who want to use those apps but can't.
And did that work for... anyone? Ever? At all?
Patches that are acceptable to and accepted by upstream is a different story.
It's committing the time and resources to get it in a good enough shape to at the very least be submitted upstream.
Embedded device drivers are often developed by cutting a lot of corners, copy-pasting huge amount of code, using magic register addresses that are undocumented and targetting old kernel versions.
Even if they make the code available, there is not much the kernel maintainers can do.
By the time the device hits the market, the driver developers have moved on to the next project in the pipeline. There is never the time to clean up, rebase on top of master, submit upstream properly, and address code review (of you are lucky to get a maintainer to even look at your code).
The last time I looked, RedHat was packaging a version for Windows.
Yes, my corporate IT stagers won't use it, but the Java corporate licenses are not as necessary as you might think.