For better or for worse, that's what Google is aiming at with ChromeOS. Especially now that the overarching "OS" is really just a Linux shell for multiple VMs.
People often claim that ChromeOS is versatile enough to replace a normal computer because it has these various compatibility layers. They often fail to mention that they work terribly. You wind up with the poor performance and annoying isolation that VMs give, but with an extra helping of instability and incompatibility. Running anything Google hasn't approved is gated behind "developer mode", and even for a developer the pseudo-Debian container "developer mode" unlocks is confusing. I regularly encounter problems (like needing to run Wireshark) that I believe are simply unsolvable.
I don't understand anything about ChromeOS. At one point it was a bad but clear idea: a machine with just a web browser, capable only of running web apps. Then at some point they decided to just make the world's most complicated and confusing Linux distro, with the vestigial browser-centric design kept around just to make things as inconsistent as possible.
You could just as easily construct an arbitrary usability test over interop that the web platform excels at while current desktop apps do terribly. For instance:
* Send a link to a Google Drive document to another person on WeChat: Pass
* Send a link to a Microsoft Word document to another person on Slack: Fail
The web has different paradigms and some of them are an improvement, one being hyperlinks, another being instant delivery just for example (no install time).
> Running anything Google hasn't approved is gated behind "developer mode", and even for a developer the pseudo-Debian container "developer mode" unlocks is confusing.
This is mixed up. "Developer mode" is a firmware mode that allows you to run unsigned images. You use that if you want to hack your ChromeOS image itself. The Linux development environment feature (crostini) runs in a VM on any chromebook, it doesn't require developer mode or any firmware features. Technologically it's basically the same thing as WSL, though integrated much better with the OS UI.
Versatile is the opposite of what ChromeOS has become. I would argue that there was a time (beginning of pandemic) where it looked like Google might strike the perfect balance between web-reliant (PWAs and safer extensions) and legacy-OS supported (Android, Linux, and even some slight Windows compatibility).
Now, it just seems like a bad version of the legacy operating systems. Android, but in a VM, Linux, but in a VM, and Windows delivered via the cloud!
All of this is worse than just running any of those systems alone.
FWIW: native audacity (literally the debian package) runs in ChromeOS as a wayland/somellier client from crostini. Basically everything not tied to particular driver or hardware environments runs great.
The whole OS is really the best "app fusion" desktop environment out there. I've got Android apps for Threads and Tesla running alongside all the web apps you'd expect to find. I've got my personal email via linux Thunderbird. I read my PDFs in Evince (because, let's be honest, both the Chrome and Adobe readers are junk) and it integrates with the native ChromeOS Files app like a normal app. In fact all the Gnome .desktop files in the Crostini personality appear as apps in the OS menu that can be associated with files types or pinned to the shelf, so there's a surprising amount of scriptability to the process. Likewise it makes a great X terminal for shells and emacs windows from development machines.
In fact I've moved (to be fair: for professional reasons, and I resisted for quite a while) to a mid-tier junky old Chromebook for basically all my client activity at this point (windows games being the sole exception). Really it's pretty great. The proverbial year of Linux on the desktop arrived and won while we were all looking elsewhere.
Unfortunately, Fugu is totally seperate from ChromeOS, since many of Fugus capabilities don't work on the platform. Still, on Windows and Mac, Fugu is definitely more impressive than anything ChromeOS is doing.
Obviously yes, there are going to be platform-dependencies with any platform abstraction API, and different platforms support different things. For sure Android is "primary" for most of these and it is doing the best, but the other platforms seem pretty well-supported, with no particular winner that I'm seeing. Is there something specific you're wanting and not getting?
Then it is correct? Many of the Fugu APIs don't work.
I didn't say none.
You can always tell someone hasn't developed consumer apps for ChromeOS when they white knight for it.
If you want to know a specific API that DOESN'T work, but performs splendidly on Windows, then the Eyedropper is a perfect example.
There's an old bug report for it that even has Google Chrome team support, and still no dice.
But yeah, keep rushing to defend the platform that doesn't even get proper support from its creators.
Another example is given in the link you posted. Direct Sockets API is deprecated, but its replacement isn't available yet.
So, if you were a web-dev using "vanilla" ChromeOS to test a site, you better install a full Debian VM on your 4 gb machine, because there's no other way to spin up a server.
No, I think it was correct to say Fugu is NOT for ChromeOS.
> Then it is correct? Many of the Fugu APIs don't work. I didn't say none
You claimed that support was significantly worse than on Mac or Windows, and the chart certainly doesn't bear that out.
And your examples seem... pretty cherry picked? I mean, there's junk that fails everywhere. If color pickers are core to your job, then... OK, I guess. It's a hole. It doesn't seem to remotely justify the kind of bile and hatred you're deploying here.
I gave another example as well. I'm also not spewing any "hate" or "bile" for an inanimate operating system.
To make this easier to understand, please give me an example of what's missing from Mac or Windows and I'll share the way it can easily be accomplished in a native environment. After that, we can try to do the same for ChromeOS and you'll see where the holes appear.
Fugu is about slowly moving Mac and Windows functions to the web, but ChromeOS exists RIGHT NOW. Thus, if it were for that platform, there would be urgency and full support across the board. Because they don't care about filling all those holes, they choose not to support every API.
That was my point. Windows and Mac don't need Fugu to function. ChromeOS does. Still, Windows and Mac needs are prioritized over ChromeOS.
I also noticed you deftly ahem cherry-picked around the lack of server support on a web-first operating system, but that's neither here nor there.
> To make this easier to understand, please give me an example of what's missing from Mac or Windows and I'll share the way it can easily be accomplished in a native environment. After that, we can try to do the same for ChromeOS and you'll see where the holes appear.
Which is kinda what I thought. This isn't about your upthread point about Fugu. You're doing a platform advocacy thing, which I'm not interested in. I jumped in to point out that it's simply not true that Fugu is poorly supported in ChromeOS, because it's not. I'm not trying to have a fight about platforms.
https://chromium.googlesource.com/chromium/src/+/main/docs/l...