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

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.

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.

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.

That's exactly the point I was making, too.

I understood the other way around, sorry about that.

Well, your username is relevant.. ART doesn’t work like that at all?

See: https://news.ycombinator.com/item?id=33534018 (tldr https://news.ycombinator.com/item?id=33542614)

And: The strange case of VMs on telephones, https://apenwarr.ca/log/20100826

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

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.

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.

>Like, it has absolutely zero security,

Wait until you discover exploits for the rust Runtime

>no accessibility

AtSPI, speech-distpacher.

>no fine-grained permissions system,

ACLs.

>no normal cross-application communication

DBUS did that.

>No userspace resource control (cgroups are cool, but they are not exposed)

Unless you use Plan9/9front, every Unix and even NT it's like that.

Inb4 sandboxing and X.org easy eavesdropping, upon running any unsupervised malware as your user account, you are powned under every OS (by default) as you can just tgz the Chromium/Firefox/SSH profile from $HOME and rsync+netcat/NNCP the whole pack over the net. Everything else it's snake oil.

> you are powned under every OS

That literally wouldn’t work on Android, or ios. And android’s solution is very elegant, and only relies on standard linux interfaces, so there is zero reason why running every process under a new, dynamic user is not the default way of interaction.