> I'd rather it stayed on Github so it doesn't disappear. Particular for businesses whose priorities might change.

People can delete projects from GitHub. Businesses whose priorities might change may not keep an old project set to public up on GitHub because they won't want people to continue contacting them for support, or they don't want to be responsible for updating security vulnerabilities for projects they are abandoning so they'd rather just pull it offline, etc.

Whether the library you're importing is hosted on GitHub or not, never assume it will be there tomorrow. *Always vendor your dependencies.*

I believe they'd also be cached by proxy.golang.org? But companies should probably run their own proxy.

Yes, electrostatic speakers are a good example. Also a lot of PC motherboards I've had over the years have had the little piezoelectric speaker. And while still magnetic, there are planar magnetic speakers which are much more like electrostatic speakers (just using a magnetic field instead of electric field) than the typical moving coil / dynamic speaker drivers that you think of.

This guy knows speakers.

I have a pair of Magneplanar speakers. They always impress people.

> The practical benefit of FIPS 140 is less that your crypto is better and more that your systems will fail to establish connections with anything not using FIPS mode, thus reducing your threat exposure.

No, I don't think so.

If I'm running, say, a TLS listener (an HTTPS web server), there is no way for you to tell if I'm using a FIPS-validated implementation of the algorithms or not. I can be using a cipher suite that is allowed by FIPS, but that doesn't mean my implementation is FIPS-validated. It's not like there's a "FIPS validated and FIPS mode enabled" flag added to the TLS spec, and even if there was, there'd be nothing stopping me from setting it to true even when using a non-validated implementation.