The pain of running on LTS systems

Tools
1

I have been running some experiments on a Nvidia Jetson AGX Orin using the default Ubuntu OS (22.04), which is now four years old. These are the types of things I run into:

cbrake@vesta:~/tf$ npm install -g prettier
npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package: 'prettier@3.8.3',
npm WARN EBADENGINE   required: { node: '>=14' },
npm WARN EBADENGINE   current: { node: 'v12.22.9', npm: '8.5.1' }
npm WARN EBADENGINE }

One solution is to install an old version of prettier:

npm install -g prettier@2

However, this version formats slightly differently from the current version, so there are needless formatting changes going into Git if multiple people are working on something.

Perhaps the only practical solution is to containerize all shared tooling.

2

Our teams have settled on containers, and no “native” code. It seems we are in the process of generalising more and more, whenever the target maker imposes a specific OS fork.

Do you think the problem is specific to LTS systems?

—
This reminds me getting burnt with the AWS DeepLens device, forcing into U18. When AWS stopped selling the device (after a short couple years), it became time consuming to progress on simple tasks. Containers do help, but U18 is now EOL, despite the hardware being still quite usable.

3

It seems the entire software ecosystem is becoming like browsers, the only path is forward because it is a dynamic system. And running anything old where you want to move the application software forward is just pain.

Trying to keep an operating system pinned to an LTS release while continuously evolving everything on top is a bit like freezing a creature’s skeleton while expecting the rest of its body to grow and adapt around it. The structure may be stable, but over time the muscles, organs, and connective tissue stop fitting cleanly. Eventually, the mismatch creates friction, limits movement, and makes further growth harder instead of easier.

1 Like