Hacker News Reader

Comment by rcarmo | Hacker News Reader

You can use docker with it - I have a couple of things with "docker run" statements in the procfile, but of course it’s not designed for that.

Most of the deployments I got wind of are on extremely stable distros - typically LTS versions where you will not need to upgrade your runtime every six months (and my website has been running in it for at least two Ubuntu LTS releases…)

But you can trivially use pyenv/nvenv/etc. by just setting environment variables. My home automation system now needs two different Node versions, and I have one set per app.

View on HN

Oh yes, I definitely use LTS distros, but my longest-running apps are from 2008, so even LTS won't cover that.

That depends on your tech stack. I have Perl CGI and Java apps that have been running unchanged for two decades. And the only thing I ever had to change on Debian over that time was adding HTTPS (Let's Encrypt) and SPF/DMARC for email.

Yeah, but my point is that you have to upgrade your OS. If you never change anything, obviously you don't need to worry.

My point is that OS upgrades don’t have to break tech stacks, and don’t tend to with runtimes that care a lot about backwards compatibility like Perl and Java. I did regularly upgrade Debian across those two decades.

IMO that quality should be the default, and I would choose my OS and tech stacks accordingly.

Don't they link against static libraries? How do they do that?

The runtimes are part of the Linux distribution and get upgraded along with it (and receive continuous security updates along with it), while maintaining backwards compatibility for the application code (Perl scripts or Java bytecode). Tools like needrestart will notify when a process needs to be restarted to take advantage of the update.

Ah, all your dependencies are in the language you're using? Some of mine use dependencies that are written in compiled languages.

Not necessarily, but they are part of the Linux distribution.

Well, I don't know about you, but my dependencies have often been built against a static library from a different version of the OS, so they wouldn't work on mine.

OS updates are important sometimes. Security and all...

At -some- point you actually need to update things. If you're using a 2008 docker container you have all manner of bugs and security issues.

I agree. But 2008 is old enough that exploits may be lost in time. I recently pentested a client, and had great problems connecting to an old service still using SSL (i think it was 2.0). Every modern tool straight up refused to connect, there was no method to override that, oldest static curl binaries i could find were still too new, I couldn't easily compile curl from source because dependencies also changed in the meantime. Finally I've found sn acient docker image that worked.

The service was ironically so old that no modern vulnerability scanner or programming language would be able to connect!

This made me seeiously ponder the fleeting nature of modern world - SSL support was everywhere 15 years ago, and now I, as an expert, had great problems using it. What chance do we have in 100 years?

But at least the attack vectors are limited

yes, limited to those that work 100%!

Reply on news.ycombinator.com