Hacker News new | comments | ask | show | jobs | submit login
Android container in Chrome OS (googlesource.com)
376 points by navigaid 10 months ago | hide | past | web | favorite | 135 comments

I can't wait for the day that phone operating systems development environments are a docker pull away. It's encouraging to see Google approaching my ideal workflow using containerisation. Apple systems are great until you run into the garden walls and are forced to use closed-source single platform software like Xcode. Chrome OS and Android are a lot more open in many respects.

Hopefully efforts like this continue with Fuchsia and other Google products.

To be fair you can't go very far without running into garden walls in Apple land. It doesn't just apply to development.

Want to change your launcher / dialer / etc? WALL!

Want to run a different web browser (an ACTUAL web browser complete with JS / CSS engine). WALL!

Want emulators or adult-themed apps? WALL!

Want to develop for iOS or macOS on Windows or Linux? WALL!

The list goes on and on...

I thought cross compiling for OSX wasn't so bad.

ChromeOS is significantly more locked down than macOS, developer mode notwithstanding. Firefox for iOS may use WebKit, but Firefox for ChromeOS isn't even a thing.

> ...Firefox for ChromeOS isn't even a thing

Uh? Most Chromebooks these days run Android apps, so you can install pretty much anything that can run on a regular Android smartphone -- including Firefox Quantum [1].

I haven't tried Firefox yet, but did install a bunch of things on my parents' notebooks - Skype, Android games, etc. Some have problems with the larger aspect ratio, but most run just fine.

[1] https://www.techrepublic.com/article/how-to-run-firefox-quan...

1. That was intended as a virtue not an omission

2. It's no longer true now you've got Android app support. Whether you think this is a good thing or a bad thing depends on your feelings about point 1.

3. "developer mode not withstanding" - well it is withstanding. You'd hear a lot less moaning about iOS if that had a similar mode.

Conversely, a ChromeOS device is much less locked down than an iOS device, since you can run full Linux (with root) in a chroot on a ChromeOS device.

We may be doomed to an infinite regress here. After all, a Chromecast is more locked down than an iPad...

Someone considering running chrooted Linux on a Chromebook is going to be more interested in a Mac than an iPad, so IMO that's the more useful comparison.

I did run Crouton on a ChromeOS device and came to regret it. ChromeOS devices don't run a mainline kernel, they run something that Google provides which eventually stops receiving updates.

The audio app I wanted to run required a newer kernel, and there was no way to get it short of forward-porting a bunch of device support and building it myself.

IMO for Linux development, users are better served by a real Linux laptop than by a ChromeOS chimera.

I would prefer a powerful ChromeOS device with the ability to run Linux containers over an iPad or a Mac. I suspect that I'm not the only developer who thinks that way.

But I sort of agree with you too. I'm running Linux desktops rather than Chrome machines for that reason.

I would prefer a ChromeOS box as it has commercially supported Linux drivers and it is Linux versus OS x close but not Linux.

Plus going to be far more secure and optimized for the hardware.

What? ChromeOS runs Android and gnu/Linux. Would say it far less locked down then anything.

Can you explain as this does not appear to make any sense?

Btw, also Google gives source code in addition.

Or are confusing strong security with a wall? They are different.

You have it with ChromeOS 67. Docker without having to put in developer.

What do you mean by "developer" in that sentence? Mostly when I see "developer" it means a person that develops code - a programmer, but here it doesn't make sense in your sentence.

Well it is a bit confusing as the same word used in two places.

There is putting your Chromebook in developer mode which removes safety checks and a way to use GNU/Linux on a CB. You then can install Crouton.

But then there is putting a CB on the developer channel or the Canary channel which is completely different.

I am currently using both as I can then see what is happening with the host OS while using the new VM capabilities with my PixelBook.

I believe he's saying: without having to put the chromebook into developer mode. A mode that allows developers to do more on their chromebook, such as using a terminal, which is not accessible in regular mode.

developer mode in ChromeOS

Can you share a specific example of this? I got lost in the parent article but was that in there?

Yes. Boot, launch chrome tab, type Ctrl alt t, then type vmc start dev.

You have a GNU/Linux kernel which you can do whatever you want.

For more info visit Reddit and the Crostini subreddit.

You can use Steam or really whatever.

What is happening is Google has enabled the KVM. You are using a second Linux kernel and can do whatever safely and away from the ChromeOS Linux kernel.

