5 ms·

This is a bunch of nonsense. Rust prefers static linking because it is predictable. These supposedly "huge" binaries are laughably small on a modern >1TB hard d

by jpm_sd 6y ago

This is a bunch of nonsense. Rust prefers static linking because it is predictable. These supposedly "huge" binaries are laughably small on a modern >1TB hard drive. If you're building a tiny embedded system, by all means optimize your builds system-wide, you have total control! But for a desktop, is this really a concern?

Jasper_ 6y ago
I seem to keep running out of space on my relatively small SSD where my OS is installed, so, yeah, it totally is a concern.
- qppo 6y ago
  Buy a bigger ssd if you can, they're cheap. The last drive I bought was a 1TB Intel SSD for like $90. But the pain point is on laptops like MacBooks which have comically small storage space for their price point. I think the base models have a measly 256GB SSD and charge crazy amounts for upgrades.
- AnIdiotOnTheNet 6y ago
  If applications were portable, then just put them on a different disk. This isn't rocket science, we've been doing it since the 80s. Problem is that portable applications are an alien concept to Linux.
  - heavyset_go 6y ago
    > Problem is that portable applications are an alien concept to Linux. Static builds, AppImage, FlatPak, containers, etc would like to have a word with you.
dTal 6y ago
Yes, it's a concern. Firstly, hard drive space isn't the only reason to make binaries small - you have RAM pressure, cache pressure, and bandwidth to save. Secondly and more importantly, waste adds up. If you replaced every binary on the system with a Rust equivalent - which, to listen to some advocates, is the eventual goal - you could end up with a base system that's many times larger. In a larger sense, something that sets out to be a "systems programming language" needs to be exactly the sort of thing suitable for a tiny embedded system, even if it isn't running on one, because everything else builds on top of it. The attitude that "we have tons of power, why not waste it" just doesn't fly at the very lowest levels. You can write a desktop application in Python, and it's broadly fine - but try writing an OS kernel!
- zaarn 6y ago
  There are patches that let Rust run on ESP32 systems, so think it's entirely suitable for tiny embedded things. What makes it bloaty is the linked in standard library, but it's not an unsolvable crisis; you can dynlink against glibc, there is a crate for core rust IIRC. That'll get you reasonably sized rust applications. And for writing kernels the same applies; without the stdlib, it gets a lot smaller very fast. I've done it, so I think I can count myself on having some experience there. The biggest part of my kernel is a 128KB scratch space variable it uses during boot as temporary memory until it has read the memory mappings from the firmware and bootstrapped memory management on a basic level. The remainder of the kernel (minus initramfs) is then about 1MB large, the largest part after the 128KB scratch space using about 96KB.
  - nwallin 6y ago
    Regarding embedded, you generally only have one program. So dynamic linking buys you precisely nothing in that space.
    - zaarn 6y ago
      Depends on if embedded refers to microcontrollers or just single board computers in various devices, but it wouldn't buy you much either way, yes.
- nemothekid 6y ago
  >Firstly, hard drive space isn't the only reason to make binaries small - you have RAM pressure, cache pressure, and bandwidth to save. FWIW, this is does not seem to be empirically true. The savings are possible in theory, but false in practice. https://drewdevault.com/dynlib.html https://drewdevault.com/dynlib.html The most used largest libraries, like libc and libpthread, would be dynamically linked by Rust anyways.
- avasthe 6y ago
  "But all silicon valley hipster webshits I know have latest macbook pro, bloat is not a problem"
cyphar 6y ago
If you add 9MB to each binary on the system by statically linking them, and your system runs 200 programs (including system services) on average, your system now uses about 2GB more memory (to be fair, probably not all the time but it does increase memory pressure needlessly). Shared libraries aren't just about storage space. They also provide page cache sharing (memory for a shared library is only mapped once and the mapping is shared by different programs). A slight aside but they also provide the ability to apply security updates sanely to all programs using that library on the system (just update the library and restart the programs, as opposed to having to install a rebuilt version of every program that uses the library). Is this a game-changing feature? These days probably not, but it is (again) just needless waste. And I say this as someone who is currently developing a shared library in Rust that will probably be included in a lot of distributions because I expect quite a fair amount of container runtimes will end up using it. (But I do also work for a Linux distribution.)
- SigmundA 6y ago
  I used to think that way, but have come to the conclusion disk and memory issues should be handled by page / block level deduplication. Security updates are a plus, but introducing bugs through a shared library is a minus. I would prefer we focus on robust application sandboxing instead. At the server datacenter level its pretty much how its handled anyway, you have isolated vm / containers sitting on deduped storage.
  - Hizonner 6y ago
    Sandboxing doesn't actually solve the biggest security problems, because most systems are there to run applications. That means that the interesting things on those systems are inside of some application's sandbox. It doesn't matter if I can't get root if I can get all the actually important assets on the system by cracking the application that actually processes those data. ... and in my experience, most application developers, and especially the developers who are the most truculently hostile to working with the system versions of libraries and the most likely to demand to bundle in their own copies for "stability" purposes, are really horrible about paying attention to security issues in their third-party dependencies. When I'm being a user and a sysadmin rather than a developer or a packager, and I have the choice of trusting a developer versus trusting a packager, then, all else being equal, I will tend to trust the packager. Not that I trust either one that much.

