Why does the Chrome OS team do anything the Chrome OS team does? They decided the best idea for low-end hardware is to run everything as a web app. They decided to make it practically useless without an Internet connection because clearly no one will use an ultraportable somewhere without Internet access. They decided to develop their own distro mostly from scratch because contributing to an existing project would be too easy, to useful, and would get them too much goodwill. They decided the best way to make the system easy to use was to split your files between local storage and the cloud so you don't know where anything is.

It's a stupid idea from start to finish. You shouldn't try to make sense of it.

And it depresses me. Its success demonstrates that Linux desktops could catch on in the mainstream market just fine if they had the marketing budget, brand recognition, and vendor support of Google. This team of idiots could have ended the hegemony of Microsoft and Apple for good.

On the other hand, Chrome OS has finally ended my nightmare as the family IT support specialist. I have to help people who don't know what a "mouse" is, what a "browser" is, or that you can read the same email on multiple devices. When I switch them to a ChromeBook, life is much easier. Do they still have problems? Yes, because they don't understand the underlying concepts and face an enormous learning curve. But they don't get viruses anymore and nearly any problem is solved with a restart. Plus, Chrome OS is truly multiuser in the sense that anyone with a Google account can log into the device and access all of their online resources without affecting any other users, so I've been able to modify the owner's idea of what it means to share the device in a secure manner. Frankly, it's a godsend for some types of users who are incapable of maintaining any system running Windows, MacOS or a mainstream Linux distribution.

So much this.

Frankly, the more I use a ChromeBook myself, the less I want to use another mainstream OS for day-to-day computing. I don't game or do much photo / video editing so I go weeks at the time on the ChromeBook without reaching for something else. It's nice having a computer that I genuinely don't need to think about.

Next step is ditching my work-provided Windows laptop for a ChromeBook...

You can add the education market into that as well, for similar reasons.

Local storage is available on later instances of ChromeOS I gather.

This entire screed is based on the incorrect premise that Chromebooks don't work offline.

https://fieldguide.gizmodo.com/everything-you-can-do-offline...

Firstly, no it isn't. The fact that they need an Internet connection is just one of Chrome OS's many problems.

Secondly, I never claimed Chromebooks don't work offline. I claimed they are nearly useless offline, which they are. They default to storing things in the cloud and using web apps. Getting them to be useful offline requires effort from the user and special effort from the developers of any offline web apps. The fact that users have to keep track of where all their data and programs live is needless complexity which is quite opposed to Chrome OS's supposed focus on ease of use.

You do not need an Internet connection. You are way, way behind.

Did you actually used ChromeOS?

Anyway, short answer: because they heavily customized and changed a lot of things. They could not have done this with an existing Distro so easy. And sad as it is -> their goal is and was not to help the linux desktop - it is to help the google Eco system. Cloud-Service. Webapp. Makes perfect sense. No matter how much you want them to support the things you (or me) want.

We linux users are not the target group, target group are ordinary newbs who like that everything just runs and don't like that their exe files somehow don't run anymore. But the ones who handle exe files per hand are rapidly declining I guess.

It was already declining in the late 90's.

Had Linux not appeared on the scene, BSD kept busy with their ongoing trial and UNIX like OSes would be surely much less relevant today.

>Makes perfect sense.

Maybe so. And as I said, that makes me sad. People who work hard to develop full-featured and high-quality software fail to make headway, but people who cynically manipulate others to lock them in to one company while providing nothing of value make millions. It's perfectly rational and perfectly disgusting.

Chrome OS is worthless for its users. I don't much care how good it is for Google.

> Linux desktops could catch on in the mainstream market just fine if they had the marketing budget, brand recognition, and vendor support of Google

The problem with Linux on the mainstream is Linux, it has nothing to do with not having a huge brand like Google's nor with marketing, just ask Dell. Linux offers exactly what the enterprise market needs and it is a huge success, far bigger than anyone in the 90s ever imagined. Linux does not offer what the mainstream market demands and no amount of marketing or brand recognition can change that.

Linux isn't the problem: with enough money and time, you could build an OS around Linux that a user can use just like MacOS or Windows. Sony built an operating system around FreeBSD for the PS4 that noone recognises as such. The problem is that open source software (which Linux necessarily attracts due to licensing and reputaion) is designed by people with a fundamentally different view of ergonomics, and the number of disparate HW components (audio, graphics, etc) create a similar number of software components that make integrating them cumbersome and frustrating.

The PS4 has very little from FreeBSD beyond the kernel.

