4 ms·

You know how the page cache works? Static linking makes it not work. So 3000 processes won't share the same pages for the libc but will have to load it 3000 tim

by guappa 1y ago

You know how the page cache works? Static linking makes it not work. So 3000 processes won't share the same pages for the libc but will have to load it 3000 times.

mandarax8 1y ago
You can still statically link all your own code but dynamically link libc/other system dependencies.
- guappa 1y ago
  Not with rust…
  - tialaramex 1y ago
    I wonder what happens in the minds of people who just flatly contradict reality. Are they expecting others to go "OK, I guess you must be correct and the universe is wrong"? Are they just trying to devalue the entire concept of truth? [In case anybody is confused by your utterance, yes of course this works in Rust]
    - guappa 1y ago
      Can you run ldd on any binary you currently have on your machine that is written in rust? I eagerly await the results!
      - tux3 1y ago
        I mean, sure, but what's your point? Here's nu, a shell in Rust: $ ldd ~/.cargo/bin/nu linux-vdso.so.1 (0x00007f473ba46000) libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x00007f47398f2000) libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007f4739200000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f473b9cd000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4739110000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4738f1a000) /lib64/ld-linux-x86-64.so.2 (0x00007f473ba48000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f473b9ab000) libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f4738e50000) And here's the Debian variant of ash, a shell in C: $ ldd /bin/sh linux-vdso.so.1 (0x00007f88ae6b0000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f88ae44b000) /lib64/ld-linux-x86-64.so.2 (0x00007f88ae6b2000)
        guappa 1y ago
        Well seems I was wrong about linking C libraries from rust. The problem of increased RAM requirements and constant rebuilds are still very real, if only slightly less big because of dynamically linking C.
        bronson 1y ago
        That would have been a good post if you'd stopped at the first paragraph. Your second paragraph is either a meaningless observation on the difference between static and dynamic linking or also incorrect. Not sure what your intent was.
        guappa 1y ago
        Why do facts offend you?
      - deleted 1y ago
        [deleted]
      - whytevuhuni 1y ago
        I’m genuinely curious now, what made you so convinced that it would be completely statically linked?
        IshKebab 1y ago
        I think people often talk about Rust only supporting static linking so he probably inferred that it couldn't dynamically link with anything. Also Go does produce fully static binaries on Linux and so it's at least reasonable to incorrectly guess that Rust does the same. Definitely shouldn't be so confident though!
        CamouflagedKiwi 1y ago
        Go may or may not do that on Linux depending what you import. If you call things from `os/user` for example, you'll get a dynamically linked binary unless you build with `-tags osusergo`. A similar case exists for `net`.
        guappa 1y ago
        go by default links libc
        IshKebab 1y ago
        It doesn't. See the sibling comment.
IshKebab 1y ago
Kind of off-topic. But yeah it's a good idea for operating systems to guarantee the provision of very commonly used libraries (libc for example) so that they can be shared. Mac does this, and Windows pretty much does it too. There was an attempt to do this on Linux with the Linux Standard Base, but it never really worked and they gave up years ago. So on Linux if you want a truly portable application you can pretty much only rely on the system providing very old versions of glibc.
- guappa 1y ago
  The standard library is the whole distro :) It's hardly a fair comparison with old linux distros when osx certainly will not run anything old… remember they dropped rosetta, rosetta2, 32bit support, opengl… (list continues). And I don't think you can expect windows xp to run binaries for windows 11 either. So I don't understand why you think this is perfectly reasonable to expect on linux, when no other OS has ever supported it. Care to explain?

by guappa 1y ago

You know how the page cache works? Static linking makes it not work. So 3000 processes won't share the same pages for the libc but will have to load it 3000 times.

mandarax8 1y ago

You can still statically link all your own code but dynamically link libc/other system dependencies.

guappa 1y ago
Not with rust…
- tialaramex 1y ago
  I wonder what happens in the minds of people who just flatly contradict reality. Are they expecting others to go "OK, I guess you must be correct and the universe is wrong"? Are they just trying to devalue the entire concept of truth? [In case anybody is confused by your utterance, yes of course this works in Rust]
  - guappa 1y ago
    Can you run ldd on any binary you currently have on your machine that is written in rust? I eagerly await the results!
    - tux3 1y ago
      I mean, sure, but what's your point? Here's nu, a shell in Rust: $ ldd ~/.cargo/bin/nu linux-vdso.so.1 (0x00007f473ba46000) libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x00007f47398f2000) libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007f4739200000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f473b9cd000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4739110000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4738f1a000) /lib64/ld-linux-x86-64.so.2 (0x00007f473ba48000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f473b9ab000) libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f4738e50000) And here's the Debian variant of ash, a shell in C: $ ldd /bin/sh linux-vdso.so.1 (0x00007f88ae6b0000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f88ae44b000) /lib64/ld-linux-x86-64.so.2 (0x00007f88ae6b2000)
      - guappa 1y ago
        Well seems I was wrong about linking C libraries from rust. The problem of increased RAM requirements and constant rebuilds are still very real, if only slightly less big because of dynamically linking C.
        bronson 1y ago
        That would have been a good post if you'd stopped at the first paragraph. Your second paragraph is either a meaningless observation on the difference between static and dynamic linking or also incorrect. Not sure what your intent was.
        guappa 1y ago
        Why do facts offend you?
    - deleted 1y ago
      [deleted]
    - whytevuhuni 1y ago
      I’m genuinely curious now, what made you so convinced that it would be completely statically linked?
      - IshKebab 1y ago
        I think people often talk about Rust only supporting static linking so he probably inferred that it couldn't dynamically link with anything. Also Go does produce fully static binaries on Linux and so it's at least reasonable to incorrectly guess that Rust does the same. Definitely shouldn't be so confident though!
        CamouflagedKiwi 1y ago
        Go may or may not do that on Linux depending what you import. If you call things from `os/user` for example, you'll get a dynamically linked binary unless you build with `-tags osusergo`. A similar case exists for `net`.
        guappa 1y ago
        go by default links libc
        IshKebab 1y ago
        It doesn't. See the sibling comment.

IshKebab 1y ago

Kind of off-topic. But yeah it's a good idea for operating systems to guarantee the provision of very commonly used libraries (libc for example) so that they can be shared. Mac does this, and Windows pretty much does it too. There was an attempt to do this on Linux with the Linux Standard Base, but it never really worked and they gave up years ago. So on Linux if you want a truly portable application you can pretty much only rely on the system providing very old versions of glibc.

guappa 1y ago
The standard library is the whole distro :) It's hardly a fair comparison with old linux distros when osx certainly will not run anything old… remember they dropped rosetta, rosetta2, 32bit support, opengl… (list continues). And I don't think you can expect windows xp to run binaries for windows 11 either. So I don't understand why you think this is perfectly reasonable to expect on linux, when no other OS has ever supported it. Care to explain?