mastodon 4.7.3
A 95% solution is often worse than a 30% solution.
When you have a 30% solution, you know that you need to mix and layer solutions.
95% solutions often lead teams to waste time and effort trying to close the gap when mixing and layering would be less expensive and less complex. Or they can lead teams to do nothing, expecting that the solution will be finished someday.
Some distributions fight the idea that applications should specifically select compatible components, and it hasn't been working for over 30 years.
https://gordonmessmer.codeberg.page/dev-blog/2026/09/24/let-applications-select-dependencies.html
Due to the linear nature of time, software must exist before other software can depend on it. A shared component must be released before software can be ported. In this way, change flows through code like light or sound through their own mediums. This is the speed of compatibility.
Consequently, the version that is compatible tends to be older as it becomes more indirect. An app that uses a component directly may need a different release than one that uses it indirectly
https://gordonmessmer.codeberg.page/dev-blog/images/png/select-deps-branch-time.drawio.png
One of the biggest drivers of productivity improvements in software development is one of the least discussed: branching.
https://gordonmessmer.codeberg.page/dev-blog/2026/09/27/stable-independent-async.html
The Free Software concept was created by people who believed that copyright should not apply to functional work. The GPL is best understood as an attempt to use copyright to simulate a world without copyright.
I'm a little worried that a generation of admins has been conditioned to believe that a package manager is a substitute for a vulnerability scanner.
No pending updates != No vulnerabilities
Someday I hope to be able to describe technical concepts as clearly as this.
Thank you @samwho@hachyderm.io
It's much more accurate to see a free LTS release as the period during which you can participate, rather than the period during which your system gets support.
Despite the name, free LTS systems come with no support, and you should not assume that the packages you use and care about will be maintained unless you participate in their maintenance.
One of the things I love about Free Software is the pervasive spirit of collaboration and respect.
But at the same time, I think that we are failing our community by never discussing the trade-offs required for development processes like LTS distributions, because it sounds too much like criticism.
SeaGL is coming up and CfP is open. I don't see any talks in their last 10 years of archives that discuss the difference between LTS and regular release systems from a security point of view. I am finding that far more people than I expected believe that LTS systems offer better security.
Do you think such a talk would be interesting or useful?
I dropped a long section of that last blog in which I had described the importance of letting people work at their own pace to promote productivity, because I've said it so many times before, and I see now that was a huge mistake.
After managing production networks for 30 years, I believe that LTS systems exist to prioritize compatibility with the ecosystem in which they operate, whereas more recent releases will typically have the smallest number of known security flaws.
Apparently there are people who don't believe this?