Hacker News Reader

Comment by bheadmaster | Hacker News Reader

If you're writing applications exclusively for Linux, what's the practical difference between using libc and system calls?

Linux system calls are one of the most stable interfaces out there, maybe even more so than glibc. "WE DO NOT BREAK USERSPACE" and all that jazz.

View on HN

Syscall numbers are different on a per-architecture basis and some architectures allow using the calling conventions of multiple architectures - something that a library will presumably abstract away.

syscall numbers may be different, but the names are not different.

BTW, this is a pet peeve of mine. Having different syscall (and errno) numbers on different architectures is an historical mistake from Linux's first non-x86 port, the DEC alpha. My understanding is that Linus used DEC UNIX to bootstrap Linux, and needed to make Linux compatible with DEC's syscalls initially. Rather than make a new ABI for DEC UNIX binaries in advance, or clean up later, everything was left in place leading to a mess of 19 errno.h files in the kernel today.

For comparison, FreeBSD has 5. 4 of which are related to linux compat..

> leading to a mess of 19 errno.h files in the kernel today

having "dirty" and "band aid" staff could be the price Linux is paying to move faster, dominate server market and extend beyond the server market. One can even say UNIX is extincted, even Microsoft added WSL and WSA, where L is for Linux, not UNIX/POSIX and A is for Android, which is sort of Linux too.

> For comparison, FreeBSD has 5. 4 of which are related to linux compat..

This sounds to me as FreeBSD is more "lean" or "clean" and even may be less "agile" and this aligns well with what I've read and heard from others on internet and in person. I don't have my own opinion here and cannot compare.

What I can compare though, is FreeBSD implementing Linux compat/Linuxulator and not vise versa ( and mentioning WSL above ), giving me impression of Linux/Linus' tactic (even strategy may be?) worked better than others.

Would be interesting to hear your opinion.

Custom threads does not mix well with libc. Unless you can avoid the whole libc ecosystem, this won't end well

It is hard to interface with other libraries if you avoid libc, unless you reimplement the whole libc ABI (thread locals for example).

Still, this stuff is very cool and I would love to have time to play with it.

Interfacing with other libraries is fine as long as those other libraries also avoid libc... though of course then you get the whole problem of everyone reinventing the various wheels libc offers. Hypothetically that would then lead to various libraries implementing all the basics springing up from the primordial soup of code and the community eventually deciding on some libraries that are "good enough" which become the de facto new standard.

Reply on news.ycombinator.com