Even GUI works as forwarded to ChromeOS. So start xclock and opens.

>Even GUI works as forwarded to ChromeOS. So start xclock and opens.

What is graphics performance like for the guest ? Does this use gpu virtualization (somewhat supported for intel gpus in recent kernels) ?

Is it also enabled in old ARM only chrome books? Mine is in dev mode and I would switch it back to regular if I can run kvm inside.

No not yet. It is also only on Pixel books right now. It uses hardware supports VM so possible on ARM.

But realize this losses cross platform support inheriently so you would have to use ARM gnu/Linux binaries.

Steam is actually still a WIP. When I tried to install it following the Debian instructions (inside a Stretch container) I was unable to do so. It currently does not support the i386 arch necessary. Maybe that has changed since I tried, but it was not working for me a week or so ago.

There is instruction on how to use Steam on ChromeOS 67 with a Pixel Book on /r/crostini.

Just visit the subreddit.


I had read that, but from what I read they get it to launch steam, but cannot run a game yet. So still a WIP.

There are people on Reddit claiming they have it working.

This. Apple, just give me a console access on iPad with keyboard.

Heck, I could even run it virtualized, if Apple didn't forbid it :(.

I don’t even want that. I just want a keyboard that doesn’t blow. iOS provides no key remapping and most iPad keyboard covers don’t have esc keys. The only way for me to type semi-fluidly on an iPad in a terminal is to hook up one of those happy hacker keyboards to a hand held scientific usb-to-Bluetooth adapter.

I have found a way around all this, which nevertheless requires a thin layer of interaction with the walled garden, and this to put everything in a VM, expose only the things that need to be exposed from the host OS, and run a common framework across all possible platforms.

Believe it or not, there are a lot of these kinds of projects out there, mostly obscure, probably by necessity because in fact it is a lot of work to maintain such a system. But, due to the abhorrent nature of the OS vendors, sleeping at the wheel, there is no choice other than to build another, OS-like, system on top.

And where that is always happening, and still will for quite a while I hope, is in the games engine department. Sooner or later, games engines become operating systems, become hosts for spreadsheets and collaboration and other such nonsense...

All this is to say, I have my xcode builds running in a VMWare container, they're safely backed up and replaceable, etc., and all they do anyway is build the target hosts: android, ios, linux, windows, macos, etc. for the .. separated through an abstraction layer .. application.

The use of Lua, I think, is a good example. Lua on all the mobile platforms, would deflate the whole thing...

Docker is quite closed as well, so I am not sure if it is a good step in the right direction.

Could you tell us exactly which part of Docker you think is "quite closed"? Docker (Moby) is licensed under Apache 2.0, and so is containerd, the default runtime.

A license unfortunately doesn’t tell the truth, but their actions. They’re extremely closed.

A license means that "their actions" don't matter.

What actions?

The tight coupling to systemd which refuses to standardise any "internal" interfaces and insists on taking over the entirety of one's system. You can't run Docker if you're not running systemd, you can't run systemd if you're not running udevd and logd and so on, you can't run those if you're not running not just Linux but essentially only the "current" version of Linux, and if you ever implement a compatible replacement for one of those pieces they'll break compatibility with it in the next minor release.

If Docker were an open system it would already be running natively (not that ridiculous docker-in-a-vm thing) on Solaris, FreeBSD (which have offered similar functionality for decades), and probably MacOS by now. Instead their maintainers are actively hostile to portability patches as a matter of policy.

