11 ms·

Really incredible work and it's been very fun to follow along. The streams where Andrew did the last part of this work can be seen here: [1], [2]. I am really

by Shoop 7y ago

Really incredible work and it's been very fun to follow along. The streams where Andrew did the last part of this work can be seen here: [1], [2]. I am really happy that someone is making the effort to steadily simplify systems programming rather than make it more complicated. Linux goes to such incredible lengths to be bug-for-bug backwards compatible, but then the complexities of all of our layers of libcs, shared libraries, libsystemd, dbus, etc cause unnecessary pain and breakage at every level. Furthermore, cross-compiling C code across different architectures on Linux is far harder than it needs to be. I have a feeling that there wouldn't be as much interest in the steady stream of sandboxes and virtual machines (JVM, NaCl, PNaCl, flatpak, docker, WebAssembly) if we could just simplify the layers and layers of cruft and abstractions in compiler toolchains, libc implementations, and shared libraries. Practically every laptop and server processor use the exact same amd64 architecture, but we have squandered this opportunity by adding leaky abstractions at so many levels. I can't wait until installing a program on linux is as simple as downloading a static executable and just running it and I hope zig brings this future. [1] https://www.youtube.com/watch?v=2u2lEJv7Ukw https://www.youtube.com/watch?v=2u2lEJv7Ukw [2] https://www.youtube.com/watch?v=5S2YArCx6vU https://www.youtube.com/watch?v=5S2YArCx6vU

Wowfunhappy 7y ago
Linux and GCC today have the ability to compile and run fully static executables, I don't understand why this isn't done...
- dataflow 7y ago
  > I don't understand why this isn't done Because when there's a security update to (say) OpenSSL, it's better for the maintainers of just that library to push an update, as opposed to forcing every single dependent to rebuild & push a new release.
  - otterley 7y ago
    I would have agreed with this statement about five years ago. (Even though you would have had to restart all the dependent binaries after updating the shared libs.) Today, with containers becoming increasingly the de facto means of deploying software, it's not so important anymore. The upgrade process is now: (1) build an updated image; (2) upgrade your deployment manifest; (3) upload your manifest to your control plane. The control plane manages the rest. The other reason to use shared libs is for memory conservation, but except on the smallest devices, I'm not sure the average person cares about conserving a few MB of memory on 4GB+ machines anymore.
    - MereInterest 7y ago
      Some of us use linux as a desktop environment, and like having the security patches be applied as soon as the relevant package has updated.
      - AnIdiotOnTheNet 7y ago
        As a user of the Linux desktop, I really love it when library updates break compatibility with the software I use too. Or can't be installed because of dependency conflicts. Containers are popular because shared libraries cause more trouble than they are worth.
    - rumanator 7y ago
      > Today, with containers becoming increasingly the de facto means This assertion makes no sense at all and entirely misses the whole point of shared/dynamic libraries. It's like a buzzword is a magic spell that makes some people forget the entire history and design requirements up to that very moment.
      - ithkuil 7y ago
        Sometimes buzzwords make sense, in the right context. This was the right context. Assuming you use containers, you're likely to not log into them and keep them up to date and secure by running apt-get upgrade. The most common workflow is indeed: build your software in your CI system, in the last step create a container with your software and its dependencies. Then update your deployment with a new version of the whole image. A container image is for all intents and purposes the new "static binary". Yes, technically you can look inside it, yes technically you can (and you do) use dynamic linking inside the container itself. But as long as the workflow is the one depicted above, the environment no longer has the requirements that led to the design of dynamic linking. It's possible to have alternative workflows for building containers: you could fiddle with layers and swap an updated base OS under a layer containing your compiled application. I don't how common is that, but I'm sure somebody will want/have to do it. It all boils down to whether developers still maintain control over the full deployment pipeline as containers penetrate the enterprises (i.e. whether re retain the "shift to the left", another buzzword for you). Containers are not just a technical solution, they are the embodiment of the desire of developers to free themselves from the tyranny of filing tickets and waiting days to deploy their apps. But that leaves the security departments in enterprises understandably worried as most of those developers are focused on shipping features and often neglecting (or ignoring) security concerns around things that live one layer below the application they write.
  - StreamBright 7y ago
    Based on my experience this is very rarely the case unless you have an extremely disciplined SecOps team.
    - rumanator 7y ago
      > Based on my experience this is very rarely the case You must have close to zero experience them because that's the norm on any software that depends on, say, third-party libraries that ship with a OS/distro. Recommended reading: Debian's openssl package. https://tracker.debian.org/pkg/openssl https://tracker.debian.org/pkg/openssl
      - StreamBright 7y ago
        You are talking about a FOSS project, I am talking about a company that has a service that uses OpenSSL in production.
        boomlinde 7y ago
        These are not diametrically opposed. Your company can have a service that uses OpenSSL in production that runs on Debian to automatically take advantage of Debian patches and updates if it's linked dynamically to the system provided OpenSSL. You can either employ an extremely disciplined SecOps team to carefully track updates and CVEs (you'd need this whether you're linking statically or dynamically) or you can use e.g. Debian to take advantage of their work to that end.
        StreamBright 7y ago
        Every single company that I used to work for had an internal version of Linux that they approved for production. Internal release cycles are disconnected from external release cycles. On the top of that, some of these companies were not using system-wide packages at all, you had to reference a version of packages (like OpenSSL) during your build process. We had to do emergency patching for CVEs and bump the versions in every service. This way you can have 100% confidence what a particular service is running with a particular version of OpenSSL. This process do not depend on Debian's (or other FOSS vendor's) release cycles and the dependencies are explicit, therefore the vulnerability assessment is simpler (as opposed to go to every server and check which version is installed). Don't you think?
  - yellowapple 7y ago
    My main issue with this rationale is that, in the vast majority of production environments (at least the ones I've seen in the wild, and indeed the ones I've built), updating dependencies for dynamically-linked dependents is part of the "release" process just like doing so for a statically-linked dependent, so this ends up being a distinction without a difference; in either circumstance, there's a "rebuild" as the development and/or operations teams test and deploy the new application and runtime environment. This is only slightly more relevant for pure system administration scenarios where the machine is exclusively running software prebuilt by some third-party vendor (e.g. your average Linux distro package repo). Even then, unless you're doing blind automatic upgrades (which some shops do, but it carries its own set of risks), you're still hopefully at least testing new versions and employing some sort of well-defined deployment workflow. Also, if that "security update" introduces a breaking change (which Shouldn't Happen™, but something something Murphy's Law something something), then - again - retesting and rebuilding a runtime environment for a dynamically-linked dependent v. rebuilding a statically-linked dependent is a distinction without a difference.
- yjftsjthsd-h 7y ago
  I know the ability exists, but I'm pretty sure that it's not exactly easy to get it working. Last time I tried, it immediately failed because my distribution wasn't shipping .a files (IIRC) for my installed libraries. There's a lot of little things that don't quite work because nobody's using them so they're harder to use so nobody uses them...
  - alexeldeib 7y ago
    Yep, exactly this. And quirks of glibc and friends make fully static compilation likely to produce odd failures, unfortunately.
    - saagarjha 7y ago
      Glibc does not really support static linking.
      - alexeldeib 7y ago
        Kind of my point — so much software depends on it, it’s difficult to statically link more things.
        needs 7y ago
        Musl is a pretty good replacement, I have been using it for years without any troubles.
        alexeldeib 7y ago
        I like Musl, but it is a source of pain at times too: https://github.com/kubernetes/kubernetes/issues/64924 https://github.com/kubernetes/kubernetes/issues/64924 https://github.com/kubernetes/kubernetes/issues/33554 https://github.com/kubernetes/kubernetes/issues/33554 Admittedly you could put that on the Kubernetes folks, but the same problem doesn't exist with glibc.
  - Hello71 7y ago
- PaulDavisThe1st 7y ago
  In addition to the other excellent reasons mentioned here, there's also the fact that some libraries deliberately choose to use runtime dynamic linkage (dlopen) to load optional/runtime-dependent functionality.
  - gmueckl 7y ago
    If you want make a program that supports plugins, you have only two real options: non-native runtimes or dynamic linking. And the later gets you into a lot of trouble quickly. The former trades performance and memory usage for ease of use and a zoo of dependencies.
  - rumanator 7y ago
    > some libraries deliberately choose to use runtime dynamic linkage (dlopen) to load optional/runtime-dependent functionality. Also known as plugins. It's not a design flaw, it's a feature.
- dman 7y ago
  You cant statically compile in glibc right?
  - spatulon 7y ago
    sure you can: $ cat hello.c #include <stdio.h> int main() { printf("hello world!\n"); } $ gcc -o hello hello.c $ ldd hello linux-vdso.so.1 (0x00007ffff9da0000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fed449d0000) /lib64/ld-linux-x86-64.so.2 (0x00007fed45000000) $ gcc -o hello hello.c -static $ ldd hello not a dynamic executable
    - luizfelberti 7y ago
      I don't think the parent comment's point was if this was technically possible. glibc is GPL licensed, and the GPL explicitly forbids statically linking to it unless your code is GPL too. Thus any non-GPL project has it's license tainted by the GPL if you statically link it. It's not a technical limitation, it's a legal one.
      - cesarb 7y ago
        This is false. The license for glibc is the LGPL, not the GPL, and the LGPL has an exception to allow static linking without the whole code having to be under the LGPL, as long as the .o files are also distributed to allow linking with a modified glibc ("As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice [...] and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library.")
        luizfelberti 7y ago
        Sounds like I got conned by my (poor) memory. I should have re-googled this before posting, thanks for the correction.
- jcelerier 7y ago
  N°1 most harmful post on the internet : https://akkadia.org/drepper/no_static_linking.html https://akkadia.org/drepper/no_static_linking.html I am convinced that Drepper's insistence on dynamic linking has set the linux desktop useability and developer friendliness back literal decades.
  - umvi 7y ago
    I work on an embedded linux system that has 256 MB of RAM. That can get eaten up really fast if every process has its own copy of everything.
    - freemint 7y ago
      You should look into fdpic as format to store your binaries in. It think i might lessen your concerns.
    - __d 7y ago
      Note that when using static linking, you don't get a copy of everything, just everything you actually use. It doesn't alter the fundamental point: shared libraries save both persistent storage and runtime memory.
      - saagarjha 7y ago
        > Note that when using static linking, you don't get a copy of everything, just everything you actually use. Which is a significant fraction of everything even if you call simple like printf. > It doesn't alter the fundamental point: shared libraries save both persistent storage and runtime memory. I fail to see the argument for this. Dynamic linking deduplicates dependencies and allows code to be mapped into multiple processes "for free".
        admax88q 7y ago
        Have you measured it? How much is dynamic linking saving you? How many processes are you running on embedded systems with of 256MB or RAM?
- pjmlp 7y ago
  Ironically that is how they have been implemented since the dawn of time. Dynamic linking was added around Slackware 2.0 timeframe.
- prussian 7y ago
  One I think people forget about is ASLR. What symbols are you going to shuffle? At least with dynamic linked dependencies the linker can just shove different shared objects into different regions without much hassle. Other have mentioned the other points: runtime loading (plugins), CoW deduplication and thus less memory and storage.
AnIdiotOnTheNet 7y ago
> I can't wait until installing a program on linux is as simple as downloading a static executable and just running it and I hope zig brings this future. For the record: This is pretty close to what AppImage is today. It's not quite 100% because userland fragmentation is so ridiculously bad that it doesn't work out of the box on a few of them, but I personally really wish all Linux software was distributed that way (or static like Zig).
- solarkraft 7y ago
  And it pretty much proves that it's not such a great thing to aspire. Images are large, dependencies aren't updatable, locations don't match with distribution defaults.
  - AnIdiotOnTheNet 7y ago
    On the other hand: no conflicts, no missing dependencies, can have multiple versions of the same thing installed at the same time, can store them anywhere including removable media...
    - tzjmetron 7y ago
      Yup. I have had some terrible experiences with dependencies. Bundling all the dependencies together makes sense in a lot of scenarios.

by Shoop 7y ago

Wowfunhappy 7y ago

Linux and GCC today have the ability to compile and run fully static executables, I don't understand why this isn't done...

dataflow 7y ago
> I don't understand why this isn't done Because when there's a security update to (say) OpenSSL, it's better for the maintainers of just that library to push an update, as opposed to forcing every single dependent to rebuild & push a new release.
- otterley 7y ago
  I would have agreed with this statement about five years ago. (Even though you would have had to restart all the dependent binaries after updating the shared libs.) Today, with containers becoming increasingly the de facto means of deploying software, it's not so important anymore. The upgrade process is now: (1) build an updated image; (2) upgrade your deployment manifest; (3) upload your manifest to your control plane. The control plane manages the rest. The other reason to use shared libs is for memory conservation, but except on the smallest devices, I'm not sure the average person cares about conserving a few MB of memory on 4GB+ machines anymore.
  - MereInterest 7y ago
    Some of us use linux as a desktop environment, and like having the security patches be applied as soon as the relevant package has updated.
    - AnIdiotOnTheNet 7y ago
      As a user of the Linux desktop, I really love it when library updates break compatibility with the software I use too. Or can't be installed because of dependency conflicts. Containers are popular because shared libraries cause more trouble than they are worth.
  - rumanator 7y ago
    > Today, with containers becoming increasingly the de facto means This assertion makes no sense at all and entirely misses the whole point of shared/dynamic libraries. It's like a buzzword is a magic spell that makes some people forget the entire history and design requirements up to that very moment.
    - ithkuil 7y ago
      Sometimes buzzwords make sense, in the right context. This was the right context. Assuming you use containers, you're likely to not log into them and keep them up to date and secure by running apt-get upgrade. The most common workflow is indeed: build your software in your CI system, in the last step create a container with your software and its dependencies. Then update your deployment with a new version of the whole image. A container image is for all intents and purposes the new "static binary". Yes, technically you can look inside it, yes technically you can (and you do) use dynamic linking inside the container itself. But as long as the workflow is the one depicted above, the environment no longer has the requirements that led to the design of dynamic linking. It's possible to have alternative workflows for building containers: you could fiddle with layers and swap an updated base OS under a layer containing your compiled application. I don't how common is that, but I'm sure somebody will want/have to do it. It all boils down to whether developers still maintain control over the full deployment pipeline as containers penetrate the enterprises (i.e. whether re retain the "shift to the left", another buzzword for you). Containers are not just a technical solution, they are the embodiment of the desire of developers to free themselves from the tyranny of filing tickets and waiting days to deploy their apps. But that leaves the security departments in enterprises understandably worried as most of those developers are focused on shipping features and often neglecting (or ignoring) security concerns around things that live one layer below the application they write.
- StreamBright 7y ago
  Based on my experience this is very rarely the case unless you have an extremely disciplined SecOps team.
  - rumanator 7y ago
    > Based on my experience this is very rarely the case You must have close to zero experience them because that's the norm on any software that depends on, say, third-party libraries that ship with a OS/distro. Recommended reading: Debian's openssl package. https://tracker.debian.org/pkg/openssl https://tracker.debian.org/pkg/openssl
    - StreamBright 7y ago
      You are talking about a FOSS project, I am talking about a company that has a service that uses OpenSSL in production.
      - boomlinde 7y ago
        These are not diametrically opposed. Your company can have a service that uses OpenSSL in production that runs on Debian to automatically take advantage of Debian patches and updates if it's linked dynamically to the system provided OpenSSL. You can either employ an extremely disciplined SecOps team to carefully track updates and CVEs (you'd need this whether you're linking statically or dynamically) or you can use e.g. Debian to take advantage of their work to that end.
        StreamBright 7y ago
        Every single company that I used to work for had an internal version of Linux that they approved for production. Internal release cycles are disconnected from external release cycles. On the top of that, some of these companies were not using system-wide packages at all, you had to reference a version of packages (like OpenSSL) during your build process. We had to do emergency patching for CVEs and bump the versions in every service. This way you can have 100% confidence what a particular service is running with a particular version of OpenSSL. This process do not depend on Debian's (or other FOSS vendor's) release cycles and the dependencies are explicit, therefore the vulnerability assessment is simpler (as opposed to go to every server and check which version is installed). Don't you think?
- yellowapple 7y ago
  My main issue with this rationale is that, in the vast majority of production environments (at least the ones I've seen in the wild, and indeed the ones I've built), updating dependencies for dynamically-linked dependents is part of the "release" process just like doing so for a statically-linked dependent, so this ends up being a distinction without a difference; in either circumstance, there's a "rebuild" as the development and/or operations teams test and deploy the new application and runtime environment. This is only slightly more relevant for pure system administration scenarios where the machine is exclusively running software prebuilt by some third-party vendor (e.g. your average Linux distro package repo). Even then, unless you're doing blind automatic upgrades (which some shops do, but it carries its own set of risks), you're still hopefully at least testing new versions and employing some sort of well-defined deployment workflow. Also, if that "security update" introduces a breaking change (which Shouldn't Happen™, but something something Murphy's Law something something), then - again - retesting and rebuilding a runtime environment for a dynamically-linked dependent v. rebuilding a statically-linked dependent is a distinction without a difference.
yjftsjthsd-h 7y ago
I know the ability exists, but I'm pretty sure that it's not exactly easy to get it working. Last time I tried, it immediately failed because my distribution wasn't shipping .a files (IIRC) for my installed libraries. There's a lot of little things that don't quite work because nobody's using them so they're harder to use so nobody uses them...
- alexeldeib 7y ago
  Yep, exactly this. And quirks of glibc and friends make fully static compilation likely to produce odd failures, unfortunately.
  - saagarjha 7y ago
    Glibc does not really support static linking.
    - alexeldeib 7y ago
      Kind of my point — so much software depends on it, it’s difficult to statically link more things.
      - needs 7y ago
        Musl is a pretty good replacement, I have been using it for years without any troubles.
        alexeldeib 7y ago
        I like Musl, but it is a source of pain at times too: https://github.com/kubernetes/kubernetes/issues/64924 https://github.com/kubernetes/kubernetes/issues/64924 https://github.com/kubernetes/kubernetes/issues/33554 https://github.com/kubernetes/kubernetes/issues/33554 Admittedly you could put that on the Kubernetes folks, but the same problem doesn't exist with glibc.
- Hello71 7y ago
PaulDavisThe1st 7y ago
In addition to the other excellent reasons mentioned here, there's also the fact that some libraries deliberately choose to use runtime dynamic linkage (dlopen) to load optional/runtime-dependent functionality.
- gmueckl 7y ago
  If you want make a program that supports plugins, you have only two real options: non-native runtimes or dynamic linking. And the later gets you into a lot of trouble quickly. The former trades performance and memory usage for ease of use and a zoo of dependencies.
- rumanator 7y ago
  > some libraries deliberately choose to use runtime dynamic linkage (dlopen) to load optional/runtime-dependent functionality. Also known as plugins. It's not a design flaw, it's a feature.
dman 7y ago
You cant statically compile in glibc right?
- spatulon 7y ago
  sure you can: $ cat hello.c #include <stdio.h> int main() { printf("hello world!\n"); } $ gcc -o hello hello.c $ ldd hello linux-vdso.so.1 (0x00007ffff9da0000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fed449d0000) /lib64/ld-linux-x86-64.so.2 (0x00007fed45000000) $ gcc -o hello hello.c -static $ ldd hello not a dynamic executable
  - luizfelberti 7y ago
    I don't think the parent comment's point was if this was technically possible. glibc is GPL licensed, and the GPL explicitly forbids statically linking to it unless your code is GPL too. Thus any non-GPL project has it's license tainted by the GPL if you statically link it. It's not a technical limitation, it's a legal one.
    - cesarb 7y ago
      This is false. The license for glibc is the LGPL, not the GPL, and the LGPL has an exception to allow static linking without the whole code having to be under the LGPL, as long as the .o files are also distributed to allow linking with a modified glibc ("As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice [...] and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library.")
      - luizfelberti 7y ago
        Sounds like I got conned by my (poor) memory. I should have re-googled this before posting, thanks for the correction.
jcelerier 7y ago
N°1 most harmful post on the internet : https://akkadia.org/drepper/no_static_linking.html https://akkadia.org/drepper/no_static_linking.html I am convinced that Drepper's insistence on dynamic linking has set the linux desktop useability and developer friendliness back literal decades.
- umvi 7y ago
  I work on an embedded linux system that has 256 MB of RAM. That can get eaten up really fast if every process has its own copy of everything.
  - freemint 7y ago
    You should look into fdpic as format to store your binaries in. It think i might lessen your concerns.
  - __d 7y ago
    Note that when using static linking, you don't get a copy of everything, just everything you actually use. It doesn't alter the fundamental point: shared libraries save both persistent storage and runtime memory.
    - saagarjha 7y ago
      > Note that when using static linking, you don't get a copy of everything, just everything you actually use. Which is a significant fraction of everything even if you call simple like printf. > It doesn't alter the fundamental point: shared libraries save both persistent storage and runtime memory. I fail to see the argument for this. Dynamic linking deduplicates dependencies and allows code to be mapped into multiple processes "for free".
      - admax88q 7y ago
        Have you measured it? How much is dynamic linking saving you? How many processes are you running on embedded systems with of 256MB or RAM?
pjmlp 7y ago
Ironically that is how they have been implemented since the dawn of time. Dynamic linking was added around Slackware 2.0 timeframe.
prussian 7y ago
One I think people forget about is ASLR. What symbols are you going to shuffle? At least with dynamic linked dependencies the linker can just shove different shared objects into different regions without much hassle. Other have mentioned the other points: runtime loading (plugins), CoW deduplication and thus less memory and storage.

AnIdiotOnTheNet 7y ago

> I can't wait until installing a program on linux is as simple as downloading a static executable and just running it and I hope zig brings this future. For the record: This is pretty close to what AppImage is today. It's not quite 100% because userland fragmentation is so ridiculously bad that it doesn't work out of the box on a few of them, but I personally really wish all Linux software was distributed that way (or static like Zig).

solarkraft 7y ago
And it pretty much proves that it's not such a great thing to aspire. Images are large, dependencies aren't updatable, locations don't match with distribution defaults.
- AnIdiotOnTheNet 7y ago
  On the other hand: no conflicts, no missing dependencies, can have multiple versions of the same thing installed at the same time, can store them anywhere including removable media...
  - tzjmetron 7y ago
    Yup. I have had some terrible experiences with dependencies. Bundling all the dependencies together makes sense in a lot of scenarios.