Hacker News Reader

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

This, and the other VM-related criticism, is true, but only on Mac & Windows. Running a Docker container on a native Linux system carries very little overhead.

But the 73m -> 500m is still true, right?

Depends entirely on how the image is built. You can have a Docker image that contains nothing but the application binaries, but then the question is why use Docker at all.

Isolation and reproducibility

Not the most useful for software intended to be used on your local machine. You don’t get the isolation benefits because the whole point is to give the container broad privilege so you can use it as if it was a native utility. Docker also doesn’t make a non-reproducible build process reproducible.

At the end of the day if you have a precompiled self-contained artifact Docker is just a convoluted way of calling exec.

At the end of the day, all the docker images depend on a lot of ./configure && make install, if not a lot of apt-get installs, which are often not reproducible. You don't get reproducibility unless you've done it all the way down the chain.

For all the other reasons the author notes: the main one being that the application running in the docker image has no access to the host system other than what the user explicitly gives it. It's a very minimal sandbox and often all the application needs.

You can't really reproduce that with any popular desktop operating system. Even if you could the interesting thing about docker is that starts with a default deny environment built on the principle of least privilege.

I'm not an expert in this area, but I've seen plenty of accounts of how Docker can be very insecure. Perhaps it's possible to configure Docker so that it is very secure, but even Google has had people break out of their containers, so these claims about container security should probably come with a disclaimer: "Docker is very secure as long as you are one of the top 0.1% in the field and never mess up". VMs seem to still be the proper tool for securely isolating processes, and should perhaps be the recommendation for the other 99.9%.

A few comments on how insecure the typical Docker recommendations are:

> Sandboxed - security claims about Docker have always been controversial. Simple Unix/BSD constructs like chroot/jails are far simpler and they are reliable

https://news.ycombinator.com/item?id=25547629

> However, I don’t agree with using it for sandboxing for security. Especially if you are giving it access to the X11 socket, as the author does in the examples. It might not be obvious, but the app will have access to all your other open windows.

https://news.ycombinator.com/item?id=25547551

> Fun fact, most docker hosts will allow access to all your files anyway! (specially true on docker for mac, which all the cool kids(tm) here are using). Even if you restrict container host-FS access to a source repo dir, mind rogue code changing your .git hook scripts in there or you might run code outside of the container when committing ;) > Another slightly relevant fun fact, USB is a bus. That means that any device can listen in on any other device. And USB access is given by default to some X-enabled docker (--tty something), and to most virtualbox machines (including the hidden one running the fake docker linux host on docker-for-mac), and more recently Google-Chrome. ;)

https://news.ycombinator.com/item?id=25547833

I think the experts in docker would note that sandboxing and privilege isolation are technical features which have many uses, but that is not at all the same as making broad-based claims about the security of docker or the virtual machine and host operating system technology upon which it runs.

It's obvious that any system with faulty sandboxing or privilege isolation is quite likely to be insecure. If the default "sandboxing" of Docker allows access to nearly everything of importance on the host, then we can indeed make "broad-based claims" about the insecurity of the system as a whole.

Podman and LXD have far more secure defaults. It's a terrifying to see that Docker is still around. jail(8) from FreeBSD seems to be the best (from security standpoint), it's also the first container system.

> You can't really reproduce that with any popular desktop operating system.

If you’re running Docker, you’re running Linux, and you can use the same kernel features as Docker to sandbox applications yourself. This way, you only incur the overhead of a separate network namespace and filesystem if you actually need it. Services can be sandboxed with a few lines of configuration in a drop-in unit, and applications can be run with a shell script that calls `systemd-run`, just like the `docker run` shell scripts suggested in the article.

Do you know of a tool that can do this for arbitrary programs? Maybe something like CARE [0] to find what the program should be accessing, then building the appropriate systemd configuration files?

[0]: https://proot-me.github.io/care/

> If you’re running Docker, you’re running Linux

As slow as it is some people apparently enjoy running docker from win / mac

Docker needs Linux to work. On Mac/Windows containers run in a Linux virtual machine.

I thought so too, but apparently support for native Windows containers has existed for a while now. e.g. https://poweruser.blog/lightweight-windows-containers-using-...

Neat! I had no idea this was a thing, thanks for sharing.

I wouldn't call "running an app in a linux VM on windows", "running linux". As a user, your main interface with your computer is windows, which is what "i'm running windows" means, and obviously "you can use the same kernel features as Docker to sandbox applications yourself" wouldn't work, e.g. you couldn't sandbox photoshop like that.

Yep. My comment was mostly made in the context of running macos desktop apps in docker. Windows would be largely the same, though the existence of WSL might make some things easier.

