[danans]

> Swap Chromebooks for PCs and you still have the problem-- how do you handle centralized management of that "fleet"?

Simplicity (and hence low cost) of fleet management, OS boot-verification, no third-party kernel updates, and A/B partitions for OS updates are among the major selling points of Chromebooks.

It's a big reason they have become so ubiquitous in primary education, where there is such a limited budget that there's no way they could hire a security engineer.

[EvanAnderson]

The OP was deriding monoculture. My point was that pushing out only Chromebooks is still perpetuating a monoculture. You're just shifting your risk over to Google instead of Crowdstrike / Microsoft.

re: Chromebooks themselves - The execution is really, really good. The need for legacy software compatibility limits their corporate penetration. I've done enough "power washes" to know that they're not foolproof, though.

[danans]

I agree that monoculture is an issue that makes events like this more probable, regardless of OS.

That said, a third party being able to add/update a kernel driver ignores (even if out of business necessity) best practices for OS architecture.

[EvanAnderson]

ChromeOS is just Linux, isn't it? It's going to suffer from the same problem as NT re: a buggy kernel mode driver tanking the entire OS.

Google gets a pass because their Customers are okay with devices with limited general purpose ability. Google is big enough that the market molds product offerings to the ChromeOS limitations. I think MSFT suffers from trying to please everybody whereas Google is okay with gaining market share by usurping the market norms over a period of years.

[danans]

> ChromeOS is just Linux, isn't it? It's going to suffer from the same problem as NT re: a buggy kernel mode driver tanking the entire OS.

ChromeOS is not just Linux. It uses the Linux kernel and several subsystems (while eschewing others), but it also has a security and update model that prevents third parties (or even the user themselves) from updating kernel space code and the OS's user space code, so basically any code that ships with the OS.

Therefore, the particular way that the Crowdstrike failure happened can't happen on ChromeOS.

However, Google themselves could push a breaking change to ChromeOS. That, however would be no different than Apple or Microsoft doing the same with their OS's.

[EvanAnderson]

> ChromeOS is not just Linux.

I am familiar with Google's walled garden w/ ChromeOS. I didn't mean to give the impression that I was not.

It's "just Linux" in the sense that it has the same Boolean kernel mode/user mode separation that NT has. ChromeOS doesn't take advantage of the other processor protection rings, for example. A bad kernel driver can crash ChromeOS just as easily as NT can be crashed.

Hopefully Google just doesn't push bad kernel drivers. Crowdstrike can't, of course, because of the walled garden. That also means you can't add a kernel driver for useful hardware, either. That limits the usefulness of ChromeOS devices for general purpose tasks.

[danans]

> That also means you can't add a kernel driver for useful hardware, either. That limits the usefulness of ChromeOS devices for general purpose tasks.

It's target market isn't niche hardware but rather the plethora of use cases that use bog standard hardware, much like many of the use cases that CS broke a few days ago.