4 ms·

This is an obvious precursor to the rumoured desktop mode coming to Pixel phones. It is also going to be a bitter pill for many Chrome OS people, who were ofte

This is an obvious precursor to the rumoured desktop mode coming to Pixel phones. It is also going to be a bitter pill for many Chrome OS people, who were often defined by a distaste for Android that verged on the absurd, and caused an awful lot of political nonsense. Android is far from ideal, but Chrome OS was better in one sense only: security. Controversially I believe the most viable future Linux desktop is likely to be based on the Android stack, especially the app packaging, but with the entire “java” layer removed.

jeffbee 2y ago
> Chrome OS was better in one sense only: security. Don't you think this is a pretty major feature?
- fidotron 2y ago
  Not if the price is confining yourself to only loading web pages with the odd api extension. Android does a huge amount more, especially around media and general hardware support (such as nn accelerators) which make security much harder but are also necessary for deploying modern applications.
  - jeffbee 2y ago
    I don't develop on Android so I have no perspective on whether it's a better situation, but as a user of both Android and ChromeOS on the daily, my impression of ChromeOS is that it is minimally intrusive, updates instantly, sleeps and wakes instantly, switches users instantly. My impression of Android is updates take forever, there are 90 minutes of hideous jank after a restart, and it takes 15+ minutes to take a bug report. But I have no way of telling from this announcement which parts of the Android tech stack are responsible for it being a pyramid of jank. However it sounds like Android has won an internal turf war and it seems inevitable that their user-oblivious development and release process will eventually tarnish ChromeOS.
    - fidotron 2y ago
      So I used to be an Android dev and left years ago because of how mismanaged their upper levels of the stack became. Their Java API was never good (j2me was cleaner) but somehow the extensions rarely represented an improvement and just introduced more new problems. The low level pieces of Android have dramatically improved over the years though, and are clearly battle tested at enormous scale. Binder, of recent security problems, is functionally very useful. The graphics system handles DRM and HDR on different hardware surprisingly well these days, and even the audio stack is far less annoying than it used to be. Considering that Android devices are expected to run continuously this is no small achievement. Some years ago I wrote and deployed Android code that decodes and plays video, with audio, constantly, for months on end, synchronized to an external clock, on a random cheap OEM board, while downloading the next one over a flaky network, with relatively minor alterations to the OS being necessary. It may be possible on other things but I would probably still be debugging it.
- Zambyte 2y ago
  I don't think it's a feature at all with an undefined threat model.
  - nolist_policy 2y ago
    ChromeOS threat model: After remote code execution exploit in some Chrome process + chained sandbox breakout exploit + chained privilege escalation to root/kernel mode, the user should be safe again after rebooting the device.
  - aseipp 2y ago
    I don't understand what you're suggesting. ChromeOS has an extensively documented threat model and it is, quite unarguably, vastly more intimate and well defined than any comparable desktop solution in the FOSS world. ChromeOS also has more tight distribution and product requirements for official devices which helps it even further, even compared to something like Android, because OEMs can't shit it up so easily e.g. longer security lifecycle, open bootloaders, mandatory hardware for verified/secure boot, etc. https://www.chromium.org/chromium-os/chromiumos-design-docs/security-overview/ https://www.chromium.org/chromium-os/chromiumos-design-docs/...
