Back

@musl I'll use musl when most software I use doesn't depend on glibc extensions.

@lanodan @musl Most notably, NVIDIA drivers only work on glibc systems.

@dusnm @lanodan @musl do they only work because they've been linked against glibc, or do they depend on any particulars of glibc? their drivers are usually distributed as a shell script with an embedded zip file, so separating then unzipping the zip may be a way to investigate the dependency. i believe it's usually possible to edit shared lib dependencies to point to musl libc although i may be wrong depending on how they package it. i'm under the impression that the drivers themselves are kernel modules and cannot link against userspace libc, even if their installer requires it for the little curses interface it provides. nvidia tries very hard to make it extremely difficult to use alternative software stacks anyway as it's a cornerstone of the monopoly their investors demand, but musl libc should be one of the least difficult components to swap in

@hipsterelectron @lanodan @musl The fact of the matter, to me at least, is that I won't switch what definitely works for what might eventually work. Not a dig at musl at all, I'm just unwilling to make the effort. Plain and simple. I'm not a systems programmer and I don't pretend to be one. For the most part, I just expect the default configuration to work. My fiddling days are gone.

@dusnm my work is specifically on build/packaging/deploy systems so scientists can do science