8 ms·

Ok, so Fuchsia is not the Linux killer we were worried about.

dmitrygr 3y ago
It never was. it was a staff retention project from the start. It walked like that, quacked like that, and smelled like that...
- IshKebab 3y ago
  What is a "staff retention project"? Companies don't generally spin up 400-employee divisions just so they can keep hold of employees. This was clearly intended to eventually replace Android and ChromeOS. The layoffs are likely because someone high up freaked out about how many people were working on a very very long term strategic project. I would guess dropping native Chrome is because it's a ton of work and they don't need it, at least not for a long time. They can use Flutter for embedded devices, and if they support Android they can just run Chrome for Android.
  - dmitrygr 3y ago
    > Companies don't generally spin up 400-employee divisions just so they can keep hold of employees. Back in ZIRP days, Google did. I was there and saw it firsthand. Were you? I know the initial team that started this. Very smart folks. But there was never a shred of future there. When they tried to convince me to join the team, there was no answer to my question of "who would use this and why?". Android compat would never happen without a vm or container (in which case all the fancy privilege control is useless since all the sensitive data is INSIDE the container that MUST act linux-like and not fancy-priviledge-separation-like). And nobody would rewrite all the apps of the world to fit the new paradigm, as seen by chrome dropping this target finally, and by the failure of much-better-sponsored windows phone OS. Given that even the team had no clear answer to what they were doing and why, yes, the conclusion is that they were permitted to do this just to keep them off market to competitors, and available should they be needed elsewhere at Google. This also explains why there were layoffs in the team once the free money ended, and it expains this article here too.
    - dmazzoni 3y ago
      I was at Google then too. I had the same questions when I was asked to work on the team or even just collaborate with the team on Chrome support. I think it would have been fine to just throw the Android runtime in a container. That wouldn't be useless - it was still a great opportunity to reinvent the kernel and the Linux driver model, and all of the other parts of the system. I find the "staff retention" thing confusing. Sure, I understand talented people want some freedom and flexibility, but I don't think that having a team of 400+ people go crazy for years with no plan is the only way to retain. Why not let them go crazy for a while but then force them to downscope, pick a real need and solve it with their tech? Or, why not make it more incubator-style? Instead of a team of 400, have 10 teams of 40 and give them a year to build something amazing, then turn only the top 1 or 2 into products and send the others back to the drawing board?
      - dmitrygr 3y ago
        > but then force them You worked at google. Would you say that serious top-down leadership with a vision existed in the age of Sundar? I spent time in ChromeOS and Android teams. Almost 8 years of time. The actual teams had some vision and plans, but there was NOTHING from above. So yes, it is quite believable to me. Imagine: fuchsia team wanted to fuck around for funsies. Nobody above stopped it. It is so google 2012+
    - o11c 3y ago
      > Android compat would never happen without a vm or container (in which case all the fancy privilege control is useless since all the sensitive data is INSIDE the container that MUST act linux-like and not fancy-priviledge-separation-like). VM-per-app has very real possibilities. You'd need some new logic for things like keyboard apps, but ...
      - dmitrygr 3y ago
        And for binder… permissions management… inter-app comms. Share sheets. and all other APIs… yeah… no. Not with the architecture of Android
  - dmazzoni 3y ago
    > This was clearly intended to eventually replace Android and ChromeOS I worked at Google (on the Chrome team) for years while Fuchsia was getting started. Replacing Android and Chrome OS would have made so much sense, but they were definitely NOT trying to do that. I never understood why. They had a great plan for an OS that lived in a complete vacuum, with absolutely no plan to gain adoption or transition any existing platform to it. It was literally tech for the sake of tech, and it made no sense.
    - medstrom 3y ago
      Can't speak for management, but they could've seen it as funding open-ended research. Give a bunch of nerds freedom from shipping dates, deadlines, adoption plans, customer demands, and other such things that they always complain about, then see what they come up with. It's expected that this kind of strategy will yield nothing most of the time, but eventually you get a positive Black Swan.
    - IshKebab 3y ago
      > Replacing Android and Chrome OS would have made so much sense, but they were definitely NOT trying to do that. I never understood why. Are you sure? In my experience people often say that project X isn't intended to replace project Y when it absolutely is, in order to avoid having to fight the people working on project Y. An open source example of this is WASM. When it first appeared there were countless "wasm isn't intended to replace JavaScript" claims. Of course it 100% was (for a number of use cases anyway), but people had to say that to placate the JS fanatics. It looks like Google potted ART to Fuchsia at one point.
      - dmitrygr 3y ago
        ART is a compiler. Its main OS interaction is file access. I can port it to MS-DOS for you in a week of free time. What will that prove?
spankalee 3y ago
But why would you be worried about it? The world having a great open source microkernel-based OS is a _good_ thing.
- acdha 3y ago
  This is true in some abstract sense but the value really goes up dramatically if more than a few people actually use it. There’s a strong feedback loop around having drivers or being able to run common code, and that’s why many people were hoping that Google had a strategy since there aren’t that many projects with the resources to push through the early iterations of those problems.
- rossy 3y ago
  I don't think having a great liberally-licenced microkernel-based OS is as good for the world in a practical sense compared to forcing every Android and Chromebook vendor to publish the changes they made to a copyleft monolithic kernel. I can totally understand being worried that the rise of Fuchsia would result in a dark age for running alternative open source OSes on cheap consumer smartphones, SBCs and ARM64 laptops.
  - google234123 3y ago
    Vendors don’t publish source code now lol
    - rossy 3y ago
      Some do. If the current state of things is what happens when vendors are required to publish their source by law, imagine how much worse it would be if they weren't - there'd be nothing. What little we have of FOSS OSes on cheap consumer devices would be gone. Imagine no LineageOS, no community-supported postmarketOS devices, no installing mainline Linux on old Chromebooks etc.

