66 ms·

> we’ll be embracing portions of the Android stack, like the Android Linux kernel and Android frameworks, as part of the foundation of ChromeOS. Ew. ChromeOS w

> we’ll be embracing portions of the Android stack, like the Android Linux kernel and Android frameworks, as part of the foundation of ChromeOS. Ew. ChromeOS was always a beautiful contrast to Android, running mainline kernels instead of Android's hacked up mess. Actually that was pretty much true of the rest of the stack as well - ChromeOS was almost a normal(ish) GNU/Linux, running Chrome on Wayland on ~Gentoo. Android, in the meantime, NIHed the whole stack. I had always dreamed that one day Google would rebase Android to use a ChromeOS base running apps through a compatibility layer. This... feels like the Bad outcome.

fidotron 2y ago
> Ew. ChromeOS was always a beautiful contrast to Android, running mainline kernels instead of Android's hacked up mess. This is at least partly because the two are distributed very differently, with Chrome OS on a much shorter leash than Android, even with Play services. With Chrome OS devices Google can push updates to any device whenever they want, whereas with Android it was often up to the manufacturer, or even carrier, which many Googlers (not all) considered to be a mistake. But this is also the Chrome OS achilles heel because support for esoteric third party hardware blocks is the Android killer feature and now more important than ever.
- yjftsjthsd-h 2y ago
  I tend to not believe that it's just that, because even Google's own phones have never run mainline kernels outside of experiments that never actually shipped to end users.
- hawski 2y ago
  That made it possible to give 10 years of updates. That's the main reason for me to want Android to base on ChromeOS, not the other way around.
kaba0 2y ago
It cuts both ways. Desktop linux NIHed a bunch of basic features in some buggy, insecure C code that barely works. Like, it has absolutely zero security, no accessibility, no fine-grained permissions system, no normal cross-application communication, no userspace resource control (cgroups are cool, but they are not exposed)..
- yjftsjthsd-h 2y ago
  Okay, except that... almost none of that is true? Desktop Linux started early enough that I don't think it could have NIH issues and has mostly iterated ever since; I grant that maybe it could have picked up something like GNUstep, but that's not obviously a good idea in hindsight and definitely wasn't at the time. And Linux is doing fine on security, is definitely behind on a11y but still has it, and mostly does cross-app communication through dbus. I will grant that resource control is underdeveloped (though I'm not aware of any other desktop OS doing it better?), and permissions only really became a thing recently with flatpak.
  - aseipp 2y ago
    Linux is behind other OSs at this point in terms of desktop security and hardening; there are of course ever-evolving mitigations for things like memory safety issues, but everyone has that, and more broadly the standard Unix permission model in the single-user system where every application has more-or-less unlimited access to everything else under your account, is very dated. In practice given a random Linux dev installation, it's morally equivalent to a workstation where you only use root. Flatpak-on-everything is like the absolute bare minimum for a comparison to ChromeOS or Android if we're being honest, and still many apps still aren't designed around supporting things like XDG Portals so permissions are typically much more coarse-grained than necessary. Not to mention the general atrocity that is setuid. You could beat all of this into submission but you'd end up rewriting a lot of stuff anyway, because those things need to be designed with it in mind (PulseAudio never had a concept of permissions and in practice you had to live with that until PipeWire was written from scratch.) The Linux desktop is a big project with a lot of stakeholders in various projects and many of these ideas only really came into the desktop realm in the past 15 years or so. This means progress is relatively slow all things considered, compared to something like Android or ChromeOS, with unified teams and top-down vision, which is why they have more or less completely replaced the entire Linux desktop in that same timeframe and even delivered on things it still doesn't have like HDR, per-application sandbox and permission models, etc. I do think that in the server space, you can produce reasonably secure and trustable Linux systems based on available distros. But on the desktop, well, it's not so hot.
