5 ms·

At the library level, I dislike how coarse grained most things are. Sadly becomes easier to reimplement things to avoid huge dependency chains. Want a simple

At the library level, I dislike how coarse grained most things are. Sadly becomes easier to reimplement things to avoid huge dependency chains. Want a simple web server ? Well, you’re going to get something with a JSON parser, PAM authentication, SSL, QUIC, websockets, an async framework, database for https auth, etc. Ever look at “curl”? The number protocols is dizzing — one could easily think that HTTP is only a minor feature. At the distro level, it is ridiculous that so long after Alpine Linux, the chasm between them and Debian/RHEL remains. A minimal Linux install shouldn’t be 1GB… We used to boot Linux from a 1.44mb floppy disk. A modern Grub installation would require a sizable stack of floppies! (Grub and Windows 3.0 are similar in size!)

udev4096 1y ago
Alpine's biggest hurdle is musl. Most of the software still relies on libc. You should look into unikernels [0], it's the most slimmed down version of linux that you can ship. I am not sure how different a unikernel is from a distroless image tho [0] - https://unikraft.org/ https://unikraft.org/
- anacrolix 1y ago
  Alpine is not as good as it seems. It's mostly broken it just works when you ask it to run a handful of common tools. Everything out of view is completely broken.
michaelmrose 1y ago
>A minimal Linux install shouldn’t be 1GB Why not this seems pretty arbitrary. Seemingly developer time or functionality would suffer to achieve this goal. To what end? Who cares how many floppies grub would require when its actually running on a 2TB ssd. The actually simpler thing is instead of duplicating effort to boot into Linux and use Linux to show the boot menu then kexec into the actual kernal or set it to boot next. See zfsbootmenu and "no more boot loader" this is simpler and less bloated but it doesnt use less space
- spacerzasp 1y ago
  There is more to size than storage space. Larger applications take more memory, more cpu caches; things spill over to normal memory, latencies grow and everything runs much slower
  - michaelmrose 1y ago
    For practical purposes given more than enough RAM and fast storage there is no meaningful user discernible performance differences between a 500Mb OS and a 30GB OS. Whereas very small linux distros are useful in several areas like containers and limited hardware running such on the desktop is an objectively worse experience and is moreso a minimalism fetish than a useful strategy.
    - datadrivenangel 1y ago
      There is never actually enough RAM and fast storage.
      - michaelmrose 1y ago
        There is enough that for most consumer use cases micro optimization only make sense in the context of poverty.
        datadrivenangel 1y ago
        One of my work laptops with 16GB of Ram struggles to open a few spreadsheets and browser tabs because of bloat.
        michaelmrose 1y ago
        Either install more RAM or install a better OS
    - RetroTechie 1y ago
actionfromafar 1y ago
I think we lost something with static linking when going from C to Dotnet. (And I guess Java.) Many C (and C++, especially "header only") libraries when statically linked are pretty good at filtering out unused code. Bundling stuff in Dotnet are done much more "runtime" often both by design of the library (it uses introspection¹) and the tools². 1: Simplified argument - one can use introspection and not expect all of the library to be there, but it's trickier. 2: Even when generating a self contained EXE, the standard toolchain performs no end-linking of the program, it just bundles everything up in one file.
- anacrolix 1y ago
  I disagree. Most people here myself included aren't using Java or .NET. You are in a microcosm in this audience.
- neonsunset 1y ago
  > I think we lost something with static linking when going from C to Dotnet. (And I guess Java.) Many C (and C++, especially "header only") libraries when statically linked are pretty good at filtering out unused code. This is an interesting statement because, for example, in C version of Mimalloc you end up paying for opt-in assertions because they still exist in the code unless you compile a different version that strips them away. In C# port, you can set the same assertions/checks early with AppContext switch, and then the values will be cached in static readonly fields. Then, when JIT recompiles the code to a more optimized version, these values will become JIT constants leading to all the unreachable code to be optimized away completely (and to much better inlining of now streamlined methods). > Even when generating a self contained EXE, the standard toolchain performs no end-linking of the program, it just bundles everything up in one file. /p:PublishTrimmed=true or even /p:PublishAot=true # please note it's better to set it as a project property, but either way it requires non-optional linking Lastly, consider that JITing the bytecode essentially acts like if everything is a single, statically-linked compilation unit since it's not subject to inconvenient compilation unit restrictions even Rust is subject to, the problems of which need to be cleaned up with link-time optimization.
  - 1y ago
