But would you really store new material encoded in Vorbis just to be able to play it on an old device? Vorbis can sound fine, even at lower bitrates like 128k or 96k, but Opus would sound much better. So perhaps then use Vorbis at higher bitrates like +192k? I prefer Vorbis to Aac but at that bitrate minor intricacies of the container format become more important than the codec because audio quality wise they are near indistinguishable.

Why? Care to explain?

I have fully switched to opus for lossy since I cannot be bothered to find the sweet spot for aac encoders and bitrate. Opus simply is too good and convenient and has been for ages.

What other lossy codec is better and for what reason? Under what circumstances and use cases? I really need put effort in looking for edge cases to not choose opus.

Aac is good too, but way too many choices to make for storing mass material for the long term and be sure the quality is always good enough.

Still having a good quality and default aac encoder is great. Though I don't get why it is mainly CBR.

And if all the IPv6 endpoints of a major service go down we should pin our mtu to the bare minimum? Nonsense.

The inconvenient truth is that IPv4 will be more stable than IPv6 until the former gets demoted to second class fallback protocol instead of the major driver of the internet. And when that happens no one knows.

This happened with pypi (IPv6 BGP routing problem caused by a bad route from one of our peers combined with their fastly CDN not reply to us on IPv6 from the other side of the ocean for some weird reason), but also with yum and apt mirrors (seemingly random problems with the IPv6 service or firewall of the remote endpoint), and various other web resources accessed from pipelines.

The solution always was to temporarily block the bad IPv6 endpoint(s) or temporarily completely disabling IPv6 on the server itself or on the squid proxy server for workloads without direct connectivity.

Obviously it also can be the other way around, but in practice it appears to happen less often with IPv4, and if it does things get addressed quickly instead of taking hours or days or weeks.

This becomes noticeable when pipelines on IPv6 connected servers suddenly have random request/post failures to public services. Then either the whole service is temporarily having issues or there are a few bad IPv6 endpoints while all the IPv4 endpoints are fine.

Seemingly this failure mode can go unnoticed for days while the same won't be true for IPv4 due IPv4-only still being the norm for corporate networks. And no, current form of happy eyeballs v2 won't account for this.

Besides bad endpoints it could also be a problem with bgp route advertisements where the IPv6 prefix takes a weird path and ends up being blocked by a CDN at the other side of the ocean. This happens more than you'd think. Obtaining pypi packages was quite a challenge last year for us for a couple of weeks due to this.

Not really a fault of IPv6 technology wise, and in general can be solved client side through retry functionality, but in practice it still can lead to a worse outcome due to lackluster IPv6 adoption.

I used to think ISPs, organisations, admins and users were just being lazy for not implementing IPv6 or turning it off as the first thing to do when network problems happen, but when this far in the rollout such basic things still lead to difficult troubleshooting sessions then perhaps time has come to say something has gone terribly wrong.

It saddens me to say that I totally understand that businesses do not want to pay the price for implementing IPv6 unless absolutely necessary, because until the majority of traffic is IPv6 or even IPv6-only it does not make a lot of sense.

The flipping point is nearer than ever, though I fear it will in the short term lead to even worse stability for both protocols until IPv6 truly becomes the norm, whenever that may be.