Hacker News Reader

Comment by ciupicri | Hacker News Reader

I don't understand why is he running it under Docker when one of the touted benefits of Rust is that all you need to do is just copy & run the binary on the destination machine.

View on HN

I don't think that's a commonly touted benefit of Rust.

You certainly can build a statically linked binary with musl libc (in many circumstances, at least), but it's not the default.

The default is a binary that statically links all the Rust crates you pull in, but dynamically links glibc, the vdso, and several other common dependencies. It's also, IIRC, the default to dynamically link many other common dependencies like openssl if you pull them in, although I think it's common for the crates that wrap them to offer static linking as an option.

Quite a lot of things can get by without needing any other dynamic libraries other than libc; there are some alternatives to using openssl in Rust that are fairly common. There definitely are places I've seen containers used for building/deploying Rust due to the need for dynamically-linked dependencies, but I've also seen it a bit in places where they already are using containers for everything else, and using the same thing for all of their services regardless of whether they're in Rust, Node, Python can can make the process around deployment simpler rather than having a separate way of doing things for each language.

You don’t need non-libc dependencies to run into issues when copying a binary from one host to another: glibc uses symbol versioning, so (unless you jump through some hoops) a binary built one a machine with a newer glibc will fail to run on a machine with an older glibc.

I ran into this last week — I wanted to install the neovim text editor from the official binary distribution, but because the project’s CI distro has a more recent glibc installed, the executable would fail to run on Ubuntu 18.04.

There are plenty of great details spelled out here, in case you aren’t familiar with this kind of thing: https://stackoverflow.com/questions/57749127/how-can-i-speci...

They explain in a different blog post.

> Now, you may wonder why profiling Rust code within Docker, an engine to run containerized applications. The main advantage of containers is that when configured properly, they provide isolation from the rest of your system, allowing to restrict access to resources (files, networking, memory, etc.).

https://gendignoux.com/blog/2019/11/09/profiling-rust-docker...

I've always heard that containers don't actually provide that much by way of security, although I imagine that maybe it could provide some value as one of many layers of a more in-depth defense. Is what I've heard correct here, or am I maybe missing some nuance?

I think there's a somewhat fine distinction to be made, here. An analogy is chroot. It's not a "security tool," and there are many ways to break out of a chroot jail, but it does provide some isolation, and that does provide a measure of security. If you run an application inside a container, and you have that container well-configured, it's going to be harder for someone with an RCE on that application to affect the rest of your system than if you weren't running that application in a container.

But a container does not provide a security boundary in the same sense as the security boundary between kernel mode and user mode.

Are you sure? I think it does provide a security boundary in a very analogous way to kernel/user mode. There are lots of ways to punch holes in that security boundary, but by default Docker provides, as far as I understood, a security boundary from the rest of the system and from other containers.

The isolation the author wants is not for security, but just to get a reproducible benchmarking environment

Ah, I see. This sounds more similar to how I've seen docker used with Rust in other places. It's interesting that it never occurred to me to think of the word "isolation" as referring to anything beyond security, but it definitely makes sense to me now that you point it out.

> one of the touted benefits of Rust is that all you need to do is just copy & run the binary on the destination machine

is it? I've heard that about Go, not so much Rust. cargo doesn't statically link system dependencies by default, only other rust dependencies.

Go statically links C deps? Like gtk?

I think the point is Go doesn't have C deps by default like Rust does.

As I've found out trying to load a golang-built .so in an Alpine Python environment, Go makes many assumptions about the system it's running on, and one of them seems to be "if linux, then glibc". Something to do with environment variables being at a magical offset somewhere that caused a null dereference.

Maybe it's been fixed since, but I wouldn't assume Go doesn't have any C dependencies.

I thought it depended on libc by default?

You might find https://mt165.co.uk/blog/static-link-go/ useful, but a quick tl;dr:

Go binaries are statically linked by default if they do not call out to any C functions.

Go will automatically switch to dynamic linking if you need to call out to C functions. There are some parts of the standard library that do this internally, and so many folks assume that go is dynamically linked by default.

He's running docker to make it easier to clean up and return to a clean slate. Profiling in itself doesn't require docker, I think it needlessly adds to the complexity of the task of profiling, unless its providing clear benefits.

Because this is a production like workflow in many companies and for performance measurements running in docker can have significant impact.

Except if the destination machine is an entirely different architecture or doesn’t include the same instructions as the compilation machine…

Docker doesn't solve that problem

It does. Docker will by default run images built for different architectures in a virtual machine.

I didn’t claim it did. I probably could have been clearer but there is no way that a touted benefit of rust is to be able to just drop a binary on a different machine.

Reply on news.ycombinator.com