Because despite the hyperbolic praise of the hackers here, Apple devices are worthless for some professional workloads.
Before you ask, I'm one user who has a Razer Blade 16 (4090) and Galaxy Book 4 Ultra that I use for CAD and BIM work. I'll pass on having a dedicated video editor.
Apple sells good hardware that's buoyed by a loud marketing department that covers its often pathetic software.
Mac users touting a bunch of third-party apps as solutions to obvious os problems (bartender, magnet, amphetamine, etc.) is tacit admission of that fact.
I would argue that in general, third-party apps to customize macOS are an expected part of a healthy ecosystem. I use Karabiner for keyboard customization, Moom for window management, Hidden Bar to hide the menu icons I use infrequently, and that's not a complete list. I don't think any of those need to be part of the core OS, Moom in particular is one of several ways to manage windows, it's the one I prefer but it being built-in to the OS wouldn't help me, or people who like it better some other way.
I don't consider the menu bar notch bug to be part of that general case, though. That's just a long standing bug and it's obnoxious.
App distribution is a major issue for the platform that I ran out of space to really talk about. Those driver-like things are largely extension APIs, but they were once the domain of the now deprecated "Chrome Apps." Both the Apps and Extensions are delivered via the Web Store, but I feel like there's a steady move to deprecate all system-customization on the platform.
If you want to use some non-optimized apps in a VM though, you can use the Gnome Software store or the Google Play Store.
To clarify, you can run standard linux apps in a linux VM with seamless file, wayland and X11 passtrough ("crostini"). Even nested virtualization works.
I installed Chrome OS Flex on my old laptop and I couldn't be happier, honestly. It has a really light and snappy shell, I can run all these PWA apps at once without so much as a hiccup, and I can use crostini to run Signal and VS Code. The only thing it doesn't handle is Steam, but I couldn't really play anything natively on that machine even on Windows.
And despite Linux being in a virtual machine the general experience is very seamless - I can install .deb packages by simply double clicking them in the file explorer!
Oh and most importantly, GeForce NOW works and I can still use it to play BG3 :D
(it goes without saying that the experience is much better if you're already tied to Google ecosystem, as the file explorer integrates, optionally, with Google Drive)
> I feel like there's a steady move to deprecate all system-customization on the platform.
To avoid the android type mess Chromeos is and was always in the iron grip of Google. That is the way to keep things secure. And I am glad it is so. Once you expose important APIs to the main google account - there will be tons of crap ChromeAPPS (not android but the chrome apps) that will be difficult to supervise (i.e) repeat of playstore.
Though painful and slow the aim is to move everything non-google to PlayStore. That way all crap is isolated into android.
For the commandline or linux person, the VM is always there.
Unfortunately, Android runs in a VM now, too. In many tasks, I've gotten better performance from Linux apps than Android counterparts.
There's also the fact that the Android VM can't do certain things that Android phones and tablets can. As an example, files management in the Android VM is so bad that I lost access to standard access for months due to a bug...
Also, the Android environment is all the way back on version 11. If your theory is correct, that Google wants to move third-party developers to Android, then they're doing a terrible job of it. Android devs haven't and won't target all these outdated devices.
I believe Chromeos is becoming an enterprise/edu only platform. That would explain the (new) lack of interest in development and focus on security at the cost of all functionality. This is a new development and wasn't "always" the case as you claim, because many of these apis are as old as Chromeos itself (10-ish years).
I would assume google uses Android to just help get onboard chromeos (example: netflix app etc). You want android devs to handle the outside chrome. No thanks. Whether it is A11 or not a large majority does not care. It is only power enthusiasts that need latest A13 in chromebook. For the rest, not at all.
See they are learning a lesson from iOS. Keep tight control - at whatever cost. The same complaints about file management is there in iPad but devs have no option.
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.
I feel like Smartwatches are to phones what tablets are to laptops: a supplementary device that doesn't work as well without the primary computer.
While many people might work entirely from a tablet, or even a Chromebook, you'll run into so many issues that you're better off carrying a laptop to cover all bases. In a pinch, a watch or tablet can pinch-hit for the device they supplement, but using them as a primary device every day gets old really quick.
While it's possible that Google hasn't said they'll be doing the updates separately for the browser there's no reason to suspect they wouldn't do that once LaCrOS was fully implemented -- after all, it works under Linux.
The comment I submitted only went so far as to say they started doing "that", referring to the parent's post about decoupling and providing separate updates.
If "that" is referring to both, it's incorrect. Google has said they will be "well into 2024" without any benefits brought by LaCrOS. That includes any theoretical extending of the expiration dates.
Are you arguing that because they won't have something providing benefits until "well into 2024" that they have not started as of the time of my comment ?
When my son was in school, the Chromebooks issued to students would buck the usual direction of the industry and get worse in performance every year. After all, if kids got computers that were capable at all they'd play
Over the last year, I've been teaching myself Javascript by developing on and for a Chromebook.
Obviously, there's a ton of room for improvement but I've enjoyed using & making these.
Before you ask, I'm one user who has a Razer Blade 16 (4090) and Galaxy Book 4 Ultra that I use for CAD and BIM work. I'll pass on having a dedicated video editor.