Back

@musl thanks that was what I was looking for!

@dusnm @musl in @spack we have recently parameterized the choice of libc, currently focused on separate glibc versions but i have been making small fixes for alpine support for a bit and musl libc support is absolutely part of the goal for the parameterized libc. spack is not a distro but i have been pitching it to distros to use as an implementation detail

@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

@hipsterelectron And I have nothing but respect for people like you. Like I said, not a dig at what other people do. Honestly, I didn't expect my one remark to spawn such a serious discussion.