Live data from Hacker News

Dissatisfied with Docker

robert.ocallahan.org

91–100 of 229 posts

Re: Dissatisfied with Docker

#91

These are real problems with docker, but do we wanna talk about docker for Mac? A total performance disaster. https://github.com/docker/for-mac/issues?q=is%3Aissue+is%3Ao...

Docker for Mac is a performance nightmare. It requires state of the art $3400 macbook pro to run properly, and even then still takes seconds (or 10s of seconds) to spin up, start local servers, etc. Build processes that would've run locally take 3-10x longer running on docker for mac. The whole thing can be quite frustrating.

Re: Dissatisfied with Docker

#92

These are real problems with docker, but do we wanna talk about docker for Mac? A total performance disaster. https://github.com/docker/for-mac/issues?q=is%3Aissue+is%3Ao...

I hate how the Docker team called it native. Docker for Mac/Windows still run in a hypervisor because so much of Docker is specific to Linux/cgroups. There was a FreeBSD port of Docker that attempted to implement a lot of the Docker API using zfs+jails but it went unmaintained and was never ported to the newer modular Docker implementation. You're always going to get that performance hit with the hypervisor layer the…

I preferred the old mac solution where they didn’t try to hide the vm from you. It was much more straightforward.

Re: Dissatisfied with Docker

#94
post #11

Earlier quoted context omitted.

Wasmer looks interesting. I couldn’t read much as I get an “unexpected error” as soon as I start scrolling. It does say that it’s not optimised for mobile.

Thanks for reporting it! We will investigate and try to fix it ASAP :) PS: if you could provide your device info (os and browser) it would be awesome

Also seeing it on an iPhone 8, iOS 12.4. The site is completely unusable/unreadable.

Re: Dissatisfied with Docker

#95
post #82

Earlier quoted context omitted.

Distroless is not non-Docker, it's very much Docker.

Please explain. You can build images using Bazel with distroless as the base image. Similarly I think Jib/ko use distroless images without needing a docker engine.

The thing you build is a Docker image.

Re: Dissatisfied with Docker

#96

Earlier quoted context omitted.

JVM requires almost all your stack to be rewritten for it. Because WebAssembly permits languages to be usable in the web, almost any other language (C, C++, Rust, Go and even Java) is now working to be compiled to WebAssembly. Therefore you don’t need to adapt your stack to run it in Wasmer :)

> "JVM requires almost all your stack to be rewritten for it." This applies no more to the JVM than to Wasmer. There exists WASM to JVM bytecode transpilers [0]. [0] - https://github.com/cretz/asmble

Although your point is completely right, once your application is in wasm perhaps you can use directly a wasm vm (wasmer) instead of another transpiler and the jvm :)

Re: Dissatisfied with Docker

#97
It's interesting to see the complaint about containers starting too slowly. I haven't seen much discussion about it before this article and this comment thread, but it's one of my biggest pain points with Docker. I know we can save some time by skipping some namespaces (e.g. `--net host`) but I've still never been able to get satisfyingly fast container execution in that way. (e.g. `time echo` -> 0.000s, `time docker run --rm alpine echo` -> 1.3s; come to think of it, this is even slower than it used to be)

Still, Docker is the best method that I've seen for distributing software, especially cross-platform. Not just for shipping a containerized web app to production, but also running dev tools (e.g. linters, compilers) and other desktop and CLI applications. I know some people run lots of stuff in containers (https://github.com/jessfraz/dockerfiles, probably the most prolific), but I think this is a largely underappreciated facet of Docker.

My team at work is heavily Mac while I'm on Linux. The dev workflows are identical on my machine, on their machines, and in Jenkins. Nobody has to have a snowflake setup, installing this or that version of Python, we're all just `docker run`ning the same image. It's great.

Unfortunately, Docker for Mac's IO performance is abysmal. If past performance is any indication of future results, that's never going to change. I'm constantly on the lookout for other ways to share tools cross-platform that don't involve Docker. Things like podman and binctr are exciting, and I've played with them, but I don't see them filling this niche.

Re: Dissatisfied with Docker

#98
post #10

I just want to be able to save a container binary to a USB drive and then run it from a different computer without having to install anything.

The first time I emailed a buddy a Go cross-compiled binary and he opened and it ran no problem (opsec aside), our worlds changed.

This is exactly how I'd like containers to be as well.

Re: Dissatisfied with Docker

#99

Earlier quoted context omitted.

I hate how the Docker team called it native. Docker for Mac/Windows still run in a hypervisor because so much of Docker is specific to Linux/cgroups. There was a FreeBSD port of Docker that attempted to implement a lot of the Docker API using zfs+jails but it went unmaintained and was never ported to the newer modular Docker implementation. You're always going to get that performance hit with the hypervisor layer the…

I preferred the old mac solution where they didn’t try to hide the vm from you. It was much more straightforward.

I personally disagree. I hated the whole docker-machine rubbish and exporting of the env vars.

That doesn't make the performance problems of docker-for-mac any less nasty though.

Re: Dissatisfied with Docker

#100
post #76
post #46

Earlier quoted context omitted.

Not just in MacOS. Over time, Docker can eat all your storage.

Because it keeps around all of the images you use as well as the containers after they are stopped so you can resume them. there is a command that auto automatically removes all unused images and containers you can use.

True. But there are situations where things get ~corrupted, and it becomes ~impossible to recover without basically nuking everything. But then, I was running containers with resource limits and long-term storage. So I could have thousands of lightweight "VMs" per physical server.
Post reply on HN