I question that as well, it's also why Go is extremely popular. Could it just be a pendulum swing back towards static linking?

Wonder when some enterprising OSS dev will rebrand dynamic linking in the future...

> I don't care about glibc or compatibility with /etc/nsswitch.conf.

So what do you do when you need to resolve system users? I sure hope you don't parse /etc/passwd, since plenty of users (me included) use other user databases (e.g. sssd or systemd-userdbd).

Most software doesn't need to resolve users. You also can always shell out to `id` if you need an occasional bit of metadata.

That's a fair point, and shelling out to id is probably a good solution.

I guess what bothers me is the software authors who don't think this through, leaving applications non-functional in these situations.

At least with Go, if you do CGO_ENABLED=0, and you use the stdlib functions to resolve user information, you end up with parsed /etc/passwd instead of shelling out to id. The Go stdlib should maybe shell out to id instead, but it doesn't. And it's understandable that software developers use the stdlib functions without thinking all too much about it. But in the end, simply advocating for CGO_ENABLED=0 results in software that is broken around the edges.

On the other hand, the NSS modules are broken beyond fixing. So promoting ecosystems that don't use them might finally spur the development of alternatives.

Could be interesting. What do you see as the main problems with NSS? I've never needed to use it directly myself. It seems quite crusty of course, but presumably there's more that your referencing.

Moving from linking stuff in-process to IPC (such as systemd-userdbd is promoting) _seems_ to me like a natural thing to do, given the nastiness that can happen when you bring something complex into your own address space (via C semantics nonetheless). But I'm not very knowledgeable here and would be interested to hear your overall take.

NSS/PAM modules have to work inside arbitrary environments. And vice versa, environments have to be ready for arbitrary NSS modules.

For example, you technically can't sandbox any app with NSS/PAM modules, because a module might want to send an email (yes, I saw that in real life) or use a USB device.

NSS/PAM need to be replaced with IPC-based solutions. systemd is evolving a replacement for PAM.

And for NSS modules in particular, we even have a standard solution: NSCD. It's even supported by musl libc, but for some reason nobody even _knows_ that it exists. Porting the NSCD protocol to Go is like 20 minutes of work. I looked at doing that more than once, but got discouraged by the other 99% of complexity in getting something like this into the core Go code.