That is really slick, I like your style. I could definitely live with like, one `.so` somewhere that never moves, I mean we've already got `vDSO` and stuff which is sort of related.
The quote about "glibc maintainers being non-helpful" slayed me. I guess at least some of the kernel people aren't exactly thrilled about the tireless efforts of the GNU project to gatekeep, take credit for, be obstructionist around, and otherwise subsume Linux into The GNU Operating System.
I hate that it's gotten to the point where I'm the "anti-GNU" guy, I never wanted that, but they need some fresh blood in the leadership or something.
> I could definitely live with like, one `.so` somewhere that never moves, I mean we've already got `vDSO` and stuff which is sort of related.
Nice idea. I think a kernel libc in the form of a vDSO would unnecessarily force compilers to use the C ABI though. The Linux system call interface is really unique in how it's not only stable but language-agnostic and it would be a shame to lose that.
I think compilers are the right place for system calls. The programming language should have a system_call keyword that makes the compiler emit the syscall instruction with the parameters in the right registers. It was my intention to eventually create that language, liblinux was something of a prelude... Then I ran out of free time. :)
Then it turned out smarter people than me have gone much farther than I did:
> The quote about "glibc maintainers being non-helpful" slayed me.
> I guess at least some of the kernel people aren't exactly thrilled about the tireless efforts of the GNU project to gatekeep, take credit for, be obstructionist around, and otherwise subsume Linux into The GNU Operating System.
I understand what you mean. I think it's really weird how often I get glibc manual pages when I look up Linux kernel documentation. I look up some system call and get glibc wrappers instead. Aren't they separate projects?
In the first AMA someone asked Greg whether glibc was blessed by the kernel:
He said no, but it still seems like the official libc of Linux.
I also get systemd manuals when I look up Linux init system documentation. I expected to read about what the kernel itself expects from PID 1, information useful for making my own system. Turns out it's just a process like any other, it just needs to bring up the system by doing things like mounting procfs and sysfs.
Linux should be its own thing. It's only "GNU/Linux" because of POSIX which says an operating system has to have binaries like cp, mv, etc. Things don't have to be that way. POSIX is just paper.
> I hate that it's gotten to the point where I'm the "anti-GNU" guy, I never wanted that, but they need some fresh blood in the leadership or something.
I think it was a quote from Lennart Poettering that inspired me to start dropping this "standard" GNU stuff. I think he wrote something like "read TLPI and ignore all the POSIX stuff". So I did and I discovered a really nice system that actually turned out to be easier and more fun to program with than dealing with C libraries. No global state anywhere!
GNU is just a POSIX compliant user space. It doesn't have to be that way... Wouldn't it be cool if some awesome person made a pure Lisp user space? A pure Rust user space? It doesn't have to be the same old POSIX tools... Linux enables that. We can trash the entire user space and start fresh if we want. We can't do that on Windows, Mac, the BSDs.
The quote about "glibc maintainers being non-helpful" slayed me. I guess at least some of the kernel people aren't exactly thrilled about the tireless efforts of the GNU project to gatekeep, take credit for, be obstructionist around, and otherwise subsume Linux into The GNU Operating System.
I hate that it's gotten to the point where I'm the "anti-GNU" guy, I never wanted that, but they need some fresh blood in the leadership or something.