Live data from Hacker News

Android container in Chrome OS

chromium.googlesource.com

121–130 of 140 posts

Re: Android container in Chrome OS

#121
post #50
post #49

Earlier quoted context omitted.

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…

> 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.

Re: Android container in Chrome OS

#122
post #56
post #49

Earlier quoted context omitted.

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…

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?

Re: Android container in Chrome OS

#124

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…

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.

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.

Re: Android container in Chrome OS

#125

Earlier quoted context omitted.

> 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 to…

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.

Re: Android container in Chrome OS

#126
post #88

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…

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.

Re: Android container in Chrome OS

#128

Earlier quoted context omitted.

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.

Re: Android container in Chrome OS

#129

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 i…

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

Re: Android container in Chrome OS

#130
post #89

Earlier quoted context omitted.

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 g…

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.
Post reply on HN