None of what you said is true. Docker does not depend on systemd (there is only one piece of systemd-specific code in the entire project and it's inside runc -- that piece of code is not used by default and also has a non-systemd implementation that is more stable than the systemd one).

I have historically had many problems with Docker and how the project is governed. I'm also no fan of systemd. But there's no point in literally spreading lies.

>The tight coupling to systemd which refuses to standardise any "internal" interfaces and insists on taking over the entirety of one's system.

systemd is also open.

Open (as in "open source") != modular (or "inherently portable" for that matter).

Open does include modular; since user freedom is the end goal, open standards are even more important than open source.

So fork it? What you outline doesn't mean it's a closed system, it means they have different goals than you and don't want to support your use case. The fact that it's open and you can submit contributions, even if they aren't accepted, is proof that it's not a closed system. Make your own fork and use that. And if that's too much work, why would you expect someone else to do it for you for free?

> The fact that it's open and you can submit contributions, even if they aren't accepted, is proof that it's not a closed system. Make your own fork and use that.

Open alternatives already exist, I use them. But people build other systems that integrate only with docker, and since docker deliberately refuses to follow any fixed standard, other systems can't be compatible with the docker ecosystem. Am I supposed to fork every codebase in the world?

I have a Gentoo system without systemd (I despise the thing for reasons I don't want to get into right now), and I also have Docker running right now.

Worst trouble I had with it was compiling the necessary modules into the kernel when I installed it. The rest was relatively painless (as painless as administering a Gentoo system can be, anyway).

Your post needs a huge dose of clarification.

Err, no. Docker is not coupled to Systemd. If anything Systemd is competing with Docker via their nspawn sub-system.

I could have sworn there has been even a few instances of Systemd cock blocking Docker even though Docker had a clear precedence.

I think instead of them not being open you mean to communicate that they are assholes who don't work with others? If you are going to be critical be accurate too.

What do you mean? You can now run Docker fine on ChromeOS 67 and personally am doing it now on the machine I am typing this.

But you could even use Docker before all this new stuff by putting in developer, install Crouton but you had to use rkt to launch the Docker containers but worked fine.

With ChromeOS 67 no longer necessary.

How did you start running docker on 67?

Apple systems are great precisely because they’re single platform and closed-source. It would be unfortunate if that changed.

I don’t see how you arrived at that conclusion. Why is the software not being open source a benefit?

Some people have different tastes. I know a lot of people who drive a Honda because it's easy for them to repair on their own, and parts are cheap. I know others who drive a BMW even though it's difficult and expensive to repair, because they would never repair it themselves so it doesn't matter. They value the experience of driving "the ultimate driving machine" even if it costs more and is harder to repair.

Some people prefer open platforms that they can customize and tinker with. Some people prefer closed platforms where the defaults are good enough and you never have to open the hood. Neither of those preferences are more wrong than the other one. It's just a preference.

The specific issue under discussion has little to nothing to do with user experience though. It wouldn't change the iOS user experience if an iOS dev environment was available for Linux, or if you could test your iOS code on a jenkins server running on an ec2 instance.

Wouldn't it? I'm sure plenty of iOS devs have Macs and understand Apple's ecosystem (since they have to right now), but if they opened that to people who aren't in the ecosystem, would it really have no impact on user experience? Mac and iOS are two different products but they both follow the Apple standard and appeal to Apple people. Limiting iOS development to Mac users means everyone who develops for iOS understands Apple at least enough to use their products for work.

Apple sells a very specific user experience, one they control soup to nuts. It's not for everyone, it's for a specific audience. Luckily we live in a world where there are tons of choices, and by far the more popular choice is "not Apple" according to every statistic I've ever read. They can afford to be picky, they can afford to turn off some customers, because there are a ton of choices that are the opposite of the Apple experience.

If you want a BMW, you want a BMW. If you want a car, you can have any car you want. Including an Audi.

But all things being equal, generally I'd say that software that allows you tinker is probably better. The fact that the freedom exists doesn't mean you have to take advantage of it, but it's nice that it's there.

While I don't agree with the parent's sentiment that iOS is great because it is closed. Neither Android Of Chrome OS is as open as proponents make them out to be. The typical Android distribution on phones have plenty of Google closed sourced parts.

Also most of the drivers are closed sourced.

Interesting. Would say the exact opposite.

Better is ChromeOS 67 enables running your own containers without having to put CB in developer.

It uses the KVM to run a second Linux kernel. So you will be able to use GNU/Linux applications including Steam. More to be shared at Google IO this year.

Are you sharing a rumor/insider knowledge? Can I do this right now?

The current dev branch (67) supports this.

From crosh:

vmc start dev start_container.sh --container_name stretch --user <yourusername> --shell

That should drop you into a shell in a debian stretch distro. You can install packages and launch them. I haven't figured out if there's a way to pin them to the shelf yet and launch that way.

Yes. No inside information. Done it myself.

I just had a vision of all major OS projects providing developer containers for their projects. Like, you could just pull the latest Firefox dev container and run a single command to have a running debuggable app.

I know one of the major pains we have when on-boarding new people is the whole dance to get to that first working build / first meaningful change. I can imagine this being significantly more simple if a working dev environment was shipped as a container.

Gnome is moving in this direction by using Flatpak + Gnome Builder. They're also running CI inside the Flatpak environment.

Exactly what Google has done with ChromeOS 67. You can run GNU/Linux applications as containers. But extra safe as a container on a separate kernel through a VM using KVM.

Versus they did Android as a container on the same Linux kernel as ChromeOS. But locked to only an Android container.

You mention "run GNU/Linux applications as containers" but is that a full dev environment? As in, I can open a cpp file or whatever, make a change, run a single command and I can see my changes?

Yes a full dev environment as of ChromeOS 67.

How you want to use is your choice.

But it looks like Google will package GNU/Linux applications as containers that you can just run.

You can use what they have enabled in other ways as I am already doing on a PB with ChromeOS 67.

> You can run GNU/Linux applications as containers.

Do you need to run gnu/linux apps inside containers or can they just run inside the VM running on top of chromeos?

Many OS projects do this with Vagrant.

You know, there once was a time when we did everything in folders and didn't need the overhead of containerization just to keep well behaved things from stepping all over each other and breaking everything.

Like all progress in computing we've reinvented the wheel, but now with a few additional layers of abstraction and the consequential performance degradation.

> You know, there once was a time when we did everything in folders and didn't need the overhead of containerization just to keep well behaved things from stepping all over each other and breaking everything.

Those were the days…when we didn't have stupid watchdogs like memory protection and preemptive scheduling, and we all shared resources nicely and fairly, all the time. There were never crashes because someone touched memory that they weren't supposed to, or hangs because someone decided they were more important than all the other processes. No siree.

Way to name some completely orthogonal problems that existed at the time. I'm surprised you didn't mention needing to go to a library to look things up or tie up the phone line to use the internet.

> Way to name some completely orthogonal problems that existed at the time.

What? These aren't completely orthogonal at all, they all fall under the umbrella of "process isolation" and containerization. There's a reason we have safeguards for processes in place; it's because it's a lot better when you have something to police badly behaved software than to trust that everything will work well 100% of the time.

Yes, I can see why orthogonal was a bad choice of words here.

Here's my point: those things mentioned were improvements on things that didn't work very well even for trusted applications that did nothing unreasonable.

When your development environment or even regular desktop software spreads itself all over the filehierarchy as a matter of practice, conflicting and interfering with every other application because it does the same thing, that's taking something that used to work just fine and breaking it. Then you add a layer of abstraction like containers to solve the mess you created.

Containers are a good idea for a lot of things, I just don't think I should need them to run normal everyday software.

>there once was a time when we did everything in folders

Not on Unix though. "Stepping all over each other" sounds like the guiding design principle behind Unix's folder structure and dynamic library loading aproach.

Docker's isolation is far more than just isolation of files and folders. It's more like J2EE for Linux :)

> keep well behaved things from stepping all over each other and breaking everything

Containers help with keeping bad behaviors from stepping all over each other.

Yes, that's their value. You shouldn't need to use them for your development environment or normal every day software.

Unless of course you're saying that most software in the GNU/Linux world is badly behaved, which I'd kind of agree with.

Containers also decrease the likelihood of bad behaviors getting fixed.

When was that time?!? Do you have a time machine so I can go there?

That never happened... Maybe it happened in some tight academic environment for a few years, but once the cat was out of the academic environment, it basically never happened.

> Like, you could just pull the latest Firefox dev container and run a single command to have a running debuggable app.

https://janitor.technology/ is attempting to provide a web-based version of this. Haven't yet used it myself, but it sounds promising.

I somehow highly doubt they're building all of Firefox in that demo video... heheh

You mean you want a statically linked binary?

By looking at the comments this article is creating confusion. So I thought I might provide an overview of the two things happening with ChromeOS.

1) Android apps have been enabled on many Chromebooks using a locked container that shares a Linux kernel with ChromeOS. You do NOT have access to the container mechanism that is being used. It ONLY supports a container locked by Google. It is NOT using Docker also.

