back
7 comments
I've been really meaning to get using relibc with NixOS going. (relibc supports Linux syscalls too).

Not going to lie, there's a lot of money for RIIR these days ;). More seriously, libc is a very crucial piece of software and a good candidate for writing in a better language. Showing that we can blur the lines further between a Linux and Rust OS userland makes the latter kernel seem much more viable. Should be a win-win all around.

Ugh, if you can simply replace getaddrinfo, I'd be sold. That shit is nuts.
That makes no sense. Implementing libc and related libs literally means implementing their API. getaddrinfo() is a part of that.

Also, getaddrinfo() is so elaborate because it handles a huge amount of networking layers. It's specifically broad and flexible because its predecessor (gethostbyname()) was not, and was found to be inadequate.

> Implementing libc and related libs literally means implementing their API. getaddrinfo() is a part of that.

I think you missed my point. getaddrinfo is implemented annoyingly and seems to rely on loopback networking to the same process for... some reason. Constant pain in the firewall because the port is randomized, so I have to allow the entire localhost. Which I don't like.

A reimplementation would be exactly good.

> Our approach is to make our C library, relibc, the interface for the stable ABI, and to make relibc a dynamic library.

Seems reasonable - but will this lead to a situation similar to GNU libc, where static binaries are difficult/impossible? (See many discussions on glibc vs musl etc).

Nope. You can still statically link everything but libc, and if you know your kernel version you can statically link your kernel too.
As a PopOS user I'll be quite interested to see if Cosmic is deemed mature enough to ship in 2024, as suggested earlier this year.