duffsdevice

> and OBS found out independently and are working to resolve it

What has OBS to resolve there? They could send a letter with an offer for a special license for one million dollars. If all open source contributors agree on thqt and have worked out how to share the fee.

This is a surprising feature of the Conan C++ package manager: It allows to specify dependencies of packages, and also to specify ranges of dependencies, but it does not provide any way to automatically resolve them. The responsibility for the resolution is with the resulting application at the top of the graph, it has to provide version numbers or ranges for all conflicting dependencies, regardless how deep thy are in the dependency graph.

Here some more information:

https://docs.conan.io/en/1.22/versioning/version_ranges.html...

See also:

https://github.com/conan-io/conan/issues/9547

I think dependency resolution in systems of networked software is a tough problem, and I believe there is only one solution that will scale well enough: Requiring strict backward compatibility on every level.

If you think that there is another way, consider this:

Application A requires dependencies D1.0 and E1.0. Both D and E require a library L1.0 , thus we have a "diamond dependency structure". And as it is C++, let's assume that L is either dynamically linked, or has versioning requirements that are visible outside, for example data formats.

Now, L1.0 makes a breaking change, and, not following semantic versioning, labels the new version as L1.1. This could be a library like boost, which is used by many thousands of applications.

Now, let's assume that D1.0 has an urgent security vulnerability (may be it is related to logging ?) and ships a new emergency release D1.1, which happens to use L1.1. And let's assume that D is well tested with that. But the incompatible change in L1.1 happens to break E. And this means that application A cannot be upgraded, unless E is adapted to L1.1. And the net effect is that the breaking change in L1.1 causes a breaking change in D1.1, because the change in D breaks A. Nothing is achieved by shifting the blame for that to A that it uses such an old library L1, it is still the change in D that breaks A, so *D is not backwards compatible*.

The corollary is that if your library D includes another library L as a dependency which introduces a breaking change, and that library is visible to the outside (that is, not statically linked and only internally used), then the breaking change in L causes a breaking change in your library D. This means that being backwards incompatible is a transitive property - you only achieve backwards incompatibility in a system if every relevant part of it is backward compatible.

I have also left Python for projects where I can chose the tools, but I have not stuck with Go. I went to Racket which has much like Python a "Batteries included" feeling, it is a very easy language with a lot of power and a really good JIT compiler. For me, it is perfect for exploration and algorithm design. For example, I could develop an algorithm in Racket and easily port it to C++11 which was what the client / employer ultimately wanted - still having a much quicker total development time.

For things that are performance-critical or require high reliability, I have successfully used Rust, even if I am still much slower writing it. One thing I like is that the resulting code is not more verbose. Which also means that it is easy to read even after months of not touching it.

The thing is, if the virus evolves to spread better amoung vaccinated people, and the large majority of the members of a population have immunity from vaccination or infection, as is the case in South Africa, there is no evolutionary pressure that the virus becomes less lethal for unvaccinated and immunologically naive people.

It could as well become more lethal for them, or certain new age groups within the unvaccinated group, without that hindering spread among the other parts of the population.

> am micromanaged,

Book tip: "My Way or the Highway: The Micromanagement Survival Guide", by Harry E. Chambers.

It is a quite frequent problem in tech. And no, you are not likely to change it. And yes, it is very bad for mental health. Don't wait too long.

One interesting insight from the book is that being subjected to micromanagement is somewhat correlated to having grown up with very critical parents. It is essentially a form of unhealthy power play.