10 ms·

I just made a generic version of the title since I see it every so often: Torvalds: [hot take that almost no one else agrees with]

pengaru 5y ago
> Torvalds: [hot take that almost no one else agrees with] Considering the popularity of vendoring and/or static linking dependencies, I'm not sure where you're getting the "almost no one else agrees with" from. glibc's hostility towards static linking is arguably a substantial part of why musl has attracted so much interest. Static linking support is explicitly stated as one of musl's core tenets [0]. One can also argue the popularity of containers has in part been due to glibc's dynamic linking requirements, and containers have become the bloated "modern" version of static linked binaries, bundling all the dependencies without eliding all the dynamic linking overhead. Torvalds is definitely not alone in this particular opinion. [0] https://www.musl-libc.org/intro.html https://www.musl-libc.org/intro.html
- tediousdemise 5y ago
  Maybe I hyperbolized that a bit. I think there are pros and cons to each approach. The uses cases for static vs dynamic are also different. There are compile time disadvantages to static libraries, and there are security disadvantages to shared libraries. But calling one method better than the other is inane.
  - Arnt 5y ago
    Are you aware of the runtime differences? Both time and space. Shared libraries (at least with ELF) requires fixups, which involve COW and a considerable number of per-process pages. Compiling with -fPIC reserves one register, which isn't a problem unless you're on a register-starved CPU, which is all of them.
    - zozbot234 5y ago
      > Shared libraries (at least with ELF) requires fixups, which involve COW and a considerable number of per-process pages. You can avoid load-time fixups via prelinking.
    - floatboth 5y ago
      > register-starved CPU, which is all of them Really? None of the 64 bit ISAs seem particularly starved, especially not aarch64.
      - kelnos 5y ago
        I think the parent's point is that all registers are precious, and freeing up even one by avoiding dynamic might be worth doing.
      - Arnt 5y ago
        It's not particularly short of registers, but IIRC even aarch64 is short enough that they implemented register renaming. I agree that taking a register away is a much less pressing issue there than on the x86.
        CalChris 5y ago
        The purpose of register renaming in the AArch64 microarchitectures is to support out-of-order. By comparison, you don't find register renaming in the in-order A53. https://en.wikichip.org/wiki/arm_holdings/microarchitectures/cortex-a53 https://en.wikichip.org/wiki/arm_holdings/microarchitectures...
        Arnt 5y ago
        Suppose you had enough registers, ie. so many that there's no real reason to compilers to save. In that case, you could "support" out-of-order execution by adding a couple sentences to the compiler guidance documentation for your CPU, telling them that they'll get better performance on o-o-o cores if they wait as long as practical with reusing registers.
- AnthonyMouse 5y ago
  > Considering the popularity of vendoring and/or static linking dependencies, I'm not sure where you're getting the "almost no one else agrees with" from. Vendoring is hugely popular for projects in year zero, because it makes it easier to ship. Until they learn that packaging specific versions of all your dependencies with your project implies taking on responsibility for backporting all security updates to that version of every dependency when upstream is only actively maintaining the latest version. Or you have a project riddled with known published security vulnerabilities, which is what most of those turn into.
  - lanstin 5y ago
    You have two choices here. Keep updating as you go along and amortize the price for so much open source deps inability to avoid breaking change; or don’t do that and then eight years later lead a heroic update the deps project that takes ten people and millions of dollars and some availability hits. You keep the principal of change only one thing at a time the first way and get promotions the second way. Static vs dynamic is just do you want the code owners to be responsible or some centralized ops group to be responsible. Usually ops doesn’t have the insight to do a good job with deps, so it’s better to have dev do it, e.g. statically linked go binaries, statically linked C/c++, frozen package versions in Python, I think mvn has a similar capability, also version pinned base container images etc etc. hence the fact all the packaging systems add new versions and only rarely remove things as that breaks it all worse than a security hole. As a dev person with a lot of ops experience I like static because I don’t want some janky dependency change to come into the execution path when I am not aware of making a change. On the other hand, people usually just freeze everything and then don’t worry about it, which is wrong. But your security team needs to review source and source deps not just deployed versions. So if code is still owned, the bad deps can be found and fixed either way.
    - lanstin 5y ago
      I think a case for dynamic loading of your SSL library can be made.
  - hibbelig 5y ago