This is available on both ARM and X86 Chromebooks and most recent models are now supported. It took a while.

All Android apps run in a single container.

2) Starting with ChromeOS 67 and only on Pixel books so far there is full GNU/Linux capabilities on a Chromebook without having to put the Chromebook in developer mode.

Developer mode is how you turn off much of the security of a Chromebook and keeping in this state is a bit of a hassle as when you boot you MUST remember not to hit the wrong keys and wipe your CB.

What Google has done is enable the KVM on the Chromebook ChromeOS Linux kernel. So you can run a second Linux kernel where you have full control of the second Linux kernel.

Then on top of this VM Google is pushing the use of containers. So these containers are completely separate from the Android containers.

Then all the containers on the VM share a common Linux kernel that is separate from the Android and ChromeOS kernel.

What this does is keeps the highly secure aspect of ChromeOS while giving you full GNU/Linux on the machine.

Google has also enabled forward GUI of the GNU/Linux VM to the ChromeOS desktop.

So say you start XClock on the VM the window will open up on the ChromeOS desktop.

What is also confusing to people is GNU/Linux has been available on Chromebooks for a long time. There has been a number of ways to use.

1) Put CB into developer, install Crouton and you have GNU/Linux. But to use Docker you MUST use rkt to start the containers.

2) Install the Android GNURoot app. This gives you GNU/Linux but in a fake chroot that breaks many things. You can also use the Android XSDL app for the GUI. Since Google implemented ALL Android apps in a common container the IP is the same for both GNURoot and the XSDL app.

