[unethical_ban]

Arguably, no one should be running a server that long in 2020.

I would say a better reason is that while both are Linux distributions, they are distinct dialects and ecosystems. It isn't impossible to switch, but for institutions that have complex infrastructure built around the RHEL world, it is a lot of work to convert.

[chousuke]

It's not really about running servers for 10 years. It's about having a platform to build a product on that you can support for 10 years. RHEL software gets old over time, but it's still maintained and compatible with what you started on.

Consider an appliance that will be shipped to a literal cave for some mining operation. Do you want to build that on something that you would have to keep refreshing every year, so that every appliance you ship ends up running on a different foundation?

[brandonmenc]

> Consider an appliance that will be shipped to a literal cave

This.

A decade ago I was technical co-founder of a company [0] that made interactive photo booths and I chose CentOS for the OS.

There are some out in the wild still working and powered on 24/7 and not a peep from any of them.

We only ever did a few manual updates early on - after determining that the spotty, expensive cellular wasn't worth wasting on non-security updates - so most of them are running whatever version was out ten years ago.

Rock solid.

[0] https://sooh.com

[deckard1]

The "don't touch it if it's not broken" philosophy is fundamentally at odds with an internet-connected machine.

You either need to upgrade or unplug (from the internet).

There are still places out there that are running WindowsNT or DOS even. Because they have applications which simply won't run anywhere else or need to talk to ancient hardware that runs over a parallel port or some weird crap like that. These machines will literally run forever, but you wouldn't connect it to the internet. Your hypothetical cave device would be the same.

Upgrading your OS always carries risk. Whether it's a single yum command or copying your entire app to a new OS.

Besides, if you're on CentOS 8 then wouldn't you also be looking at Docker or something? Isn't this a solved problem?

[chousuke]

The point is the amount of "touching". Applying security patches to RHEL is still a change, but it's significantly less risky than upgrading a faster-changing system where you might not even get security patches at all for the versions of software you're using unless you switch to a newer major version.

[effie]

"don't touch it if it's not broken" is not a philosophy, it is a slogan. Some people say it, because it is preferable to them to run old unpatched vulnerable systems rather than spend resources on upgrades. That's just a reality. Some care about up-to-date, some don't. Most people don't really care about security, and some of those don't care even about CYA security theatre. If they did care about security, they wouldn't run unverified software downloaded from the Internet.

Why Docker has anything to do with this discussion?

[effie]

I think it is mostly about running servers (standard services that don't change much) for 10 years (and more). You don't need 10 year LTS distribution for building a product. You take whatever version of OS distribution you like, secure local copy should the upstream disappear, and vendor it into your product and never deviate from it.

[dmix]

I'm assuming this involve upgrading the application often as well?

[NotHereNotThere]

OK I'll bite..

How would I run our SAP ERP apps/databases without "running servers that long"?

[unethical_ban]

Of course there are use cases, but _ideally_, most workloads are staged, deployed, and backed up in such a way that it is a documented, reproducible procedure to tear down an instance of a server, rebuild, and redeploy services.

And while it may be cumbersome or cause some downtime or headaches if that isn't the case, I find the very need of doing it once every 1-3 years forces your hand to get your shit together, rather than a once per decade affair of praying you migrated all your scripts manually and that everything will work, as your OS admins threaten your life because audit is threatening theirs.

[effie]

How many simultaneously running machines can you keep updating with this method? If you run non-trivial workloads for hundreds of customers, this becomes high maintenance system already with two machines. It takes ages to upgrade all applications, then validate everything works, then actually migrate with no downtime.

[petepete]

Run them on Kubernetes in GCP with a containerised DB2!

[joana035]

> Arguably, no one should be running a server that long in 2020

The main reason people choose Linux is due to its stability.

It is totally ok to run servers in 2020.

Also your statement seems the default cloud vendor lingo used to push people to adopt proprietary technology with high vendor lock-in.

[mdeeks]

I think they only meant "that long". In other words, not for 5+ years without an upgrade. Not that you shouldn't run them at all.

Not everything can be highly ephemeral or a managed service, so running servers yourself is totally okay like you said.

[joana035]

You are right, I misunderstood his message.

[that_guy_iain]

Honestly, 10 years is a long time for a server. I would be honestly surprised if a server lasted 10 years.

But I agree I also get the tone of "servers should be cattle and not pets, just kill them and build a new one". Which can also be done on bare metal if you're using vms/containers. It seems like most people forget these cloud servers need to run on bare metal.

[bcrosby95]

Really? We've colocated our servers for the past 18 or so years.

We have about 40. The oldest is around 17 years old. Our newest server is 9 years old. Our average server age is probably around 13 years old.

The most common failure that completely takes them out of commission is a popped capacitor on the motherboard. Never had it happen before the 10 year mark.

Never had memory failure. Have had disk failures, but those are easy to replace. Had one power supply failure, but it was a faulty batch and happened within 2 years of the server's life.

[that_guy_iain]

The last time I worked with a ~8 year old server, it used to go through hard drives at a rate of 1 every 2 months. While we could replace them easily and it was RAID so there wasn't any data loss, I personally would've got fed up of replacing HDDs every couple of months.

Also, most of my experience is with rented dedicated servers and they just give me a new one completely so I never really see if they're fully scrapped.

[bcrosby95]

We haven't had any hardware failures - hard drive or otherwise - in the last 5 months.

[moonbug]

>Arguably, no one should be running a server that long in 2020.

That's mental.

[Karunamon]

My read on that is that you should be treating your servers as disposable and ephemeral as possible. Long uptimes mean configuration drift, general snowflakery, difficulties patching, patches getting delayed/not done, and so forth.

Ideally you'd never upgrade your software in the usual way. You'd simply deploy the new version with automated tooling and tear down the older.

[hibbelig]

I don't get this. If there are many servers, sure. But if it's something that runs on a single box without problem, why on earth should I tear it down?

Also, "running a server for ten years" does not need to mean that it has ten years of uptime. I think that wasn't meant.

[moonbug]

Ten years of uptime seems neither an unreasonable nor unattainable requirement. There's more to computers than mayfly web startups.

[hibbelig]

If it's not connected to the Internet, okay.

If it is connected to the Internet, then I guess the kernel needs to be hot-patched need to be applied to avoid security issues.

Were hot kernel patches available ten years ago? I remember some company who did this (for Linux), and it was quite a while back, so it's possible. But I doubt it was mainstream.

I recall long ago that SunOS boxes had to be rebooted for kernel patches.

I don't remember about Solaris.

I'm not familiar with other Unices.

[moonbug]

ksplice, and it's an Oracle product

[NDizzle]

"Ideally" - that's the problem. I have half a dozen long tail side projects running right now on Centos 7, and a few still on Centos 6.

Do you have any idea how much effort it is to change everything over to "treating your servers as disposable"?! It's going to eat up a third (to half) of my "fun time" budget for the foreseeable future!

[effie]

Exactly, young devs here are completely out of touch with operations. Of course ideally something like standard 1TB HDD+32GB RAM system would be upgraded to newer OS and apps version by a central tool in 2hours, but we don't such FM technology yet.

[cat199]

> automated tooling

the 'usual way' is automated tooling