41–50 of 140 posts
Does anyone have a link to what Chromebooks will support ChromeOS 67? Is there a matrix somewhere?
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 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 wi…
Earlier quoted context omitted.
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. https://twitter.com/rothgar/status/981579699833880576 More info on Crostini https://www.reddit.com/r/chromeos/comments/7ytpb1/project_cr... …
Would this work on a ChromeOS that I install on, say, an aging PC Laptop?
Edit: yes, Chrome OS kernels come with the binder driver enabled.
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 wor…
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.
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 wi…
Docker is quite closed as well, so I am not sure if it is a good step in the right direction.
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
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 replace…
systemd is also open.
Open (as in "open source") != modular (or "inherently portable" for that matter).