4 ms·

I was never that close to the Fuchsia project, but knew quite a few people who worked on it. My understanding from them was, as much as I can remember it now,

I was never that close to the Fuchsia project, but knew quite a few people who worked on it. My understanding from them was, as much as I can remember it now, something like: 1. That yes, Fuchsia was originally intended, by at least some in senior leadership on the team, to replace both Android and ChromeOS. This is why Fuchsia had a mobile shell (or two?) at one point. 2. The Android team wasn't necessarily on board with this. They took a lot of ideas from Fuchsia and incorporated them into Android instead. 3. When Platforms were consolidated under Hiroshi it brought the Android and Fuchsia teams closer together in a way that didn't look great for Fuchsia. Hiroshi had already been in charge of Android and was presumed to favor it. People were worried that Hiroshi was going to kill Fuchsia. 4. Fuchsia pivoted to Nest devices, and a story of replacing just the kernel of Android, to reduce the conflict with the Android team. 4a. The Android team was correct on point (2) because it's either completely infeasible or completely dumb for Google to launch a separate competitor to Android, with a new ecosystem, starting from scratch. To work around the ecosystem problem, originally Android apps were going to be run in a Linux VM, but that was bad for battery and performance. Starnix was started to show that Fuchsia could run Linux binaries in a Fuchsia component. 5. Android and ChromeOS are finally merging, and this _might_ mean that Android gets some of the auto-update ability of ChromeOS? Does that make the lower layer more suitable for Nest devices and push Fuchsia out there too? Again, I was a pretty removed from the project, but it seemed too simplifying to say that Fuchsia either was never intended to replace Android, or always intended to replace Android. It changed over time and management structures.

cflewis 2y ago
I worked on Fuchsia engprod for a while. I am still employed at Google and can't talk about anything that isn't publicly available already (which really means anything gleaned from commits to the Git repo). I think the best way to look at it is like any software: there's Fuchsia The Artifact (thing that is made) and Fuchsia The Product (how thing is used, and how widely). I don't know anything about operating systems, but my understanding is that the engineers are very happy with Fuchsia The Artifact. Fuchsia The Product has had some wandering in the wilderness years.
raggi 2y ago
You got the high drama stories with the timelines re-arranged to fit the narrative :D Fuchsias underlying goals are to be a great platform for computing. This is distilled in its current incantation into a short tagline on fuchsia.dev: simple, secure, updatable, performant. The details of how when and where Fuchsia might fit / gets exercised are nuanced and far more often about other factors than those which make great stories. Maybe there will be some of the good stories told one day, but that'll need someone from the team to finish a book and take it through the Google process to publish :D In the meantime, here's Chris interview: https://9to5google.com/2022/08/30/fuchsia-director-interview-chris-mckillop/ https://9to5google.com/2022/08/30/fuchsia-director-interview...
- saagarjha 2y ago
  Look I understand the context here but if you're going to go around saying "a great platform for computing" it's not really telling me much about the project.
  - lukan 2y ago
    It is a OS. Intended to run on mainstream devices. Main difference to Linux: stable driver API. So vendors could make their blobs and support them easier, without open sourcing, like linux demands.
    - PaulDavisThe1st 2y ago
      Stable driver API and open source/GPL'ed drivers are orthogonal. They are both significant for some companies in deciding whether to support Linux, but they are independent from each other. If Linux ever had a stable driver API, the GPL requirement would still cause some vendors to not provide drivers for Linux. If Linux dropped the GPL requirement (such as it is), but did not promise a stable driver API, some vendors would still choose not to provide drivers for Linux.
  - raggi 2y ago
    fuchsia.dev has literally hundreds of pages of detailed content, I’m not going to rewrite it all in an HN comment
pfannkuchen 2y ago
> Fuchsia pivoted to Nest devices, and a story of replacing just the kernel of Android, to reduce the conflict with the Android team This is like a textbook example of weak leadership of an executive team. The power jockeying of a fiefdom’s chieftain (power reduction mitigation in this case) is allowed to drive the organizational structure and product strategy.
- geodel 2y ago
  "Google force replace Android kernel with Fuchsia and hit some teething troubles". This is example of technically incompetent clueless leadership. That's why MBAs should not be in control in technical companies. They have ruined a product running on billion devices by replacing rock solid kernel with immature experimental project. And so on...
  - surajrmal 2y ago
    Why do you think fuchsia is immature and/or experimental? It's been iterated on for nearly a decade and is deployed on millions of devices. Also why do you believe there are any MBAs involved in any decision making? Your understanding of how Google works seems to rely on faulty assumptions. It's also not clear why you seem to wish for Fuchsia to fail - having a Linux monoculture has all the same issues many folks argue against with other monocultures. Fuchsia succeeding will lead to improvements in all OS as they learn from each others advantages.
