Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Run More Stuff in Docker

jonathan.bergknoff.com

Post reply on HN
Print view View original

81–90 of 293 posts

Re: Run More Stuff in Docker

#81

Post by hansvm »

qmmmur wrote: post #23
physicsgraph wrote: post #5

A few years ago I set a goal to minimize the number of applications installed bare-metal on my laptop. Everything is containerized, just as the blog describes. There is some initial overhead, and some extra work associated with maintaining the infrastructure, but overall I can report improved reproducibility (due to an isolated and static environment per app). I use a bash alias for each common application. For examp…

That just seems insane to be running black inside a container. Why dont you just configure your environment properly?

That just seems insane to be running black on any old system python. Why don't you just wrap it in a proper dockerfile?

Re: Run More Stuff in Docker

#82

Post by twblalock »

harryruhr wrote: post #20

Docker for every application? If you create and maintain the Docker image or Dockerfile for every applucation yourself, you must have plenty of time. If you rely on public images from Docker Hub, you must have plenty of trust in the creators of those images.

You also have to have plenty of trust in the creators of the applications. Using Docker isn't really different, especially when the creators of the applications have also provided the Dockerfiles. What you had before Docker was just as much based on trust.

Re: Run More Stuff in Docker

#83

Post by tomcam »

johnsoft wrote: post #43

I appreciate the sentiment, but I wouldn't be able to put up with the slow container boot time for regular use. The author mentions this at the bottom. He claims 1sec delay. Last month I benchmarked it on new-ish hardware at 560ms, or 290ms if you disable namespaces (and so disable isolation). I wanted to also benchmark bocker[1] (docker written in bash) for a baseline comparison, but it no longer runs and I threw in…

> curl | jq | grep | less

OK I didn’t know about this. Does each one of the piped commands cause the creation of a new container? And why?

Re: Run More Stuff in Docker

#84

Post by viraptor »

antoinealb wrote: post #26
qmmmur wrote: post #23

Earlier quoted context omitted.

That just seems insane to be running black inside a container. Why dont you just configure your environment properly?

Serious question: Why do you believe that to be insane? The Dockerfile for a simple application such as black must be very short (probably 3-4 lines), the alias is probably quite short and the container overhead time is minimal for native docker (the story might be different for things like docker mac). On the other hand, you get some benefits from installing black through docker rather than through the system packag…

> you must reinstall it once for each project

You can install it either in a venv outside of all projects or even "pip install --user black".

> updating python to a new (major) version breaks your formatter

Uninstalling the old version breaks the formatter. Installing a new one does not. Either way, with asdf, pyenv, and others you can keep all relevant version around.

> you cannot move the env around

Sure you can. Use "--relocatable"

I agree docker may be nicer if you're not working day to day in python... but in that case black is not a great example. You probably want to have a specific version bound to the project so everyone uses it (including the ci platform).

Re: Run More Stuff in Docker

#85

Post by ridiculous_fish »

Docker is intimately tied to Linux. It it only "cross platform" in that it can use a VM (Mac, WSL2) or flaky compat layers (FreeBSD). If software embraces Docker, it effectively excludes other OSes, like Windows, BSDs, Haiku, Fuschia, etc.

Re: Run More Stuff in Docker

#86

Post by pknopf »

the_duke wrote: post #13

For end user devices, I much prefer Nix/NixOS [1] for this kind of thing. With Flakes [2] (experimental feature), you get full reproducibility. The documentation is spotty and there is a considerable learning curve, but I've switched to NixOS on my laptop and desktop early this year and am mostly very happy with it. That doesn't cover sandboxing though. I would actually agree that sandboxing / restricting application…

It's worth mentioning my pet project, Darch.

https://godarch.com/

Re: Run More Stuff in Docker

#87

Post by josephg »

peteretep wrote: post #61
cowsandmilk wrote: post #55

Earlier quoted context omitted.

