undefined | Better HN

0 pointscrabbone2y ago0 comments

While I think that most of your reply is pretending to not notice the real problem and making lame excuses, I specifically want to point out this:

> You can program in another language other than C and avoid using GNU libc

Linux is a set of various system interfaces. Many of which are exposed through libc functions. If you deliberately exclude libc and program something parallel to it instead, then you aren't really using Linux. You've created a hybrid system. This only reinforces OP's complaint about not being able to program in a different language, because, in other words, this means that to C language programmer Linux is available fully, and to other languages the functionality is not completely available.

Take, for example, async I/O, which is implemented in libc around other system primitives, s.a. threads. If you don't use libc, you don't have async I/O, and by extension, you don't have Linux, since Linux is supposed to have that.

0 comments

thecodedmessage2y ago

This is a surprising take.

Linux as a project is the kernel. Unlike most OSes, the most commonly used libc is maintained separately. As a result, Linux the operating system is the one where it’s the most common and supported to avoid the “standard” libc because the kernel itself has a stable interface.

crabboneOP2y ago

Again, you are trying to pretend not to notice the common understanding and the use of the word, while pulling out some definition nobody cares about.

Yes, technically, Linux is a kernel project. But, most time the word is used to designate the whole operating system (which annoys people who like to be precise, but it's also clear as day how OP meant to use the word, and you swapping the meaning of the word OP used for something that's convenient to you to make a useless contrarian point is just an example of bad discussion).

tsimionescu2y ago

This is simply false. The Linux maintainers have little idea of how different libc implementers expose the interface they provide, and there are non-C languages using those ABIs as well. There is also full documentation for how to access any piece of ABI that Linux exposes without using C.

For example, here is a site that documents all Linux syscalls on x86_64, with the exact registers that they read their arguments from, and the registers they write their results in:

https://filippo.io/linux-syscall-table/

crabboneOP2y ago

> Linux maintainers have little idea of how different libc implementers expose the interface they provide

This is literally false. A huge chunk of discussion on kernel mailing lists is exactly about this subject.

And, again. When OP used the word "Linux" they meant the entire operating system. The fact that this is also the name of the kernel project is irrelevant. Perhaps OP should've written "GNU/Linux" to satisfy mindless bureaucrats, but, I guess, OP hoped that this wouldn't be necessary.

tsimionescu2y ago

OP explicitly talks about the system interfaces - i.e. the kernel. I don't see any sign that they are talking about the whole OS. In fact, if they were talking about the whole OS, the post would be nonsensical: any OS has a userspace implemented in some language, so any OS is 'pushing a language' in this limited sense, by definition.

Either way, the OP is clearly confused about what Linux-the-kernel provides vs Linux-the-OS. Their example of async IO is nonsense - async IO is built into the kernel itself, as are threads (which are not even available in libc, at least until very recently).

I will admit that I was "greatly exaggerating" (read: lying) when claiming that kernel maintainers don't know/care how libc uses their API. But the point is that, while the needs of libc obviously inform their designs, they are not directly writing or maintaining it, unlike virtually all other mainstream OSs.

bregma2y ago

Linux is not exclusively GNU/Linux. For example, Musl/Linux (eg. Alpine Linux) and Android/Linux are widespread. The Linux ABI is unchanged.

Legitimate Linux applications are written in Go all the time. Linux applications are often written in Rust and use the Linux ABI without going through any libc. They seem to be doing mighty fine in terms of "being Linux".

This sounds like some variant of the True Scotsman fallacy.

crabboneOP2y ago

Wow, this is a third commenter who didn't bother to read what OP wrote.

Come on! OP meant the whole OS, not the kernel project. How is this not obvious?

j / k navigate · click thread line to collapse

0 pointscrabbone2y ago0 comments

While I think that most of your reply is pretending to not notice the real problem and making lame excuses, I specifically want to point out this:

> You can program in another language other than C and avoid using GNU libc

0 comments

thecodedmessage2y ago

This is a surprising take.

crabboneOP2y ago

Again, you are trying to pretend not to notice the common understanding and the use of the word, while pulling out some definition nobody cares about.

tsimionescu2y ago

For example, here is a site that documents all Linux syscalls on x86_64, with the exact registers that they read their arguments from, and the registers they write their results in:

https://filippo.io/linux-syscall-table/

crabboneOP2y ago

> Linux maintainers have little idea of how different libc implementers expose the interface they provide

This is literally false. A huge chunk of discussion on kernel mailing lists is exactly about this subject.

tsimionescu2y ago

bregma2y ago

Linux is not exclusively GNU/Linux. For example, Musl/Linux (eg. Alpine Linux) and Android/Linux are widespread. The Linux ABI is unchanged.

This sounds like some variant of the True Scotsman fallacy.

crabboneOP2y ago

Wow, this is a third commenter who didn't bother to read what OP wrote.

Come on! OP meant the whole OS, not the kernel project. How is this not obvious?

j / k navigate · click thread line to collapse