It never was. it was a staff retention project from the start. It walked like that, quacked like that, and smelled like that...

IshKebab 3y ago
What is a "staff retention project"? Companies don't generally spin up 400-employee divisions just so they can keep hold of employees. This was clearly intended to eventually replace Android and ChromeOS. The layoffs are likely because someone high up freaked out about how many people were working on a very very long term strategic project. I would guess dropping native Chrome is because it's a ton of work and they don't need it, at least not for a long time. They can use Flutter for embedded devices, and if they support Android they can just run Chrome for Android.
- dmitrygr 3y ago
  > Companies don't generally spin up 400-employee divisions just so they can keep hold of employees. Back in ZIRP days, Google did. I was there and saw it firsthand. Were you? I know the initial team that started this. Very smart folks. But there was never a shred of future there. When they tried to convince me to join the team, there was no answer to my question of "who would use this and why?". Android compat would never happen without a vm or container (in which case all the fancy privilege control is useless since all the sensitive data is INSIDE the container that MUST act linux-like and not fancy-priviledge-separation-like). And nobody would rewrite all the apps of the world to fit the new paradigm, as seen by chrome dropping this target finally, and by the failure of much-better-sponsored windows phone OS. Given that even the team had no clear answer to what they were doing and why, yes, the conclusion is that they were permitted to do this just to keep them off market to competitors, and available should they be needed elsewhere at Google. This also explains why there were layoffs in the team once the free money ended, and it expains this article here too.
  - dmazzoni 3y ago
    I was at Google then too. I had the same questions when I was asked to work on the team or even just collaborate with the team on Chrome support. I think it would have been fine to just throw the Android runtime in a container. That wouldn't be useless - it was still a great opportunity to reinvent the kernel and the Linux driver model, and all of the other parts of the system. I find the "staff retention" thing confusing. Sure, I understand talented people want some freedom and flexibility, but I don't think that having a team of 400+ people go crazy for years with no plan is the only way to retain. Why not let them go crazy for a while but then force them to downscope, pick a real need and solve it with their tech? Or, why not make it more incubator-style? Instead of a team of 400, have 10 teams of 40 and give them a year to build something amazing, then turn only the top 1 or 2 into products and send the others back to the drawing board?
    - dmitrygr 3y ago
      > but then force them You worked at google. Would you say that serious top-down leadership with a vision existed in the age of Sundar? I spent time in ChromeOS and Android teams. Almost 8 years of time. The actual teams had some vision and plans, but there was NOTHING from above. So yes, it is quite believable to me. Imagine: fuchsia team wanted to fuck around for funsies. Nobody above stopped it. It is so google 2012+
  - o11c 3y ago
    > Android compat would never happen without a vm or container (in which case all the fancy privilege control is useless since all the sensitive data is INSIDE the container that MUST act linux-like and not fancy-priviledge-separation-like). VM-per-app has very real possibilities. You'd need some new logic for things like keyboard apps, but ...
    - dmitrygr 3y ago
      And for binder… permissions management… inter-app comms. Share sheets. and all other APIs… yeah… no. Not with the architecture of Android
- dmazzoni 3y ago
  > This was clearly intended to eventually replace Android and ChromeOS I worked at Google (on the Chrome team) for years while Fuchsia was getting started. Replacing Android and Chrome OS would have made so much sense, but they were definitely NOT trying to do that. I never understood why. They had a great plan for an OS that lived in a complete vacuum, with absolutely no plan to gain adoption or transition any existing platform to it. It was literally tech for the sake of tech, and it made no sense.
  - medstrom 3y ago
    Can't speak for management, but they could've seen it as funding open-ended research. Give a bunch of nerds freedom from shipping dates, deadlines, adoption plans, customer demands, and other such things that they always complain about, then see what they come up with. It's expected that this kind of strategy will yield nothing most of the time, but eventually you get a positive Black Swan.
  - IshKebab 3y ago
    > Replacing Android and Chrome OS would have made so much sense, but they were definitely NOT trying to do that. I never understood why. Are you sure? In my experience people often say that project X isn't intended to replace project Y when it absolutely is, in order to avoid having to fight the people working on project Y. An open source example of this is WASM. When it first appeared there were countless "wasm isn't intended to replace JavaScript" claims. Of course it 100% was (for a number of use cases anyway), but people had to say that to placate the JS fanatics. It looks like Google potted ART to Fuchsia at one point.
    - dmitrygr 3y ago
      ART is a compiler. Its main OS interaction is file access. I can port it to MS-DOS for you in a week of free time. What will that prove?

spankalee 3y ago

But why would you be worried about it? The world having a great open source microkernel-based OS is a _good_ thing.

acdha 3y ago
This is true in some abstract sense but the value really goes up dramatically if more than a few people actually use it. There’s a strong feedback loop around having drivers or being able to run common code, and that’s why many people were hoping that Google had a strategy since there aren’t that many projects with the resources to push through the early iterations of those problems.
rossy 3y ago
I don't think having a great liberally-licenced microkernel-based OS is as good for the world in a practical sense compared to forcing every Android and Chromebook vendor to publish the changes they made to a copyleft monolithic kernel. I can totally understand being worried that the rise of Fuchsia would result in a dark age for running alternative open source OSes on cheap consumer smartphones, SBCs and ARM64 laptops.
- google234123 3y ago
  Vendors don’t publish source code now lol
  - rossy 3y ago
    Some do. If the current state of things is what happens when vendors are required to publish their source by law, imagine how much worse it would be if they weren't - there'd be nothing. What little we have of FOSS OSes on cheap consumer devices would be gone. Imagine no LineageOS, no community-supported postmarketOS devices, no installing mainline Linux on old Chromebooks etc.