Sven Slootweg @joepie91@pixie.town

And it's not exactly a *small* difference we're talking about here either:

As far as I can estimate, the issue seems to have started when Plasma started supporting HDR mode

Okay, am I imagining things or has someone else observed things going wonky with color balance in KDE Plasma on a multi-screen HDR setup?

I'm seeing a frankly absurd color difference between two identical monitors that are both in sRGB mode over an identical display protocol and that didn't exist in the past.

For a concrete example:

"Static typing will catch some subset of type errors at compile/build time" can be an objective truth; it is measurable and/or provable exhaustively within clear parameters.

"Static typing makes software more reliable" is an opinion. There are many factors that go into reliability, not all of which you may be personally aware of, and some of which may be mutually exclusive with static typing.

"Static typing makes programming easier because you see errors faster" is an opinion. There are different ways to get that kind of advantage, some of which may again be unknown to you and at odds with static typing.

And you may feel very strongly about those opinions, and you may well be able to cherrypick twenty different studies that seem to confirm it, but it is still just an opinion! You would need to have exhaustively evaluated every possible approach that could theoretically exist to consider it an *objective fact*, and nobody on this earth has done so (or likely will ever do so).

Basically, learn to say "I don't know" or "the best solution I've been able to find...".

I really dislike how shaky of a grip developers seem to have on the distinction between 'truth' and 'opinion', and how little care they often take to distinguish between the two in how they communicate.

You can measure objective truth for something with clear, exhaustive parameters and outcomes. You can't do so for something that's based in personal beliefs or limited perspective! And likewise, when there *is* an objective truth, it's not a matter of opinion either.

It's not a surprise that misinformation spreads so readily in software development circles, if you look at how eg. a lot of new programmers are constantly faced with 'senior developers' framing their personal preferences and conclusions as the ultimate and only truth.

Federation isn't always the right answer, when designing a self-hosted or autonomous software thing. Here are some reasons why it might not be (non-exhaustive):

1. Difficulty of moderation - you not only have to account for the users on your own service, but also that on every other service. This will be a familiar one to many fedi instance admins.

2. Difficulty of limit enforcement - if you're trying to keep the content size manageable by eg. introducing storage limits, it's hard to enforce these across the federation, as anyone can change the limits on their instance and it'd be weird if eg. large files are allowed from external users but not local ones. And blocking large external data is essentially partial defederation, and gets messy.

3. Protocol lock-in - the more interoperable instances you have of something, the harder it becomes to change anything in how it works, because everyone will have to agree with you on the change, at least to a point of compatibility.

4. Network traffic - content has to be distributed between servers, and that can generate quite a lot more traffic than you would expect. Not always a downside; it depends on whether the federated content is actually being accessed frequently on remote servers, because if so, you otherwise would've had to serve all those users directly. But this often isn't the case with opportunistic federation of data.

5. Context collapse - it is very difficult to provide a global network view across a federated network, at least in a way that doesn't use absurd amounts of resources. In practice everyone will usually only see a part of the network, and that can rip eg. conflicts out of their original context, causing them to escalate unnecessarily.

Note that most of these apply to fully-decentralized systems too (and those have some problems of their own); often the optimal solution is many self-hosted centralized instances, rather than full decentralization or P2P systems.

There are definitely some cases where federation still makes sense, like in a chat system where semi-universal reachability is the point, much like a phone network.

But federation isn't free; don't make something federated just because you can; often it's better to run many copies on single servers, and maybe just share an account or identity system, or some similar 'restricted' form of interoperability.