As someone who uses Debian for their own home server I was interested in reading this person's experience, but they seem to have filtered it through an LLM which added a lot of words and not a lot of insight making it significantly less readable in the process.
Agreed - not only does the obvious LLM writing/editing make it hard to read, but the weird stylistic choice to have long sections where every single short sentence is its own line made the read even more grating.
I usually like blog posts about homelabs but came out of this one disappointed.
Ultra-low-sulfur diesel became mandated in 2006 as the only type that was legal to sell for road use. That requires extra refining to remove the naturally-occuring sulfur from the fuel which is why the cost went up.
The answer is pretty obviously AV1 if you care about delivering content to actual end-users, unless you expect them to be severely bandwidth constrained such that the ~30% improved efficiency makes a noticeable difference. AV2 is still not mature from an implementation perspective; I wouldn't consider it ready until at least the dav2d software decoder has had time to mature, which the project page implies is still in a fairly early stage of development (they still list "complete C implementation of the decoder" as "on-going": https://www-test.videolan.org/projects/dav2d/) and I am not sure if any encoder exists besides the AOM reference implementation (which was notoriously slow for AV1, so I assume the same for AV2). Furthermore it will be years before hardware AV2 decoders and encoders make their way into consumer products (this will likely be further delayed with the current shortages of memory and storage chips causing hardware lifecycles to be extended even more than they already had been over the past decade).
Why shouldn't they get 6 MHz? My PBS station broadcasts 4 subchannels: the main PBS channel, PBS Kids, a channel with programming about our local region (which airs live coverage of our state legislature when it's in session), and a loop of weather information with audio from the local NOAA Weather Radio broadcast. Those are all useful public services. PBS Kids in particular I think has a very good reason to exist, considering the absolute wasteland that is young children's media on streaming.
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.
The solution to this is so simple that it would blow your mind. In regulated industries in the U.S. there is a law called "Know Your Customer" (KYC). If businesses actually made an effort to know their customers, they would not have any issues at all.
The real issue is that everyone scrambles to make a sale, and nobody stops to determine if they should actually make that sale. Funny enough, I blame all of this on marketing and sales.
I wonder if this could be pitched as a money-making scheme. As you have financial products that aren't for sale but to qualified buyers...
Force businesses to only sell to qualified buyers and make it incredibly easy for businesses to qualify buyers at the lowest possible cost. The end result in my fantasy world is that a business ends up with some document, some self attestation, that they've educated the customer. The benefit that actually matters much more than the attestation no one should ever see would be the educated customer.
Clearly, this is way too much just for a little storage.
But I also would be curious to know if there's another customer qualification concept like this. (And I just thought of one. Scuba diving! Customer pays to learn, otherwise you're in deep (reputational) doodoo when they drown.)
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.
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.
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...).
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).
> 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.
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).
You literally just told me the market doesn't care about quality. I don't get what point you're trying to make?
> 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
Right, but this magical market you're talking about doesn't exist. That's my point.
Have you seen Facebook's code quality? Have you seen any-big Chinese corpo code? There are a lot of very profitable businesses in the world with endless amount of tech debt. But tech debt is not necessarily a big deal in most scenarios. Obviously I'm not talking about mission critical software, but for general consumer/business software, it's fine. The hard part is understanding where you can cut the costs / add debt, and that comes from requirement gathering.
