Or they're selling their product to a market where the purchaser doesn't understand how much they would need to pay if they were paying by the gigabyte (or even how to check how much they would need). Telling those people they don't need to worry about that "detail" is a key selling point. Backblaze has a product for people who understand the limitations of their consumer product and don't find them acceptable: B2, which is priced by the gigabyte.
Only the asymmetric portion of the cryptography (which is only used in the handshake) will need to use PQC algorithms. Symmetric crypto algorithms (AES/ChaCha20/SHA-*), which are used after the handshake, are not as badly affected by quantum computing so they're not being replaced in the immediate term. I'm pretty sure that general purpose CPUs do not have hardware acceleration for the asymmetric crypto anyways.
This page lists some figures for ML-KEM-768 (which is the PQ key exchange algorithm that's most widely deployed today): https://blog.cloudflare.com/pq-2025/#ml-kem-versus-x25519 This one is actually faster than X25519 (a highly optimized ECC algorithm) by about double but requires 1,184 bytes of data to be exchanged per keyshare vs 32 for X25519. In practice everyone today is using a hybrid algorithm (where you do both ECC and PQ in case the PQ algorithm has an undiscovered weakness) so an ECC+PQ key exchange will be strictly slower than an ECC-only key exchange.
This page lists some numbers for different PQ signature algorithms: https://blog.cloudflare.com/another-look-at-pq-signatures/#t... Right now the NIST has selected three different ones (ML-DSA, SLH-DSA, and Falcon a.k.a. FN-DSA) which each have different trade-offs.
SLH-DSA is slow and requires a large amount of data for signatures, however it's considered the most secure of the algorithms (since it's based on the well-understood security properties of symmetric hash algorithms) so it was selected primarily as a "backup" in case the other two algorithms are both broken (which may be possible as they're both based on the same mathematical structure).
ML-DSA and Falcon are both fairly fast (within an order of magnitude of Ed25519, the X25519 curve signature algorithm), but both require significantly larger keys (41x/28x) and signatures (38x/10x) compared to Ed25519. Falcon has the additional constraint that achieving the listed performance in that table requires a hardware FPU that implements IEEE-754 with constant-time double-precision math. CPUs that do not have such an FPU will need to fall back to software emulation of the required floating point math (most phone, desktop, and server CPUs have such an FPU but many embedded CPUs and microcontrollers do not).
The net result is that TLS handshakes with PQ signatures and key exchange may balloon to high single- or double-digit kilobytes in size, which will be especially impactful for users on marginal connections (and may break some "middle boxes" https://blog.cloudflare.com/nist-post-quantum-surprise/#dili...).
Post-quantum algorithms tend to be slower than existing elliptic curve algorithms and require more data to be exchanged to provide equivalent security against attacks run on non-quantum computers.
Along similar lines, Mozilla recently updated their recommended server-side TLS configuration to enable the X25519MLKEM768 post-quantum key exchange now that it's making it into actually-deployed software versions: https://wiki.mozilla.org/Security/Server_Side_TLS At the same time they removed their "old client" compatibility profile as newer TLS libraries do not implement the necessary algorithms (or at least do not enable them by default) and slightly tweaked the "intermediate" compatibility profile to remove a fallback necessary for IE 11 on Windows 7 (now Windows 10 is the minimum compatible version for that profile).
Users care about quality, even if the people buying the software do not. You can't just say "well the market doesn't care about quality" when the market incentives are broken for a paricular type of software. When the market incentives are aligned between users and purchasers (such as when they are the same person) quality tends to become very important for the market viability of software (see Windows in the consumer OS market, which is perceptibly losing share to MacOS and Linux following a sustained decline in quality over the last several years).
> This obviously doesn't represent all of the billions of dollars spent on software like Salesforce, SAP, Realpage, Booking.com, etc. etc. (all notoriously buggy, slow, and complex software). You can't tell me with a straight face that all of the thousands of developers who develop these products/services care deeply about the quality of the product. They get real nice paychecks, benefits and put dinner on the table for their families. That's the market.
Those first three are "enterprise" or B2B applications, where the person buying the software is almost never one of the people actually using the software. This disconnect means that the person making the buying decision cannot meaningfully judge the quality of any given piece of software they are evaluating beyond a surface level (where slick demos can paper over huge quality issues) since they do not know how it is actually used or what problems the actual users regularly encounter.
Every generation of the production Nissan Leaf has used lithium batteries. AFAIK no modern (~post-2000) mass-produced (>10k units sold) EV has ever used NiMH or lead-acid batteries.
Edit: Checking Wikipedia to verify my information, I found out that Nissan actually sold a lithium-battery EV in 1997 to comply with the same 90s CARB zero-emissions vehicle mandate that gave us the GM EV-1: https://en.wikipedia.org/wiki/Nissan_R%27nessa#Nissan_Altra
> Are you saying that if I'm using D-without-GC, I can use any D library, including ones written with the assumption that there is a GC? If not, how does it not fracture the community?
"Are you saying that if I'm using Rust in the Linux kernel, I can use any Rust library, including ones written with the assumption they will be running in userspace? If not, how does that not fracture the community?"
"Are you saying that if I'm using C++ in an embedded environment without runtime type information and exceptions, I can use any C++ library, including ones written with the assumption they can use RTTI/exceptions? If not, how does that not fracture the community?"
You can make this argument about a lot of languages and particular subsets/restrictions on them that are needed in specific circumstances. If you need to write GC-free code in D you can do it. Yes, it restricts what parts of the library ecosystem you can use, but that's not different from any other langauge that has wide adoption in a wide variety of applications. It turns out that in reality most applications don't need to be GC-free (the massive preponderance of GC languages is indicative of this) and GC makes them much easier and safer to write.
I think most people in the D community are tired of people (especially outsiders) constantly rehashing discussions about GC. It was a much more salient topic before the core language supported no-GC mode, but now that it does it's up to individuals to decide what the cost/benefit analysis is for writing GC vs no-GC code (including the availability of third-party libraries in each mode).
Yeah, AV1 is primarily based on what Google was working on for their own successor to VP9, what would have been VP10, with technology contributions from Mozilla/Xiph's Daala and Cisco's Thor codecs.
ATSC 3.0 has a new modulation scheme with more robust error correction and modern codecs, but it will take years for people to upgrade and for ATSC 1.0 to be phased out. Here's a video giving a preview of how 3.0 compares to 1.0 in real world conditions: https://www.youtube.com/watch?v=lgIm01Tsmt4
Though most broadcast stations have sub-channels which eat some of that bandwidth. In my market, almost every station broadcasts at least 3 video channels. A few of them even manage to squeeze 6(!) into their 20 megabits (which would be fine with modern codecs, but ASTC 1.0 is stuck with MPEG-2).
Furthermore, leaving it out in the open allows it to spread. There's good evidence that "de-platforming" is highly effective at preventing the spread of hate.