3 ms·

No offense, but 4.3MB is huge for what it does. Most shells take less space than that! Where's all the bloat coming from?

by esafak 1y ago

have-a-break 1y ago
I feel like that's just the result of having a native package manager making natural bloat and a compiler which hasn't had decades of work.
o11c 1y ago
For reference, some statically-linked shells on my system: 2288K /bin/bash-static (per manual, "too big and too slow") 1936K /bin/busybox-static (including tools not just the shell) 192K /usr/lib/klibc/bin/mksh 2456K zsh-static For comparison, some dynamically-linked binaries (some old) 804K ./bin/bash-3.2 888K ./bin/bash-4.0 908K ./bin/bash-4.1 956K ./bin/bash-4.2 1016K ./bin/bash-4.3 1092K ./bin/bash-4.4 1176K ./bin/bash-5.0 1208K ./bin/bash-5.1 1236K /bin/bash (5.2) 124K /bin/dash 1448K /bin/ksh93 (fattest when excluding libc!) 292K /bin/mksh 144K /bin/posh 424K /bin/yash 848K /bin/zsh (The reason I don't have static binaries handy is because they no longer run on modern systems. As long as you aren't using shitty libraries, dynamic binaries are more portable and reliable, contrary to internet "wisdom".)
JoshTriplett 1y ago
Among the features it has: an interactive terminal GUI, threaded parallel directory walking, and git repository support. In around a thousand lines of code, total, including tests, half of which is the GUI.
- oguz-ismail 1y ago
  *TUI. Not GUI