- 2y ago
ignoramous 2y ago
> I had always dreamed that one day Google would rebase Android to use a ChromeOS base running apps through a compatibility layer I wished and hoped for the same (or at least, for ChromeOS to not get cannibal'd by Android). But... > This... feels like the Bad outcome. Realistically, running apps inside of a language runtime (VM) is bad enough for an embedded device (the HP Dynamo-like gymnastics to speed up ART, notwithstanding)... and here we were wishing each app ran in its own guest OS?
- pjmlp 2y ago
  Not only does ART compile to native code, its performance is much better than V8, running the whole ChromeOS userspace, or the VM for Crostini.
  - ignoramous 2y ago
    That's exactly the point I was making, too.
    - pjmlp 2y ago
      I understood the other way around, sorry about that.
- kaba0 2y ago
  Well, your username is relevant.. ART doesn’t work like that at all?
  - ignoramous 2y ago
    See: https://news.ycombinator.com/item?id=33534018 https://news.ycombinator.com/item?id=33534018 (tldr https://news.ycombinator.com/item?id=33542614 https://news.ycombinator.com/item?id=33542614) And: The strange case of VMs on telephones, https://apenwarr.ca/log/20100826 https://apenwarr.ca/log/20100826
deleted 2y ago
[deleted]

fidotron 2y ago

> Ew. ChromeOS was always a beautiful contrast to Android, running mainline kernels instead of Android's hacked up mess. This is at least partly because the two are distributed very differently, with Chrome OS on a much shorter leash than Android, even with Play services. With Chrome OS devices Google can push updates to any device whenever they want, whereas with Android it was often up to the manufacturer, or even carrier, which many Googlers (not all) considered to be a mistake. But this is also the Chrome OS achilles heel because support for esoteric third party hardware blocks is the Android killer feature and now more important than ever.

yjftsjthsd-h 2y ago
I tend to not believe that it's just that, because even Google's own phones have never run mainline kernels outside of experiments that never actually shipped to end users.
hawski 2y ago
That made it possible to give 10 years of updates. That's the main reason for me to want Android to base on ChromeOS, not the other way around.

kaba0 2y ago

It cuts both ways. Desktop linux NIHed a bunch of basic features in some buggy, insecure C code that barely works. Like, it has absolutely zero security, no accessibility, no fine-grained permissions system, no normal cross-application communication, no userspace resource control (cgroups are cool, but they are not exposed)..

yjftsjthsd-h 2y ago
Okay, except that... almost none of that is true? Desktop Linux started early enough that I don't think it could have NIH issues and has mostly iterated ever since; I grant that maybe it could have picked up something like GNUstep, but that's not obviously a good idea in hindsight and definitely wasn't at the time. And Linux is doing fine on security, is definitely behind on a11y but still has it, and mostly does cross-app communication through dbus. I will grant that resource control is underdeveloped (though I'm not aware of any other desktop OS doing it better?), and permissions only really became a thing recently with flatpak.
- aseipp 2y ago
  Linux is behind other OSs at this point in terms of desktop security and hardening; there are of course ever-evolving mitigations for things like memory safety issues, but everyone has that, and more broadly the standard Unix permission model in the single-user system where every application has more-or-less unlimited access to everything else under your account, is very dated. In practice given a random Linux dev installation, it's morally equivalent to a workstation where you only use root. Flatpak-on-everything is like the absolute bare minimum for a comparison to ChromeOS or Android if we're being honest, and still many apps still aren't designed around supporting things like XDG Portals so permissions are typically much more coarse-grained than necessary. Not to mention the general atrocity that is setuid. You could beat all of this into submission but you'd end up rewriting a lot of stuff anyway, because those things need to be designed with it in mind (PulseAudio never had a concept of permissions and in practice you had to live with that until PipeWire was written from scratch.) The Linux desktop is a big project with a lot of stakeholders in various projects and many of these ideas only really came into the desktop realm in the past 15 years or so. This means progress is relatively slow all things considered, compared to something like Android or ChromeOS, with unified teams and top-down vision, which is why they have more or less completely replaced the entire Linux desktop in that same timeframe and even delivered on things it still doesn't have like HDR, per-application sandbox and permission models, etc. I do think that in the server space, you can produce reasonably secure and trustable Linux systems based on available distros. But on the desktop, well, it's not so hot.
2y ago

ignoramous 2y ago

> I had always dreamed that one day Google would rebase Android to use a ChromeOS base running apps through a compatibility layer I wished and hoped for the same (or at least, for ChromeOS to not get cannibal'd by Android). But... > This... feels like the Bad outcome. Realistically, running apps inside of a language runtime (VM) is bad enough for an embedded device (the HP Dynamo-like gymnastics to speed up ART, notwithstanding)... and here we were wishing each app ran in its own guest OS?

pjmlp 2y ago
Not only does ART compile to native code, its performance is much better than V8, running the whole ChromeOS userspace, or the VM for Crostini.
- ignoramous 2y ago
  That's exactly the point I was making, too.
  - pjmlp 2y ago
    I understood the other way around, sorry about that.
kaba0 2y ago
Well, your username is relevant.. ART doesn’t work like that at all?
- ignoramous 2y ago
  See: https://news.ycombinator.com/item?id=33534018 https://news.ycombinator.com/item?id=33534018 (tldr https://news.ycombinator.com/item?id=33542614 https://news.ycombinator.com/item?id=33542614) And: The strange case of VMs on telephones, https://apenwarr.ca/log/20100826 https://apenwarr.ca/log/20100826

deleted 2y ago

[deleted]