notorious_pgb

You're right and I was misremembering (we had only developed against modern mobile browsers), though I am 100% certain we made use of these extensions on iOS Safari, so I honestly don't believe caniuse when they assert that it supports _neither_ extension. Per my recollection, iOS Safari supported the large blob extension quite early on.

Apologies for the brash statement earlier; that was wrong of me.

Very fair (see my edit), though I would submit to you that this isn't a sufficient polyfill for PRF, since PRF allows for a _secondary secret_ alongside the public key, allowing the server to safely store the public key without storing the cryptographic seed material itself.

The inability to use a passkey for the purposes of both authentication and secret storage (at least, without building non-trivial additional cryptographic plumbing) seems to me a reason to just use and push for the continued adoption and acceleration of the purpose-built extensions, instead of reusing a _public_ key as private material.

Interesting, but the PRF / LargeBlob extensions already enable just such functionality (and more) without relying on the secrecy of a public key.

Why not just use those?

Edit: that's what I get for not reading far enough -- the article addresses this, though I would quibble with the confident assertion that the extensions are not available in major browsers, given I worked for a startup literal years ago which built major functionality on top of these extensions, which were available in (at least) all relevant mobile browsers.

Deeply, deeply insulting.

I don't mean to be rude, but what could possibly have given anyone with eyes and ears a positive -- friendly, even -- impression of Google?

Not the most gracious post, I suppose.

I would draw a distinction between "working in the tech industry" and "being instrumental to the rise of a terribly consequential corporation over the course of decades".

Copyright is a strange thing to bring up, given I mentioned it not and I couldn't possibly care less about it.

Really tired of reading LLM blog posts, especially ones used to hock SaaS.

Respectfully, it's not clear to me what you're saying. You're clearly displeased with both the author of the article and with myself, but beyond that, I'm not sure what your thesis is.

Primarily poor wording on my part.

I think in terms of language features and patterns which actually mean something. OOP doesn't really mean anything to me, given that it doesn't seem to mean anything consistent in the industry.

Of course I work with classes, inheritance, interfaces, overloading, whatever quite frequently. Sometimes, I eschew their usage because the situation doesn't call for it or because I am working in something which also eschews such things.

What I don't do is care about "OOP" is a concept in and of itself.

I think that "OOP" is an incredibly overloaded term which makes it difficult to speak about intelligibly or usefully at this point.

Are we talking about using classes at all? Are we arguing about Monoliths vs [Micro]services?

I don't really think about "OOP" very often. I also don't think about microservices. What some people seem to be talking about when they say they use "OOP" seems strange and foreign to me, and I agree we shouldn't do it like that. But what _other_ people mean by "OOP" when they say they don't use it seems entirely reasonable and sane to me.

With respect, none of this sounds like "amazing" work on DuckDB's part. It's not bad work, either! It's competent work.

Comparing it to a naive approach (encrypting an entire database file in a single shot and loading it all into memory at once) is always going to make competent work seem "amazing".

I say this not to shit on DuckDB (I see no reason to shit on them); rather, I think it's important that we as professionals have realistic standards that we expect _ourselves_ to hit. Work we view as "amazing" is work we allow ourselves not to be able to replicate. But this is not in that category, and therefore, you should hold yourself to the same standard.

Roblox isn't embedding arbitrary Unity games though; they're exposing an SDK to use the base Roblox multi-player framework for custom game modes -- which Fortnite also already does, no?

Nice article. Really gets to the heart of what's been troubling me the past decade or so.

It's certainly not the same, but this reminds me of the "NFTs in video games" lunacy of a few years back. Just add NFTs to your games! An ore mined in Minecraft will somehow be usable in every other game!

It's not clear at all to me why people who are playing Fortnite would want to launch a completely different game within it. Doesn't it just become the Epic Games Store at that point? Is this just a growth hack to try to bootstrap another Steam competitor after the unmitigated disaster of their last attempt?

Not in the US.

There's nothing which fills me with despair at the bleakness of the modern digital hellscape quite as efficiently as AI-written articles bemoaning the usage of AI.

Hating AI slop is an art, god dammit -- so of course you just had to throw an LLM at it.

Do you know, deep down, what a thread is? What it actually is?

If not, I suggest reading this blog post: https://prettygoodblog.com/p/what-threads-are-part-2

(disclaimer: I wrote this)

Well, not really. They've explained why their existing solutions don't work well for proxies / gateways, which cloud-based AI agents are an example of.

This blog post is offensive to me on three levels:

1. It is clearly not written with a desire to actually convey information in a concise, helpful way.