Linux desktop apps running in docker would work better because there's no VM in between the native environment and the application. You'd still need to forward GUI calls across the LXD container boundary. That used to be easy with X11 forwarding, but AFAIK wayland removed that feature. I don't know enough to guess how difficult that would be to implement.

But, if you solved that it should be mostly smooth sailing. Linux desktop apps distributed via docker would just be the same apps, but unnecessarily bigger, with probably less access to the filesystem. They would be harder to patch for security errata. And they would leave extra junk in your docker images cache. Docker's sandboxing would be nice though.

WSL2 mostly solves the problem of manual memory partitioning.

I am so glad I can read something like this in public.

When I say stuff like this in job interviews, I get eye rolls and don't end up getting a job.

The industry is so far up its ass lately, no one even dare stating the facts in public. /rant

Now talk about deploying something NOT using Kubernetes. The double whammy. Now you're looking like an insane 100 year old graybeard fossil.

Or overuse of microservices

^ this. Proliferation of many microservices and repos is a trend I’m trying (and failing) to buck at my current job.

The next time I have to copy/paste the same utility to a new microservice because [insert corporate reason] I’m going to scream.

I had a conversation a couple months ago where some guy was telling me that I should run my personal website using Kubernetes. It’s a static website served with Nginx! I just about lost my mind trying to talk to this guy, and he kept trying to convince me to try Kubernetes for my personal website.

Why even run nginx? My personal website is served out of a private S3 bucket, with CloudFront sitting in front of it.

As a former sysadmin, the less actual admin I need to do the better.

You could have other, self-hosted services there. That's my setup: I have self hosted trilium and used to self host matrix. The personal nginx served website was just a cherry on top of the cake.

> I have self hosted trilium and used to self host matrix.

Wait, you’re self hosting multiple apps on one system, and not using K8?!? Your apps can’t autoscale or do blue/green upgrades or any of the cool stuff you are now mandated to do by the cargo cult. How do you sleep at night??

/s

>or any of the cool stuff you are now mandated to do by the cargo cult.

This is ultimately what drives me insane about the tech sector: so many choices are trend based and cult like when any sort of technical discipline shouldn't be.

S3 has no https and unsatisfactory performance.

My website used to be in an S3 bucket, I was unhappy with it.

If you run it behind CloudFront it does support HTTPS.

Anything “supports HTTPS” if you count putting an HTTPS proxy in front of it. In other words, S3 does not support HTTPS, but you can work around that limitation by combining it with other services.

My personal website is low-traffic, it’s not going to be very hot in any CDN caches. Based on my experiences with S3 performance, adding another layer of cache misses in front of it is probably just going to slow things down.

Fair enough.

The suggestion was more for the HTTPS part and not the performance part of your complaint. It's simple enough to set up, pay-as-you-go, only requires one vendor, and should be very scalable.

I'd just as soon throw up nginx on a Linode, myself.

Fossil here, happily using VMs.

I guess that makes me fossilizing, because this is the direction I think we should really be heading.

When I stare at docker long enough I wind up at "why couldn't this be a static binary" or "this would be easier to secure if it was it's own VM".

Many people are basically misusing Docker to work around Python and Ruby dependency problems.

^ this is a very good point. Someone else's mess, let me put it all together, in a nice pot plant.

9/10 times I see the problems getting solved in the same way you can do without docker, except now the application is also running as root and several more containers are added to work around other issues created by running in docker :(

A Docker container is a lot simpler to maintain than a VM, for just about any task you care to mention.

A static binary is much better than a Docker container, I agree. Unfortunately a lot of useful apps can't or won't ship as a static binary (Java, Python, PHP apps), and Docker makes them behave much more like a static binary.

Java can certainly be shipped as single static binary, AOT compilers exist since around 2000.

Same applies to Python bundlers like py2exe.

At this rate we should make a fossil of deployments moto, where we claim there is nothing wrong with makefiles and bash scripts :)

like http://programming-motherfucker.com but against triple-buffered-virtualization.

Just want to call out: this is on Windows and macOS. So, these remarks are certainly true for probably a majority of Hacker News readers, but if you were on Linux these limitations do not exist. I'm also not sure how much these limitations hinder you in reality, I hear few complaints from the macOS users around me, and we use Docker a lot.

> Its called a statically linked executable. They work great.

Doesn't this make OpenGL, Vulkan, and parts of glibc break?

Yes. In the case of glibc, it's long past time that flaw was corrected by moving NSS modules out of process and using a pipe or socket to run queries. IIRC OpenBSD already does this. They already cause problems with pulling in their transitive dependencies into your process' address space and potentially causing nasty conflicts. Same goes for PAM modules.

That's absolutely terrifying. Thanks for the insight.