Membership in the libvirt group is root-equivalent, not a permissions fix. Through qemu:///system it lets you attach arbitrary host block devices to a VM, so anyone in that group can mount and read the host's own disk. If you want to manage VMs without root or that group, use qemu:///session instead: unprivileged, images live under ~/.local/share/libvirt, no sudo. Tradeoff is you lose bridged networking without a setuid helper.
Consensus is one of those areas where the interesting engineering and the number of
people who actually need it are inversely correlated. Most "we need distributed
coordination" turns out to be "we need one writer and a lock," which a single
Postgres hands you for free: advisory locks, SELECT ... FOR UPDATE, SKIP LOCKED for
work distribution. Linearizability without running Raft..
The real threshold is multi-region writes on a hard latency budget, and even then a
single-region primary plus accepting cross-region read latency beats eating a
consensus round-trip on every write for a lot of teams. Curious what workload pushed
you past single-primary - usually a better story than the impl itself.
> This article is about Cloudflare developing for their own internal control plane--I'm fairly certain their requirements preclude a single Postgres.
True, but the article claims both strong consistency (sort of) and linearizability; that is basically a serializable writer and a lock; if I read correctly (I haven't read all the details), the article conflates both; afaik it is possible to have linearizability with eventual consistency; algorithms to solve concurrent writes and having multiple writers in raft is a "solved problem". sad to see such a spotty article on such important topic by a major company, even if the underlying paper is strong. This feels like manure.
Are you arguing that most teams that recognise a need for a distributed system chicken-out and use a single node instead, and if so, is that a good thing?
