The usual convention for configuring listening interfaces usually involves listing IP addresses or interface names. There's very little room for misconfiguration here, although it's possible. More likely to be a bug in Snapcast (it's almost certainly not an issue in the Linux kernel).

Moreover, this general problem (i.e. configuring listening interfaces) is not/should not be different between IPv4 and IPv6. So introducing IPv6 should not™ incur any additional risk at this level.

But as said, it's hard to get more concrete without knowing exactly what happened in your case.

Since the introduction of flock on Linux, how bad is it really though? I don't see why one would need kludges like filename.lock. Though of course flock is still an "honor system" as you put it.

Note: I’m not asking for the Reddit armchair kvetching about the evils of modern capitalism and the failings of line-must-go-up. I’m wondering why, when serious financial decision-makers are involved, it makes sense to blow something up rather than steadily take profits over time, even if those profits aren’t always going up.

I was unaware of this, so thanks. Sounds like it addresses (pun intended) my concern.

> How does DHCPv6 hold back IPv6-mostly? First, most clients will send out a DHCPv4 request in case IPv4 is the only option, in which case IPv6-mostly can be signalled

It's not the signalling that's the problem--it's the configuration of the CLAT which requires SLAAC, afaiu. This is in fact the subject of the latest IPv6 Buzz podcast episode: https://packetpushers.net/podcasts/ipv6-buzz/ipb197-slaac-an...

That alone is significant.

Furthermore, DHCPv6 holds you back from various desirable things like privacy addresses and (arguably even more importantly) IPv6 Mostly.

But yeah, SLAAC's paradigm of moving assignment logic into the node (away from network infra like in DHCP) is definitely a stumbling point.

However, I think people do get tripped up by the paradigm shift from DHCP -> SLAAC. That's not something that is an inevitable consequence of increasing address size. And compared to other details (e.g. the switch to multicasting, NDP, etc.), it's a change that's very visible to all operators and really changes how things work at a conceptual level.

What makes you suggest that it's backbone hardware that is the problem? It's largely enterprise customers and tier 3 providers that don't really do IPv6 afaics.

But to stick with the ASCII->UTF-8 comparison: how would you have done the transition if you had to stay within ASCII's size of 7 bits?

I really don't miss this part of the Python world. When I started on backend stuff ~10 years ago, the morass of runtime stuff for Python webservers felt bewildering. uWSGI? FastCGI? Gunicorn? Twisted? Like you say, missing batteries all the way down, presumably due to async/GIL related pains.

Then you step into the Go world and it's just the stdlib http package.

Anyway, ranting aside, batteries included is a real thing, and it's great. Python just doesn't have it.