Obviously time and money aren’t the problem. Look at windows phone. Microsoft wasn’t being frugal in marketing

Linux can do whatever it damn well pleases. You can take Linux and turn it into the most feature-poor "easy-to-use" toy on the planet, as Google has demonstrated. The UI has little to do with the underlying technology.

The problems with the Linux desktop that I can see are poor driver support and a limited software selection. OEM support solves the driver support problem and Chrome OS demonstrates that people are willing to use a system with no software at all. What else makes it unsuitable for most users?

Could not disagree more. How ChromeOS works makes it so much more secure and easier to manage.

I believe they don't use Gentoo, rather they use Gentoo's build system (portage) to build ChromeOS. They use their own tree (ebuilds) and they don't include portage into ChromeOS.

It is based on Gentoo as software can be based on make and gcc. But the user only sees the resulting binary.

AFAIK Portage, Gentoo's package manage, is used only to build the rootfs image. Because Gentoo is really a meta distribution. This distinction is not an empty slogan. You can use Gentoo as a build system to create separate operating system, just like ChromeOS does.

You can use of course use Gentoo directly and prepare tailor built binary packages to distribute them to users. Then it would be a bit more similar to other distributions. But ChromeOS is not an ordinary distribution. It's update model is not really compatible with typical distribution model. It's one of the greatest strengths of the system. You could shoehorn packages meta data, but it would be pointless, because whole image is updated at once.

Technically it's a container not a VM. So using this is about sandboxing it from the OS.

Seems like they run the Debian in a KVM virtual machine, and containers inside that?

Any links for more info about containers vs VM there? The article just says:

"That’s because Google is going to start shipping Chrome OS with a custom virtual machine that runs Debian Stretch, the current stable version of the operating system."

I have been using this on my pixelbook and, unless I am wildly mistaken, it's generating an LXC container. Android apps for instance all run inside a single container for them as well

The container itself is running Debian Stretch. However, for someone not using this it can be easily misinterpreted to mean a VM. Functionally it's not much different.

No it is a container on top of a VM. Different kernels. Android is just a container sharing a common Linux container with ChromeOS.

Both. Machine containers on top of a VM.

apt-get is still the golden standard for installing apps on Linux because of its dependency resolution system, and being able to "sudo apt-get install <package>" is a core use-case for end-users (i.e. students who are learning how to use Linux / code for the first time).

Disclaimer: I work at Google, but not on Chrome OS.

Genuinely asking, what makes apt-get that much better than other package managers? Outside of Slackware I think good dependency resolution is pretty much universal at this point, and I can't say I've ever noticed any major problems with pacman, for instance.

Technically speaking, nothing.

Windows has a lot of users just because they're familiar with it.

The same goes for Debian derivatives. A lot of people's first Linux distro is Ubuntu, so they get familiar with apt and don't have a compelling reason to use anything else.

I'm a perfect example. The second package-manager I really interacted with was Alpine's "apk", and that's only because I've been working with Docker pretty extensively over the last year.

It not APT itself, but the policies, tooling and practices around creating and installing packages.

A lot of work is done to ensure smooth upgrades, or prevent packages from breaking each other by overwriting files, breaking configurations, changing ownership of some files or directories and so on.

Apt-get got there first. Debian does a pretty good job of trying to make upgrades work (which isn't really an apt thing, plenty of apt based distributions don't actually care to make upgrades work).

It's been a while, but my understanding is redhat figured out dependency resolution too, though.

Depends on what you mean by "figured out". Yum was capable of dependency resolution 15 years ago, maybe more, but was unbearably slow compared to apt-get. Maybe dnf solved that, maybe yum is faster now, I don't know, I switched to Debian more than a decade ago and didn't have a reason to retest RH since.

Even on the slowest systems I still have access to (64MB VPS, RasPi 1), apt-get is reasonably quick and responsive.

It's been a while since I've used it but yum used to tie up my machine pretty badly on significant upgrades. After reboot it could take hours to finish applying the upgrade, during which time the machine was usable. Apt has never given me that sort of trouble.

>It's been a while, but my understanding is redhat figured out dependency resolution too, though.

About 20 years ago, give or take.

Maybe 15, but I do recall using redhat in 1998 and getting things like you can't install foobar.rpm because it needs /usr/lib/libsomethingcool.so.4 and then plugging in that file name to rpmfind.net to figure out what package I needed (maybe it didn't need to be that hard, but it wasn't obvious that it could be easier)

> what makes apt-get that much better than other package managers

