I know this because I wrote a Unreal Engine texture repacking tool with a "DXT detection" feature so that I wouldn't be responsible for losing DXT compression on a texture which had already paid the price, only to find that this situation was already hyperabundant in the ecosystem.

Many Unreal Engine games of the day could have their size robotically halved just by re-enabling DXT compression in any case where this would cause zero pixel difference. This was at a time before Steam, when game downloads routinely took a day, so I was very excited about this discovery. Unfortunately, the first few developers I emailed all reacted with hostility to an unsolicited tip from what I'm sure they saw as a hacker, so I lost interest in pushing and it went nowhere. Ah well.

Carriers don't need 6GHz for backhaul. They have fiber and cable and (other) microwave. Not to mention the ability to shape their own links with antennas and beam forming and do a good job of it rather than a "default job." What they don't have -- and shouldn't be given under any circumstances -- is the excuse to build a moat in the bustling public park.

As for most efficient use of the resource, well, consulting my spectrum analyzer, ISM bands are winning by a mile and we should want more of them.

EDIT: the rush of people offering up sieve optimizations is pushing me back towards formulating the rule of thumb on a consecutive block of numbers, since it makes it very clear that these are not included, rather than implicitly or explicitly including some subset of them (implicit is bad because opacity, explicit is bad because complexity).

Rule of thumb: Want a 1024-bit prime? Try 1024 1024-bit candidates and you'll probably find one. Want a 4096-bit prime? Try 4096 4096-bit candidates and you'll probably find one.

The approximate spacing of primes around p is ln(p), so ln(2^1024) = 1024*ln(2), and ln(2)=0.693 so if you are willing to absorb 0.693 into your rule of thumb as a safety margin you get the delightfully simple rule of thumb above. Of course, you'll still want to use a sieve to quickly reject numbers divisible by 2, 3, 5, 7, etc, and this easily rejects 90% of numbers, and then do a Fermat primality test on the remainders (which if you squint is sort of like "try RSA, see if it works"), and then do Miller-Rabin test to really smash down the probability that your candidate isn't prime. The probabilities can be made absurdly small, but it still feels a bit scandalous that the whole thing is probabilistic.

EDIT: updated rule of thumb to reflect random candidate choice rather than sequential candidate choice.

My list would be: 1. FDR, 2. Carter, 3. Teddy. Carter because he sacrificed his career to fix inflation (Republican attempts to rewrite history notwithstanding), and Teddy because he wasn't merely an excellent man with excellent politics, but also because whenever present-day Republicans try to claim the man without claiming his politics I can turn it into a teachable moment, and putting him on a list with the other two is the perfect bait.

Routers are going to be a bit more expensive and a bit less reliable for a while. We'll live.

If I go to https://www.google.com using Chrome and Inspect > Security, I see it is using X25519Kyber768Draft00 for key exchange. X25519 is definitely ECC and and Kyber is being used for key encapsulation (per a quick google). I don't know to what extent it can be used independently vs it's new so they are layering it up until it has earned the right to stand on its own.

I was going to include the digits for comparison, but yes, on second thought 6002 digits is probably too much for polite inclusion in a HN post.

2^255-19

This is where Curve 25519 and the associated cryptography (ed25519, x25519) gets its name from. Written out, 2^255-19=57896044618658097711785492504343953926634992332820282019728792003956564819949.

Is there?

10 years ago, I burned about 6 months of project time slogging through AMD / OpenCL bugs before realizing that I was being an absolute idiot and that the green tax was far cheaper than the time I was wasting. If you asked AMD, they would tell you that OpenCL was ready for new applications and support was right around the corner for old applications. This was incorrect on both counts. Disastrously so, if you trusted them. I learned not to trust them. Over the years, they kept making the same false promises and failing to deliver, year after year, generation after generation of grad students and HPC experts, filling the industry with once-burned-twice-shy received wisdom.

When NVDA pumped and AMD didn't, presumably AMD could no longer deny the inadequacy of their offerings and launched an effort to fix their shit. Eventually I am sure it will bear fruit. But is their shit actually fixed? Keeping in mind that they have proven time and time and time and time again that they cannot be trusted to answer this question themselves?

80% margins won't last forever, but the trust deficit that needs to be crossed first shouldn't be understated.

Sure, let's turn down the temperature.

> youre being flippantly dismissive to the point of shading instead of illuminating

Let's turn down the temperature.

> I wouldn't be excited to have either Australia ... or Chile ... as my sources

China is even less excited than you are to have Australia and Chile as their sources. Eliminating a small pain from the USA and a big pain from China gives a net benefit to China, so it's weird to see it advertised as a net benefit for the USA.

That said, raw material availability isn't the limiting factor here. We probably shouldn't even be discussing it.

> requires discussion about new battery chemistry supply chains to only discuss lithium-ion (??)

That's the alternative Na-ion has to beat. We could build lithium refining and manufacturing capacity in the US sphere of influence. Evaluations of any new technology should compare it to the best available alternatives, yes?

https://www.isi.fraunhofer.de/en/blog/themen/batterie-update...