5 ms·

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 des

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.

duped 2y ago
> 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.
- 01HNNWZ0MV43FF 2y ago
  Go statically links C deps? Like gtk?
  - password4321 2y ago
    I think the point is Go doesn't have C deps by default like Rust does.
    - m0shen 2y ago
      I thought it depended on libc by default?
      - mirashii 2y ago
        You might find https://mt165.co.uk/blog/static-link-go/ 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.
    - jeroenhd 2y ago
      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.
maxbond 2y ago
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-perf.html https://gendignoux.com/blog/2019/11/09/profiling-rust-docker...
- saghm 2y ago
  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?
  - khafra 2y ago
    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.
    - CGamesPlay 2y ago
      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.
  - Ar-Curunir 2y ago
    The isolation the author wants is not for security, but just to get a reproducible benchmarking environment
vips7L 2y ago
Except if the destination machine is an entirely different architecture or doesn’t include the same instructions as the compilation machine…
- duped 2y ago
  Docker doesn't solve that problem
  - dymk 2y ago
    It does. Docker will by default run images built for different architectures in a virtual machine.
  - vips7L 2y ago
    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.
mcronce 2y ago
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.
- saghm 2y ago
  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.
  - cstrahan 2y ago
    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-specify-the-glibc-version-in-cargo-build-for-rust https://stackoverflow.com/questions/57749127/how-can-i-speci...
kristianp 2y ago
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.
deleted 2y ago
[deleted]
datadeft 2y ago
Because this is a production like workflow in many companies and for performance measurements running in docker can have significant impact.

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.

duped 2y ago

> 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.

01HNNWZ0MV43FF 2y ago
Go statically links C deps? Like gtk?
- password4321 2y ago
  I think the point is Go doesn't have C deps by default like Rust does.
  - m0shen 2y ago
    I thought it depended on libc by default?
    - mirashii 2y ago
      You might find https://mt165.co.uk/blog/static-link-go/ 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.
  - jeroenhd 2y ago
    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.

maxbond 2y ago

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-perf.html https://gendignoux.com/blog/2019/11/09/profiling-rust-docker...

saghm 2y ago
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?
- khafra 2y ago
  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.
  - CGamesPlay 2y ago
    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.
- Ar-Curunir 2y ago
  The isolation the author wants is not for security, but just to get a reproducible benchmarking environment

vips7L 2y ago

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

duped 2y ago
Docker doesn't solve that problem
- dymk 2y ago
  It does. Docker will by default run images built for different architectures in a virtual machine.
- vips7L 2y ago
  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.

mcronce 2y ago

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.

saghm 2y ago
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.
- cstrahan 2y ago
  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-specify-the-glibc-version-in-cargo-build-for-rust https://stackoverflow.com/questions/57749127/how-can-i-speci...

kristianp 2y ago

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.

deleted 2y ago

[deleted]

datadeft 2y ago

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