IshKebab 2y ago
Yeah the "was never meant to replace" here sounds exactly like the placation we got with wasm - "it's not meant to replace JavaScript" (it totally is).
- mdhb 2y ago
  Is it? I don’t think those statements are incompatible in either example. In both scenarios we are looking at very meaningful leaps forward in terms of the underlying architecture and what that enables that simply aren’t possible within the boundaries of what is out there currently. I don’t think that’s the same thing as “meant to replace” at all though.
- josephg 2y ago
  > "it's not meant to replace JavaScript" The word meant is doing a lot of heavy lifting here. Meant - by who? The technology itself doesn’t want anything. Do some people want to use wasm instead of JavaScript for websites? Yes. Will JS ever be removed from web browsers? Probably not, no. Wasm isn’t a grand design with a destiny it’s “meant to” reach. It’s actually just some code written by a bunch of people trying to solve a bunch of disparate problems. How well wasm solves any particular problem depends on the desires and skills of the people in the room, pushing the technology forward. It’s kind of like that for everything. Rust was never meant to be a high performance systems language by its original creator. But the people in the room pushed it in that direction. Fuscia could replace Linux in Android. I’m sure some people want that to happen, and some people don’t. There’s no manifest destiny. What actually happens depends on a lot of arguing in meeting rooms somewhere. How that turns out is anyone’s guess!
  - IshKebab 2y ago
    > Meant - by who? The technology itself doesn’t want anything. The people who created the project and who are writing the code, obviously. This is clear from the context; you don't need to nitpick stuff like this. > Wasm isn’t a grand design with a destiny it’s “meant to” reach. Yes it is. The destiny is being able to create dynamic websites with languages other than Javascript. The first step was Asm.js which allowed compiling other languages to Javascript. Then we got WASM which compiles them to a binary format instead. But you still need some Javascript glue to interact with the DOM APIs. And now there are extensions in progress that will remove that requirement (GC, reference types etc). > Rust was never meant to be a high performance systems language by its original creator. Yeah citation needed. The very first compiler release already described it as "a strongly-typed systems programming language with a focus on memory safety and concurrency." https://web.archive.org/web/20130728230358/https://mail.mozilla.org/pipermail/rust-dev/2012-January/001256.html https://web.archive.org/web/20130728230358/https://mail.mozi... Even before that the website described it as "a programming language for low-level, safe code." https://web.archive.org/web/20110924054534/http://www.rust-lang.org/ https://web.archive.org/web/20110924054534/http://www.rust-l...
tmp-fuchsia 2y ago
That’s a narrative I’ve heard before, and there’s probably some truth to it. There’s the product side, and there’s the technical side. I’m not sure what qualifies as “senior leadership,” but when a VP finally stepped into the org, all the ambitious product ideas were cut, and we landed on Nest as a product. Until then, I believe it was mostly courtship and sales pitches (I wasn’t in the room). Apologies if this comes across as harsh, but Fuchsia always seemed to suffer from poor product judgment. I think it’s only healthy to acknowledge that. That said, it’s not entirely surprising—good product people don’t tend to stay very long at Google. Yes, there was a mobile shell briefly. There was also a desktop shell. I think the narrative you’re describing could be better framed as a series of attempts and experiments to see if Fuchsia could find a use case and client. That doesn’t necessarily mean there was a concrete plan that was seriously contended or scrutinized. Just to clarify, these are my personal opinions and observations. I don’t actually know what went on behind closed doors, but I’m not sure it’s all that useful to know either, for the reasons I mentioned above.

cflewis 2y ago

I worked on Fuchsia engprod for a while. I am still employed at Google and can't talk about anything that isn't publicly available already (which really means anything gleaned from commits to the Git repo). I think the best way to look at it is like any software: there's Fuchsia The Artifact (thing that is made) and Fuchsia The Product (how thing is used, and how widely). I don't know anything about operating systems, but my understanding is that the engineers are very happy with Fuchsia The Artifact. Fuchsia The Product has had some wandering in the wilderness years.

raggi 2y ago

You got the high drama stories with the timelines re-arranged to fit the narrative :D Fuchsias underlying goals are to be a great platform for computing. This is distilled in its current incantation into a short tagline on fuchsia.dev: simple, secure, updatable, performant. The details of how when and where Fuchsia might fit / gets exercised are nuanced and far more often about other factors than those which make great stories. Maybe there will be some of the good stories told one day, but that'll need someone from the team to finish a book and take it through the Google process to publish :D In the meantime, here's Chris interview: https://9to5google.com/2022/08/30/fuchsia-director-interview-chris-mckillop/ https://9to5google.com/2022/08/30/fuchsia-director-interview...

saagarjha 2y ago
Look I understand the context here but if you're going to go around saying "a great platform for computing" it's not really telling me much about the project.
- lukan 2y ago
  It is a OS. Intended to run on mainstream devices. Main difference to Linux: stable driver API. So vendors could make their blobs and support them easier, without open sourcing, like linux demands.
  - PaulDavisThe1st 2y ago
    Stable driver API and open source/GPL'ed drivers are orthogonal. They are both significant for some companies in deciding whether to support Linux, but they are independent from each other. If Linux ever had a stable driver API, the GPL requirement would still cause some vendors to not provide drivers for Linux. If Linux dropped the GPL requirement (such as it is), but did not promise a stable driver API, some vendors would still choose not to provide drivers for Linux.