OS X apps share frameworks in the user space, while docker images don’t...and docker images have all the constraints everyone hates about sandbox, but only make it worse. E.g. the file open dialog in macOS will grant apps access to the file when the user chooses the file. In docker, I have to manually add a path whenever I want tools to have access.

That doesn’t match my mental model of how that works. Can you give me an example of a shared 3rd party framework that a Mac app bundle will find on the file system rather than just include in the bundle?

Sharing dynamically linked 3rd party frameworks on macos is relatively rare. But all the system built-in frameworks are shared via dynamic linking in userspace. (Eg Cocoa, UIKit, Foundation, etc). Native macos apps feel native because they dynamically link to the system's standard set of UI libraries. (And more recently font sets like SF Symbols.)

For many reasons, none of that is available via docker.

The GP is also referencing the fact that even if you somehow had access to cocoa from your linux binary inside your docker VM, the docker image doesn't / shouldn't have access to your host (macos's) filesystem. So the save / load dialog wouldn't work properly anyway.

Re: Run More Stuff in Docker

#88

Post by peteretep »

josephg wrote: post #87
peteretep wrote: post #61

Earlier quoted context omitted.

That doesn’t match my mental model of how that works. Can you give me an example of a shared 3rd party framework that a Mac app bundle will find on the file system rather than just include in the bundle?

Sharing dynamically linked 3rd party frameworks on macos is relatively rare. But all the system built-in frameworks are shared via dynamic linking in userspace. (Eg Cocoa, UIKit, Foundation, etc). Native macos apps feel native because they dynamically link to the system's standard set of UI libraries. (And more recently font sets like SF Symbols.) For many reasons, none of that is available via docker. The GP is also…

> none of that is available via docker

I'd expect someone building many tools like the author of the original piece is using the same shared image as the base for most of them?

Re: Run More Stuff in Docker

#89

Post by zaptheimpaler »

I prefer to just make a big "devbox" docker with all the utilities I need installed, and the home directory as a docker volume.

The advantage is i don't have to fiddle with containers for every little program, no startup delay for every program, and my base ubuntu install stays clean and stable (which runs a VM and other services so stability is important).

It does have a few warts, the main one being you can't have the entire container root volume be a docker volume, so to install new programs persistently inside the devbox i have to rebuild the image (if they don't live completely in the home volume). But logically its an okay tradeoff because the only way to make the whole environment reproducible is to specify things at build time.

Re: Run More Stuff in Docker

#90

Post by josephg »

systemvoltage wrote: post #49
peteretep wrote: post #46

Earlier quoted context omitted.

> Imagine downloading every application as a docker container. WTF. Help me understand the WTF here, and also how that’s meaningfully different from an OS X app?

Jumping from 73 MB -----> 500 MB or whatever. Have you been running Docker on your system? Have you tried running: `docker system prune -a`? It's gonna print something like Total reclaimed space: 31.2GB .

Its worse than just the size jump. Every application would also need to run all its code inside a linux VM. So that means:

- Dedicated RAM for all your docker apps (which you have to partition manually)

- Slow startup time for the first docker app you run each time you reboot, as it boots the linux VM.

- All syscalls run through the VM's emulation layer, which is way slower than native

- No access to the system's native UI toolkits. (Docker apps can't dynamically link to cocoa for obvious reasons.) We can probably work around this by wasting a huge amount of developer time making a networked bridge or something silly but ??

- No easy way to load and save files (the VM doesn't have filesystem access)

- All the other downsides of docker - like it gobbling up all your disk space with images that are no longer used

- Lower battery life, because the host can't easily sleep the VM's scheduler. The CPU can't enter low power state when nothing's running.

Please don't do this. We already have a special kind of container for "self contained program on disk". Its called a statically linked executable. They work great. They're fast, small, have access to everything the host system provides. You can SHA them if you want and you can easily host them yourself using a static web server. My computer's responsiveness is more important to me than your shiny docker shaped toy.

Post reply on HN