- attractivechaos 5y ago
  > glibc's hostility towards static linking is arguably a substantial part of why musl has attracted so much interest. Anothre reason is that glibc is equally bad for dynamic linking. Often a binary compiled on recent glibc doesn't work with older glibc. It is certainly possible but quite challenging to compile portable executables on Linux.
CrLf 5y ago
I don't think this is the case here. It's not hard to agree that shared libraries are meant to be _shared_ among different applications and when they're not (or not shared enough, which is a subjective measure) it's best to statically link.
incrudible 5y ago
Imagine a world where Linux binaries "just worked", every distribution's major selling point, the package manager, would be obsolete. These people are propagandizing the bogus security argument that static linking is bad practice. Take the red pill: statically linked executables are actually good practice.
- kiwijamo 5y ago
  Until the day comes when an application isn't updated with a patched library and people get hacked. This is the reason why I'm not so keen on statically linked applications. I'd rather my applications focus on their concerns and link to shared libraries for stuff like SSL and so on. This means the SSL people can focus on shipping secure SSL libraries and application people can focus on shipping applications built on secure shared libraries.
  - incrudible 5y ago
    This is an unlikely scenario. Most vulnerabilities are not in shared libraries. If you don't update your software, either it doesn't matter, or you eventually run into security issues. Optimizing for the unlikely scenario is not a worthy tradeoff. Focusing on shared libraries can indirectly lead to less security overall, because people run outdated software, because of dependency hell leading people to defer upgrades.
  - CalChris 5y ago
    That application wasn't updated, full stop.
- Cloudef 5y ago
  While i want static linking, i would still use package manager for convenience and because it provides some form of curation. (Packages in repos are usually not malicious)
  - incrudible 5y ago
    Sure, but again, if these packages were simple binaries that "just work", you wouldn't need your package manager to be strongly coupled to your distribution.
coldtea 5y ago
> Torvalds: [hot take that almost no one else agrees with] [but should and would if they knew better] Here, I fixed it for you!

pengaru 5y ago

> Torvalds: [hot take that almost no one else agrees with] Considering the popularity of vendoring and/or static linking dependencies, I'm not sure where you're getting the "almost no one else agrees with" from. glibc's hostility towards static linking is arguably a substantial part of why musl has attracted so much interest. Static linking support is explicitly stated as one of musl's core tenets [0]. One can also argue the popularity of containers has in part been due to glibc's dynamic linking requirements, and containers have become the bloated "modern" version of static linked binaries, bundling all the dependencies without eliding all the dynamic linking overhead. Torvalds is definitely not alone in this particular opinion. [0] https://www.musl-libc.org/intro.html https://www.musl-libc.org/intro.html

tediousdemise 5y ago
Maybe I hyperbolized that a bit. I think there are pros and cons to each approach. The uses cases for static vs dynamic are also different. There are compile time disadvantages to static libraries, and there are security disadvantages to shared libraries. But calling one method better than the other is inane.
- Arnt 5y ago
  Are you aware of the runtime differences? Both time and space. Shared libraries (at least with ELF) requires fixups, which involve COW and a considerable number of per-process pages. Compiling with -fPIC reserves one register, which isn't a problem unless you're on a register-starved CPU, which is all of them.
  - zozbot234 5y ago
    > Shared libraries (at least with ELF) requires fixups, which involve COW and a considerable number of per-process pages. You can avoid load-time fixups via prelinking.
  - floatboth 5y ago
    > register-starved CPU, which is all of them Really? None of the 64 bit ISAs seem particularly starved, especially not aarch64.
    - kelnos 5y ago
      I think the parent's point is that all registers are precious, and freeing up even one by avoiding dynamic might be worth doing.
    - Arnt 5y ago
      It's not particularly short of registers, but IIRC even aarch64 is short enough that they implemented register renaming. I agree that taking a register away is a much less pressing issue there than on the x86.
      - CalChris 5y ago
        The purpose of register renaming in the AArch64 microarchitectures is to support out-of-order. By comparison, you don't find register renaming in the in-order A53. https://en.wikichip.org/wiki/arm_holdings/microarchitectures/cortex-a53 https://en.wikichip.org/wiki/arm_holdings/microarchitectures...
        Arnt 5y ago
        Suppose you had enough registers, ie. so many that there's no real reason to compilers to save. In that case, you could "support" out-of-order execution by adding a couple sentences to the compiler guidance documentation for your CPU, telling them that they'll get better performance on o-o-o cores if they wait as long as practical with reusing registers.
