Google’s Fuchsia OS was one of the hardest hit by last week’s layoffs(arstechnica.com)
arstechnica.com
Google’s Fuchsia OS was one of the hardest hit by last week’s layoffs
https://arstechnica.com/gadgets/2023/01/big-layoffs-at-googles-fuchsia-os-call-the-projects-future-into-question/
30 comments
> Either it's no longer a priority and then you should cut 100% / terminate the product.
> 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.
> 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.
> Fuchsia is in production; in people's homes today. You can't kill the whole project without a plan for those devices.
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.
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.
> last I looked Chromecast was still a thing, so the OS distrib is still there and shipping on devices
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.
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.
Yeah I have the Android TV based Chromecast device here at home. It's janky and laggy in the UI :-)
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.
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.
Pardon my ignorance, but what UI in Chromecast? From what I remember, there are just pretty pictures with clock when you don't play anything and your chosen stream, when you do.
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.
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.
The topic in the thread here is the Google/Nest Home Hub / Home Hub Max display assistants.
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 ;-) )
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 ;-) )
Oh, those devices do have UI... somehow I managed to skip this entire line. As I said, pardon my ignorance :-).
Thanks for the behind the scenes.
Thanks for the behind the scenes.
> Then most of it got tossed
Surely someone "took responsibility" for that one
Surely someone "took responsibility" for that one
I'm a bit surprised Chromecast is still kicking. It used to be a pretty unheralded innovation which I found to be really useful. But, honestly, these days I usually have multiple other options to get most content up on a TV screen.
It should be slightly less janky than Android with all the Java in it.
There are still a lot of midrange phones out there, and IOS has always felt smoother.
There are still a lot of midrange phones out there, and IOS has always felt smoother.
> It should be slightly less janky than Android with all the Java in it.
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.
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.
Dart is also AOT/JIT compiled since version 2 was introduced.
Java is AOT compiled since Android 5, switched into AOT/JIT with PGO feedback loop since Android 7, and as of Android 8 PGO data gets shared across devices via the Play Store.
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.
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.
> I hope more organizations started to invest in fuchsia before it dies inside google.
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...
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...
I'd imagine any company trying to contribute to android would nope the fuck out of even trying to contribute to any google-led project.
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"
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"
> Why would any other tech company contribute to something like this?
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.
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.
If said “legacy stuff” are things like an ethos of user freedom, then I don’t see a reason to keep Fuchsia.
I was thinking more that legacy stuff meant memory safety bugs and decades of design choices made for devices with radically different hardware profiles than most used today.
But sure that too…
But sure that too…
Although they probably can't call it Fuchsia, the license is such that anyone can create a fork of Fuchsia.
I worked briefly on Fuchsia and LK (little kernel), years ago, as a contributor.
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.
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.
Exactly. So why not a 85% cut from 400 to 50, instead of 16%? What strategic purpose does a reduction in workforce serve it it's not materially realigning staffing on updated business priorities, such as putting the effort on a very clear pause? I don't think 16% is going to change the objectives and priorities of a team. Just gonna make them slower.
> You can't kill the whole project without a plan for those devices.
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.
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.
Fuschia powers the current, on sale, Nest Hub
Lots of companies sell things they no longer plan to support long term simply because they have inventory.
(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.)
(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.)
The Google Way would be to create an internal competitor to Nest :P
You can’t kill the thermostat project if the thermostats were installed in the offices and C-level exec’s houses.
> You can't kill the whole project without a plan for those devices.
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.
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.
>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?
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.
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.
Cutting a feature on their Mail client is different from a physically shipped product.
I agree though, maybe Google should drop the entire device’s organization. Or spin-off nest.
I agree though, maybe Google should drop the entire device’s organization. Or spin-off nest.
10 years ago, Google cancelled a mildly popular $0 revenue web app.
Seems they killed a tiny bit more that a mildly popular $0 revenue web app: https://killedbygoogle.com/
Ok maybe not 100% but 300 people aren't needed to do the occasional security patch for some kind of smart speaker. Sounds like the future of this project is towards the trashcan then.
Cutting 16% is a sign that Google has over hired.
> 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...
> 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...
And how it runs the chrome browser better than Linux? That's the question. Saving a meg of memory for OS doesn't matter once you start running hundreds of megs of code, and different, less popular kernel just means less drivers and harder onboarding for any developer
You're right; it isn't about saving a meg of ram.
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.
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.
It's not like most Android vendors -- or their SoC providers -- aren't ignoring GPL anyway. Inside these drivers, there's nothing world-shatteringly innovative, except by not publishing the sources they are not showing the low quality job they do, and make reuse, updating of their devices more difficult.
[deleted]
My understanding is that a large chunk of the Fuchsia team is dedicated to experimentation. It’s like asking why Microsoft laid off part of their Microsoft Research team: it’s likely many of those experimental projects weren’t paying off and now the project’s direction is being pared down to known needs. Additionally, probably only 50-75 of those engineers are considered “critical”, with the rest being used to alleviate load and accelerate velocity (if it’s like any other large incubation/startup team).
But what experiments did they do? Microsoft's Fuschia-like OS research project generated some interesting blog posts and research papers, it had a genuinely very different take on what an OS should look like. Fuschia seems like an ordinary microkernel written in C++.
Maybe. Unless it's a separate area that is purely speculative (within a business that is already a long shot itself), losing >10% of an org with no notice, no knowledge transfer, is a hard thing to adjust to, even if it's some moderately useful support function.
Incubator teams like this rarely lack knowledge redundancy. I highly doubt a single one of the people laid off had silo’d knowledge or worked solo on any mainline components.
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).
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).
> 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.
From what I heard most managers were not consulted ahead of time.
From what I heard most managers were not consulted ahead of time.
It's all politics. Top level leadership is triangulating between keeping investors happy and the business running. Product Area leads saying "we need to keep headcount to fend of competitor X" or "to stop customer Y from losing trust and abandoning us" (although that last one clearly doesn't work at Google).
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.
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.
It's always politics but the triangulation seems like poor decision making.
400 to 336 could happen with a bit of housekeeping. It's more or less politics as to who gets budget in bg orgs.
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 this is a project that can meander rather than sprint, it's not that important to race to a finish line here.
To play devil's advocate, in the case of a company like Google, it's unclear whether or not execution actually gets much slower. From what I hear the amount of people coasting or even distracting teammates with negativity is pretty high, cutting such people might even speed up execution in the net.
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.
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.
From my contacts at Google, the cuts don't appear to be strongly correlated to poor performance, rest & vest attitude, negativity, etc. It has been messaged by company leaders as "role eliminations", not as "dropping underperformers", so it doesn't give anyone a reason to work harder.
> I'd love a 411 from any HNers with know-how
What's a 411?
What's a 411?
Parochial north american slang originating from local directory assistance phone number in Canada and the United States.
Equiv. to give me the details, the lowdown, fill me in, etc.
Equiv. to give me the details, the lowdown, fill me in, etc.
[deleted]
https://en.wikipedia.org/wiki/4-1-1
Commonly used as "information"
Commonly used as "information"
Eh, better translated as “a summary” or “abstract” here.
411 was a phone service that you could call and ask basic questions to and a human operator would look up answers for you.
Kind of a primitive version of Google.
Kind of a primitive version of Google.
Anyone remember GOOG-411? During the days before smart phones, you'd call a phone number and do a Google search via voice.
My favorite part was that the sound it made while waiting for the results was a human making robotic beep-boop sounds.
My favorite part was that the sound it made while waiting for the results was a human making robotic beep-boop sounds.
> it's still a priority but then you just made execution wayyy slower.
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.
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.
There was alot of rumours that they would eventually make this their mobile device OS. By cutting 16%, you're probably realigning goals of the project, and I wouldn't be surprised if those 16% cut are to shift away from making this to mobile.
A small team can curate institutional memory and make roadmaps ? (Like, if the cut were not 16% but 84%.)
> Why cut 16% of a thing?
16% is approximately equal to one-sixth, expressed as a fraction.
16% is approximately equal to one-sixth, expressed as a fraction.
maybe 16% was a group porting for a cancelled device.
Maintenance mode.
Fuchsia is cool from an OS perspective but isn’t the problem that there simply isn’t a business case for it?
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.
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.
The business case is obvious: Google has little control over Android due to historical licensing and external dependencies (Java is the big one). Building their own OS with its own user space gives them the same control Apple has over iOS.
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.
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 is in full control of android. Android open source is much more about making it hard for new competitors to emerge (as they would have to compete with something that is free). Fuchsia has similar open source components.
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.
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.
What happened?
Loss of access to the Play Store, meaning a loss of compatibility with the vast majority of the applications out there.
> The business case is obvious: Google has little control over Android due to historical licensing and external dependencies (Java is the big one). Building their own OS with its own user space gives them the same control Apple has over iOS
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.
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.
Well thanks, now I'm afraid fuschia could succeed.
It's from Google, it won't. Which product from the last decade has won their respective market?
Google 2000s is way different from Google 2020s.
Google 2000s is way different from Google 2020s.
I wonder how The Google will fare in the future when millennials (and even Gen Z to an extent) become far less relevant. Call it a hunch, but much of their success outside of their technical achievements comes from their identity from the 2000s. People who were around in the early Web still see The Google as representing both excellence and defiance against the tech establishment. After all, "don't be evil, maaaaan." The Google can basically just ride upon their prior success because of their size and the number of relevant consumers who grew up with them. Come the time millennials reach retirement age, they're going to seem to younger generations like Sears did to mine; they'll be seen as an old-people thing that's too big to fail but totally uncool and obsolete. In the tech world, they'll be seen exactly as Oracle, Hewlett-Packard, and IBM are today.
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.
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.
If the future of video publishing is TikTok, then I don’t see myself consuming much video content in the future.
Google Photos?
Gmail?, G Suite?, Android?, Chrome (and the entire ecosystem around it)?
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.
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.
Literally none of those successes* are from the last decade, which was GP’s point.
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.
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.
> They’ve struggled to stamp out repeated successes (because that’s inherently hard, not because they suck).
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.
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.
Stadia was a stupid idea in the first place that was going to be fraught with problems, and The Google may have thought those problems could be overcome with their incredible genius or their customers' brand loyalty. Why buy a new gaming system selling itself on a technology (cloud gaming) that the player has no reason to care about and will inevitably cause problems that won't happen with locally installed games? Cloud gaming thinks it solves a problem that players never had; storage today is plentiful and affordable. Enough gamers simply knew that the proposition The Google was making would be a road to hell and wasn't appealing regardless.
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.
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.
> Cloud gaming thinks it solves a problem that players never had; storage today is plentiful and affordable.
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.
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.
Maybe those would actually be advantages in a world where network delay and connectivity issues aren't a thing.
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.
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.
The other prob is the size of the company. If say a couple of dudes make a 10 million dollar steady business. It changes their lives. A 10 million dollar steady project in a company the size of google will probably get killed. It does not 'move the needle'. They probably can produce hundreds of small applications that are cool and slightly profitable. They even try it. But if those products do not 'hockey stick' forget it. Then also your point people stopped trusting them to long term support 'new' things. Also getting support out of them if you are using some of their products seems to be awful. That reflects badly even on products where they do give decent service as they now have a reputation for that.
> due to historical licensing and external dependencies (Java is the big one).
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.
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.
> (Java is the big one)
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.
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.
Here you have simply assumed that the business case for Fuchsia must be externally visible to consumers. Why assume this? The overwhelming majority of Google's software runs on Google's computers and you have never seen it. Perhaps they would consider it a success even if the only role for Fuchsia is in their datacenters. There are abundant reasons why Google would want a non-Linux operating system internally.
When gVisor was released to the public, my conspiracy theory was that the future of Google Container Engine was gonna be gVisor-on-Fuchsia instead of current gVisor-on-Linux. Consumers couldn't tell the difference, gVisor is the one implementing the user-visible "Linux" on both.
(What's visible of Fuchsia doesn't quite support running on "big computers" well enough for that to be true...)
(What's visible of Fuchsia doesn't quite support running on "big computers" well enough for that to be true...)
> here are abundant reasons why Google would want a non-Linux operating system internally.
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.
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.
Google pays for hundreds of engineers working on the Linux kernel, who spend a lot of their time arguing with Linux maintainers about what should or should not be upstreamed, and painstakingly grooming their internal diffs vs upstream. You can imagine why not having to do that would be easier.
They don't have to do this. They can maintain their own patches.
The business case would be to replace Linux kernel on Android.
For something to be a (good) business case it really has to save or make money loosely proportional to the number of people working on it.
Reducing all those people that are still around to push upstream changes.
And eventually all the Java on Android - which apart from the issue around licensing would hopefully make the experience of using Android phones better.
I don't see why this would make the experience better. Java has been a huge part of Android's success allowing for backwards compatibility in a smooth manner. Java should also be given credit for Android's stability, due to its lack of memory safety errors.
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.
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.
But maybe they fear stepping away, because that can mean less influence in the Linux sphere and possible rise of competition. And since the Oracle decision, they don't have to make any moves that would jeopardize the status quo. If they allow things to stay as they are, they are arguably fine. They can afford to move slowly and extra carefully or not at all. Fuchsia seems more about extra insurance, just in case.
Which in turn seems like a weak case because android presently performs very well
In all these years Google has been replacing most of the GPL stuff on Android, dropping GCC for clang, moving driver infrastructure out of kernel space with Project Treble, and so on, the Linux kernel is the only thing left, that would be the business case.
replacing "the only thing left" is not a business case
(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)
(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)
It is, given the non-copyleft nature from Fuchsia.
From Google's point of view they likely believe that a microkernel could more easily be secured than a monolithic kernel. Also, it's probably great [from their point of view] to have control over their OS and its "community".
And Google has spent so much time pushing rust for Linux.
Worth pointing out that at the time Google first launched Chrome the business case didn't seem clear. The product itself was compelling, but it wasn't clear what Google would do with it and why. (Now we know)
There was plenty of discussion on this topic at the time, and there seemed to be a rough consensus: chrome was the google vote for choosing the direction of the www.
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...
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...
I think it was pretty obvious at the time. I don't recall anyone being surprised by it, except maybe how large the budget was. Google was paying for every search referral from browsers since nearly the start. If you search with their browser, they don't pay anyone else.
Yeah and Google’s motto used to be “don’t be evil”. Now it is a bit more like “yeah we are a nasty monopoly that spies on people, watcha gonna do about it”.
Times have changed but maybe the underlying factors driving the business were always the same.
Times have changed but maybe the underlying factors driving the business were always the same.
I see Fuchsia's benefit mostly in security and stability. Linux is one big blob with potentially huge security holes in it, many of which simply haven't yet been discovered (except maybe by intelligence agencies).
Fuchsia's architecture is extremely resilient and secure by design and there's very little change culprits will be able to breach its security.
Fuchsia's architecture is extremely resilient and secure by design and there's very little change culprits will be able to breach its security.
The linked interview https://9to5google.com/2022/08/30/fuchsia-director-interview... is an informative read.
> At that time, Fuchsia was never originally about building a new kernel. It was actually about an observation I made: that the Android team had their own Linux kernel team, and the Chrome OS team had their own Linux kernel team, and there was a desktop version of Linux at Google [Goobuntu and later gLinux], and there was a Linux kernel team in the data centers. They were all separate, and that seems crazy and inefficient.
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/
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/
From my own experience working there... On the embedded side the problem was that the various consumer device Linux distributions really reflected org-chart boundaries, not really technical/engineering requirements.
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.
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.
I wonder if all these massive amounts of layoffs from huge companies are designed to flood the employment markets with candidates and drive wages down long term?
this is definitely by design, but it is driven by public policy (reducing inflation), not private companies conspiring against their employees.
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.
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.
> I wonder if all these massive amounts of layoffs from huge companies are designed to flood the employment markets with candidates and drive wages down long term?
Massive? Head count is back to like it was on 2021, for all of the major tech companies.
Massive? Head count is back to like it was on 2021, for all of the major tech companies.
What other explanation is there? The layoffs are Google were not tied to employee perf metrics. The company is still wildly profitable. The severance package costs are high, and they will likely hire in various places by the end of year or into next, undoing much of the layoffs, so costs won't really be reduced by much if any.
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.
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.
To put things into an even better perspective, even if Google's revenue and net profit fall to pre-Covid levels, they would still be making about:
- $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...
- $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...
I'm really starting to suspect that Google abandons a high percentage of its products.
Big if true!
I'm sympathetic to all those who lost their jobs, but I'm a bit baffled that 400 people were working on this. Can someone enlighten me as to why so much headcount was required by this project?
400 people for an essentially from-scratch OS? That's incredibly lean as far as tech companies are concerned these days.
It's a microkernel-based capability-based object-oriented operating system. They're trying to make commercially viable what is essentially a research project.
How is that a lot if this product should be the differentiator for Google between them and all the ones using just Android?
I hope I'm just living under a rock but this made me realize I haven't heard anything about Fuchsia in years.
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.
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.
> 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.
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.
SoC vendors probably want Google to pay to support Fuchsia. If they want it to replace Linux, it has to be bottom-up, not top down.
I'd imagine making something worthy of replacing Linux Kernel isn't easy, even for a big corporation with the size of Google.
The kernel, Zircon, was a pet project of the original dev later brought on to a Google team, if I remember my conversation with him correctly.
I always imagined Fuchsia as a server OS, not a replacement for Linux on Android. Wouldn't their KataOS/Sparrow project be more relevant to Android?
Fuchsia was announced around the time of the Google Vs Oracle case if I remember correctly. They said it had been in development for years but I guess the assumption of the public announcement was that it was directed at oracle.
I was hoping we'd get a usable Capability Based OS soon. Genode is still in the works. I hear that there are some features slowly showing up in iOS and Android.
WebAssembly is still a hopeful, they haven't gutted the security in WASI yet.
WebAssembly is still a hopeful, they haven't gutted the security in WASI yet.
There was another group inside Google that shipped something based on Genode.
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 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 idea of capabilities is so foundational, and yet so obscure, on my darker days it seems like there's an active conspiracy to keep it out of general awareness.
We are left with the ideas that were popular when UNIX rose to prominence. We are still in an "operating systems" winter.
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.
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.
300+ people, in existence longer and with 300x the headcount of Andreas Kling's SerenityOS; I know the 2 OSes have different goals but you do wonder.
Another example: Plan9's headcount was never high, and look at what they shipped.
Another example: Plan9's headcount was never high, and look at what they shipped.
Is there something fundamentally bad that Linux does that requires a new OS to fix? I only know the surface level arguments of monolithic vs micro kernels, but is there something else that reasonably can't be fixed in Linux that would require a new custom OS? Or is Fuchsia simply about control?
I think the main problem with Linux is the security model.
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.
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.
> 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.
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.
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.
Fuchsia was (when I left) strictly Vulkan in the core OS interfaces for the rendering stack. Picking one technology rather than pulling over several reduces the overall cost of solving for sandboxing that technology. There is still plenty to do in the Vulkan space though - where Chrome solved for webgl we don't yet have a full equivalent for Vulkan, and in some ways Vulkans design has things that make this extra painful (ICDs).
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...
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...
Thanks for the insight, this is pretty interesting. I'm not surprised that Vulkan is a special case considering Fuchsia is using more-or-less off-the-shelf drivers if I understood correctly.
Drivers vary. The intel driver that Fuchsia has was written early on entirely by the team. (This was when I left the only OSS Vulkan driver in the system)
Thats the current model, yes. But it needn't be that way. The application could simply say "I want a textbox here, and that animation there", and then another UI-drawing-process does the actual rendering.
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.
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.
But basically every app with UI requires 3D rendering because that's how 2D toolkits are implemented these days too.
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.
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.
That separate process would probably end up much more complex than today's kernel drivers.
Doubtful? You can read the source of the GPU process in Chrome. Drivers are more complex.
Diving into the origin story, as one reading the usenet posts of the day and hacking non standard OS's ..
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].
[1] https://en.wikipedia.org/wiki/Multics
[2] https://en.wikipedia.org/wiki/EROS_(microkernel)
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].
[1] https://en.wikipedia.org/wiki/Multics
[2] https://en.wikipedia.org/wiki/EROS_(microkernel)
> I think the main problem with Linux is the security model.
Does Apple have the same problem with iOS and its BSD heart?
Does Apple have the same problem with iOS and its BSD heart?
Kinda, although most of their new stuff is built on Mach ports, which allows construction of far more complex permissions systems.
> Is there something fundamentally bad that Linux does that requires a new OS to fix?
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
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
Good discussion from the other month, on how Unix hegemony has caused stagnation in OS research: https://news.ycombinator.com/item?id=33740235
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.
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.
> Is there something fundamentally bad that Linux does that requires a new OS to fix?
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.
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'm sorry for being rude here, but your understanding is obviously flawed. Even a cursory glance at the project would let you know that this wasn't the case. There are a bunch of obviously interesting ideas in Fuchsia that may or may not be useful in the long term, but describing it as being "simply about control" is just lazy as hell.
Well, I don't think that you're rude, and you might be correct from your point of view. I completely respect your views.
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).
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).
The Linux driver ABI makes Android ROM upgrades an absolute nightmare afaik.
there might be various aspects considered "novel" but the angle I was intrigued conceptually (though not an expert in this area) is about memory safety and security. So Rust is somehow involved [0], thus breaking with the C heritage of linux (though apparently not exclusively) and another advertised security enhancement is object capabilities [1],[2] which is an old idea but apparently not widely implemented. To further confuse things there is also KataOS and involvement in sel4 [3]
[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-...
[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-...
Well for one, it's a time sharing operating system. What does that bring to a phone other than potential security vulnerabilities?
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.
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.
As others have pointed out, it's the security model. As a matter of project governance, linux could not be changed in the way required. It's too far from its original mission, and backwards compatibility is a reason for its success, and a core value of the project.
+1 to what @bayindirh said. In linux driver api is not fixed that makes it very difficult to upgrade kernel in android as soc vendors don't want to make changes to support their devices due to commercial reasons (because once soc is sold they don't see any dime).
I do know that Linux is not an RTS (Real-Time Operating System). Not sure if Fuchsia is (or can be easily modded as one).
For normal computers and phones/communication devices, this is no big deal, but it does limit usefulness in IoT.
For normal computers and phones/communication devices, this is no big deal, but it does limit usefulness in IoT.
Most of the IoT does not care about real time, maybe if you run on the audio controller - but there you have Zephyr now.
I've done work with digicams and surveillance cameras. RT makes a fairly significant difference, there.
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.
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.
From the look of it, it will be in the Google Graveyard soon. Clearly this OS failed expectations.
I'm more worried that if Fuchsia goes, Flutter will go with it too. Flutter is actually a useful framework.
Companies that bet big on flutter are in for a world of pain when google abandons it.
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
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
Not useful enough for Google to use in most of their own cross platform apps…
https://9to5google.com/2021/10/10/google-ios-apps-native/
https://9to5google.com/2021/10/10/google-ios-apps-native/
Aside from that article being quite old, the newest version of Flutter has tons of fixes for iOS. Although at the moment it's mostly used for internal apps.
So you think Google decided to reverse course again and depend on cross platform frameworks?
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.
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.
We're using Flutter for plenty of apps internally. Just yesterday we showed off Google Classroom, which has just been rewritten using Flutter for both iOS and Android. Classroom also uses Flutter for the web-based practice sets. https://www.youtube.com/watch?v=JVJF_M9bgj4
(Disclosure: I work on the Flutter team.)
(Disclosure: I work on the Flutter team.)
The only one I can think of is Stadia... which was killed this week.
My money's on Kotlin Cross platform being the viable longterm solution.
300+ is still an enormous team.
The OS was never deployed on a production phone, what expectations were there?
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.
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.
Java was literally designed for washing machines, and look how it evolved.
Java was designed for a lot of applications and branched outward. Fuchsia was designed to replace Android and is instead being used for appliances. A sector that LG, Oracle, and many other appliance manufacturers and software companies are already well invested into.
The future for this OS doesn't look very bright.
The future for this OS doesn't look very bright.
Not necessarily. They made substantial effort to make it ready. It seems more a low priority because there are already other solutions like Linux. Now with chatgpt and other, google is trying to focus her attention on the present and not in the future, which is more important. It's all about the money.
I wonder if some people would carry on this thing? I mean it's open source, you can just hire people and work on it. It's sad to see years of extremely high-qualified man-work go down the toilet.
Even something as simple as porting Debian to Fuchsia might be enough to keep it interesting.
Even something as simple as porting Debian to Fuchsia might be enough to keep it interesting.
They have been working on Fuscia forever and no signs of shipping, one of many projects that seem to be designed to entertain very expensive talent to keep them busy.
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.
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.
> They have been working on Fuscia forever and no signs of shipping, one of many projects that seem to be designed to entertain very expensive talent to keep them busy.
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...
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...
Indeed, I would also argue it is shipped. They may not want outsiders to deploy it yet, and ChromeOS and Android ideally need to run existing Android apps before it can ship to end users, so that it can take from the existing ecosystem of apps. That would be the killer feature to ensure initial adoption.
Any news from the Flutter team?
Obviously a tough week for everyone at Google. But we're looking forward to sharing our roadmap and plans at our Flutter Forward event later today: https://flutter.dev/events/flutter-forward#schedule
Consider salary decreasing instead of layoffs. I'm pretty sure most of 500K-700K+ H1B people would prefer downgrading to 150K-200K instead of deportation. In these days of remote work, many would happily move out of SF/Bay Area to e.g. Oklahoma.
There are so many video ads on that page. I couldn't read the article; it was too distracting. Ars sure has changed.
I like Ars, but I have to ad block them. It's quite the conundrum because I want them to succeed, but those ads are annoying...
They have an ad-free subscription thing https://arstechnica.com/store/product/subscriptions/ where all the features seem to amount to "we removed all the crap" which I think is sorta funny.
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.
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.
Googlers pride themselves in an ability to execute multi years project.
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.
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.
I think google is more famous for executing (killing) multi year projects than for executing (successfully conpleting) them.
Does anyone have an idea of how much the layoffs affected the Dart / Flutter project?
Fuchsia was supposed to be a step up on OS security with ocap technologies and what not?
If this is the case, is Dart + Flutter a sinking ship?
Anyone building their entire business on top of an app that's built on top of flutter is going to be in for a world of pain when google kills it.
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.
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.
It would have been cheaper to acquire QNX
Previously:
Google Fuchsia OS team affected by layoffs: https://news.ycombinator.com/item?id=34473500 (3 days ago)
Google Fuchsia OS team affected by layoffs: https://news.ycombinator.com/item?id=34473500 (3 days ago)
Another thing could be that many components and processes are now well established and do not need constant iteration. These mass layoffs would be appropriate time to let part of team go.
I don't have a crystal ball but Fuchsia seems like it's dead on arrival. Most likely anything gained from the project will be rolled into Android.
isnt that good? fuchsia success means death of linux, similar to how chrome success meant death of firefox (purely because of funding and power)
[deleted]
Fuchsia is one of Google's most interesting products, so these layoffs put out a huge question mark.
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.
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.
Any news about the AMPhtml team?
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.