2. It is riddled with advertisements for Cloudflare services which bear absolutely no relevance to the topic at hand

3. The actual point of the article (anonymous rate limiting tokens) is pointlessly obscured by an irrelevant use case (AI agents for some reason)

Of course, the second two points seem to be heavily related to the first.

This is barely any better -- in terms of respect for the reader's intelligence and savviness -- than those "Apple just gave ten million users a reason to THROW AWAY THEIR IPHONES" trash articles. Just slop meant to get you to click on links to Cloudflare services and vaguely associate Cloudflare with the "Agentic AI future", with no actual intention whatsoever of creating a quality article.

It seems to me that once things like Neuralink start being used for more than strictly restoring functionality in injured or disabled individuals -- once there's a competitive advantage to have one -- it'll quickly become an arms race.

This is definitely the core issue from my perspective.

tl;dr: Yes; at least some of us are. I deeply am.

I wouldn't normally post a link to my blog in the comments of another thread -- I'm really not trying to shamelessly plug here -- it's just _incredibly_ relevant, and I've already poured my heart and soul into writing out exactly what I think here, so I think it's germane:

https://prettygoodblog.com/p/the-big-secret-that-big-ai-does...

I cannot write the necessary philosophical screed this deserves, but: there are things which make us human and in our individual humanity unique; these things are art and skill of any kind; and it so greatly behooves one to strive to master art in any and all its forms.

Submission statement:

I wrote this as a desperate plea to all those who actually care about craft as craft: keep your ability to do. You are going to need it, and it is easy as hell to lose.

I appreciate your humility in assuming that the term is correct, and your understanding must be off.

As a matter of fact, the truth is that this is not an RTOS, and I'm embarrassed that I put that term in the title. It wasn't intentionally malicious -- in the moment I felt it fit -- but it was clouded by the bias of wanting to create an interesting HN title.

Truly appreciate the thoughtful response.

First off: you're absolutely correct, and in ways which pain me to admit, because I do want to create correct analogies, as opposed to ones which mislead or half-inform.

I racked my brain, during the writing of this post, to figure out how to resolve these inconsistencies without sacrificing the goal of the post, which was basically to "unlock" an understanding of:

"The things you think are magic are actually just well-designed systems which you can, and should, reason about."

I think most programmers who use threads but don't know what they are have likely primarily had threads explained to them via analogies which teach their effects, not their nature. While this makes a lot of sense, and this instruction is certainly necessary and very valuable, it also has the unfortunate effect of mystifying and deifying such systems.

I also think most programmers would have no trouble accepting, or perhaps stating, that a thread is a data structure. But the nature of that data structure -- what goes inside it? -- has, in my experience, not been well understood.

And I truly think the core thing one has to do to demystify threads is explain what a thread holds -- a snapshot of CPU state -- because it links together the two most important things:

1. What would a thread structure even contain? 2. What features of a processor would even enable threads to function?

And with that as my primary motivation, I will defend the usefulness of this analogy. While the exact "state" being swapped is very different (which certainly demands explanation in any rigorous instruction), the fact that "it's simply state being swapped around, by code you can read, at an interval combined with conditions" is what I truly believe is the missing keystone -- and I do think this way of demonstrating it is useful to that degree.

But I am planning a part 3 which goes into fine detail on all of the disanalogies in part 2.

(Finally, I think my biggest sin of this whole thing is using the term "RTOS" in the title. That was stupid. This is not an RTOS at all. I didn't even use the term anywhere in the blog post itself, so why use it in the HN title? I regret this.)

Ah well -- the article itself has its own fair share of accuracy issues -- and I learned something from your conversation, which wouldn't have happened without said mistake.

I think this is a pretty damn good metaphor for the introduction of these concepts, especially in a context where the learner(s) might need to imminently apply this knowledge.

What drove me to write this post (as someone who didn't attend college where I might've learned exactly what I'm about to say -- big grain of salt) is that it took me being forced by circumstance to become a firmware engineer for a time to actually understand not just how to multithread well, but what the hell this all even was.

And I guess I saw one too many Reddit comments (mistake #1) which downplayed the idea that there's any benefit to knowing the answer to such things.

That all said, this blog post / metaphor is definitely aimed at someone who's already been using threads effectively for some time -- I don't think it'd fare very well as a first introduction.

I suppose the actual thing it is is closer to what you're describing, but the thing that it makes viscerally understandable is threads itself -- I hope.

My person!

I worried that I'd come across as a high-horse dickhead in the mystification section, when that's the fundamental opposite of my intention and attitude here. I'm glad to hear that it resonated with another.

Although I guess we could both be high-horse dickheads.