johncolanduoni

Why would he stress about a theoretical inefficiency that has very little effect on the finished product or development process? Especially one that could be rectified in a weekend if needed? The game industry is usually pretty practical about what it focuses on from a performance perspective with good reason. They don’t build games like they’re demosceners min-maxing numbers for fun, and there’s a reason for that.

I also wonder how many people who sing the praises of an HTML file with a script tag hosted by Nginx or whatever have ever built a significant website that way. There’s a lot of frustrating things about the modern JS landscape, but I promise you the end results were not better nor was it easier back before bundlers and React.

I’m circumspect that anyone knows how it’ll play out. I think there’s strong evidence a correction is coming, but some talking head is predicting it’s going to be this week every week, and have been for a while. Nobody has convinced me it’s likely to look like the Great Depression yet.

I also think the circular dealing fears in particular are overstated. Debt financing that looks like this is common in semicon, and I doubt there are any serious investors that haven’t already priced it in. If the bust is fatal for AI investment, it’ll just be bankrupt companies owing money to other bankrupt companies.

> The point about Solow's Paradox is that the gains of certain high productivity technologies do not provide society-wide economic benefit

Some people certainly argue that about the computer age, and it’s not totally unsupported. But I don’t think the evidence for that interpretation (as opposed to a delayed effect) is strong enough that I’d want to automatically generalize it to a new information technology advance.

To be clear, I don’t think China’s reticence is necessarily wrongheaded. But “we will usher in an age of undisputed dominance in a decade or two instead of right now from this investment” is a weird argument, especially from a government as ostensibly long-term focused as China.

Okay, but it’s a web game. Those will make up less than 0.1% of the downloaded bytes required to render the first frame of the game. One image asset will dwarf the entire gzip/brotli Next.js/React framework.

Pointing to Solow’s Paradox is kind of weird to me. Productivity growth accelerated in the 90s and 2000s, so it’s easy to tell a story where the computer age simply didn’t accelerate things until it had sufficiently penetrated the economy. If AI follows the same pattern, betting big on it still makes sense: China would probably be the predominant superpower if the computing developments of the 70s and 80s were centered there instead of the US.

Well, they didn’t say OpenAI was right. I think that a lot of the people working there believe that. It was kind of built into the original corporate/non-profit structure (that they since blew up).

The shenanigans that set off the GFC were much more nakedly corrupt and didn’t have even a fig leaf of potential usefulness to anybody to justify them. The revolution failed to materialize then. If the AI bust isn’t worse for the median person than 2008, I don’t think people in power have anything to fear.

I suspect the reality is that they missed the boat, as they have missed tens of other boats since the mainframe market dried up. I guess you could argue they came to the boat too early with their pants on backwards (i.e. Watson), and then left before it showed up. But it’s hard to tell from the outside.

Maybe that will turn out to be a good decision and Microsoft/Google/etc. will be crushed under the weight of hundreds of billions of dollars in write-offs in a few years. But that doesn’t mean they did it intentionally, or for the right reasons.

What effect do you imagine Next.js has on a bunch of code manipulating an HTML canvas? For vanilla code directly using browser APIs it’s basically just a bundler configuration, and while it’s not optimally configured for that use case (and annoying for other reasons) it’s probably better than what someone who has never configured webpack before would get doing it themselves.

My point isn’t that you absolutely need that, just that the negative effect on your game development are pretty minimal if you’re not leaning on the SPA framework for anything related to the game. If your game is going to be embedded into an otherwise normal-ish website, this isn’t a terrible way to go (I’ve done it personally with a game mostly written in Rust and compiled to WASM). You can get gains by splitting your game and web site bundles and loading the former from the latter explicitly, but they’re not massive if your bundler was already reasonably incremental (or was already esbuild).

Thanks for assuming I “read” about bundlers somewhere, though. I’ve been using (and configuring) them since they existed.

He may have been serving a game in a canvas hosted in a Next.js app, but have done all the actual game (rendering, simulation, etc.) in something else. That’s a decent approach - Next can handle the header of the webpage and the marketing blog or whatever just fine.

No, I don’t trust a word Sundar or Satya say about AI either. CEOs should be hyping anything they’re invested in, it’s literally their job. But convincing investors that every thing they don’t invest in heavily is worthless garbage is effectively part of their job too.

What is more convincing is when someone invests heavily (and is involved heavily) and then decides to stop sending good money after bad (in their estimation). Not that they’re automatically right, but is at least pay attention to their rationales. You learn very little about the real world by listening to the most motivated reasoner’s nearly fact-free bloviation.

There’s no marginal tax impact of discarding it or not after 5 years - if it was still net useful to keep it powered, they would keep it. Depreciation doesn’t demand you dispose of or sell the item to see the tax benefit.

It makes it suspect when combined with the obvious incentive to make the fact that IBM is basically non-existent in the AI space look like an intentional, sagacious choice to investors. It very may well be, but CEOs are fantastically unreliable narrators.

I’ve never understood the security utility of the Deno flags. What practical attack would they protect you from? Supply chain seems to be the idea, but how many npm packages do people use that neither:

* Get run by devs with filesystem permissions

* Get bundled into production

Maybe I’m using the wrong web browsers - mine have always had those problems (except that the pseudo-relationships were with real, horrifically bad people).

Usually it’s Mozilla not wanting to implement something Google wants to implement, not the other way around.

Whatever the original intent was, POST definitely does not return a new record consistently in most actual APIs. It's frequently used for actions that don't conceptually create anything at all.

Apart from the sectarian conflicts about what REST means, having a HTTP method that proxies can cache like a GET but allows bodies is pretty useful from a purely practical standpoint. You can do this with POST, but it requires proxy-specific configuration.

