5 ms·

The kicker these days is that "standing still" is not enough. Software that "lasts" has to constantly change, because externalities force it to - primarily, sec

by zmmmmm 6y ago

The kicker these days is that "standing still" is not enough. Software that "lasts" has to constantly change, because externalities force it to - primarily, security. Whatever library, language or foundation you built on, you can guarantee whatever version you used is going to stop getting security updates in a couple of years. And then there will be a whole lot of baked in dependencies you didn't know about - URLs (like XML schema URIs that were never meant to be resolved but lots of libraries do), certificates, underlying system libraries etc. So designing software "to last" now is designing software to be constantly updated in a reliable and systematic way. And the interesting thing about that is from what I can observe, the only way to achieve that currently IS through simplicity - as few dependencies as possible, those that you do have very well understood and robust, etc etc. So it sort of comes back to the author's argument in the end, though maybe through a different route.

fulafel 6y ago
It's possible to engineer for this. The mental model: imagine you are equipping a time travel mission decades into the future, to integrate with the future internet, and to return home with acquired results. A TLS client is not possible to future proof like this of course, but you could have a roster of approaches. For example, try getting your hands on the latest curl / wget builds (try each with a few different approaches), or the latest JVM/Python/Powershell & use those TLS APIs. A fun game would be to try this with tools available 20 years ago, and then redo it to make a sw time capsule from present day to 20 years into the future...
- mjevans 6y ago
  A better approach is to have the "TLS" library accept either an already connected socket (and host-name to validate) OR return something that behaves like one after dialing and validating an address. That way when the underlying library is re-linked to something modern it'll still have the same API / ABI but the underlying security implementation will belong with the updated library.
  - fulafel 6y ago
    That could indeed be an idea, if you can assume the SW can be rebuilt/linked against API compatible libs, and you rely on the API existing far into the future. The automatic CLI tool scouring option would allow you to hedge your bets over several implementations because of looser coupling.

by zmmmmm 6y ago

fulafel 6y ago

It's possible to engineer for this. The mental model: imagine you are equipping a time travel mission decades into the future, to integrate with the future internet, and to return home with acquired results. A TLS client is not possible to future proof like this of course, but you could have a roster of approaches. For example, try getting your hands on the latest curl / wget builds (try each with a few different approaches), or the latest JVM/Python/Powershell & use those TLS APIs. A fun game would be to try this with tools available 20 years ago, and then redo it to make a sw time capsule from present day to 20 years into the future...

mjevans 6y ago
A better approach is to have the "TLS" library accept either an already connected socket (and host-name to validate) OR return something that behaves like one after dialing and validating an address. That way when the underlying library is re-linked to something modern it'll still have the same API / ABI but the underlying security implementation will belong with the updated library.
- fulafel 6y ago
  That could indeed be an idea, if you can assume the SW can be rebuilt/linked against API compatible libs, and you rely on the API existing far into the future. The automatic CLI tool scouring option would allow you to hedge your bets over several implementations because of looser coupling.