Android container in Chrome OS
chromium.googlesource.com
chromium.googlesource.com
Hopefully efforts like this continue with Fuchsia and other Google products.
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...
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...
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.
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.
But I sort of agree with you too. I'm running Linux desktops rather than Chrome machines for that reason.
Plus going to be far more secure and optimized for the hardware.
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.
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.
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.
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) ?
But realize this losses cross platform support inheriently so you would have to use ARM gnu/Linux binaries.
Just visit the subreddit.
Heck, I could even run it virtualized, if Apple didn't forbid it :(.
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...
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.
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.
systemd is also open.
Open (as in "open source") != modular (or "inherently portable" for that matter).
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?
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.
I could have sworn there has been even a few instances of Systemd cock blocking Docker even though Docker had a clear precedence.
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.
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.
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.
Also most of the drivers are closed sourced.
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.
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.
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.
Versus they did Android as a container on the same Linux kernel as ChromeOS. But locked to only an Android container.
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.
Do you need to run gnu/linux apps inside containers or can they just run inside the VM running on top of chromeos?
Like all progress in computing we've reinvented the wheel, but now with a few additional layers of abstraction and the consequential performance degradation.
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.
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.
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.
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 :)
Containers help with keeping bad behaviors from stepping all over each other.
Unless of course you're saying that most software in the GNU/Linux world is badly behaved, which I'd kind of agree with.
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.
https://janitor.technology/ is attempting to provide a web-based version of this. Haven't yet used it myself, but it sounds promising.
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.
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).
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.
Basically a commercial gnu/linux.
I have no interest in the play store but I would like my lineageos/fdroid userspace available directly to my desktop.
At the very least, one would need to replace what sounds like a surfaceflinger <-> wayland proxy.
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.
Not a surprise to anyone who has followed Linux kernel security for the past years...
Edit: yes, Chrome OS kernels come with the binder driver enabled.
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.
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...
It'll interesting to see where they'll go with this, specifically since Google also work on Kubernetes and that new OS, Fuchsia.
https://twitter.com/rothgar/status/981579699833880576
More info on Crostini https://www.reddit.com/r/chromeos/comments/7ytpb1/project_cr... …
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.
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".
But now with ChromeOS 67 no longer need to use developer to do.
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.
Any modern containerization tool depends on them for resource isolation.
Or are you talking about the ChromeOS kernel in particular?
Also noticed there is a web "demo" of Fuschia experimental OS. That can be run in a single Chrome tab (click "guest"):
Then install the Android XSDL app for the GUI.
I'd like to be able to run native (via container) android apps on my desktop OS
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.