Comment

Is it? I thought the thing that musl optimized for was disk usage, not memory usage or CPU time. It's been my experience that alpine containers are worse than their glibc counterparts because glibc is damn good. It's definitely faster in many cases. I think this is fixed now, but I remember when musl made the python interpreter run like 50-100x slower.

source

Sort:hotnew top

non_burglar@lemmy.world ⁨1⁩ ⁨day⁩ ago
Glibc matters on desktop, but the speed advantage doesn’t really matter to services running in cgroup2 containers borrowing the host’s kernel and namespaces.

For op’s purposes, memory density is important, and alpine base images will need about 10x less memory than their Debian counterparts, mostly due to a very pared-down service layout.

There’s a reason a huge portion of docker images are alpine-based.

source
- Badabinski@kbin.earth ⁨1⁩ ⁨day⁩ ago
  Do you have any sources for the 10x memory thing? I've seen people who have made memory usage claims, but I haven't seen benchmarks demonstrating this.
  
  source
  - 486@lemmy.world ⁨16⁩ ⁨hours⁩ ago
    
    or DNS over TCP.
    
    musl does support DNS over TCP since version 1.2.4.
    
    source
  - non_burglar@lemmy.world ⁨1⁩ ⁨day⁩ ago
    Image
    
    That is incus. But similar in other implementations of LXC. Docker has similar ratios, but I suspect you know this already.
    
    Also, I fucking hate the person that decided it wasn’t going to do search domains properly or DNS over TCP.
    
    That has been fixed since 3.18.
    
    Look, I’m not sure why you’re challenging me so hard on this, I’m not a superfan of Alpine or anything. I use it when I can because it’s really, really light on memory and so do others. There are lots of cases that don’t work with Alpine, like mongodb, sql, etc. But there are lots of great uses for alpine as well, like networking or anything that works well with busybox tooling.
    
    Have a better one.
    
    source