Solution Smith

A promise of stability and the bleeding edge - Have your cake and eat it too.

If somebody does a deep dive into why systems become unstable, they quickly understand why software development companies do not automatically update their systems.

Software developers often work around an issue they find in a library. But when it is patched, the work around is no longer needed and the work around may become a problem. Hence the phrase "broken on next release."

It should be noted that Windows OS does not address the issue. On Windows user can find themselves in the situation where two programs can not run on the same machine because they conflict over a DLL version that is required.

Solutions to "broken on next release"

1> The first solution is robust testing of libraries before they are put into use. The branding for the Ubuntu distributions of Linux is associated with using libraries that have matured to a high degree of stability.

2> The Flatpak and Snap, solutions are to incorporate the libraries required for the program, which may be on the bleeding edge, with the application. The required libraries are only used by that application within the flatpak package and don't become part of the enviroment affecting other programs.

3> Immutablity in the operating system: A system that runs programs in a (virtual machine / container) or an immutable OS, runs applications with their required libraries. But the OS itself is unchanged. One can safely approach the bleeding edge without falling off the edge.

Vanilla OS applies all three solutions

If your use case pushes toward the bleeding edge, Vanilla OS should be something you consider as you can put in the libraries you need, use flatpaks and snaps for programs that require libraries you don't want, roll back without needing to start from scratch, and containers for programs that require the bleeding edge.