Google’s Fuchsia OS was one of the hardest hit by last week’s layoffs
arstechnica.com
arstechnica.com
Either it's no longer a priority and then you should cut 100% / terminate the product.
Or you can't afford the cash, but that doesn't check out here.
Or it's still a priority but then you just made execution wayyy slower.
It's hard to understand how an OS project gets to 400 people and then to 336 people. It doesn't sound like it'll help get to success. Armchair CEO predicts Fuchsia will not be able to take on a big launch crunch and will join Stadia in the graveyard of doomed investments that ran for way too long.
As for Fuchsia as a product I'm not really sure what exactly it is so if possible I'd love a 411 from any HNers with know-how.
What's a 411?
Commonly used as "information"
Equiv. to give me the details, the lowdown, fill me in, etc.
Kind of a primitive version of Google.
My favorite part was that the sound it made while waiting for the results was a human making robotic beep-boop sounds.
Let’s say they were testing a new Camera subsystem. The results weren’t promising. So they choose to stick with porting the legacy subsystem; well, losing that team isn’t a loss and doesn’t have much effect on velocity or knowledge coverage.
I’m just making assumptions here, but the higher ups almost definitely had many meetings with the management and product teams to decide what was and wasn’t needed and who was “expendable” (I hate HR terms/dehumanization, but this is almost definitely how it was presented) before making their list. Is there a likelihood this would affect the velocity or direction of the project? Sure. But I don’t read losing 15% of an experimental team as deprioritizing it, but more mainlining it (based on my personal experience and knowledge of the subject).
From what I heard most managers were not consulted ahead of time.
> It doesn't sound like it'll help get to success.
Fuchsia is in production; in people's homes today. You can't kill the whole project without a plan for those devices. What if there is a bug in the kernel? Who's going to fix those devices, who's going to ensure a security update comes out?
> Why cut 16% of a thing?
Well, maybe you realize that 336 people is enough? Or you cut 16% of the scope. Or you want to kill the project over the next year, but you need people there to help kill it gracefully, without jeopardizing a bunch of in-prod devices.
> it's still a priority but then you just made execution wayyy slower.
> you can't afford the cash
Fuchsia is in prod, but there is realistically not much google can do with it. Its in prod on a few devices, and based on leaks on HN/media, that may increase. But that doesn't mean its anywhere near a new alternative to linux/android. Maybe they realized that they can't afford to build a new full-feature operating system that they'll never use for anything more than a smart speaker, so they're cutting 16+% of the scope.
Rumors I've heard from contacts in google is that more layoffs are coming across the year. 16% could be the biggest chunk they can take out at once without jeopardizing too much "bus factor". Fuchsia may get cut another 16% in 6mo. If they're de-prioritizing all non-smart-speaker utility, then they may be able to cut 50% over the long run, without "graveyard"ing it.
Personally, I agree that it doesn't make sense to maintain a custom OS over a linux distro if it isn't going places. They used to want to grow in-house knowledge and research on operating systems, but I bet those days are over now. I hope more organizations started to invest in fuchsia before it dies inside google.
Those devices never used to run Fuchsia, they ran the Chromecast linux distrib. When I left that team half the devices (the small ones) were being re-flashed with Fuchsia, but the big ones were still running Chromecast. The UI layer was the same (Flutter-based) on both and a consumer can't tell the difference. There were no feature advantages to the Fuchsia transition. (In fact the opposite since a bunch of stuff [e.g. accessibility features] had to be rewritten from scratch)
I'm sure some stuff has bitrotted, but last I looked Chromecast was still a thing, so the OS distrib is still there and shipping on devices. And it will still run on those devices in the field.
Not actually suggesting this as a course of action, but I think you're wrong that they have no alternative to keeping Fuchsia. It would actually be very easy to kill it. It was super late rolling out on the Home Hub, added nothing consumers didn't have already, and would not be noticed when it was gone.
Besides there was always a political turf war about those display devices in which certain product teams (with the ear of people higher up) really thought they should be running Android. Unfortunately Android was a pig and couldn't reasonably perform on the bargain-basement SoC that was used. If Fuchsia was gone, Android would take over.
Chromecast for TV now runs android, CastOS use cases are mostly moved to android or fuchsia now.
> There were no feature advantages to the Fuchsia transition
I agree, yet I'm glad they did this just for the interestingness of technology. (Theoretically, the Rust based OS may have better security/protection against memory/buffer issues, but thats surely overshadowed by the bug risk of a new OS)
> It would actually be very easy to kill it
My understanding from my time there is that CastOS isn't in a shipping-new-features state anymore.
> If Fuchsia was gone, Android would take over.
This is why the announced Pixel Tablet is also a hub device.
There are still a lot of midrange phones out there, and IOS has always felt smoother.
GP comment mentions that userspace apps on Fuschia are predominantly Flutter apps, which isn't only running Dart (in a VM), but also using Skia for 2D (and 3D?) graphics, and that isn't going to go faster than native. With Fuschia, I believe the primary objective has always been a secure kernel base to build the rest of the OS upon. Even ignoring its vast codebase (think: openvpn/ipsec v wireguard), that is pretty hard to do with Linux without performance costs or support from underlying architectures (ex: https://github.com/google/kernel-sanitizers).
The Android Runtime otoh has long moved to AOT for hot-paths (profile-guided optimization) and JIT for the cold ones.
The biggest difference is that while some Android devices might be a sluggish if too many applications are taking liberties with memory, on iOS they just die, specially on Objective-C code, where not everyone checks all pointer related code.
My coworkers did hero-work getting chromium to render beautifully at decent frame rates with very little lag on a very cheap and underpowered SoC for the original Home Hub UI (which was HTML-based).
Then most of it got tossed so the UI could be rewritten in Dart/Flutter.
Surely someone "took responsibility" for that one
But if you mean UI of Android TV itself, then it seems to be a choice of a suitable SoC, or rather not picking an underpowered one. For example, Nvidia picked well for their Shield line.
They initially ran a version of the same "CastOS" (we didn't call it that then) the same as what ran on Chromecast sticks. But the landing screen on it is richer than what boots on a Chromecast, and it had an interactive gesture based touch screen. CastOS is just a Linux distrib with some boot and build stuff stolen from Android, but the user space for it is basically booting straight into a chromium based web shell.
Before it (the display assistant) launched, I wrote (and ported from ChromeOS) some of the gesture stuff on it. And some of the accessibility features (magnification).
The "Dragonglass" UI that ran on it was originally built as a HTML/TypeScript stack application. Later it was rewritten in Flutter/Dart, ran for a while like that on CastOS using a Wayland-based wedge layer; and now it runs on Fuchsia.
(I don't think any of this is particularly internal or secret anymore since it's old news and replaced, and most of it was visible from the public chromium repo. Also they can't fire me anymore because I quit ;-) )
Thanks for the behind the scenes.
> Maybe they realized that they can't afford to build a new full-feature operating system that they'll never use for anything more than a smart speaker, so they're cutting 16+% of the scope.
An OS that is able to run the Chrome Browser? [0] The code to make this function is already there and I think this effort is more than just for smart speakers or Nest devices.
[0] https://9to5google.com/2022/03/04/full-google-chrome-browser...
To Google Fuschia is about having a better (to them) alternative than Linux. GPL is a pain in the ass when working with hardware vendors and getting driver code produced. Fuschia is about having an alternative they control where the user will never get copyleft access to driver sources.
I hope they don't. There is no incentive to contribute to such a project where you have 0 influence - especially when it is steered directly by a potential competitor. From Fuschia's governance page:
> Google steers the direction of Fuchsia and makes platform decisions related to Fuchsia. While Googlers contribute substantially to Fuchsia’s code base, the Fuchsia project encourages contributions from anyone, not just from Googlers [1].
Why would any other tech company contribute to something like this?
[1] https://fuchsia.dev/fuchsia-src/contribute/governance/govern...
Also it appears to be in the weird niche between "big" OSes like Linux and "microncontroller/embedded OSes" like FreeRTOS or seL4, with outward-facing features begin "It's from google" and "it's new"
It’s a new OS without a lot of the baggage and legacy stuff of Linux/etc.
I agree the Google-influence makes it hard, but it could be a valuable target for other companies IOT work. They’d probably need to maintain a fork though.
But sure that too…
Given google's track record (cutting that RSS feed) wouldn't surprise me they would just cut the whole project. They main bread and butter is somewhere else. It is time to move away from this company product.
I agree though, maybe Google should drop the entire device’s organization. Or spin-off nest.
looks at the graveyard of past Google projects
Which isn't to say you don't have a point, but Google do have form in killing stuff just like that.
Yes, you can.
If small company can kill eye prosthetics project and leave people with implants without support, why does Google cannot kill thermostats project?
Google is known by killing projects which are still used by thousands, without any replacement.
(ETA: Not that that's a good thing, mind you. There's a placard a few blocks from my home about the birth of Truth in Advertising as a reminder it was a hard-fought thing, easily lost. Some would say it is lost in modern advertising.)
First of all, Fuchsia is SMALL. I mean it could easily be maintained and developed by 50 people. The kernel is tiny despite being of many modules and so is the application layer. I don't see any problems wit the 16% lay off.
I think this is a project that can meander rather than sprint, it's not that important to race to a finish line here.
I think in this case, letting go of the most senior decision makers may actually speed things up. Even letting go of senior talent may cause the upcoming engineers to grow faster and better. New nimble team that much rather fail fast than ponder long over what succeeds.
This might be a positive pruning. But yes letting go of staff is a short term loss. Hoping for the best in their future.
16% is approximately equal to one-sixth, expressed as a fraction.
The actual headcount number a team has at is the integral of a hundred political decisions, not any kind analysis of what headcount actually makes sense.
I see people comparing it to Chrome but the business case for Chrome is massive; protecting Google’s search and advertisement surveillance monopoly by avoiding to have to pay Apple and others big bucks to have Google as default search engine.
(especially where "the only thing left" is more than the sum of the rest put together)
replacing the GNU userland reduces legal risk and increases operational flexibility significantly due to GPL3's tivoisation/patent clauses
however the kernel isn't GPL3 (and never will be)
IMHO Google shouldn't pull-back from using Java (or Kotlin). Rust could be an option but that would certainly degrade Android's developer experience.
Times have changed but maybe the underlying factors driving the business were always the same.
As other voters, we had internet explorer, where Microsoft basically decided to strangle the web and end evolution after it won the browser war, just to keep windows relevant. We had firefox, where mozilla is forever on life support and never very well managed. We had safari, only a valid choice in the apple world. So google's survival depended on the goodwill of an enemy actively trying to kill them, a drunk zombie, and an at best uninterested party.
In this world, google brought much better security, much faster javascript execution speeds, much better rendering. All of these were building blocks for a higher level of web-based applications.
I think everyone was surprised about how good chrome fulfilled its role. The desktop never got its central role back, to the point that electron a.k.a. chrome is now the dominant desktop gui paradigm for microsoft itself.
Here is one random example from 2008: https://channeldailynews.com/news/the-business-case-for-goog...
In addition, the team working on it has made the argument that there is a technical benefit and that Linux + ART has failed to scale (to their needs).
You combine both of those factors and you end up with a bespoke kernel, with a home brew environment (Dart-first, with Rust as a complement) and an Android ABI abstraction or virtualization (similar to Microsoft’s approach) to run legacy software until it’s phased out.
Google 2000s is way different from Google 2020s.
Their presence in the web is so extremely entrenched, it is quite hilarious to already write them off over a obvious market correction.
Google is fine. They just over hired just like the rest of the companies did. The free / cheap money era had to come to an end.
Google’s core business appears sound (as an outsider). They’ve struggled to stamp out repeated successes (because that’s inherently hard, not because they suck).
* G-suite arguably hasn’t won its category at all and Android has won in install base, but probably not in overall economic value. Gmail and Chrome have earned the hat-tip and nod-with-respect.
Partially it is also because Google has a nasty reputation by now for closing down services with bare minimum notice, despite many millions still using them (RIP Google Reader), or for barely keeping them on life support (Gmail). Stadia was the most recent victim of that - consumers didn't want to invest actual money into something Google made no public commitment to keep it running for years, and where there are no consumers the game developers didn't want to invest money into porting either.
This is an example of how The Google keeps shooting itself in the foot. In terms of aesthetics, they mostly know what they are doing, but they are terrible at selling things and believing in their own products. If they don't believe in their own products and are so quick to give up on ideas, why should I believe in their products?
In contrast, if Apple does something, you know they'll stick with it for more than a few weeks. If Apple decided to get more competitive in the gaming space, I actually think they could do quite well because nobody thinks they're going to be swindled by them.
Actually I think cloud gaming has its advantages - you don't have to worry about upgrading a computer all the time to keep up with new developments, to keep it running and patched, some online trolls gaining RCE on your machine (yes, that happens, remember Minecraft and log4j!), giving kernel-level access to crappy anti-cheat software or about the power and heat. And when a new game comes out, you don't have to deal with downloading dozens of gigabytes on day 1 and another dozen gigabytes in patches in the following weeks. Just go online and play.
And if you want to go on vacation or on other travel, you don't need to haul around a thousand dollar worth PC or laptop, you only need your Chromecast.
Stadia reminds me of the time Homer Simpson designed a car. Just because an idea sounds ingenious doesn't mean it will result in an ingenious product. Actually, Stadia is a lot like Homer's car. Instead of Homer, the reigns were seemingly handed to engineer-types living in the Silicon Valley bubble who thought it'd be cool to play games over VNC (an oversimplification, yes). The product should never have seen the light of day and, when unveiled, everyone who saw it knew it was doomed.
In reality, most people just don't care about downloading game updates, regardless of how unreasonably gargantuan they can be. It's arguably a good thing that people have to take some break from gaming. Regardless, there's no evidence that downloading updates is preventing any meaningful number of users from spending more money on gaming. Anti-cheat software sucks, but again, it's not much of a roadblock for most gamers if at all.
The disadvantages outweigh the benefits. Input lag is frustrating, even if it happens occasionally, and is borderline unacceptable when playing online multiplayer games. Lose access to internet? Just go read a book, kid!
At best, Stadia might have been a niche product for the minority who would want it. Not in a million years would I have wanted a Stadia.
To compete in the highly competitive sphere of gaming, Stadia needed more of a value proposition than being able to play games instantly without downloading updates.
On a related note, The Google will face more trouble as their Search and YouTube products become less useful and relevant. Many people, namely those around in Web 1.0, still insist on using The Google, but even they will be using it far less often the more that the Web just fills itself with trash content from bots and the more that Search hawks lame shit over actual results. The more that YouTube transforms itself into cable TV, the more it's going to set itself up to not make it into the next paradigm. Say what you want about TikTok, and I'm certainly not a fan, but I think TikTok has proven that YouTube will soon be viewed as missing-link media.
From a consumer (and therefore business) perspective Android is useless without Google mobile services. Just witness what happened Huawei to phone sales when they were forced over to Android open source on nearly perfect hardware.
If this is a big reason, then a big reason is eliminated since Google has won the lawsuit against Oracle and have moved to OpenJDK so the licensing concerns are moot.
Fuchsia is orthogonal to Java. They could switch the runtime to anything they wanted without going down to the OS if that was the priority.
If that was the goal they don't need to make new kernel to make new userspace.
They can just make new userspace, like they did when they created the android in the first place.
You may be in the right, but I personally don't see no reason for it. Linux is the best supported operating system in the world and Google always has the option to alter the OS if need be.
I do believe Fuchsia is vastly more secure and stabler than Linux, which could be a benefit, but Google isn't exactly being pilfered by miscreants on a daily basis, so that benefit is in doubt.
(What's visible of Fuchsia doesn't quite support running on "big computers" well enough for that to be true...)
Fuchsia's architecture is extremely resilient and secure by design and there's very little change culprits will be able to breach its security.
I have to disagree with Chris on this, it allows these teams to tune their products exactly to their needs. If they wanted to streamline this process then the most logical step would be to upstream their patches (which the Android team has been doing [1]).
Seems like the XKCD "Standards" meme stikes again [2]
[1] https://arstechnica.com/gadgets/2021/09/android-to-take-an-u... [2] https://xkcd.com/927/
And this impacted velocity and quality.
And yes, Fuchsia was not the answer here. Rewriting a bunch of stuff in Fuchsia just meant that the existing Chromecast distrib got neglected, bitrotted, and mistreated and failed to improve. But AFAIK it still hasn't gone away -- and likely won't -- so was that smart?
Multiple distributions for specific needs are fine. Multiple distributions for political reasons is something else.
These layoffs were coordinated across our entire industry, starting with Twitter, to bring discipline and downward wage pressure to tech workers. Musk at least made some (implausible) theatre out of supposedly "measuring" employees to justify his moves. Sundar/Larry/Sergey just used a glorified random number generator.
- $800k in revenue
- $200k in net profit
per employee.
And this is assuming in 2023 they drop to pre-Covid levels, which will probably not happen since the world has changed for good. So more realistically they'll be over:
- $1m in revenue
- $300k in net profit
also per employee.
Also, history rhymes:
https://www.theverge.com/2015/1/15/7554397/apple-google-inte...
the worst possible thing from a central bank perspective is a wage-price spiral where employees can negotiate wage increases that keep up with inflation. increasing interest rates is designed to depress wages by cooling the employment market, which decreases income, which decreases spending, which then decreases the rate of inflation.
Massive? Head count is back to like it was on 2021, for all of the major tech companies.
Reading the article now it seems to be the case that I have not been living under a rock, and they are just tight lipped about it. If it's being used for nest devices today then I imagine it is finding it's niche.
Actually I think the original vision was to get rid of the Linux Kernel in Android and have everything 'googled'.
They wanted to go full vertical but then not sure why it was downsized to more embedded targets.
WebAssembly is still a hopeful, they haven't gutted the security in WASI yet.
The most valuable thing for the community to extract from projects like these would be capability based drivers, ideally on top of seL4.
The choice to not use seL4 as a base for Fuchsia is also confusing. It lends credence to the idea that Fuchsia is a project to retain engineers, rather than to build a solid OS. I think it would be possible for a team like the Fuchsia team to build a better platform than Genode, but starting from scratch without seL4 is unlikely to produce anything better. They definitely didn't come up with a better security model, or IPC performance.
The tough thing about getting out of a winter is that taste, an understanding of what is good and bad, has been lost because it was never transferred to the next generation. The next generation of system designers will have to (unfortunately) rediscover and rebuild a sense of good taste so that in practice engineers can accurately identify ideas (e.g. capabilities) as good ideas, worth implementing, when other more popular well trodden ideas (e.g. ACL, RBAC) are also on the table.
Another example: Plan9's headcount was never high, and look at what they shipped.
From Google's perspective, yes. License, and maybe driver ABI, but I doubt Google wants to change its support model.
> Is Fuchsia simply about control?
From my understanding, yes. It's all about locking systems more, making them more closed, and immutable. A "better" way to control hardware and what OS runs on that hardware. A more iOS like control, without shoehorning everything into Google Play Services.
I concur that Fuchsia indeed has some interesting ideas. However, I see these interesting ideas as instruments to favor Google's long term vision about their devices, not for doing research in the name of research.
Over the years, I have lost faith in Microsoft and Google. I see every action they take as a means to improve their dominance while (ab)using and EEEing technologies they like, but they can't control. I don't trust these companies and always start from a slightly negative, corporate-centric view of everything they put out there. This is something I do knowingly. This is not a bias which is blind-siding me. It's intentional and I'm aware.
Having a kernel, complete with a Linux emulation layer, which is designed to enable seamless plumbing-rugpulls while having architectural decisions made to please hardware vendors doesn't look like simple research to me.
Adding a MIT license on top of it, and saying "We might be running closed source, slightly modified versions of this that we don't share" adds more wieght to my view, in my eyes.
So, also this is not Google's first rodeo. They are slowly close sourcing Android by moving things into Google Play services. Having a kernel and OS not encumbered by this "pesky" GPL stuff will allow them to have their private forks while playing "Hey, look, we're open source!" tune.
It's VSCode of Google. Designed to fracture, touted as open source but useless without Google's own secret sauce and blessing. Merely a source-available showcase which is full of interesting ideas useful for its creator and useless without its touch.
Oh, at least we see the code and get inspired by some of the ideas they put forward, if they are indeed portable.
We hit Apple for their walls, but at least they contribute their kernel inventions back to BSDs (libdispatch, for example).
If no one ever builds anything new, nothing new will ever be built.
There's an implicit assumption in your question that Linux has solved all problems or is even fit for its current uses and all future use cases. (A similar sentiment is voiced in other discussions e.g. about programming languages, frameworks, editors, etc)
Related: "The Thirty Million Lines [of Code] Problem" https://www.youtube.com/watch?v=kZRE7HIO3vk
I watched a bunch of lecture videos on operating systems a few months ago: https://www.youtube.com/@johnkubiatowicz3737/videos It didn't seem like they are fundamentally that complex. I'm pretty sure CMU has a class where undergrads are required to write their own operating system within a single semester.
My vague impression is that Linux has become bloated since the project's scope is so large -- Linux is used to address every possible use case. That's naturally going to lead to a ton of complexity and bugs. I'm really excited by the idea of people creating new OSes that explore alternative paradigms and try to beat Linux for specific use-cases.
Writing a replacement for Android in Rust would be interesting, for example. I don't think you would need to create a full Linux compatibility layer -- you could create just enough compatibility for the Android APIs to still work.
Then you could add anti-distraction features at the OS level -- e.g. make it so if someone has deliberately uninstalled an app in the past, they have to solve a bunch of captchas if they want to install it a second time.
Tons of everyday people struggle with addiction to apps like Instagram, where they uninstall the app to try & waste less time, then give in and reinstall it, over and over again. I think solid, creative app blocking features (e.g. user selects how much effort is required to disable their own self-restriction when they set it up) could be an attractive selling point for many users. There is the potential to make millions or even billions of dollars by changing the relationship that people have with their devices.
For normal computers and phones/communication devices, this is no big deal, but it does limit usefulness in IoT.
Then, there's things like SCADA, drones, and transportation. RT also matters, there.
I guess it isn't a big deal for speakers and AI-powered cheese straighteners, but I've always found it to be important.
[0] https://fuchsia.dev/fuchsia-src/development/build/fuchsia_cu...
[1] https://en.wikipedia.org/wiki/Object-capability_model
[2] https://fuchsia.dev/fuchsia-src/concepts/components/v2/capab...
[3] https://opensource.googleblog.com/2022/10/announcing-kataos-...
Linux was designed in a multi-user world. Bob, Fred, and Alice would each have user accounts, and could edit only their own files, etc. If Bob ran an application, that application had access to all of Bobs files.
Whereas modern devices tend to be single-user, but with many applications with different amounts of access to different resources. The user in general is running code they don't trust. For example, the web browser doesn't need access to the contacts. The Wifi stack doesn't need access to the printer. The Facebook application doesn't have access to your twitter followers. The user wants to use the Facebook application, but doesn't trust it to do only what it says it will do.
It's a different world, and bolting those requirements onto Linux was getting harder and harder.
Just look at the HN frontpage yesterday - Google Pixel phone pwned because all android applications have unfettered access to the GPU driver, which itself had a vulnerability. In a Fuchsia world, only apps requiring 3D rendering would have access to the 3D bits of the GPU driver.
Multics was designed as [1], Unix was spawned as a small, simple, mini-Multics with elegant minimal desgin goals, and Linux arrived down the way as a hobbyist Intel architecture monolithic Unix clone.
While Linux expanded as a project to include more and more hardware targets and ever so slowly become less monolithic, it never really moved far from the One True Way of Unix, at least not in its early life.
The opportunity was there to adopt a capability based security model from almost the beginning, but the thrust was always to make a solid Unix clone and eschew 'experimental' features from niche OS's such as Extremely Reliable Operating System (EROS) [2].
Does Apple have the same problem with iOS and its BSD heart?
I think that's a common misconception. I'll freely admit I don't know how Fuchsia handles this, but in the realm of conventional OSes,[0] all modern apps require what twenty years ago would be considered “3D”. The GPU isn't just there for games, it's used to render the UI of all applications, and it's done via APIs you might associate with 3D. Actually, if we define GPU strictly[1] and ignore GPU compute for a moment, there are no “non-3D bits” of the driver.
[0] At least macOS, iOS, Windows and Android. Not sure what GNOME etc do.
[1] A modern graphics card combines display output, 3D rendering/GPU compute, and video encoding/decoding. If you were to build an SoC with those capabilities, you would want to licence three different IPs: a display processor, graphics processing unit and video processing unit respectively.
That 2nd process can have the special '3D drawing permission'.
Then, if you find a flaw in the GPU driver, you also need to find a flaw in the special UI-drawing-process to allow you to exploit it.
At the time when I left the ICD loader is in fact a special case in the OS where it's one of the few mechanisms by which regular components ever get executable memory that does not come directly from their own package (which is a normal and significant design encouraged and policy enforced constraint for most product builds on top of the OS, excepting JITs which are rare). The ICD loader provides a special path for the ICD and some associated data to be loaded from a peer component at runtime. An ideal eventual outcome for secure systems would be to find ways to avoid this vendor runtime mixing, instead for mechanisms to efficiently push command queues through stages of processing. The Vulkan folks have performance related cases to make as to why they took the route they did - I suspect a middle ground is possible eventually but would need new specs and new drivers.
Not everything needs this capability, and not everything gets it. Product builds out of the OS can effectively apply policy as to what components get this capability and arrange for other solutions to rendering as best fits the product. The system design makes these choices explicit, rather than implicit, and can be tuned for a particular balance of security, performance and other properties.
There was an RFC recently formalizing some of these details, I've not gone over it to see if it also introduced significant new changes. https://fuchsia.dev/fuchsia-src/contribute/governance/rfcs/0...
The actual systematic fix for the Android GPU issue is what Chrome does: require untrusted code to serialize command streams to a separate process that does extensive validation before handing off to the driver. But that yields a performance/energy impact, so, it may also be more reasonable to just audit and fix drivers.
Linux is a pretty generic operating system, it runs on just about everything and wasn't initially designed for phones in mind. Of course at the rate phone hardware is progressing, I think Google has realized how little important an optimized OS really is.
Facebook also realized that they had to go full native a long time ago.
You should always worry when your platform vendor doesn’t eat their own dog food. Besides Flutter will always be behind tsking advantage of the latest iOS features - especially if Google doesn’t depend on it.
This is also one of the major complaints about some of Apple’s APIs especially on the Watch. Even worse, Apple has specialized equipment that makes Watch development faster than it is on the outside.
(Disclosure: I work on the Flutter team.)
You'll end up with a huge legacy codebase and dart devs that are useless for most other platforms.
I do expect there will be lots of $$$ rebuilding legacy flutter apps in SwiftUI and Jetpack Compose
Right now as it stands, Google has made no more use of Fuchsia than LG has with webOS. It's a washing machine operating system.
The future for this OS doesn't look very bright.
Even something as simple as porting Debian to Fuchsia might be enough to keep it interesting.
Part of me wonders if many of these projects really only exist to remove potential competitors from the market.
Anytime some engineer seems to be capable of building an Android opportunity; hire them on a make work project to keep them busy which will never Be launched, and they know it will never be launched.
Terrible for the industry . If that’s what happening it’s a form of cancer, preventing the best people not only from advancing themselves and taking risks in the real world but also consumers.
Please. Fuchsia has already launched and is in production devices. [0] At least get the spelling right as well as the fact that it has shipped.
I have not seen anyone else create a production-level OS from scratch in less than 7 years and release it on to real world devices other than Google and have it run the full Chrome browser in that same time period. [1]
It is as almost as if that they are planning to replace something inside ChromeOS, or even Android...
[0] https://9to5google.com/2022/08/24/nest-hub-max-fuchsia-rollo...
[1] https://9to5google.com/2022/03/04/full-google-chrome-browser...
Still if you want to support what they do 25 bucks for the year seems reasonable.
I don't though. I run ublock and did not even know there were ads.
They are rewarded for it for being able to execute such projects.
Chrome sandbox is a rare one that is successful.
But I always think it is absurd that Google rewards such a thing so heavily. As you can imagine, everyone is trying to make their projects multi-years.
I'd bet Fuschia is one of those projects. Then, when a bad time hits, it has to go first.
The best part will be the HN thread about how "everyone saw this coming", despite years of downvotes for suggesting a company as notorious as Google can't be trusted as a core dependency for your app.
Google Fuchsia OS team affected by layoffs: https://news.ycombinator.com/item?id=34473500 (3 days ago)
Another day in the office for Google. RIP.
The company will soon have to decide how to move forward since replacing Linux will require a sizeable investment in manpower. My suggestion would be to focus on only replacing the Linux kernel whilst keeping other parts of the Android stack intact as much as feasible.
They should be able to do this in relatively short order, say two years.