Brief items

The Cellmate chastity lock works by allowing a trusted partner to remotely lock and unlock the chamber over Bluetooth using a mobile app. That app communicates with the lock using an API. But that API was left open and without a password [...] it may require the intervention of a heavy-duty bolt cutter or an angle grinder to free the user.

We have knowingly and willingly built the architecture of a police state, just so companies can show us ads.

I understand that this situation could be quite frustrating, but we can only expect a memory model to model memory. Its job is to help us understand what can work and what will not work from a memory-ordering perspective, which at best will provide you with the options that you seem to be so dissatisfied with. The memory model is quite incapable of browbeating intransigent human beings into agreeing on which option should be used in a given situation. This last never was a requirement of the LKMM project. Please rest assured that it will remain a non-requirement.

That is getting to be a fairer comparison. But we still are not comparing only package manager differences. In fact, this comparison is heavily skewed towards how a distribution chooses to package the software. Pacman appears at a disadvantage, because Arch packages all files for the software in a single package, and does not split binaries, libraries, docs, include files, etc into separate packages. That is a distribution decision, and not a package manager decision – all package managers in the comparison list are capable of splitting packages into smaller units. So maybe not apples to oranges, but rather oranges to orange segments? I don’t think I am good at analogies!

Firstly it’s for designers, so they no longer have to suffer through countless hours of trying to build software themselves, in order to test the latest development versions of some of our core modules (most notably GNOME Shell). Tightening that feedback loop is incredibly valuable for delivering a polished product. After that, it’s for the release team, so it can validate releases before slinging them out the door; for developers and translators, so they can have a complete system to test and debug their changes on; for our downstream distributors and OS vendors, so that they can have a known to be working baseline against which they can compare their own products. Last but not least, it’s for the machines and robots that keep an eye out for regressions.

Enjoy GNOME OS!

I suspect the above example of focus/activation requests will ultimately be addressed by a token exchange via Wayland, and the notification spec way of doing things will be implemented alongside it as well, rather than picking one way of doing things. And perhaps that's fine.

But it's worth stopping for a moment and being conscious of what's going on. We would all benefit from some commonly agreed-upon guidelines on where the scopes of Wayland and D-Bus end in our application platform, and where they overlap. Where does the windowing system start and end? Where should new protocols go? We also want to be smart in spec'ing out how the two mediums relate to each other, and making translations from one of the other safe and robust.

Technologists have failed to listen to non-technologists. In technological circles, there’s a quantitative fallacy that if you can’t do maths on it, you can just ignore it. And so you just incinerate the qualitative elements and do maths on the dubious quantitative residue that remains. This is how you get physicists designing models for reopening American schools – because they completely fail to take on board the possibility that students might engage in, say, drunken eyeball-licking parties, which completely trips up the models.