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.
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.
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.
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.
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.
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.
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.
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.
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.
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...
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.
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.
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).
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.
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.
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.
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.
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.
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?
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 :)
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.
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).
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.
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
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.
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 ...”.
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.
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.
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.
> 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).
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.
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"):
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.
Hopefully efforts like this continue with Fuchsia and other Google products.