procaryote 1y ago
> Want a simple web server ? Well, you’re going to get something with a JSON parser, PAM authentication, SSL, QUIC, websockets, an async framework, database for https auth, etc. Simple means different things for different people it seems. For a simple web server you need a tcp socket. If you want a full featured high performance web server, it's not gonna be simple.
_fat_santa 1y ago
> At the distro level, it is ridiculous that so long after Alpine Linux, the chasm between them and Debian/RHEL remains. A minimal Linux install shouldn’t be 1GB… I would say this is a feature and not a bug. Alpine Linux is largely designed to be run in containerized environments so you can have an extremely small footprint cause you don't have to ship stuff like a desktop or really anything beyond the very very basics. Compare that to Ubuntu which for the 5GB download is the "Desktop" variant that comes with much more software

udev4096 1y ago

Alpine's biggest hurdle is musl. Most of the software still relies on libc. You should look into unikernels [0], it's the most slimmed down version of linux that you can ship. I am not sure how different a unikernel is from a distroless image tho [0] - https://unikraft.org/ https://unikraft.org/

anacrolix 1y ago
Alpine is not as good as it seems. It's mostly broken it just works when you ask it to run a handful of common tools. Everything out of view is completely broken.

michaelmrose 1y ago

>A minimal Linux install shouldn’t be 1GB Why not this seems pretty arbitrary. Seemingly developer time or functionality would suffer to achieve this goal. To what end? Who cares how many floppies grub would require when its actually running on a 2TB ssd. The actually simpler thing is instead of duplicating effort to boot into Linux and use Linux to show the boot menu then kexec into the actual kernal or set it to boot next. See zfsbootmenu and "no more boot loader" this is simpler and less bloated but it doesnt use less space

spacerzasp 1y ago
There is more to size than storage space. Larger applications take more memory, more cpu caches; things spill over to normal memory, latencies grow and everything runs much slower
- michaelmrose 1y ago
  For practical purposes given more than enough RAM and fast storage there is no meaningful user discernible performance differences between a 500Mb OS and a 30GB OS. Whereas very small linux distros are useful in several areas like containers and limited hardware running such on the desktop is an objectively worse experience and is moreso a minimalism fetish than a useful strategy.
  - datadrivenangel 1y ago
    There is never actually enough RAM and fast storage.
    - michaelmrose 1y ago
      There is enough that for most consumer use cases micro optimization only make sense in the context of poverty.
      - datadrivenangel 1y ago
        One of my work laptops with 16GB of Ram struggles to open a few spreadsheets and browser tabs because of bloat.
        michaelmrose 1y ago
        Either install more RAM or install a better OS
  - RetroTechie 1y ago

actionfromafar 1y ago

I think we lost something with static linking when going from C to Dotnet. (And I guess Java.) Many C (and C++, especially "header only") libraries when statically linked are pretty good at filtering out unused code. Bundling stuff in Dotnet are done much more "runtime" often both by design of the library (it uses introspection¹) and the tools². 1: Simplified argument - one can use introspection and not expect all of the library to be there, but it's trickier. 2: Even when generating a self contained EXE, the standard toolchain performs no end-linking of the program, it just bundles everything up in one file.

anacrolix 1y ago
I disagree. Most people here myself included aren't using Java or .NET. You are in a microcosm in this audience.
neonsunset 1y ago
> I think we lost something with static linking when going from C to Dotnet. (And I guess Java.) Many C (and C++, especially "header only") libraries when statically linked are pretty good at filtering out unused code. This is an interesting statement because, for example, in C version of Mimalloc you end up paying for opt-in assertions because they still exist in the code unless you compile a different version that strips them away. In C# port, you can set the same assertions/checks early with AppContext switch, and then the values will be cached in static readonly fields. Then, when JIT recompiles the code to a more optimized version, these values will become JIT constants leading to all the unreachable code to be optimized away completely (and to much better inlining of now streamlined methods). > Even when generating a self contained EXE, the standard toolchain performs no end-linking of the program, it just bundles everything up in one file. /p:PublishTrimmed=true or even /p:PublishAot=true # please note it's better to set it as a project property, but either way it requires non-optional linking Lastly, consider that JITing the bytecode essentially acts like if everything is a single, statically-linked compilation unit since it's not subject to inconvenient compilation unit restrictions even Rust is subject to, the problems of which need to be cleaned up with link-time optimization.
- 1y ago

procaryote 1y ago

> Want a simple web server ? Well, you’re going to get something with a JSON parser, PAM authentication, SSL, QUIC, websockets, an async framework, database for https auth, etc. Simple means different things for different people it seems. For a simple web server you need a tcp socket. If you want a full featured high performance web server, it's not gonna be simple.

_fat_santa 1y ago

> At the distro level, it is ridiculous that so long after Alpine Linux, the chasm between them and Debian/RHEL remains. A minimal Linux install shouldn’t be 1GB… I would say this is a feature and not a bug. Alpine Linux is largely designed to be run in containerized environments so you can have an extremely small footprint cause you don't have to ship stuff like a desktop or really anything beyond the very very basics. Compare that to Ubuntu which for the 5GB download is the "Desktop" variant that comes with much more software