4 ms·

It fits perfectly in the Unix philosophy.

immibis 3y ago
Sucky working code is better than code that doesn't exist, yes. But isn't it silly that every Linux system needs to place this exact file at this exact path or else no program for another system will possibly be able to run on it?
- jclulow 3y ago
  The name of the file is just part of the committed interface that the binary consumes. You could just as well suggest it's silly that every Linux system needs to agree on the behaviour of each system call number, or no program for another system will possibly be able to run on it.
- cryptonector 3y ago
  "But isn't it silly that every Linux system needs a kernel and an initrd image or else it won't boot?"
pjmlp 3y ago
Translation, worse is better philosophy.
- anthk 3y ago
  9front does it better. No dynamic linking. At all.
  - cryptonector 3y ago
    User-land code can always add dynamic linking.
- cryptonector 3y ago
  Not really. Would you rather that the dynamic linker-loader be part of the kernel? Do you think that the kernel can somehow prohibit user-land dynamic linking?
  - pjmlp 3y ago
    I would rather have it as Windows and AIX do, or even mainframes, or by gone systems of similar age like Xerox PARC or ETHZ ones, yes they are in the kernel. In any case, modern security considerations have already shown that dynamic loading of foreign code into process memory isn't that much of a good idea after all, unless there are hardware restrictions regarding performace and memory use.
    - cryptonector 3y ago
      Well, I don't want dynamic linking and loading of user code to be done in the kernel -- that only increases the attack surface on the kernel. > In any case, modern security considerations have already shown that dynamic loading of foreign code into process memory isn't that much of a good idea after all, [...] As with many things it all depends on best practices and how you use the technology. Dynamic linking can be a big performance win. It can also be a performance loss. Dynamic linking can also be a big win in terms of code size, which even today is a good thing to have because container images can get bloated and you can need to have lots and lots of them, and it all adds up. None of that means you should be willing to dlopen() untrusted code, say. And again, you can always implement your own dynamic linking and loading regardless of what such facilities (if any) the host OS provides.

Sucky working code is better than code that doesn't exist, yes. But isn't it silly that every Linux system needs to place this exact file at this exact path or else no program for another system will possibly be able to run on it?

jclulow 3y ago
The name of the file is just part of the committed interface that the binary consumes. You could just as well suggest it's silly that every Linux system needs to agree on the behaviour of each system call number, or no program for another system will possibly be able to run on it.
cryptonector 3y ago
"But isn't it silly that every Linux system needs a kernel and an initrd image or else it won't boot?"

pjmlp 3y ago

Translation, worse is better philosophy.

anthk 3y ago
9front does it better. No dynamic linking. At all.
- cryptonector 3y ago
  User-land code can always add dynamic linking.
cryptonector 3y ago
Not really. Would you rather that the dynamic linker-loader be part of the kernel? Do you think that the kernel can somehow prohibit user-land dynamic linking?
- pjmlp 3y ago
  I would rather have it as Windows and AIX do, or even mainframes, or by gone systems of similar age like Xerox PARC or ETHZ ones, yes they are in the kernel. In any case, modern security considerations have already shown that dynamic loading of foreign code into process memory isn't that much of a good idea after all, unless there are hardware restrictions regarding performace and memory use.
  - cryptonector 3y ago
    Well, I don't want dynamic linking and loading of user code to be done in the kernel -- that only increases the attack surface on the kernel. > In any case, modern security considerations have already shown that dynamic loading of foreign code into process memory isn't that much of a good idea after all, [...] As with many things it all depends on best practices and how you use the technology. Dynamic linking can be a big performance win. It can also be a performance loss. Dynamic linking can also be a big win in terms of code size, which even today is a good thing to have because container images can get bloated and you can need to have lots and lots of them, and it all adds up. None of that means you should be willing to dlopen() untrusted code, say. And again, you can always implement your own dynamic linking and loading regardless of what such facilities (if any) the host OS provides.