deleted 2y ago
[deleted]
curt15 2y ago
>Controversially I believe the most viable future Linux desktop is likely to be based on the Android stack, especially the app packaging, but with the entire “java” layer removed. What would replace all the APIs provided by the Java layer? Compared to what you find in traditional Linux desktops, the Java APIs are 1) comprehensive, providing a one-stop shop for basically all core app functionality; desktop Linux has no equivalent of the Android SDK or the Windows API. 2) versioned, with strong backward compatibility. Linux desktops have no well-defined "minimum API version" that developers can target like they can on Android.
- yjftsjthsd-h 2y ago
  > Linux desktops have no well-defined "minimum API version" that developers can target like they can on Android. Of course they do: "Ubuntu 16.04+", " Debian 11+", "RHEL-like 8+". If you can use a single distro (which you're proposing anyways with Android), it's not hard. Sadly LSB didn't really work out so you don't have a more portable solution, but that just means that we're stuck with the status quo and not better.
- fidotron 2y ago
  For your point 2, I had to stop them from throwing that out of the window all the way back circa 2.3. The key problem with desktop Linux is the entire distro concept. Just have the kernel, some services (the android ones like binder, surfaceflinger etc) and go from there. Iirc that isn’t far from what firefox os was, only they insisted on everything being browser based. The Java API on android is thinner than it looks, and contains most of the serious problems, such as the entire UI stack. Now that Swift has grown static Linux support that would probably make most sense as the first class target for API consumption.

jeffbee 2y ago

> Chrome OS was better in one sense only: security. Don't you think this is a pretty major feature?

fidotron 2y ago
Not if the price is confining yourself to only loading web pages with the odd api extension. Android does a huge amount more, especially around media and general hardware support (such as nn accelerators) which make security much harder but are also necessary for deploying modern applications.
- jeffbee 2y ago
  I don't develop on Android so I have no perspective on whether it's a better situation, but as a user of both Android and ChromeOS on the daily, my impression of ChromeOS is that it is minimally intrusive, updates instantly, sleeps and wakes instantly, switches users instantly. My impression of Android is updates take forever, there are 90 minutes of hideous jank after a restart, and it takes 15+ minutes to take a bug report. But I have no way of telling from this announcement which parts of the Android tech stack are responsible for it being a pyramid of jank. However it sounds like Android has won an internal turf war and it seems inevitable that their user-oblivious development and release process will eventually tarnish ChromeOS.
  - fidotron 2y ago
    So I used to be an Android dev and left years ago because of how mismanaged their upper levels of the stack became. Their Java API was never good (j2me was cleaner) but somehow the extensions rarely represented an improvement and just introduced more new problems. The low level pieces of Android have dramatically improved over the years though, and are clearly battle tested at enormous scale. Binder, of recent security problems, is functionally very useful. The graphics system handles DRM and HDR on different hardware surprisingly well these days, and even the audio stack is far less annoying than it used to be. Considering that Android devices are expected to run continuously this is no small achievement. Some years ago I wrote and deployed Android code that decodes and plays video, with audio, constantly, for months on end, synchronized to an external clock, on a random cheap OEM board, while downloading the next one over a flaky network, with relatively minor alterations to the OS being necessary. It may be possible on other things but I would probably still be debugging it.
Zambyte 2y ago
I don't think it's a feature at all with an undefined threat model.
- nolist_policy 2y ago
  ChromeOS threat model: After remote code execution exploit in some Chrome process + chained sandbox breakout exploit + chained privilege escalation to root/kernel mode, the user should be safe again after rebooting the device.
- aseipp 2y ago
  I don't understand what you're suggesting. ChromeOS has an extensively documented threat model and it is, quite unarguably, vastly more intimate and well defined than any comparable desktop solution in the FOSS world. ChromeOS also has more tight distribution and product requirements for official devices which helps it even further, even compared to something like Android, because OEMs can't shit it up so easily e.g. longer security lifecycle, open bootloaders, mandatory hardware for verified/secure boot, etc. https://www.chromium.org/chromium-os/chromiumos-design-docs/security-overview/ https://www.chromium.org/chromium-os/chromiumos-design-docs/...

deleted 2y ago

[deleted]

curt15 2y ago

>Controversially I believe the most viable future Linux desktop is likely to be based on the Android stack, especially the app packaging, but with the entire “java” layer removed. What would replace all the APIs provided by the Java layer? Compared to what you find in traditional Linux desktops, the Java APIs are 1) comprehensive, providing a one-stop shop for basically all core app functionality; desktop Linux has no equivalent of the Android SDK or the Windows API. 2) versioned, with strong backward compatibility. Linux desktops have no well-defined "minimum API version" that developers can target like they can on Android.

yjftsjthsd-h 2y ago
> Linux desktops have no well-defined "minimum API version" that developers can target like they can on Android. Of course they do: "Ubuntu 16.04+", " Debian 11+", "RHEL-like 8+". If you can use a single distro (which you're proposing anyways with Android), it's not hard. Sadly LSB didn't really work out so you don't have a more portable solution, but that just means that we're stuck with the status quo and not better.
fidotron 2y ago
For your point 2, I had to stop them from throwing that out of the window all the way back circa 2.3. The key problem with desktop Linux is the entire distro concept. Just have the kernel, some services (the android ones like binder, surfaceflinger etc) and go from there. Iirc that isn’t far from what firefox os was, only they insisted on everything being browser based. The Java API on android is thinner than it looks, and contains most of the serious problems, such as the entire UI stack. Now that Swift has grown static Linux support that would probably make most sense as the first class target for API consumption.