- raggi 2y ago
  fuchsia.dev has literally hundreds of pages of detailed content, I’m not going to rewrite it all in an HN comment

pfannkuchen 2y ago

> Fuchsia pivoted to Nest devices, and a story of replacing just the kernel of Android, to reduce the conflict with the Android team This is like a textbook example of weak leadership of an executive team. The power jockeying of a fiefdom’s chieftain (power reduction mitigation in this case) is allowed to drive the organizational structure and product strategy.

geodel 2y ago
"Google force replace Android kernel with Fuchsia and hit some teething troubles". This is example of technically incompetent clueless leadership. That's why MBAs should not be in control in technical companies. They have ruined a product running on billion devices by replacing rock solid kernel with immature experimental project. And so on...
- surajrmal 2y ago
  Why do you think fuchsia is immature and/or experimental? It's been iterated on for nearly a decade and is deployed on millions of devices. Also why do you believe there are any MBAs involved in any decision making? Your understanding of how Google works seems to rely on faulty assumptions. It's also not clear why you seem to wish for Fuchsia to fail - having a Linux monoculture has all the same issues many folks argue against with other monocultures. Fuchsia succeeding will lead to improvements in all OS as they learn from each others advantages.

IshKebab 2y ago

Yeah the "was never meant to replace" here sounds exactly like the placation we got with wasm - "it's not meant to replace JavaScript" (it totally is).

mdhb 2y ago
Is it? I don’t think those statements are incompatible in either example. In both scenarios we are looking at very meaningful leaps forward in terms of the underlying architecture and what that enables that simply aren’t possible within the boundaries of what is out there currently. I don’t think that’s the same thing as “meant to replace” at all though.
josephg 2y ago
> "it's not meant to replace JavaScript" The word meant is doing a lot of heavy lifting here. Meant - by who? The technology itself doesn’t want anything. Do some people want to use wasm instead of JavaScript for websites? Yes. Will JS ever be removed from web browsers? Probably not, no. Wasm isn’t a grand design with a destiny it’s “meant to” reach. It’s actually just some code written by a bunch of people trying to solve a bunch of disparate problems. How well wasm solves any particular problem depends on the desires and skills of the people in the room, pushing the technology forward. It’s kind of like that for everything. Rust was never meant to be a high performance systems language by its original creator. But the people in the room pushed it in that direction. Fuscia could replace Linux in Android. I’m sure some people want that to happen, and some people don’t. There’s no manifest destiny. What actually happens depends on a lot of arguing in meeting rooms somewhere. How that turns out is anyone’s guess!
- IshKebab 2y ago
  > Meant - by who? The technology itself doesn’t want anything. The people who created the project and who are writing the code, obviously. This is clear from the context; you don't need to nitpick stuff like this. > Wasm isn’t a grand design with a destiny it’s “meant to” reach. Yes it is. The destiny is being able to create dynamic websites with languages other than Javascript. The first step was Asm.js which allowed compiling other languages to Javascript. Then we got WASM which compiles them to a binary format instead. But you still need some Javascript glue to interact with the DOM APIs. And now there are extensions in progress that will remove that requirement (GC, reference types etc). > Rust was never meant to be a high performance systems language by its original creator. Yeah citation needed. The very first compiler release already described it as "a strongly-typed systems programming language with a focus on memory safety and concurrency." https://web.archive.org/web/20130728230358/https://mail.mozilla.org/pipermail/rust-dev/2012-January/001256.html https://web.archive.org/web/20130728230358/https://mail.mozi... Even before that the website described it as "a programming language for low-level, safe code." https://web.archive.org/web/20110924054534/http://www.rust-lang.org/ https://web.archive.org/web/20110924054534/http://www.rust-l...

tmp-fuchsia 2y ago

That’s a narrative I’ve heard before, and there’s probably some truth to it. There’s the product side, and there’s the technical side. I’m not sure what qualifies as “senior leadership,” but when a VP finally stepped into the org, all the ambitious product ideas were cut, and we landed on Nest as a product. Until then, I believe it was mostly courtship and sales pitches (I wasn’t in the room). Apologies if this comes across as harsh, but Fuchsia always seemed to suffer from poor product judgment. I think it’s only healthy to acknowledge that. That said, it’s not entirely surprising—good product people don’t tend to stay very long at Google. Yes, there was a mobile shell briefly. There was also a desktop shell. I think the narrative you’re describing could be better framed as a series of attempts and experiments to see if Fuchsia could find a use case and client. That doesn’t necessarily mean there was a concrete plan that was seriously contended or scrutinized. Just to clarify, these are my personal opinions and observations. I don’t actually know what went on behind closed doors, but I’m not sure it’s all that useful to know either, for the reasons I mentioned above.