Nothing these days. I guess more desktop users are familiar with it because ubuntu + mint make up a lot of the Desktop market share.

It is better because it is more common

I'm a Debian user, but RedHat has had Yum (Apt-equivalent) for probably a decade now.

Way more than a decade. I remember running yum on fedora core more than 15 years ago.

These days it's all pacman for me though.

In terms of front-ends, there's always packagekit. The following will work on both rpm and dpkg derivatives:

sudo pkcon install <package>

Probably because the Gentoo ecosystem (package tree, package managers) is build for source packages and not for binary packages.

Portage can work with binary packages just fine: https://wiki.gentoo.org/wiki/Binary_package_guide

ChromeOS/ChromiumOS uses portage for its build system, to produce a signed, read-only image that the OS can boot from. CoreOS uses the same tooling FWIW: http://www.chromium.org/chromium-os/build

This is why you can’t just install random packages onto the parent OS. Any additional software needs to run in some overlay filesystem or sandbox.

I have never tried using portage with binary packages, but I am using Paludis with binary packages since a while and I have to say it is very different from using Apt or Pacman.

Package managers which are build for source packages (e.g. ebuilds/exheres) have a much more complicated logic running in the background, come up with much harder to solve problems and are a lot slower (orders of magnitude).

The only aspect where this setup is superior than e.g. arch + pacman is when it comes to using source packages on the same system. So I guess that is nothing you would like to use on a Chromebook anyway. Therefore, using a Debian container is a reasonable choice, in my opinion.

Do you know if pacman is available on Chrome OS? My understanding is that it's based on Gentoo but it's heavily modified. So adding a different binary-based package manager isn't that crazy of an idea, especially for Google.

Two package managers are a bad idea. They would need to cooperate somehow. Pacman developers probably have heard of Gentoo, but I wouldn't call it "based on Gentoo".

I meant that since pacman is not available, then use a different one entirely (not both). It seems it's a moot point b/c of the sibling comment saying the disk is read-only.

Chrome OS puts the core operating system on a read-only partition, which is why people have been using chroots in developer mode up until now.

I'd guess they wanted a simpler solution. Debian mostly has stable packages, but if users want more it is easier to get it compatible with Ubuntu repositories and packages.

For example if chromeos users wanted to install steam on their system having a Debian base would help.

Aside from this I'm really surprised that they are using Wayland instead of X11, this decision ought to bring some stability issues until Wayland gets widely adopted.

If I were to guess this feature has been added as a freetime project amongst Google employees. As such, I don't think we can expect continuity. If those developers go away/get reassigned or lose enthusiasm, I don't think Google would allocate resources to maintain a linux VM inside their OS. IMHO if it were important to Google that users could be able to use Linux apps, they would've strived for binary compatibility with Linux from the beginning.

> If I were to guess this feature has been added as a freetime project amongst Google employees.

I believe the impetus was enabling Android app development on Chrome OS. Google first said they were working on that a long time ago. I guess in the process of doing so they figured they might as well expand the functionality to cover all Linux apps, not just Android Studio.

As such, I expect support will be stable. Chrome OS in general has had very solid support, too.

Sandboxing

I guess because they want to keep the actual OS locked down. This way you can run any kind of linux software and even pretend to be root, all without really having root access to the pixelbook.

If I had to guess its because they want to move to their own proprietary systems and don't want to support backwards compatibility with "native" linux applications.

Exactly–ChromeOS being Linux-based is, at this point, an implementation detail. No ChromeOS "apps" depend on that fact, because they all run under their own VMs or ABI sandboxes. This means that Google could make a Fuchsia-based ChromeOS and nothing in userland (save for the code of those VMs and sandboxes) would have to change.

Isn't Fuchsia OS as well, kust no GPL?

Yes, various parts use BSD/MIT/Apache licenses, e.g.: https://github.com/fuchsia-mirror/docs/blob/master/LICENSE

That said, parent comments seem to be talking about two different topics. Later comment about Google switching the underlying foundation of Chrome OS from Linux to Fuchsia sounds plausible, while earlier comment complaining about Fuchsia being proprietary is nonsense.

It might not be proprietary, but if OEMs already only release updates at gun point with GPL, just wait until they get an OS with MIT like licenses given to them. It will be a big party.

Still does not make Fuchsia proprietary. There will be proprietary fuchsia bundles, sure, they are unfortunately standard with Android allready, but that was not the point.

Fuschia doesn't contain any Linux at all, hidden or otherwise. There's a compat layer you can run on top, but it's closer to the Windows subsystem for Linux than Chrome OS.