by jpm_sd 6y ago

Jasper_ 6y ago

I seem to keep running out of space on my relatively small SSD where my OS is installed, so, yeah, it totally is a concern.

qppo 6y ago
Buy a bigger ssd if you can, they're cheap. The last drive I bought was a 1TB Intel SSD for like $90. But the pain point is on laptops like MacBooks which have comically small storage space for their price point. I think the base models have a measly 256GB SSD and charge crazy amounts for upgrades.
AnIdiotOnTheNet 6y ago
If applications were portable, then just put them on a different disk. This isn't rocket science, we've been doing it since the 80s. Problem is that portable applications are an alien concept to Linux.
- heavyset_go 6y ago
  > Problem is that portable applications are an alien concept to Linux. Static builds, AppImage, FlatPak, containers, etc would like to have a word with you.

dTal 6y ago

Yes, it's a concern. Firstly, hard drive space isn't the only reason to make binaries small - you have RAM pressure, cache pressure, and bandwidth to save. Secondly and more importantly, waste adds up. If you replaced every binary on the system with a Rust equivalent - which, to listen to some advocates, is the eventual goal - you could end up with a base system that's many times larger. In a larger sense, something that sets out to be a "systems programming language" needs to be exactly the sort of thing suitable for a tiny embedded system, even if it isn't running on one, because everything else builds on top of it. The attitude that "we have tons of power, why not waste it" just doesn't fly at the very lowest levels. You can write a desktop application in Python, and it's broadly fine - but try writing an OS kernel!

zaarn 6y ago
There are patches that let Rust run on ESP32 systems, so think it's entirely suitable for tiny embedded things. What makes it bloaty is the linked in standard library, but it's not an unsolvable crisis; you can dynlink against glibc, there is a crate for core rust IIRC. That'll get you reasonably sized rust applications. And for writing kernels the same applies; without the stdlib, it gets a lot smaller very fast. I've done it, so I think I can count myself on having some experience there. The biggest part of my kernel is a 128KB scratch space variable it uses during boot as temporary memory until it has read the memory mappings from the firmware and bootstrapped memory management on a basic level. The remainder of the kernel (minus initramfs) is then about 1MB large, the largest part after the 128KB scratch space using about 96KB.
- nwallin 6y ago
  Regarding embedded, you generally only have one program. So dynamic linking buys you precisely nothing in that space.
  - zaarn 6y ago
    Depends on if embedded refers to microcontrollers or just single board computers in various devices, but it wouldn't buy you much either way, yes.
nemothekid 6y ago
>Firstly, hard drive space isn't the only reason to make binaries small - you have RAM pressure, cache pressure, and bandwidth to save. FWIW, this is does not seem to be empirically true. The savings are possible in theory, but false in practice. https://drewdevault.com/dynlib.html https://drewdevault.com/dynlib.html The most used largest libraries, like libc and libpthread, would be dynamically linked by Rust anyways.
avasthe 6y ago
"But all silicon valley hipster webshits I know have latest macbook pro, bloat is not a problem"

cyphar 6y ago

If you add 9MB to each binary on the system by statically linking them, and your system runs 200 programs (including system services) on average, your system now uses about 2GB more memory (to be fair, probably not all the time but it does increase memory pressure needlessly). Shared libraries aren't just about storage space. They also provide page cache sharing (memory for a shared library is only mapped once and the mapping is shared by different programs). A slight aside but they also provide the ability to apply security updates sanely to all programs using that library on the system (just update the library and restart the programs, as opposed to having to install a rebuilt version of every program that uses the library). Is this a game-changing feature? These days probably not, but it is (again) just needless waste. And I say this as someone who is currently developing a shared library in Rust that will probably be included in a lot of distributions because I expect quite a fair amount of container runtimes will end up using it. (But I do also work for a Linux distribution.)

SigmundA 6y ago
I used to think that way, but have come to the conclusion disk and memory issues should be handled by page / block level deduplication. Security updates are a plus, but introducing bugs through a shared library is a minus. I would prefer we focus on robust application sandboxing instead. At the server datacenter level its pretty much how its handled anyway, you have isolated vm / containers sitting on deduped storage.
- Hizonner 6y ago
  Sandboxing doesn't actually solve the biggest security problems, because most systems are there to run applications. That means that the interesting things on those systems are inside of some application's sandbox. It doesn't matter if I can't get root if I can get all the actually important assets on the system by cracking the application that actually processes those data. ... and in my experience, most application developers, and especially the developers who are the most truculently hostile to working with the system versions of libraries and the most likely to demand to bundle in their own copies for "stability" purposes, are really horrible about paying attention to security issues in their third-party dependencies. When I'm being a user and a sysadmin rather than a developer or a packager, and I have the choice of trusting a developer versus trusting a packager, then, all else being equal, I will tend to trust the packager. Not that I trust either one that much.