koito17 1y ago
> Most shells take less space than that! Most shells dynamically link to a runtime your OS provides "for free". The 4.3 MiB binary in question is bundling the Rust runtime and its dependencies. For reference, a statically-compiled C++ "Hello, World" is 2.2 MiB after stripping. % cat hello.nix { pkgs ? import <nixpkgs> { crossSystem = "aarch64-linux"; } }: pkgs.stdenv.mkDerivation { name = "hello-static"; src = pkgs.writeText "hello.cpp" '' #include <iostream> int main() { std::cout << "Hello, World!" << std::endl; return 0; } ''; dontUnpack = true; buildInputs = [ pkgs.glibc.static ]; buildPhase = "$CXX -std=c++17 -static -o hello $src"; installPhase = "mkdir -p $out/bin; cp hello $out/bin/"; } % nix-build hello.nix ... % wc -c result/bin/hello 2224640 result/bin/hello
- esafak 1y ago
  2.2MiB for "Hello, World"? I must be getting old... The executable takes 33KB in C, 75KB in nim.
  - creatonez 1y ago
    > The executable takes 33KB in C, 75KB in nim. Did you statically link Glibc...? Or is this with a non-GNU libc? Either way, it probably is true that this 2.2MiB number would be smaller on, say, Debian 5. And much smaller on PDP Unix.
  - koito17 1y ago
    By switching to e.g. musl, you can go down to a single megabyte ;) But in all seriousness, my example is quite cherrypicked, since nobody will actually statically link glibc. And even if they did, one can make use of link-time optimization to remove lots of patches of unused code. Note that this is the same strategy one would employ to debloat their Rust binaries. (Use LTO, don't aggressively inline code, etc.)
    - 3836293648 1y ago
      Just a `puts("Hello world!")` with -Os statically linked to musl is 22k
  - 3836293648 1y ago
    We just have large standard libraries now
    - surajrmal 1y ago
      lto will remove most of it.
  - AdieuToLogic 1y ago
    Just for fun, I wondered how small a canonical hello world program could be in macOS running an ARM processor. Below is based on what I found here[0] with minor command-line switch alterations to account for a newer OS version. ARM64 assembly program (hw.s): // // Assembler program to print "Hello World!" // to stdout. // // X0-X2 - parameters to linux function services // X16 - linux function number // .global _start // Provide program starting address to linker .align 2 // Setup the parameters to print hello world // and then call Linux to do it. _start: mov X0, #1 // 1 = StdOut adr X1, helloworld // string to print mov X2, #13 // length of our string mov X16, #4 // MacOS write system call svc 0 // Call linux to output the string // Setup the parameters to exit the program // and then call Linux to do it. mov X0, #0 // Use 0 return code mov X16, #1 // Service command code 1 terminates this program svc 0 // Call MacOS to terminate the program helloworld: .ascii "Hello World!\n" Assembling and linking commands: as -o hw.o hw.s && ld -macos_version_min 14.0.0 -o hw hw.o -lSystem -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.2.sdk -e _start -arch arm64 Resulting file sizes: -rwxr-xr-x 1 <uid> <gid> 16K Jun 18 21:23 hw -rw-r--r-- 1 <uid> <gid> 440B Jun 18 21:23 hw.o -rw-r--r-- 1 <uid> <gid> 862B Jun 18 21:21 hw.s 0 - https://smist08.wordpress.com/2021/01/08/apple-m1-assembly-language-hello-world/ https://smist08.wordpress.com/2021/01/08/apple-m1-assembly-l...

No offense, but 4.3MB is huge for what it does. Most shells take less space than that! Where's all the bloat coming from?

by esafak 1y ago

No offense, but 4.3MB is huge for what it does. Most shells take less space than that! Where's all the bloat coming from?

have-a-break 1y ago

I feel like that's just the result of having a native package manager making natural bloat and a compiler which hasn't had decades of work.

o11c 1y ago

For reference, some statically-linked shells on my system: 2288K /bin/bash-static (per manual, "too big and too slow") 1936K /bin/busybox-static (including tools not just the shell) 192K /usr/lib/klibc/bin/mksh 2456K zsh-static For comparison, some dynamically-linked binaries (some old) 804K ./bin/bash-3.2 888K ./bin/bash-4.0 908K ./bin/bash-4.1 956K ./bin/bash-4.2 1016K ./bin/bash-4.3 1092K ./bin/bash-4.4 1176K ./bin/bash-5.0 1208K ./bin/bash-5.1 1236K /bin/bash (5.2) 124K /bin/dash 1448K /bin/ksh93 (fattest when excluding libc!) 292K /bin/mksh 144K /bin/posh 424K /bin/yash 848K /bin/zsh (The reason I don't have static binaries handy is because they no longer run on modern systems. As long as you aren't using shitty libraries, dynamic binaries are more portable and reliable, contrary to internet "wisdom".)

JoshTriplett 1y ago

Among the features it has: an interactive terminal GUI, threaded parallel directory walking, and git repository support. In around a thousand lines of code, total, including tests, half of which is the GUI.

oguz-ismail 1y ago
*TUI. Not GUI

koito17 1y ago

> Most shells take less space than that! Most shells dynamically link to a runtime your OS provides "for free". The 4.3 MiB binary in question is bundling the Rust runtime and its dependencies. For reference, a statically-compiled C++ "Hello, World" is 2.2 MiB after stripping. % cat hello.nix { pkgs ? import <nixpkgs> { crossSystem = "aarch64-linux"; } }: pkgs.stdenv.mkDerivation { name = "hello-static"; src = pkgs.writeText "hello.cpp" '' #include <iostream> int main() { std::cout << "Hello, World!" << std::endl; return 0; } ''; dontUnpack = true; buildInputs = [ pkgs.glibc.static ]; buildPhase = "$CXX -std=c++17 -static -o hello $src"; installPhase = "mkdir -p $out/bin; cp hello $out/bin/"; } % nix-build hello.nix ... % wc -c result/bin/hello 2224640 result/bin/hello

esafak 1y ago
2.2MiB for "Hello, World"? I must be getting old... The executable takes 33KB in C, 75KB in nim.
- creatonez 1y ago
  > The executable takes 33KB in C, 75KB in nim. Did you statically link Glibc...? Or is this with a non-GNU libc? Either way, it probably is true that this 2.2MiB number would be smaller on, say, Debian 5. And much smaller on PDP Unix.
- koito17 1y ago
  By switching to e.g. musl, you can go down to a single megabyte ;) But in all seriousness, my example is quite cherrypicked, since nobody will actually statically link glibc. And even if they did, one can make use of link-time optimization to remove lots of patches of unused code. Note that this is the same strategy one would employ to debloat their Rust binaries. (Use LTO, don't aggressively inline code, etc.)
  - 3836293648 1y ago
    Just a `puts("Hello world!")` with -Os statically linked to musl is 22k
- 3836293648 1y ago
  We just have large standard libraries now
  - surajrmal 1y ago
    lto will remove most of it.
- AdieuToLogic 1y ago
  Just for fun, I wondered how small a canonical hello world program could be in macOS running an ARM processor. Below is based on what I found here[0] with minor command-line switch alterations to account for a newer OS version. ARM64 assembly program (hw.s): // // Assembler program to print "Hello World!" // to stdout. // // X0-X2 - parameters to linux function services // X16 - linux function number // .global _start // Provide program starting address to linker .align 2 // Setup the parameters to print hello world // and then call Linux to do it. _start: mov X0, #1 // 1 = StdOut adr X1, helloworld // string to print mov X2, #13 // length of our string mov X16, #4 // MacOS write system call svc 0 // Call linux to output the string // Setup the parameters to exit the program // and then call Linux to do it. mov X0, #0 // Use 0 return code mov X16, #1 // Service command code 1 terminates this program svc 0 // Call MacOS to terminate the program helloworld: .ascii "Hello World!\n" Assembling and linking commands: as -o hw.o hw.s && ld -macos_version_min 14.0.0 -o hw hw.o -lSystem -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.2.sdk -e _start -arch arm64 Resulting file sizes: -rwxr-xr-x 1 <uid> <gid> 16K Jun 18 21:23 hw -rw-r--r-- 1 <uid> <gid> 440B Jun 18 21:23 hw.o -rw-r--r-- 1 <uid> <gid> 862B Jun 18 21:21 hw.s 0 - https://smist08.wordpress.com/2021/01/08/apple-m1-assembly-language-hello-world/ https://smist08.wordpress.com/2021/01/08/apple-m1-assembly-l...