Live data from Hacker News

Docker for Mac and Windows Beta

blog.docker.com

71–80 of 250 posts

Re: Docker for Mac and Windows Beta

#71

The last time I used xhyve, it kernel panic'ed my mac. Researching this on the xhyve github account [1] showed that it was determined that it's due to a bug with Virtualbox. That is, if you've started a virtual machine since your last reboot with Virtualbox, subsequent starts of xhyve panic. So, buyer beware, especially if said buyer also uses tools like Vagrant. [1] https://github.com/mist64/xhyve/issues/5 I've said…

vbox4 caused issues with xhyve when xhyve first came out (not sure if it's still an issue), vbox5 coexists just fine.

Re: Docker for Mac and Windows Beta

#72

If I read correctly, docker for Mac is run on top on another visualization (xhyve, not VirtualBox) and docker for windows run on top of Hyper-V, which mean that it is not for production workload (at least for Windows). So you can only use it for development. And it is close sourced. hmmm...

This announcement is about a beta for native apps on Mac and Windows. The idea is to allow you to work with Linux containers on your development machine of choice. The images/containers you build there are just as deployable elsewhere — i.e. production — as they were before (when people had to use docker-machine, Virtual Box, etc).

Re: Docker for Mac and Windows Beta

#73
post #3

If I had a yearly quota on HN for upvotes, I'd use all of them on this. > Volume mounting for your code and data: volume data access works correctly, including file change notifications (on Mac inotify now works seamlessly inside containers for volume mounted directories). This enables edit/test cycles for “in container” development. This (filesystem notifications) was one of the major drawbacks for using Docker on M…

Here is the catch: you just need to realise that docker-machine is really just a virtual box linux machine. Once you get that, having shared volumes working as expected is quite easy without requiring 3rd party tools. I'm actually quite concerned on how this is going to change with this new tools, if they introduced "more magic" it could mean to lose control on your local environments.

Re: Docker for Mac and Windows Beta

#74
post #54

Can someone explain in simple terms how Docker for Windows is different from Application Virtualization products like VMware ThinApp, Microsoft App-V, Spoon, Cameyo, etc? Also, why does it require Hyper-V activated in Windows 10? I found this: https://docs.docker.com/machine/overview/ but I don't understand if you need separate VMs for separate configurations or they have a containerization technology where you are a…

docker on windows requires a linux vm running on top of virtualbox.

Re: Docker for Mac and Windows Beta

#76
To be entirely honest, I'm quite concerned about your choice on choosing Alpine as the base distro. Their choice of using musl over glibc might be cool but if you have to put old libs inside a container, it's hell (if not entirely incompatible).

Re: Docker for Mac and Windows Beta

#78

The last time I used xhyve, it kernel panic'ed my mac. Researching this on the xhyve github account [1] showed that it was determined that it's due to a bug with Virtualbox. That is, if you've started a virtual machine since your last reboot with Virtualbox, subsequent starts of xhyve panic. So, buyer beware, especially if said buyer also uses tools like Vagrant. [1] https://github.com/mist64/xhyve/issues/5 I've said…

Thanks, this is useful feedback. There are various workarounds in the app to prevent such things, but the purpose of the beta program is to ensure that we catch all the weird permutations that happen when using hardware virt (e.g. the Android emulator).

If anyone sees any host panics ever, we'd like to know about it (beta-feedback@docker.com) and fix it in Docker for Mac and Windows. Fixes range from hypervisor patches to simply doing launch-time detection of CPU state and refusing to run if a dangerous system condition exists.

Re: Docker for Mac and Windows Beta

#79
post #35
post #26

Earlier quoted context omitted.

Nix is more difficult. With Docker, you don't need to learn much new stuff, since images are created from sequences of ordinary shell commands running on familiar distributions. Nix requires you to familiarize yourself with a new package manager and its somewhat arcane definition language. And then also the specific Nix tools for working with npm, ghc, or whatever you want to use. So the experience is very different.

In this case you could still pick homebrew as your package manager of choice. It works pretty well, is available cross platform ( https://github.com/Linuxbrew/linuxbrew ) and is far more simple than docker. You just have write a short shell script which installs all the dependencies via brew when not installed already (much like you'd do in a Dockerfile).

Brew doesn't offer you isolation - you cannot run multiple isolated applications with different dependencies at the same time.
Post reply on HN