Google is no longer bringing the full Chrome browser to Fuchsia
9to5google.com
9to5google.com
The team had some of Google's most brilliant engineers working on it. Technically, they had some really impressive stuff.
However, I don't think anyone was ever able to articulate to me its path to success. In other words - let's say you build an amazing, powerful new operating system. How do you actually get anyone to adopt it?
What frustrated me is that there wasn't even an answer for Android or Chrome OS. Why build a new operating system that wouldn't even be relevant or useful for those, the two platforms that Google had total 100% control over?
If I had been in charge of the world, I would have taken a more pragmatic approach. Chrome OS was the obvious first target - it was built on Linux but it didn't have to be. The operating system really only has a tiny number of native binaries that need to run on it:
* Chrome * The Chrome OS GUI (which shares a lot of code with Chrome but is distinct) * The Android VM * A Linux VM
If you port those four to run on another operating system, then you're done. You could start shipping Chrome OS devices based on that new OS.
I think it also would have been reasonable to have a goal to port Android to run on it, basically replace the Linux kernel. Probably it would have been necessary to add some Linux compatibility layer to enable Linux drivers for some number of years, with the goal of eventually shipping devices that don't require Linux.
But the Fuchsia team wanted to build a complete operating system from scratch, including a whole new GUI, a whole new developer SDK, and more.
Why???
When they were finally forced to ship something useful, they shipped the Nest Hub, which in my opinion was a big mistake. The Nest Hub based on Fuchsia does absolutely nothing that the previous one didn't do. It basically took a relatively simple, easy product and increased its maintenance burden by 100x while providing no value.
If they had chosen Chrome OS instead it could have actually provided some value in terms of performance, security, modularity, and developer APIs.
It just seems like such a waste of talent to try to reinvent everything with no plan for adoption, rather than building more incrementally and actually shipping.
Although I don't really see why they can't do that with the linux kernel, maybe the linux kernel sort of prevents them from collecting more royalties.
But I agree that making a new kernel from scratch is not really a very good idea, unless it brings big improvements, which I doubt.
I have not worked at Google. My assumption was that they wanted to avoid the GPL and avoid Linux's strick userspace backwards compatibility to get things upstreamed.
I still hear the words of a (quite incompetent and unpleasant) PM at a place I worked at in 2000-2001; we were having some problems (glitches on network traffic triggered by a GFX card interrupt) with Tru64 on Alpha machines and since we had a lot of hardware at hand we installed Linux (RedHat if memory serves) for comparison tests and the problem disappeared, so we jokingly told "well, then just ask the client to install Linux, they'll also save a lot in licenses since it's free". His reply: "Linux? Nah, that's an hobby project, the customer uses professional software". Two years later the PM had been sacked and the customer was starting to migrate everything to Linux. Too bad I already left the year before, but that's how life goes.
I recall using Linux around 2000. Calling it "hobby project" might be derogatory, but it was definitely very rough on the edges. For perspective, the infamous SCO lawsuits, which to me marks the moment Linux was officially deemed a competitor and a threat by established companies in the industry, only took off nearly a decade after this date.
Back in 2000 I wouldn't have risked my career by suggesting my company's product line should depend on it to run.
Also, a lot changes in two years, specially in IT circles. I also recall back in the early 2000s people rushed to install new development versions of distro releases because those would finally add critical feature/fix an egregious bug even at the expense of introducing regressions. Knoppix was only released late 2000, which goes to show how untested this domain was back then.
Other than that, it was something we dual booted at home by not being able to afford big UNIX.
Why???
CADT ?
It is, since 20 years, a trend in SW development: Delete and start over.
It's a bummer because Fuchsia takes everything we've learned from automatic software updates, devices that run untrusted and semi-trusted code, proprietary drivers in a OSS kernel, devices whose manufactures aren't compelled to update them, the unsuitability of the user-based security model, containers, and more and applied it to a new kernel and OS.
Fuchsia is more or less exactly the kind of trust-nothing OS architecture I want to run as an end user and as a developer who has to run a lot of random 3rd-party code locally.
My guess is that what happened is that they failed to get OEMs enthusiastic about Fuchsia. At least I assume the likes of Samsung would not be super excited about giving away control of even more of their stack to Google. And I don't think it's a recent thing either; this likely became pretty clear years ago and the project has been slowly dying ever since.
As a privacy-conscious user I'd worry more about whether the licence permits something like lineage to exist based on fuchsia. I'm sure it's more secure but more under the control of Google too who I'd put into the adversary camp. I wouldn't use it until it was first cleaned of spyware by projects like graphene or lineage. I'm not sure if the license permits this.
Money in the bank doesn't care if it comes from stuff 'normal' people is aware of, or something else.
Just like despite all issues, many here won't be aware Bell Labs and UNIX legacy now belong to Nokia.
Or how many Linux projects depend on Oracle and Microsoft money, as per contributors on their salaries.
In the case of research and semiconductor technology, typically IBM isn't out to deliver a finished product, they work with other companies who bring the end result to market. E.g., there's a joint venture between Intel and IBM to advance Intel's fabrication capabilities.
When you think of IBM as more of an R&D consulting company or custom enterprise application company it starts to make more sense. To some extent they also have an off-the-shelf product lineup, but most of the reasons to choose them involve custom solutions.
Example of a $700 million contract with Disney: https://www.computerworld.com/article/2555832/ibm-signs--730...
That looks like a fairly straight forward outsourcing / "consulting" contract rather than anything to do with R&D.
Their R&D is basically structured like a consulting gig in itself. They help people like Nvidia and Intel deliver on their products.
There are some extremely popular tech stacks like Docker and Hashicorp led by companies that are struggling to be profitable. The whole reason those technologies are popular is because they are free or cheap. Then as soon as the company starts to tighten the screws and monetize their user base, the user base crumbles.
IBM’s Disney contract is about double the size of Hashicorp’s annual revenue.
Most "Quantum Ambassadors" and similar are funded thanks to benevolence/nepotism of local management since they do not create billable hours or maintenance contracts. Adding to that, IBM's rolling out suffocating utilization targets for their employees in more and more countries which will take care of that as well.
It's a dying company.
In the 1970’s IBM was a behemoth. Yet IBM of that time was unable to translate that success meaningfully to personal PCs. In the realm of the personal PC it was Intel and Microsoft that dominated.
Similarly the Microsoft of the 2000’s was a behemoth that failed to translate that success to mobile computing.
I believe the other poster was trying to say that Google of today is like IBM of the 70’s or Microsoft of the 2000’s.
That being said IBM is different today than it was even a couple decades ago and Microsoft has changed a lot in recent years so maybe Google could become innovative again.
Some blame Sundar, personally I have no idea if it's true but it's sad to see a company that seemed so bleeding edge slowly decay like that.
OpenAI has a ton of interest right now but is also losing a lot of money annually, and a lot of AI products are hitting pain points around reliability and security which are going to require significant advances to overcome. Google appears to be flailing around trying to find something which will work, and given how much of this technology they invented that is really a strong argument for better management.
It is a shame, Fuchsia has a lot of cool ideas, I guess by having Binder, Android IPC for Treble drivers with a microkernel like approach, and Rust integration, kind of keeps some of Fuchsia's ideas on Android, leaving little else for Fuchsia, other than replacing the Linux kernel.
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.
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.
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?
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+
VM-per-app has very real possibilities. You'd need some new logic for things like keyboard apps, but ...
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.
It's expected that this kind of strategy will yield nothing most of the time, but eventually you get a positive Black Swan.
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.
> At first, the shift from workstation to workbench seems like a simple name change, but the subsequent discontinuation of Chrome for Fuchsia all but confirms that Google does not intend to release a desktop/mobile device directly powered by Fuchsia in the foreseeable future.
But then it turns around and says what seems to be: oh, but the web view will still be maintained!
> Importantly, this move has no implications for the Nest Hub lineup, which will continue to receive updates and support web-based features as normal.
Giving up on Chrome as an app, a full browser with user experience - that's one thing. But if the web engine is still alive & maintained, that feels like a fairly reversible choice. It's hard to imagine Fuschia persisting without a web engine, but that doesn't seem like what the pile of inferences in this article is saying!
And this is coming from someone who cheered for Google until I guess 2012, then gave them up but defended them until maybe 2017 - 2019 somewhere and now just hope they are never recovers.
Let them go the way of IBM: continue to exist without threatening general purpose computing.