For some reason the RFC focuses on idempotency, but then says it's explicitly intended for enabling caching semantics. Caching a query that mutates visible state doesn't really make sense, and like you point out if you just want idempotent modifications PUT already has the relevant semantics. I guess we haven't learned our lesson from making the original HTTP semantics super squishy.

For sandboxes where the underlying software is assumed to be non-hostile (e.g. browser sandboxes), these kind of restrictions can be applied very early in a program's execution. If the program doesn't accept any untrusted input until after the restrictions are applied, it can still provide a strong defense against escalation in the event of a vulnerability.

> And sticking with that example, once it becomes TCP's job to handle packet loss due to transmission errors (instead of just congestion), things go south pretty quickly.

Outside of wireless links (where FEC of some degree is necessary regardless) this is mostly because TCP’s checksum is so weak. QUIC for example handles this much better, since the packet’s authenticated encryption doubles as a robust error detecting code. And unlike TLS over TCP, the connection is resilient to these failures: a TCP packet that is corrupted but passes the TCP checksum will kill the TLS connection on top of it instead of retransmitting.

ECC memory modules don’t do their own very complicated remapping from linear addresses to physical blocks like SSDs do. ECC memory is also oriented toward fixing transient errors, not persistently bad physical blocks.

> What would we have done differently knowing what we now know?

With the MLKEM standard? Probably nothing, Bernstein would have done less rambling in these blog posts if he was aware of something specifically wrong with one of the implementations. My key point here was that establishing an implementation phase during standardization is not an incoherent or categorically unjustifiable idea, whether it makes sense for massive cryptographic development efforts or not. I will note that something not getting caught by a potential process change is a datapoint that it’s not needed, but isn’t dispositive.

I do think there is some baby in the Bernstein bathwater that is this blog post series though. His strongest specific point in these posts was that the TLS working group adding a cipher suite with a MLKEM-only key exchange this early is an own goal (but that’s of course not the fault of the MLKEM standard itself). That’s an obvious footgun, and I’ll miss the days when you could enable all the standard TLS 1.3 cipher suites and not stress about it. The arguments to keep it in are legitimately not good, but in the area director’s defense we’re all guilty of motivated reasoning when you’re talking to someone who will inevitably accuse you of colluding with the NSA to bring about 1984.

I don’t think IETF is in the pocket of the NSA. I really wish the US government hadn’t hassled Bernstein so much when he was a grad student, it would make his stuff way more focused on technical details and readable without rolling your eyes.

> Further, the people involved in the NIST PQ key establishment competition are a murderers row of serious cryptographers and cryptography engineers.

That’s actually my point! When you’re trying to figure out if your standard is difficult to implement correctly, that everyone who worked on the reference implementations is a genius who understands it perfectly is a disadvantage for finding certain problems. It’s classic expert blindness, like you see with C++ where the people working on the standard understand the language so completely they can’t even conceive of what will happen when it’s in the hands of someone that doesn’t sleep with the C++ standard under their pillow.

Like, would anyone who developed ECC algorithms have forgotten to check for invalid curve points when writing an implementation? Meanwhile among mere mortals that’s happened over and over again.

I mean have a bunch of competent teams that (importantly) didn’t design the algorithm read the final draft and write their versions of it. Then they and others can perform practical analysis on each (empirically look for timing side channels on x86 and ARM, fuzz them, etc.).

> If instead you mean "figure out after some period of implementation whether the standard itself is good", I don't know how that's meant to be workable.

The forcing function can potentially be: this final draft is the heir apparent. If nothing serious comes up in the next 6 months, it will be summarily finalized.

It’s possible this won’t get any of the implementers off their ass on a reasonable timeframe - this happens with web standards all the time. It’s also possible that this is very unlikely to uncover anything not already uncovered. Like I said, I’m not totally convinced that in this specific field it makes sense. But your arguments against it are fully general against this kind of phased process at all, and I think it has empirically improved recent W3C and IETF standards (including QUIC and HTTP2/3) a lot compared to the previous method.

This isn’t black and white. There’s a medium between:

* Wait for 10 years of cryptanalysis (specific to the final algorithm) before using anything, which probably will be relatively meager because nobody is using it

* Expect the standardization process itself to produce a blessed artifact, to be set on fire as a false god if it turns out to be imperfect (or more realistically, just cause everybody a bunch of pain for 20 years)

Nothing would stop NIST from adding a post-competition phase where Google, Microsoft, Amazon, whoever the hell is maintaining OpenSSL, and maybe Mozilla implement the algorithm in their respective libraries and kick the tires. Maybe it’s pointless and everything we’d expect to get from cryptographers observing that process for a few months to a year has already been suitably covered, and DJB is just being prissy. I don’t know enough about cryptanalysis to know.

But I do feel very confident that many of the IETF standards I’ve been on the receiving end of could have used a non-reference implementation phase to find practical, you-could-technically-do-it-right-but-you-won’t issues that showed up within the first 6 months of people trying to use the damn thing.

I don't think it's incoherent. On one extreme you have web standards, where it's now commonplace to not finalize standards until they're implemented in multiple major browser engines. Some web-adjacent IETF standards also work like this (WebTransport over HTTP3 is one I've been implementing recently).

I'm not saying cryptography should necessarily work this way, but it's not an unworkable policy to have multiple projects implement a draft before settling on a standard.

They may not be involved with this process, but ITL has way more than 3 cryptographers.

Okay, I should've said implementing AES in C without a timing sidechannel performantly enough to power TLS for a browser running on a shitty ARMv7 phone is basically impossible. Also if only Thomas Pornin can correctly implement your cipher without assembly, that's not a selling point.

I'm not contesting AES's success or saying it doesn't deserve it. I'm not even saying we should move off it (especially now that even most mobile processors have AES instructions). But nobody would put something like a S-Box in a cipher created today.