Don't ever mention PD 1.0, it's a cursed standard that was never actually used and that nobody should ever use. USB PD started with PD 2.0, and we shall never speak of the stillborn child that is 1.0
Sun is continuously running a very nice distillation cycle the size of the world that makes fairly clean water just fall out of the sky. It's only a question of where does it fall, and how much. If you want it even cleaner, wait a couple centuries for it to filter down underground, and get it from there - besides maybe a bit high mineral contents, that can easily be removed, it's essentially free, clean water. The only question is how much it's replenished in the area you're taking it from.
There's plenty of areas where there's more rainfall, than there is outflow/evaporation, with water continuously replenishing deep groundwater. "Saving water" in such areas is of little concern besides the basic, economic one of well maintenance - each one can only pull so much, and more usage means more wells, and more upkeep.
Youtube has been long normalizing videos standard feed, switching to a -14 LUFS target in 2019. But LUFS is a global target, and is meant to allow higher peaks and troughs over the whole video, and the normalization does happen on a global level - if you exceed it by 3dB, then the whole video gets it's volume lowered by 3dB, no matter if the part is quiet or not.
The stable volume thing is meant to essentially level out all of the peaks and troughs, and IIRC it's actually computed server-side, I think yt-dlp can download stable volume streams if asked to.
Companies that build themselves on selling open source software put themselves in the position where anyone else can copy them and compete with them on price, and price alone. This is clearly the disadvantage of open source. It brings plenty of advantages, which is why people do it - but you can't have only the advantages and no disadvantages of open source.
Open sourcing your product is a risky investment, and as with all risky investments, it might pay out, or it might not.
As I said before, I believe that using permissive licences is a bad idea. I have seen multiple projects choosing a permissive licence as a way to compete against an already established copyleft project, just because it's easier to get adopted by companies. I find it unfair but also a bit stupid: by using a permissive licence, they allow anyone to compete with them with a proprietary fork.
Still, there is an antitrust question (that is slightly orthogonal): if TooBigTech can offer a similar product at a loss (e.g. for free) until they capture the market, then that's a problem. And they can only do it because they are too big, and that is an antitrust issue IMO.
Hey, you now have a specific cost to point to when arguing for/against solutions that have this problem. "each deployment will cost us at least 12 specialist hours per year just replacing the certificates" is a non-negligible cost that even the least tech-minded people will understand, and it can be a good lever for requiring the support.
It's because S3 api is quite a fair bit worse than what they offer. They define their guarantees for storage products way more clearly than other clouds, and for blob storage, from my understanding, their model is better than S3.
It cannot route HDMI, partly because HDMI is built upon antiquated principles and doesn't really fit besides more modern protocol designs. USB4 would need to get entirely redesigned for tunneling native HDMI.
Having a DP to HDMI converter on one end though, that's easy.
HDMI uses a digitalized form of the traditional TV signals. The format of the transmitted data still depends on the parameters that defined traditional TV signals, like video frame frequency, video line frequency, vertical and horizontal retrace intervals and so on. Such parameters are no longer essential for digital television and there is no longer any need to constrain the transmission of video signals with them.
DisplayPort uses a typical communication protocol that can carry arbitrary data packets, not much different from the protocols used on USB or Ethernet.