3 ms·

Shared libraries are a pain for sure. They also have a lot of really nice advantages, including: - You can upgrade core functionality in one location - You

Shared libraries are a pain for sure. They also have a lot of really nice advantages, including: - You can upgrade core functionality in one location - You can fix security bugs without needing to re-install the world - Overall, they take up less disk-space and RAM - They can take much less cache, which is significant today The cache aspect is one that I'm surprised not to see people talk about more. Why would I want to blow out my CPU cache loading 20 instances of libSSL? That slows down performance of the entire system.

taeric 8y ago
I think the dream is you could have one SSL process that others communicated with. Message passing at large.
- otterley 8y ago
  It's not without cost, though. Moving messages around causes CPU data cache pressure and CPU cycles you wouldn't otherwise have spent if you merely referenced shared memory that's mapped into your process.
  - taeric 8y ago
    Right. I didn't mean that to be why it is correct. Just giving some comment to what was actually suggested. Static linking is not the only alternative to dynamic linking.
- joejev 8y ago
  So, like some sort of shared library that my programs dynamically communicate with? How is this functionally different from a shared object?
  - AnIdiotOnTheNet 8y ago
    It isn't really. The actual big problem with shared libraries is that developers cannot be trusted not to change their interfaces or behavior and break things. That's true regardless of what mechanism you use to share code.
  - a1369209993 8y ago
    > How is this functionally different from a shared object? Because it's a separate process, so when it crashes your application can put up a "SSL failed, reconnecting" message and carry on. Also when your application has read-something-somewhere security vulnerability, it can't compromise your SSL keys. Nitpick: it's not one process, but one executable; you can have multiple SSL daemons using the same (read-only) binary, so a attack on one only gets one set of keys. (The same attack will probably work on every instance of the same version of SSLd, but shared objects don't fix that.)
shereadsthenews 8y ago
That is just not how cpu cache works on multi-user systems. There is no L1 icache sharing between programs.
- twoodfin 8y ago
  You don’t have to go much further down the hierarchy before you’re sharing one copy of common code & static data.

taeric 8y ago

I think the dream is you could have one SSL process that others communicated with. Message passing at large.

otterley 8y ago
It's not without cost, though. Moving messages around causes CPU data cache pressure and CPU cycles you wouldn't otherwise have spent if you merely referenced shared memory that's mapped into your process.
- taeric 8y ago
  Right. I didn't mean that to be why it is correct. Just giving some comment to what was actually suggested. Static linking is not the only alternative to dynamic linking.
joejev 8y ago
So, like some sort of shared library that my programs dynamically communicate with? How is this functionally different from a shared object?
- AnIdiotOnTheNet 8y ago
  It isn't really. The actual big problem with shared libraries is that developers cannot be trusted not to change their interfaces or behavior and break things. That's true regardless of what mechanism you use to share code.
- a1369209993 8y ago
  > How is this functionally different from a shared object? Because it's a separate process, so when it crashes your application can put up a "SSL failed, reconnecting" message and carry on. Also when your application has read-something-somewhere security vulnerability, it can't compromise your SSL keys. Nitpick: it's not one process, but one executable; you can have multiple SSL daemons using the same (read-only) binary, so a attack on one only gets one set of keys. (The same attack will probably work on every instance of the same version of SSLd, but shared objects don't fix that.)

shereadsthenews 8y ago

That is just not how cpu cache works on multi-user systems. There is no L1 icache sharing between programs.

twoodfin 8y ago
You don’t have to go much further down the hierarchy before you’re sharing one copy of common code & static data.