5 ms·

Both real-world and on-paper status are literally the exact opposite of what you're describing. As others have already mentioned, just stating the facts about

by phh 2y ago

Both real-world and on-paper status are literally the exact opposite of what you're describing. As others have already mentioned, just stating the facts about long-term support: chromebooks have much longer support than Android devices. Both looking at the 99-percentile, the median, and the 1-percentile. Chromebooks don't get stupid bugs that require workarounds in userspace like: - BPF maps being broken because someone at Mediatek ran some proprietary static analyser and blindly pushed some fix - Camera only works properly in the OEM app - GL drivers are upgraded once every blood moon and very OEM has its custom GL version - Treble doesn't break because Samsung decided that mount loops were dangerously insecure at a time it wasn't required - 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] Android deprecates driver after 3 years [2], so vendor need to do a lot of work on a very frequent basis. As an OEM, I just want to do my (painful) contributions to mainline, and have them maintain it. Android actively hinders me from doing that. As an Android OS developer, I could go on and on and on about the stupid issues that Android kernels get that Chromebooks don't. All of those issues would happen just exactly the same on Fuchsia. I'm not saying ChromeOS' development method works for smartphones, it doesn't. I'm not saying it is desirable, I think it isn't (because it completely kills most innovation). But ChromeOS handles fragmentation better than Android on every single criteria you could imagine. [1] Google/Android added a bunch a new stupid policies that actually prevent me from upgrading kernels on deployed devices [2] Yes there is actual planned obsolescence nowadays in Android. It wasn't the case few years ago where obsolescence was accidental

rob74 2y ago
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...
- phh 2y ago
  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.
- nolist_policy 2y ago
  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.
  - jeffbee 2y ago
    That's the irony of this announcement. The only problems I ever suffered on ChromeOS came from the Android subsystem.
- hawski 2y ago
  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.
- freedomben 2y ago
  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.
loa_in_ 2y ago
Android system deals with so many more different architectures of hardware though
- 1oooqooq 2y ago
  everything is arm ebi... even x86 is long gone (Android 4)
  - loa_in_ 2y ago
    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.
surajrmal 2y ago
Why do you say the same issues would happen on fuchsia?
- phh 2y ago
  > - 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...

by phh 2y ago

rob74 2y ago

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...

phh 2y ago
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.
nolist_policy 2y ago
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.
- jeffbee 2y ago
  That's the irony of this announcement. The only problems I ever suffered on ChromeOS came from the Android subsystem.
hawski 2y ago
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.
freedomben 2y ago
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.

loa_in_ 2y ago

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

1oooqooq 2y ago
everything is arm ebi... even x86 is long gone (Android 4)
- loa_in_ 2y ago
  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.

surajrmal 2y ago

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

phh 2y ago
> - 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...