AnthonyMouse 5y ago
> Considering the popularity of vendoring and/or static linking dependencies, I'm not sure where you're getting the "almost no one else agrees with" from. Vendoring is hugely popular for projects in year zero, because it makes it easier to ship. Until they learn that packaging specific versions of all your dependencies with your project implies taking on responsibility for backporting all security updates to that version of every dependency when upstream is only actively maintaining the latest version. Or you have a project riddled with known published security vulnerabilities, which is what most of those turn into.
- lanstin 5y ago
  You have two choices here. Keep updating as you go along and amortize the price for so much open source deps inability to avoid breaking change; or don’t do that and then eight years later lead a heroic update the deps project that takes ten people and millions of dollars and some availability hits. You keep the principal of change only one thing at a time the first way and get promotions the second way. Static vs dynamic is just do you want the code owners to be responsible or some centralized ops group to be responsible. Usually ops doesn’t have the insight to do a good job with deps, so it’s better to have dev do it, e.g. statically linked go binaries, statically linked C/c++, frozen package versions in Python, I think mvn has a similar capability, also version pinned base container images etc etc. hence the fact all the packaging systems add new versions and only rarely remove things as that breaks it all worse than a security hole. As a dev person with a lot of ops experience I like static because I don’t want some janky dependency change to come into the execution path when I am not aware of making a change. On the other hand, people usually just freeze everything and then don’t worry about it, which is wrong. But your security team needs to review source and source deps not just deployed versions. So if code is still owned, the bad deps can be found and fixed either way.
  - lanstin 5y ago
    I think a case for dynamic loading of your SSL library can be made.
- hibbelig 5y ago
attractivechaos 5y ago
> glibc's hostility towards static linking is arguably a substantial part of why musl has attracted so much interest. Anothre reason is that glibc is equally bad for dynamic linking. Often a binary compiled on recent glibc doesn't work with older glibc. It is certainly possible but quite challenging to compile portable executables on Linux.

CrLf 5y ago

I don't think this is the case here. It's not hard to agree that shared libraries are meant to be _shared_ among different applications and when they're not (or not shared enough, which is a subjective measure) it's best to statically link.

incrudible 5y ago

Imagine a world where Linux binaries "just worked", every distribution's major selling point, the package manager, would be obsolete. These people are propagandizing the bogus security argument that static linking is bad practice. Take the red pill: statically linked executables are actually good practice.

kiwijamo 5y ago
Until the day comes when an application isn't updated with a patched library and people get hacked. This is the reason why I'm not so keen on statically linked applications. I'd rather my applications focus on their concerns and link to shared libraries for stuff like SSL and so on. This means the SSL people can focus on shipping secure SSL libraries and application people can focus on shipping applications built on secure shared libraries.
- incrudible 5y ago
  This is an unlikely scenario. Most vulnerabilities are not in shared libraries. If you don't update your software, either it doesn't matter, or you eventually run into security issues. Optimizing for the unlikely scenario is not a worthy tradeoff. Focusing on shared libraries can indirectly lead to less security overall, because people run outdated software, because of dependency hell leading people to defer upgrades.
- CalChris 5y ago
  That application wasn't updated, full stop.
Cloudef 5y ago
While i want static linking, i would still use package manager for convenience and because it provides some form of curation. (Packages in repos are usually not malicious)
- incrudible 5y ago
  Sure, but again, if these packages were simple binaries that "just work", you wouldn't need your package manager to be strongly coupled to your distribution.

coldtea 5y ago

> Torvalds: [hot take that almost no one else agrees with] [but should and would if they knew better] Here, I fixed it for you!