My personal (probably non-representative) experience with ChromeOS vs. Android: my ChromeOS device (a Lenovo IdeaPad Duet 2-in-1 Chromebook) tends to get extremely unresponsive (i.e. hangs itself up for minutes before responding again, or just spontaneously reboots) the longer it runs without being rebooted, to the point that I eventually have to hard reset it after about a week of on-and-off use. I basically only use the browser on it (but with lots of tabs open). This never happened to me on any of the many Android phones/tablets I had. Maybe it's some bug in how newer ChromeOS versions work on this by now pretty old device, but it's still annoying as hell...

Gotta admit I'm curious there. I've rocked a rk3399 chromebook for years (stopped roughly when it got deprecated) without issues, and I was stressing it with crouton. My gf is still using a rk3288 chromebook "fine" (it's no longer her daily driver though). Those are low-end 8yo devices.

Anecdotal counter-point I have a colleague with a Samsung Galaxy Tab A 8" 2019 (SM-T290), and after just 3 years it became absolutely unusable, even after a factory reset. And it's "by design": it shipped with 2GB RAM, which was usable in Google/Android 9 (shipped OS), but just completely dead on Google/Android 11 (updated OS). Obviously I saved that device from oblivion with a Google-less Android that takes half as much RAM.

You could try disabling the Android system ("Google Play"), since they switched running Android in a VM in newer ChromeOS versions. So you have an Android VM running in the background all the time and that might overwhelm the small Mediathek processor in the Duet.

That's the irony of this announcement. The only problems I ever suffered on ChromeOS came from the Android subsystem.

I had issues like that a few years back on memory starved Chromebooks, in my case the biggest savior was the Great Suspender/Discarder extension as I hoard tabs, otherwise the Android subsystem on a 4GB RAM machine is stretching it thin.

I've been using Linux for a long time, including chromebooks, and this sounds like textbook low memory to me. I love linux, but it doesn't handle low memory situations well[1], and whatever Chrome does in low memory situations makes it much worse. Tab discipline is the most important thing you can do. I have an obscene amount of tabs open too so I feel you. I've started making liberal use of the Session Buddy extension and that is helpful, though my true fix was putting 128 GB of RAM in :-D

[1] This is improving greatly in the last year or two, but that probably wouldn't have made it to your chromebook.

EarlyOOM [1] could help with that quite a lot. Not to sure about using it on chromebooks, but linux got quite a bit more usable because of it.

[1] https://github.com/rfjakob/earlyoom

Are you by chance using external storage media such as USB or SD cards?

The bus on these older model chromebook devices had a choking issue where the kernel would fully saturate the transfer bus and cause a cgroup scheduling strategy to give full priority to the processes using the bus at the expense of the gui. Solutions to this problem include a new NVME or software level cgroup reconfiguration of the kernel to revert scheduling priority to equal across all cgroups.

Or it could be something else entirely, but last time i had this issue and bug hunted it the finding was as stated above.

I know your Duet problem well. I've got a Duet around here. It was slow from the beginning. Noticeably, it would often slow to a crawl while Chrome OS was downloading an update in the background. And sometimes, it would be slow after waking for about 5 to 10 minutes and then suddenly go to a more acceptable speed.

I also have a Lenovo Ideapad Chromebook running on an Intel 4020 with only 4GB. Despite being slow hardware, it runs circles around the Duet. The 4020 can be sluggish at times, but it never had the big slowdowns of the Duet. It could even run Visual Studio Code at acceptable speeds. Something was very wrong with the Duet. Usually Chrome OS is good on lower end hardware.

Android system deals with so many more different architectures of hardware though

everything is arm ebi... even x86 is long gone (Android 4)

I know the processor architectures, but there are things in play like:

- some phones can read from the screen framebuffer, some are write only - a variety of actual chips used for modem, storage, etc.

Why do you say the same issues would happen on fuchsia?

> - BPF maps being broken because someone at Mediatek ran some proprietary static analyser and blindly pushed some fix

Technically this one would possibly not be in Fuchsia, though Google let OEMs put so many hooks everywhere in the system that tbh it would still be possible to do this kind of fuckups

> - Camera only works properly in the OEM app

Fuchsia or not, if Google allows OEMs to add custom vendor calls from OEM app to camera driver, then OEM will still be allowed to do that. They could already forbid it in Android and choses not to.

> - GL drivers are upgraded once every blood moon and very OEM has its custom GL version

GL has nothing to do with the OS, GL vendors pretty much ship the same GL across all OS

> - Treble doesn't break because Samsung decided that mount loops were dangerously insecure at a time it wasn't required

This would definitely still happen (in other ways), by all the hooks that Google leave to OEMs to implement their own security systems (and Samsung is the company who brought SELinux in Android, so even though they do a lot of shit, let's not completely ignore them)

> - You don't need to keep workarounds for mainline kernels that you can't upgrade, because Google/Android forbids you to upgrade your kernel [1]

This one, ironically, would STILL HAPPEN, at least if we extrapolate how Android team work. When building Android from main, you get 10000 as SDK version number to explicitly mention that this is a development tree not to be used.

Fuchsia theoretical advantage should be that one will be able to upgrade the kernel without upgrading the drivers. But again let's extrapolate what Android team does: They create new API versions every year or more, and PLAN THE OBSOLESCENCE of those API versions within 3 years. So currently when an OEM write their drivers, they get kernel security patches for 6 years after the release of the "original" kernel of that version. With Fuchsia you get down to 3 years.

I want to re-iterate that even though from that perspective, ChromeOS' approach is ideal, it has issues wrt innovation. I believe that the ideal situation is an open but centralized approach like what we have currently with DKMS on GNU/Linux distributions. Except let it focus on LTS Linux kernel versions, and have flags on the DKMS to allow switching to newer LTS. Here "open" doesn't necessarily mean community-led. It can be very well just be that each vendor is responsible for its own product. So like Mali is responsible for their mali kernel driver, BOE is responsible for their panel driver, etc...