7 min read

End of life (self-deprecating)

If you’ve ever played the video game Grand Theft Auto, you’ve felt it.

The thrill!

Crashing your car, robbing people, and doing much worse. Despite the game’s ethics (or thanks to them), GTA gets your heart going.

The gear for that kind of game is also a big draw. Not to mention the tech inside. New consoles packed with new power hit the market on the regular.

But new doesn’t mean it works with old.

If you’ve got a PS4 and your favorite game stops getting upgraded, you have to buy, beg, borrow, or steal a PS5 just to play the latest version, GTA V. Like the kindness of strangers, backwards compatibility can’t always be depended on.

Video streaming software gets updated too. Frequently the new release often does not support older operating systems. Often it’s a case of owners and/​or suppliers already ceasing support for an OS, so it makes little business sense for video streaming software developers to keep supporting it. But more on this later.

On January 10, 2023, in GA release version 1.12.1, Unified Streaming stopped supporting CentOS 7 and Alpine Linux 3.15. The release also let everyone know that soon, Debian 11 and Ubuntu 18 would also be deprecated. In the newest GA, 1.12.3, we have more updates and there will be more deprecations expected down the line.

Being deprecated is another way of saying a software version is being phased out. The curiously organic and morbid term ​“end of life” is another way of saying deprecation.

(We tried using the phrase ​“end of support,” but the word ​“end” is less the operative word than ​“support.” If we were to refer to deprecation as ​“end of support,” then the question would likely remain, ​“why not support?” Thus: ​“end of life.” Sometimes we use the acronym for end of life, EOL — as in ​“Ubuntu 18’s gonna be EOL’d.”

We also use the term ​“sunset,” as in: ​“We’re sunsetting (software OS).” Meaning: we’re gently guiding software into hospice care.

In our defense, we’re not the only ones. The manufacturer of the particular OS (Red Hat, Alpine, etc) also stops supporting its own software versions at some point, so we need to, as well.

So how do we communicate the imminent demise of certain software? Well, we try to give folks lead time, a heads-up, via email. And anyone who’s up on their ​“end-of-life fact sheet” at https://​docs​.uni​fied​-stream​ing​.com/​f​a​q​s​/​f​a​c​t​s​h​e​e​t​.​h​t​m​l​#​e​n​d​-​o​f​-life knows what software support changes are coming.

Here’s an excerpt from that fact sheet below that highlights differences between our end-of-life cycle and vendors’ end-of-life cycles.

“Unified Streaming Platform is available for various Operating Systems. For each OS, we generally aim to have two major (LTS, or long-term support) versions: the latest as well as the previous release. In general, this means that development on a particular OS release will cease before the OS vendor’s end of life of that OS release …

​“Customers using Ubuntu LTS should typically upgrade every 2 years, while Alpine — which is typically provisioned in an automated setting (i.e. kubernetes, docker, or LXC) — should re-provision at least once per year.”

But even if we recommended checking our end-of-life fact sheet every morning, every day of the year, including holidays, (which we’d never do, it’s a bit much to ask), to everyone who used our software, we can’t count on everyone staying current.

And that can prove a challenge, because software deprecation can impact people.

If you rely on an operating system that Unified no longer supports, then you can no longer benefit from bug fixes or new features in subsequent GA releases that apply only to operating systems that are supported. In a sense, if you’re on the wrong side of your OS version, you’re stuck where you are. Which is kinda like being stranded on the shoulder of the 10 freeway in Grand Theft Auto’s version of Los Angeles, watching open-mouthed as a muscle car loaded with bat-wielding gangsters pulls up behind you.

So what can you do?


Well, there are many ways customers can ease the process. You can:

1. Keep an eye out on release notes and the support roadmap. These will give clear signs on the direction we’re all heading.
2. Upgrade your OS regularly.
3. Consider whether the platform you chose a couple years ago is still the best option for you.
4. Automate machine provisioning and integration tests. On this point, here’s a note from our veteran software dev Tijn Porcelijn: ​“With computers being computers, it’s always a great idea to ​‘automate everything.’ Once provisioning, configuration, and testing are scripted, you’re on your way to ​‘just pushing a button’ and gaining confidence that your newly spun-up system is on par with the last one. And once pushing the button becomes a habit, the whole upgrade cycle no longer needs to be this scary ​‘cross your fingers and hope for the best’ kind of thing!”
5. Let us know if your road map doesn’t match ours.
6. Check our newsletter that contains EOL notices.

But isn’t software symbiotic, after all? Don’t we depend on you like you depend on us? Naturally. Yes.

So what can Unified do? Well, here’s the shortlist. We can …

1. Skate to where the puck is going. (Not literally. We’re geeks, not athletes. Though just try to beat us in a bike race to the other side of the country. We’re based in the Netherlands, after all.) We can try to understand what our customers want now, and what they’ll want in the future, better.
2. Be reliable. As best we can, we should leave the rug lying there nicely, and not pull it out from under people, especially if we promised not to.
3. Keep the costs down so we can offer support to as many targets as possible. At the least, we can strike a decent balance versus development velocity.

But it’s a challenge for each side of the dev process. Customers do the best they can, and so do we.

Here’s how we can illustrate one of the challenges we face, in terms of keeping things current. Check out an image of our build infrastructure on a typical day, below.

There’s just a huge number of build jobs running every time we commit, and the proportional number of machines to build and test artifacts for each target flavor.

Every time we change a single line of code we need to make sure that’s an improvement on *all* target platforms. That’s a lot of testing.

And every platform potentially has its own particular quirks and challenges.

In particular, the latest compiler toolchain may have fixed an issue on one platform. But if another platform uses an older toolchain, we cannot upgrade: we’re stuck with the lowest common denominator.

With a mature, stable C++ stack the speed of those changes is manageable. Still, in aggregate, supporting every single platform would significantly affect development velocity and complicate support.

Despite the mounting complexity, we will persist, like this nasty character in GTA V.

And we hope you’ll persist, too.

Want an external resource about end-of-life stuff, perchance? Check it out here: https://endoflife.date/. Handy to have. (It also helped explain why I need to stop trying to upgrade to iOS 16.4 on my iPhone 3G.)

By the way, I’m terrible at video games.
And knowing me, I’ll be terrible at video games till the day I die.
And now the blog title is justified!

Share