So starnix is a tool being worked on at Google (in Rust, [1]) to implement Linux's syscall layer and is validated against test cases [2] written for gVisor, also a program that implements Linux's syscalls, but one that is instead written in Go [3].
I see NIH is growing even stronger at Google. Why not build on gVisor, rather than re-implement everything from scratch?
Long story short: "gVisor uses host-native abstractions, such as threads and memory mappings, to co-operate with the host and enable the same resource model as native containers."
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.
> That obviously doesn't work for a linux-on-fuschia compat layer.
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.
Right, it would be silly to intercept the syscalls and just pass them on as is to the host kernel. If you just want to validate/filter things for security reasons, there are existing Linux APIs for that.
"implementing linux syscalls" ==> a million tools.
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 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.
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.
So maybe they should team up and work on replacing gVisor with something that shares as much code as possible with this new thing, which one would hope would be architected in a way to be able to help replace gVisor?
Not everything needs to be molded into a common base that serves the needs of all. Fuchsia has different constraints than the ones gvisor is written for and choosing to not try to morph gvisor into something it doesn't want to be is okay. Optimizing to solve problems should be the goal. Sharing code is nice to have where it makes sense.
The context here was that gVisor was a suboptimal way to solve the problem and they know that... so I am not sure in what point you are trying to make by saying people can optimize to solve problems unless you actually mean people can optimize to not solve problems.
Yeah, of course: if you are the kind of company that like a having tens of thousands of engineers working on five different versions of the same thing, with one team explicitly working on solving a problem another team has but without helping them as that's some combination of not-fun and not-promotion-worthy, you can of course do whatever you want.
That's false: you're assuming perhaps reliance on the garbage collector, and overlooking escape analyses (the compiler pass) enabling entire classes of Go programs indistinguishable, after code generation which obviates the garbage collector from user code at least, from optimized C++/Rust.
I worked at Google up until 2017. In the last year or two of my time there I had many conversation with some people who worked for or were adjacent to the Fuchsia team. It's hard to believe it's been 6 years. We're now talking billions (quite literally) of dollars later and all we've got to show for it is an OS for the Nest?
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.
I have never worked at Google, but some of this seems... odd from my perspective.
> 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.
>> 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.
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...
I don’t understand why it’s such a big hurdle to have upstream driver for a SoC - usually Qualcomm makes the chip and probably the drivers for a given chipset. They are the only ones whose responsibility it would be to have an upstream kernel driver.
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.
I think the Intel and AMD situation (and Cyrix and VIA in the past) is exactly opposite: open source was build on their public ISA. Qualcomm does not build SoCs for open source, they build SoCs and don't even want to open source the drivers for it, reverse engineering is too complicated or not worth (as SoC changes too often), so third parties cannot write open source drivers.
> Google doesn't have to play the game of avoiding anti-trust.
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.
Alright but think about mediatek. For Chromebook socs, they diligently upstream their changes. For android? They don't do shit. Someone is putting pressure on them for the Chromebook SoCs, but not for smartphone SoCs.
> 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?
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.
> 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;
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!"
One guess is that getting drivers upstream for Chromebook improves the possibility of external vendors making hardware. And Chromebook I seems to be supported for a long time.
The patches & drivers involved in most Chromebook peripherals are much closer to that of a PC in architecture than for the SoC's that go into phones. In this regard the patches are far less invasive, and thus more easy to match with upstream requirements.
My question remains, would this money have been better spent in buying QNX?
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?
Good point, I would like Google using QNX for their mobile OS, too, because of the Hard Real-Time OS feature. Or keep using Linux, but putting more effort on it, e.g. adding better NDK support, without relying in Java at all, a la iOS.
> Good point, I would like Google using QNX for their mobile OS, too, because of the Hard Real-Time OS feature.
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.
> Or keep using Linux, but putting more effort on it, e.g. adding better NDK support, without relying in Java at all, a la iOS.
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.
They could also have considered porting Minix 3 OS - https://en.wikipedia.org/wiki/Minix_3 - to the mobile platform. It is freely available with far less restrictive license than Linux. The only "production" ready and usable Linux based mobile OS currently is Sailfish OS - https://sailfishos.org/ . There is also Tizen OS https://www.tizen.org/ and LG's webOS - https://en.wikipedia.org/wiki/WebOS , though I don't know how how much Linux support is open to use in these two.
What an ironic statement given the deployments in High Integrity Computing, and being the production OS for NVidia's automative software (where GNU/Linux is used for development purposes).
> 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
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
Being a pet project of very senior engineer is not necessarily a bad thing. You know what? MapReduce, BigTable, Spanner, TensorFlow and tens of other important infrastructures were once Jeff Dean's toy projects. I don't think Google even can exist without them... Important thing is execution of the project, not its inception.
Those projects all had a unique and very successful take on the problem they were solving, though.
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.
Your points don't jive with the success of ChromeOS. It doesn't have "native" apps, and runs Android and Linux applications via VMs. No one writing applications targets ChromeOS as far as I know. They target chrome, steam, or Android. People don't write applications for OS anymore, they write applications for platforms which can be abstracted and ported to different OS.
Good point, but, you can argue that ChromeOS isn't actually the OS in that case. Linux and HTML5 are. ChromeOS is more or less a detail of the hardware that matters to admins who want/need total control and entirely cattle-like devices (the unique value prop).
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.
Fuchsia isn't necessarily targeting end users or application developers. Fuchsia exists to make products easier to build and maintain. Products are responsible for the app developer and end user experience.
mapreduce was a pain in the ass for anything but indexing. Very few if anything uses it any more (the MR engineers even had a CL to delete it entirely from google3). bigtable was hard to use, didn't have transactions, and was slow unless you put a ton of $$$ into it. Spanner... wasn't available for years to devs, until it had matured significantly. TF is just a piece of crap because everybody wanted to be associated with Jeff's projects and piled on their incompatible bits.
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.
This is a Truism of big anything. Once people are high enough in an organization and we’ll connected enough… their projects are unassailable.
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.
This comment and the parent got me thinking of the contrast between "privilege" and "merit" as useful ways to describe some of the difference between small company land and the likes of Google. How many product disasters could be attributed to the wrong people accidentally possessing or ageing into privilege? I wonder if Plus or Reader could be phrased in these terms
This is true, but there is a survivorship bias. Someone who sticks around gains credit from the work of those who left. Exponential growth in a core business means promotions for everyone. Someone who is considered "good" gets looped into key projects. After 4-5 years these become a self-fulfilling prophecy in some organizations, as "good" people get attached to the growth drivers.
> healthy ecosystem of phone manufacturers. For awhile there were but now? Now it's really just Samsung.
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?
It's the market that's unhealthy. Samsung and Apple are really the only big players at this point - Sony has sub 1% market share, Asus likely even less. OnePlus is owned by OPPO and together they have about 9% market share. Samsung is the only brand that is actually able to compete with Apple.
Still confused. So what would be healthy in your mind? The sheer number of manufacturers competing in the Android ecosystem seems like the definition of a healthy market for Android phones—in contrast with iOS where there's 1 player. Obviously you can't have 10 manufacturers each with 50% market share, so what sign of health are you looking for that deviates so strongly from the status quo?
In other industries a healthy fragmented market looks like the major player having 30 percent share, the second about 20, and the rest is divided among a dozens different competitors.
Obviously this is not the case at all in the android market.
Android seems [1] to be 34% (EDIT: or 23%? see [2]) vs. 15% for the top 2 players—is it really that stark of a contrast with 30% vs. 20% to call it unhealthy?
That kind of market share in volume is useless. The market share in value is much more relevant. Selling 100 usd smartphones is not the same as selling 1000 usd smartphones.
Maybe now only Samsung contributes to upstream Android project significantly, and makes advanced device. For example, Desktop Mode code is came from DeX IIRC, WearOS is finally merged to Samsung's OS, foldable phones and customizes are from Galaxy. Samsung is also a one of the biggest conglomerate that has own fab and makes SoC, display, battery, DRAM, NAND, etc... Possibly also Huawei contributed much but it was gone. I think Sony, OnePlus, Asus makes just good smartphones for consumer, but not contributed to advance futuristic Android ecosystem much now (Perhaps Sony Ericsson was big in early days). I'd like to see AOSP commit ranking by organization.
if that case the case why are they all still making android phones if it isn't profitable? My perhaps naive presumption is that they are in fact profitable but not a high margin market. If it was not a profitable venture they wouldn't make them
Getting drivers upstreamed is a political/legal issue, not a technological one. If google wants android drivers to get upstreamed, they can do so by throwing their weight around. Google can add a clause to the bottom of the license of the next android release that the licensee agrees to consider kernel modules a derivative work, and voila Google would have a legal crowbar to get drivers source released to the public.
In almost all cases the party who writes the drivers it's the SoC vendor which is either Samsung themselves for their own chipsets or for everyone else Qualcomm, Mediatek or one of the less popular upstarts (Allwinner, Rockchip). For everything used by Google and Samsung, both do open source the kernel modules. Almost everything by Mediatek leaks sooner or later somewhere.
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.
The core problem is Linux' lack of a stable internal API for drivers by design, which was thought of as an incentive for SoC and other HW vendors to upstream their drivers so that they need not care about keeping them updated.
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).
How hard would it be to stabilise that API? My line of thinking is : sure maintaining a fork of the Linux kernel would be a huge amount of work, but would it be less than writing a new one and then maintaining that?
Then the majority voice here would be crucifying Google for forking Linux. "Hurr durr embrace extend extinguish amirite????" See ashmem, binder, wakelocks, etc...
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.
This is what the Android Common Kernel is, it already exists as a Linux fork to provide a stable ABI. They are creating their alternative kernel Zircon so they can instead have a less free ecosystem like Apple, steps to do this may be deprecating open-source Android and continuing on with Google Play Services mandatory closed-source fork.
>given that Samsung in an unhappy spouse in a loveless marriage of necessity
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.
Your statements about Samsung reminds me of Wear OS 3, that Google is said to have developed together with Samsung. Does anyone know how much of that is Wear OS, i.e. Android, and how much is Tizen from Samsung? Wear OS 3 seems to differ quite a bit from previous versions, it's been Samsung exclusive for a year, and it doesn't work together with the Wear OS companion app on Android.
With the Wear OS 3 the licensing terms have more flexible, I believe it is to get Samsung on board. OEM's bring their own companion app. OEM's also can skin the UI as long it follows Android Wear UX. OEMs also can release their own companion app on iOS. Samsung isn't supporting iOS at the moment, but Fossil and Montblanc are.
There is no "Tizen" inside WearOS 3. Samsung contributed their own UI skin on top of WearOS like they build their own UI skin on top of Android for phones.
Samsung switched to WearOS because they realized their Tizen OS was a failure on smartwatches just as it was on smartphones. Growth was stagnating, their app ecosystem was dead and the development environment was a nightmares.
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.
Is that right? I didn't understand the technical reasoning behind Fucshia, but I understand there was always some disappointment that Linux took off the way it did when it was more of copy of unix rather than an evolution. Having said that, the issue was more with gnu than the kernel AFAIK.
Is AOSP dead, or do your favorite manufacturers just not have a clue how FOSS is supposed to work, and/or have a toxic relationship with the Google Play Services?
It’s likely unrelated and caused by UI and generally old and underpowered HW, but since my Nest was updated to Fuchsia it’s much less reliable, very often laggy and generally frustrating to use.
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.
I don’t know what changes they made in the app layer that runs there, so I’m not making definite judgment. So far I only have correlation, not causation.
Unsurprisingly, this paves the way for apps to be written for Linux or Android apps to work on Fuchsia on day 1 with Starnix. I will not be surprised to see that Fuchsia / Zircon will replace Linux and be the base of ChromeOS.
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]
Fuchsia's development has taken a huge amount of time and the problem with trying to switch ChromeOS to Fuchsia is that if there are ANY regressions as a result (including to android support or crostini), a ton of people will be very unhappy. If there are any downsides, it would have to be WAY better in terms of user experience to make up for that, and I'm not sure that seems likely right now.
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.
In the starnix design doc [1] they mention the similarity to WSL1. There they mention the reason for abandoning WSL1 for WSL2 was due to poor performance characteristics of NTFS and that for starnix they need to make sure the filesystem is performant enough to compare against ext4.
> 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.
Android apps have already been long since restricted in what syscalls they are allowed to use. And they have always run in a per-app sandbox. That's going to help tremendously.
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.
I happen to have some idea of the depth of ptrace, having written one partial reimplementation of it capable of bringing up a GDB on a "hello world"-type binary. It is not an easy system call to support, but also definitely not an impossible one. In some sense it's kind of sad to see Microsoft with a comparatively large amount of resources decide to give up on WSL1.
It's an idea with a long history. BSD and Solaris can also emulate Linux system calls and back in the day IIRC Linux could emulate system calls for some other OSes.
It's a lot more tenable when you're not attempting to run all possible Linux applications. For that sort of thing using a VM is probably the way to go. If you're targeting a subset of applications with a more narrowly defined subset of the Linux surface it doesn't seem too unreasonable. For instance, I'm not sure it's even possible to emulate the eBPF in it's full fidelity via something like starnix.
Indeed it is better for many use cases, but they seemed to have stopped taking feature requests for WSL1 a couple of years ago when I asked for the adjtimex syscall to set system time: https://github.com/microsoft/WSL/issues/6310
> 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.
I more or less give WSLg a pass because it's very complex and inherently requires WSL2 to run the internals. It would be nice if you could connect WSL1 programs to it at some point, but they only just got it working at all.
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.
> 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.
Saying to make a new ticket isn't exactly saying they're willing, though.
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.
> They said they were still working on it, was that not true?
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.
That Starnix link is so weak that even 9to5google is second result. What’s up with the obsession that naming needs to be unique?
> 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”
Hey guys. We're a 24 year old consultancy in Toronto. We are very much an active company with a line of products and services. And yes we have more than two employees (not sure where that came from).
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 :)
> Easily the most ambitious of these is a clear intention for some Fuchsia devices to be able to run apps from other operating systems like Android and Linux.
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 difference is that the HarmonyOS API was just a fork of Android, even if the underlying system changed (and it wasn't changed that much). Fuchsia is completely different, from the kernel all the way to the API.
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.
This is what happens when a company has too much money.
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?
Only if you buy into Raymond Chens fairytales. In reality there’s plenty of software that is not at all compatible with Windows later than XP or later than 7.
Presumably it would benefit people using Android in Fuchsia, like how putting drivers for various hypervisors in the linux kernel benefits people who are using linux in those hypervisors.
I read the article, and I do hope that Fuchsia is successful. A fast and secure microkernel that is open source would truly be godsend for many security needs, and a threat to each and all monolithic kernels.
The article is rather light on detail, dwells on a "starnix shell" (which sounds like dom0 not mksh), goes on about a clock widget, but adds this:
"It’s now been over a year since the Starnix proposal was accepted and work began. In that time, the Fuchsia team has made significant progress in making Linux programs capable of running on Fuchsia devices."
When I build a chroot() for a legacy application, I am expecting to dramatically raise the difficulty of exploitation.
I shouldn't have that expectation of Fuchsia just yet, even though it has been released into commercial products.
We are all really hoping for a kernel that "just works, and never needs patching" in the manner of chacha.
Almost any software project from Google with some kind of user-facing API seems to fail, because Google somehow sucks at API design. Like how awful to use Tensorflow became, leading to it getting largely replaced by PyTorch. Or how complex and convoluted AngularJS was, compared to ReactJS which replaced it. Google's design philosophy seems to be the polar opposite of Linux's "Don't break userspace", so I can see why application developers wouldn't trust a kernel written by them.
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 died when Chrome competitors - mostly Mozilla at the time - refused to include another VM in the browser. On the one hand I think it’s a shame because Dart is much better than even the last version of JS. On the other hand wasm and transpiling solved a lot of the issues Dart was trying to solve with less fragmentation so all things considered maybe it was the right decision.
Very confusing to see this considering most mobile developers I know (completely anecdotal) who use cross platform tools have moved from RN to Flutter for myriad reasons.
Disgusting move by Google to further reign in what hardware and software you can use, how you use it and how quickly you have to upgrade your device.
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.
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.
couldn't Google issue a statement that as of date X any new android licening agreement will stipulate that manufactures release the drivers source code and submit them to the Linux kernel team and threaten to revoke access to the google marketplace and other google services if they don't release the drivers. the manufacturers lost the leverage when they switched to android and the other major non iOS mobile os's died (palm, blackberry, whatever it was call mozilia tried ubuntu mobile etc). now there is only a market for android and ios with sub 1% other.
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).
there already are but unless you have the CPP forcing its use no one will use it as the apps arent there. googles now go the smae vendor lock in that MS does wit windows. no one will wan to pay for all their apps again on another platform.
Couldn't Google force (b) relatively easily by saying that starting at some date in the near future, newly released phones are only allowed to ship with GApps if all of their drivers are upstreamed?
IMO a better/more subtle option: mandate at least 5-7 years of security patches for each device including for the kernel. Manufacturers will figure out real quick that their current practices are unsustainable in the long run.
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.
How do you mandate future behavior? If the device shipped, it shipped, and if Google revokes the Play license four years from now when security patches still haven't been applied, what does the company care? The phones are already sold, Play services aren't going to uninstall themselves, and they can claim they pinky swear to do it this time. Google's only recourse at that point would be to cut out their own market share with no real path to settling the dispute (how can you tell if this time Samsung or whoever will follow through?). At least with a simple upstream requirement, there's an immediate resolution: you can ship the phones with Play once you're done with the upstream merges. Not saying that's in any way likely to happen -- making your terms contingent on the whims of Linus Torvalds does not sounds like a wise strategy IMO -- but it at least makes more sense than after-the-fact requirements.
The more likely scenario is Samsung and others running on their own, in that case. They already have their own store, and crap clones of many Gapps.
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.
> The more likely scenario is Samsung and others running on their own, in that case. They already have their own store, and crap clones of many Gapps.
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.
Yes... But these companies are still unlikely to give a damn. Software is an expense. It isn't seen as a value add, which is also why you won't see software in any of their advertising.
One problem here is the difference between “complies with GPLv2” and “upstream”.
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.
Exactly; it's my understanding at least that most vendors do release their code - it's just that the code tends to be awful and will never get upstreamed as-is, so it's not as useful as you might wish. Still has some value, still complies with the GPL, but nowhere near "lets the phone run on mainline Linux" (which is super rare except for IIRC some Sony phones).
Let's not forget, when Google introduced Project Treble they made it optional for OEMs to actually push updates of Treble drivers anyway, so they didn't.
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...
[3] https://gvisor.dev/