In ChromeOS 67 Google has fixed the IPs used by the Android container and now using the NAT reserved IPs instead of private IPs. This solves a weird bug you would run into where you had a IP conflict if you used the same private IPs elsewhere.

Google is also using the NAT reserved IPs with the new GNU/Linux support through a VM.

It looks like Google will be packaging GNU/Linux applications like Android Studio in containers that you can then run on a Chromebook with just a click. But will they be in the play store is unclear. But these containers will run on the VM.

Google will have ChromeOS 67 hitting stable at the same time as Google IO where they are rumored to explain things better. All of this new GNU/Linux support with a VM is in beta.

Hey! Thanks for the detailed reply. What I don't get is: ChromeOS is open source, so why do all these things only work on certain hardware? Isn't there a way to install ChromeOS on any laptop today and already use Anroid apps et al, without said machine being a Pixelbook?

I have a machine that is not an official ChromeBook and I'd love to install ChromeOS with Android support to try it out. But I've done quite some google-fu and could not figure out whether this is possible (and how I'd set that up).

ChromiumOS is to ChromeOS as Chromium is to Chrome: https://www.chromium.org/chromium-os

To expand on andrewaylett's comment, that it is open source doesn't automatically mean "100% hardware compatibility."

Even for the linux kernel, someone somewhere has to figure out how to get it to boot on every piece of hardware.

It's not magic. The nice thing is that if the first person who gets it working can just 'git push' their code to kernel.org, then the next person doesn't have to redo all that work.

You're correct in sentiment. But one can't git push to Linux master without having the patch reviewed and merged by a maintainer.

There's also another option. Many Chromebooks and Chromeboxes allow you to install a new bios and run a normal Linux distro without ChromeOS at all. Handy if you like the cheap hardware but aren't interested in ChromeOS. See https://johnlewis.ie

Much better to use gnu/Linux on chromeOS. That way you get updates for drivers, security, etc.

Basically a commercial gnu/linux.

I guess. Running apt-get periodically isn't a huge task though. My chromebox is current, despite the lack of ChromeOS.

Thanks for the detailed breakdown! Any idea if the new VM itself will be accessible? Or will everything have to run in a container?

I'd really like this to evolve into a standard thing in our linux distros. By which I mean apt-get'able, which it looks very close to.

I have no interest in the play store but I would like my lineageos/fdroid userspace available directly to my desktop.

I wonder how hard it would be to get this working on, say, Fedora...

At the very least, one would need to replace what sounds like a surfaceflinger <-> wayland proxy.

Yeah, it would be pretty interesting to be able to use this as an Android development environment. It should be significantly faster than current approaches with emulation.

Supports AS. The thinking is this is why Google did it. You can now run GNU/Linux applications

Very easy with ChromeOS 67.

Just boot, launch a chrome window and type Ctrl alt t.

Then type vmc start dev.

Then you can use whatever distribution you want as you have full GNU/Linux.

Only works on Pixelbooks but Google will extend and will share more at Google IO.

You can even package up gnu/Linux applications. One click and they run in a container but on a second Linux kernel.

So Android shares the ChromeOS kernel where gnu/Linux will run in a container on top of a VM using the KVM.

It is interesting that Google did not feel just using containers for GNU/Linux was secure enough.

And that helps me get an Android container running on an actual desktop OS how? That was the question, after all.


Read OP's first line again. Note how it says "on Fedora" without specifying hardware, which last I checked is mutually exclusive with "on ChromeOS and a pixelbook".

The question was how to get it working on a non-ChromeOS device and system, and you provided instructions for ChromeOS. I don't believe they'll work, but hey, I can try it.

On my self-built desktop, running Ubuntu 17.10, the following result happens:

    zsh: command not found: google-chrome-stable

    zsh: command not found: vmc
So, again, how do I get any of this running on an actual desktop OS, on a usual computer?

You just claimed I can, please provide instructions, or please stop trolling.


Parent commenters said that they wanted to do the same thing as OP article but on Fedora instead of on Chrome OS. You responded to them with how to do it on Chrome OS which is not what they were looking for.

It’s like if you asked me “can I develop iOS apps with Chrome OS on my Chromebook?” and I told you “sure, in macOS on your MacBook just ...”.

Personal insults like this will get your account banned. Please follow the guidelines instead.


I think you missed the "Very easy with ChromeOS 67." this doesn't work in any Chrome browser on any OS

The question was how to get it working WITHOUT ChromeOS 67, on a normal desktop OS, such as fedora or ubuntu.

Well then the answer is that you can't.

Edit: Why would you expect to be able to use a Chrome OS feature on other operating systems?

No one's expecting to be able to use it right away. But maybe a Chrome OS (which is a modified Gentoo, after all) feature can be ported to another Linux distro.

Yes requires not only chromeOS 67 but also a pixel book and more info available at Google IO this year.

> It is interesting that Google did not feel just using containers for GNU/Linux was secure enough.

Not a surprise to anyone who has followed Linux kernel security for the past years...

OK, but he was asking how to do it in Fedora, not ChromeOS.

There's Anbox http://anbox.io/

What about Binder? Do Chrome OS kernels come with Binder built in, or are they emulating it on top of another IPC mechanism?

Edit: yes, Chrome OS kernels come with the binder driver enabled.

Does anyone have a link to what Chromebooks will support ChromeOS 67? Is there a matrix somewhere?

Just about all will support ChromeOS 67 including ARM. But that does not mean they all will get the new gnu/Linux without developer support.

Right now only the pixel book supports in ChromeOS 67.

Google will share more at Google IO as this is still beta stuff. The hope is it will be more than just the PB.

I'm assumng that it will be very close to the Android support list [0]. I'm a bit sad that NaCl Dev Environment [1] went nowhere, because I think, that my Acer Chromebook 13 will never be otherwise supported. That's also a reason for me to not buy ARM. I'm mildly counting on the hypothetical AMD Chromebook.

However my miniscule trust in corporations is getting even smaller lately, so I don't know what I will do when my Chromebook will see it's inevitable EOL. As much as I like technology behind ChromeOS I would prefer to finish my own Linux distribution project.

[0] https://www.chromium.org/chromium-os/chrome-os-systems-suppo...

[1] https://chrome.google.com/webstore/detail/nacl-development-e...

[2] https://chromeunboxed.com/news/amd-chromebook-in-development...

This is incredible. Using this, going from Linux to Zirkon is just a Kernel-switch away. Potentially they could replace small parts of the Linux-parts of Chrome OS slowly and iteratively with Fuchsia.

I have an ARM64 React Native toolchain sitting on blocks for ChromeOS. Caret is the IDE for this but Android SDK is truly lacking for ARM the build tools are base level. There is a guide floating around out there to make your own too. Looking forward to more stuff like this because essentially you get realtime Native app development with this but hooking into the debugger via crosh terminal is hard. Smoothing out the rough edges on this and then wow! You will have a powerhouse. NativeScript? Even better in theory.

Interesting to see Chrome OS adopt process compartmentalization techniques such as this, specifically adopting `cgroups'. Afaik, cgroups isn't enabled by default and requires customizing the kernel before you can enable it. At the very least, container tools such as Docker require symlinks too to invoke chroot-like filesystem isolation and this is also not available.

It'll interesting to see where they'll go with this, specifically since Google also work on Kubernetes and that new OS, Fuchsia.

Speaking of which, it is now possible to run full linux and android apps on chromebooks which support containers (and vms?) in a tab with the new official Google Crostini project. Makes the Pixelbook more attractive.


More info on Crostini https://www.reddit.com/r/chromeos/comments/7ytpb1/project_cr...

There is a Crostini subreddit where people are trying different things with it: https://www.reddit.com/r/Crostini/

Would this work on a ChromeOS that I install on, say, an aging PC Laptop?

Yes. The code is also being done in chromium OS.

> Afaik, cgroups isn't enabled by default and requires customizing the kernel before you can enable it.

cgroups are supported on every distribution's kernel I've ever touched in the past 5 years. Not to mention that they were originally developed (in part) by Google, though they had a different purpose back then. They're also a requirement for systemd to work properly, so any distribution that needs to run systemd will have them enabled in their kernels.

> At the very least, container tools such as Docker require symlinks too to invoke chroot-like filesystem isolation and this is also not available.

Docker (or rather runc) uses pivot_root and mount namespaces to implement filesystem isolation -- not symlinks (though I'm not sure what you mean here to be frank). These features have been in Linux for more than 10 years.

No, cgroups is enabled on every major linux distro (though I'm too lazy to check if every configurable is set such that it will run this particular Android container). It's well-established base linux technology at this point, certainly nothing weird.

I think OP might be referring to the fact that Android kernels disable most functionality required to run most standard Linux container tech. AFAIK it's not possible to run Docker even on rooted devices if they are running a (close to) vanilla kernel, whereas you can run Docker just fine on Linux single board computers that run similar processors.

The host OS in this case is ChromeOS, though. But OK.

I took the point to be "cgroups is weird, nonstandard and by implication dangerous" when the truth is more "cgroups is standard equipment, sorta boring, and the obvious way to implement a container like this".

You can run LXC on Android, and have been able to for several years. So on Android enough of the kernel features are there (though to be honest you only really need a pid+mnt namespaces and most people wouldn't tell the difference).

You can use Docker fine on a CB that you put in developer now. Just install Crouton and use rkt.

But now with ChromeOS 67 no longer need to use developer to do.

cgroups are a dependency of systemd, so they're extremely standard. (I'm not sure what you mean by "customizing"; there are no binary builds of the Linux kernel available from the kernel developers, so everyone builds their own kernel.)

Not sure what you mean by symlinks either - the right primitives for secure filesystem isolation (pivot_root, etc.) are also very common. pivot_root is the normal way to switch from an initramfs to the real root filesystem, so it's also extremely prevalent.

I don't work on Chrome OS, but my understanding is that one of the things that makes this possible is that Chrome OS requires device manufacturers to upstream kernel drivers for a device to be supported. This means that -- unlike Android -- it's always possible to rebuild a new kernel from source using the Chrome OS source tree.

cgroups are pretty standard nowadays and all major distros have them enabled.

Any modern containerization tool depends on them for resource isolation.

Or are you talking about the ChromeOS kernel in particular?

Thanks for publishing. Very informative. Am just setting up NeverWare as a devenv for Android. With localhost ADB connections. Could prove a powerful platform for Android automation.

Also noticed there is a web "demo" of Fuschia experimental OS. That can be run in a single Chrome tab (click "guest"):


The recently announced Droplet containers extend on this idea with a supposedly commercial-ready multiplatform solution


You can use gnu/Linux on Android with a CB. But you have to use a fake Chroot. Just go to play store and install GNUroot.

Then install the Android XSDL app for the GUI.

can you use this to properly replicate the functionality of dropbox, though?[1]

[1]: https://news.ycombinator.com/item?id=8863

Should not be a problem unless I am missing something? Can what you are talking about run on GNU/Linux?

Theoretically, this container should be able to run in any host os supporting containers.

I'd like to be able to run native (via container) android apps on my desktop OS

When the hell are we going to get electron and node.js apps on chromeos. Those are far more important than these crappy blown up phone apps

I disagree on the "more electron" front. Running old Chrome with known vulns packaged up into an app is not the direction I'm looking for ChromeOS to go. I'll take an app in a tab, please.

Not sure if this is a sarcastic comment. But afaict, Android apps in Chrome OS need not be artificially blown up to full screen. They can run in a windowed mode, in an optimal size.

However, I don't see any technical challenges in supporting Electron apps as well, other than constraints in RAM, performance and security of the Electron platform.

Android need a kernel feature called binder which afaik is not part of vanilla kernels / distro kernels.

Does this open the path to running android apps on gnu/linux desktop?

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact