4 ms·

Yeah, I heard that argument — but seriously, how many people run or "install" single executables these days? What actually gets distributed as a single executab

by jwr 6y ago

Yeah, I heard that argument — but seriously, how many people run or "install" single executables these days? What actually gets distributed as a single executable? I honestly can't think of anything, on any system, except perhaps ngrok which I use for development.

jgalt212 6y ago
I think that's true for the technical crowd, but much less so for the general populace.
- sidpatil 6y ago
  I don't see how, unless you're counting Windows application installers as single-file executables.
phone8675309 6y ago
The previous version of the article (https://www.timmons.dev/posts/static-executables-with-sbcl.html https://www.timmons.dev/posts/static-executables-with-sbcl.h...) explains a few contexts where static binaries are desirable.
tumdum_ 6y ago
In my case: $ find ~/bin /usr/bin/ /bin/ -executable | xargs -I XXX file XXX | rg "statically linked" | awk '{ print $1 }' /home/t/bin/floki: /home/t/bin/yj: /home/t/bin/helm: /home/t/bin/fzf: /home/t/bin/kubectl: /usr/bin/containerd-shim-runc-v1: /usr/bin/hyperfine: /usr/bin/docker-init: /usr/bin/containerd-shim: /usr/bin/containerd-shim-runc-v2: /bin/busybox:
yellowapple 6y ago
> but seriously, how many people run or "install" single executables these days? Pretty much everyone who's ever used an AppImage on Linux, for one. This is also still the norm for macOS, from the user's point of view (yes, the application is technically a folder, but as far as most end users are concerned it's a single "thing" that gets dropped into their Applications folder). Still the norm for Windows, too, at least for installers (and "portable" apps, while not as common as ones installed to Program Files, certainly ain't obscure, even in this day and age).
qbasic_forever 6y ago
Almost every single tool in the k8s ecosystem is a simple statically linked go-based executable. Core stuff like kubectl, helm, etc. Read any k8s guide and step 1 is usually "go download all theses exes from github releases" (or more in vogue now, install a global NPM package that has the executable in its bin dir).
7thaccount 6y ago
In my eyes, that's part of the problem. A single executable is a lot easier to deal with. Having someone download Anaconda Python (massive install) to run a script is a huge fail in my eyes.
aseipp 6y ago
Chicken and egg. "many people" on Linux don't download executables and run them even if they're perfectly trusting of the source, because they'd often be linked against missing or incompatible dynamic libraries, which can lead to other problems during use. So then users are hesitant of them, so there's less of a desire to produce them in the first place (because users don't want it.) This is exacerbated by the fact static linking on Linux is complicated by historical factors and design decisions in some components like glibc. Go and Alpine Linux especially have caused a resurgence of interest in distributing static binaries. The vast majority of tools in the Go ecosystem encourage this, for instance. Really the whole conflation of and "executable application" as a "single file" is a historical mistake that we made but haven't fully let go of yet, and it's caused huge issues for users. For example, the distinction between "static linking" and "dynamic linking" largely isn't exposed to users on macOS, because they use .app bundles -- for all intents and purposes every macOS .app is "statically linked" because it can never resolve against other (possibly incompatible) dynamic libraries and it's a single file the user can manage. Then static/dynamic linking is just a technical aspect of how some amounts of code get loaded into the process, it's not a factor which impacts distribution or anything. At the end of the day, an "application" is NOT a file. It's an abstract object from the users perspective. Maybe there is a single file hiding behind the curtain, or it's a collection of files, or maybe something else entirely, but they aren't the same. Even Windows is also now moving in this direction (you can now have 'Runtimes' in Windows so that, say, a .py file and its data files can appear collectively like an .exe and be managed like a single file, with a single python runtime in the background), and Linux is too with things like AppImage, etc. Static linking is dead, long live static linking, etc etc.

by jwr 6y ago

jgalt212 6y ago

I think that's true for the technical crowd, but much less so for the general populace.

sidpatil 6y ago
I don't see how, unless you're counting Windows application installers as single-file executables.

phone8675309 6y ago

The previous version of the article (https://www.timmons.dev/posts/static-executables-with-sbcl.html https://www.timmons.dev/posts/static-executables-with-sbcl.h...) explains a few contexts where static binaries are desirable.

tumdum_ 6y ago

In my case: $ find ~/bin /usr/bin/ /bin/ -executable | xargs -I XXX file XXX | rg "statically linked" | awk '{ print $1 }' /home/t/bin/floki: /home/t/bin/yj: /home/t/bin/helm: /home/t/bin/fzf: /home/t/bin/kubectl: /usr/bin/containerd-shim-runc-v1: /usr/bin/hyperfine: /usr/bin/docker-init: /usr/bin/containerd-shim: /usr/bin/containerd-shim-runc-v2: /bin/busybox:

yellowapple 6y ago

> but seriously, how many people run or "install" single executables these days? Pretty much everyone who's ever used an AppImage on Linux, for one. This is also still the norm for macOS, from the user's point of view (yes, the application is technically a folder, but as far as most end users are concerned it's a single "thing" that gets dropped into their Applications folder). Still the norm for Windows, too, at least for installers (and "portable" apps, while not as common as ones installed to Program Files, certainly ain't obscure, even in this day and age).

qbasic_forever 6y ago

Almost every single tool in the k8s ecosystem is a simple statically linked go-based executable. Core stuff like kubectl, helm, etc. Read any k8s guide and step 1 is usually "go download all theses exes from github releases" (or more in vogue now, install a global NPM package that has the executable in its bin dir).

7thaccount 6y ago

In my eyes, that's part of the problem. A single executable is a lot easier to deal with. Having someone download Anaconda Python (massive install) to run a script is a huge fail in my eyes.

aseipp 6y ago

Chicken and egg. "many people" on Linux don't download executables and run them even if they're perfectly trusting of the source, because they'd often be linked against missing or incompatible dynamic libraries, which can lead to other problems during use. So then users are hesitant of them, so there's less of a desire to produce them in the first place (because users don't want it.) This is exacerbated by the fact static linking on Linux is complicated by historical factors and design decisions in some components like glibc. Go and Alpine Linux especially have caused a resurgence of interest in distributing static binaries. The vast majority of tools in the Go ecosystem encourage this, for instance. Really the whole conflation of and "executable application" as a "single file" is a historical mistake that we made but haven't fully let go of yet, and it's caused huge issues for users. For example, the distinction between "static linking" and "dynamic linking" largely isn't exposed to users on macOS, because they use .app bundles -- for all intents and purposes every macOS .app is "statically linked" because it can never resolve against other (possibly incompatible) dynamic libraries and it's a single file the user can manage. Then static/dynamic linking is just a technical aspect of how some amounts of code get loaded into the process, it's not a factor which impacts distribution or anything. At the end of the day, an "application" is NOT a file. It's an abstract object from the users perspective. Maybe there is a single file hiding behind the curtain, or it's a collection of files, or maybe something else entirely, but they aren't the same. Even Windows is also now moving in this direction (you can now have 'Runtimes' in Windows so that, say, a .py file and its data files can appear collectively like an .exe and be managed like a single file, with a single python runtime in the background), and Linux is too with things like AppImage, etc. Static linking is dead, long live static linking, etc etc.