dvt

I am so happy I haven't written a line of C++ in like 15 years. Absolutely disgusting language. Every time I look up one of their new standards, I'm like how does anyone keep all of this in their head (usually on top of stuff like boost, etc.)? No wonder LLMs are a thing.

If you're testing how good LLMs are at compressing information, then I think that's a fair test. Personally, I don't really think that's where their strength comes from (especially considering how much more useful local models that are orders of magnitude smaller than Claude/OpenAI-tier models have gotten). In other words, we already have a "super-intelligence"—it's called the internet, so just use the darn thing.

One-shotting is a bit of a red herring, imo. Let's say I wanted to build a "Super Dario" meme platformer. I would do some research, find a platformer on Codepen or Github that "feels" good, tweak it to my liking, change the sprites, and voila.

I constantly have to tell agents to just "look it up online" and "don't hallucinate your own components" because people have already done this a million times. Ironically, being more lazy could make these models more useful.

Pangram does work

It's trivial to see how many people think Pangram is absolute trash[1] (because it is).

You appear to be misinformed about how Pangram specifically works, it is not based on pattern detection of that sort. I recommend reading their whitepaper, it's a pretty understandable explanation of exactly how they trained their classifier.

I did read their paper (which is, by the way, very scant on details), and they trained their classifier in the laziest way possible: here's a chunk of "human-written" text and here's a chunk of "AI-written" text, put them in the right bucket, and do this a zillion times. Literally zero sophistication. Also: what do you think "pattern recognition" is, if not a "classifier"?

[1] https://www.reddit.com/r/academia/comments/1rm11rs/pangram_c...

Pangram doesn't work, and I wish people would stop treating it as gospel (but the AI/anti-AI grift is real). Here's a fun paradox: I can literally tell ChatGPT: "Say X" and it will say "X"—so that's a case where content is both AI generated and not. What if it changes a few words? Moves some sentences around? Where does something go from human- to AI-generated? (This is the classic Sorites paradox.)

Pangram tries to look for common patterns (rule of three, em dashes, etc.) but these are heuristic methods and not to be taken as gospel. There is no provable method to make a distinction between AI and human-generated other than the fact that AI-generated text tends to reek of pseudo-intellectual undergrad with a thesaurus.

Who implements transliteration rules? I assume operating systems? Or text renderers?

This is pretty crazy, literally built something almost exactly like this for a project I'm working on (a local-first AI agent that does work on folders while you sleep). Basically going from JSON "Lego blocks" to full reports (including charting, though a subset of what Flint offers). And with post-generation validation and retry steps.

Functions extremely well and the result is a very clear (and consitent) human-readable "output layer." Cool idea, fun to see people converging on similar concepts in the space.

I'm using Kokoro for a fun little side-project browser-based game I'm working on. It's legitimately super good for being only 85mb (for the wasm version) or 300mb (for the webgpu version).

to reveal both players to each client during the same tick

And I explained why this is not feasible given modern network topology. Players move around maps and peek around corners in between these "tick updates" the client gets from the server; therefore, we have to use clever methods of interpolation and prediction as well as server consensus to ensure that gameplay is smooth (e.g. models can't just pop in out of nowhere, movement feels good) while also being as fair as possible (e.g. we don't favor one player's view over another's).

A tick is the smallest amount of time the server does its "work" in. It does not mean, as the person I'm replying to was implying, that clients are 100% always lined up, because a game is played (locally) at much higher update rates.

So a server, of course, does send updates (player position, etc.) every "tick," but that doesn't matter. Even assuming zero dropped packets (suppose we're playing over TCP), it would feel like shit (stuttering, rubber-banding, pop-in, jittery physics, etc.) to play a game over a ~60ms latency that updates ~60 times a second vs other people that also are ~60ms from the server, so game engines do a lot of interpolation and servers are in charge of concensus. Hence, it's a bit of a misdirection to say: "can't you just send everyone the right player data every server update?" because servers obviously already do that (and that's not really the hard part, anyway).

Local interpolation and remote concensus is the hard part, and games handle this differently. In CS, for example, two players cannot kill each other (with guns) simultaneously. Valve's engine requires that someone always wins a gunfight (which sometimes can feel random). However, I would argue that feels way better than, e.g. in Halo, where you can headshot each other (and both players die), which feels dumb and frustrating.

So when building these servers, there are lot of tradeoffs to consider (a lot of which might change the feel of the game).

Well, if you cheat in WoW, Blizzard might just sue you[1], so that tends to be quite effective :)

[1] https://en.wikipedia.org/wiki/MDY_Industries,_LLC_v._Blizzar....

so I would consider it absolutely tenable

Always confuses me why people speak so authoritatively on topics they aren't versed in. PVS culling is not even remotely comparable to occlusion culling, mainly because wallhacks are not relevant accross the map; in fact they are only useful when opponents are always well into your PVS range.

FYI: there are also some clever ways to get around PVS culling (mostly by inferring opponent position based on other indicators, like gunfire).

"Same tick" is a misnomer for a few reasons. First of all, games use UDP, which is basically a "fire and forget" protocol (which means packets get dropped routinely). Second of all, realtime games use some interpolation/prediction to make up for latency (and aforementioned dropped packets).

So it's sort of a "relativistic" temporal system, not a linear "oh now you're at t=1, now you're at t=2" kind of timeline. And there's all kinds of complicated ways you create concensus between multiple clients, between server and clients, etc. (A lot of this remains an active research area.)

This has been done before in both 1.6 as well as Source. I helped with some of these implementations back in the late-2000s when I was playing professionally and I even tried to kickstart an anti-cheat hardware solution about a decade ago[1].. spent way too much time working on some of these problems. The main issue with occlusion was slightly increased latency, visual jitter because of interpolation (especially around corners), and a few other more technical problems[2]. It's good enough for public servers, but not tenable in serious competition.

Cheating has always been a problem in FPSs, and it likely won't go away. That's why premier competitions have always been on LAN.

[1] https://www.pcgamer.com/introducing-gameref-the-anti-cheat-h...

[2] Hard to fully obfuscate audio sources, hard to obfuscate hitboxes since you still need them for collision checking (e.g. if a grenade bounces off an enemy player behind a wall—the server does not do all physics for all clients), and this is on top of the engine itself sometimes requiring actual entities, so you're stuck with these dummy entities in memory, and so on.

Location:Los Angeles

Remote: Yes

Relocation: Case-by-case

I'm an engineer and data professional interested in team-building, consulting and architecting data pipelines. At Edmunds.com, I worked on a fairly successful ad-tech product and my team bootstrapped a data pipeline using Spark, Databricks, and microservices built with Java, Python, and Scala.

At ATTN:, I re-built an ETL Kubernetes stack, including data loaders and extractors that handle >10,000 API payload extractions daily. I created SOPs for managing data interoperability with Facebook Marketing, Facebook Graph, Instagram Graph, Google DFP, Salesforce, etc.

More recently, I was the CTO and co-founder of a crypto gaming startup. We raised over $6M and I was in charge of building out a team of over a dozen remote engineers and designers, with a breadth of experience ranging from Citibank, to Goldman Sachs, to Microsoft. I moved on, but retain significant equity and a board seat.

I am also a minority owner of a coffee shop in northern Spain. That I'm a top-tier developer goes without saying. I'm interested in flexing my consulting muscle and can help with best practices, architecture, and hiring.

Would love to connect even if it's just for networking!

Blog: https://ai.dvt.name/whos-david/ (under construction)

GitHub: https://github.com/dvx

Email: [d]@[dvt].[name]

This is a very authoritative answer that should be more nuanced and caveated as implementation-dependent. In some cases, repetition penalties take precedence over sampling; top_k and top_p can also be handled before or after the temperature step. In other cases, `0` is turned into like 1e-10 or some super tiny float value (which can drift if you do any arithmetic with it). Routing, quantization, etc. can also have an effect on sampling. And yes, in some cases, setting temperature to 0 can mean "pure greedy decoding" which makes the decoder about as deterministic as it can get.

An alarming number of people don't understand that LLMs work via purely stochastic processes, so I'm happy to see in-depth pieces like this. I'm looking for a job and maybe this is why it's so hard to get a callback these days: resumes are just dumped in some LLM black hole and no one really knows how it works. The author says:

temperature 0.1 — low, supposedly nudging the model toward deterministic outputs

This is not correct (and is briefly touched on later in the piece when he sets temperature to 0), temperature is not some kind of "deterministic" switch, but rather it affects the sampling distribution (which becomes more "spiky"—but is still very much a distribution).

This is one of the few AI hills I will die on: not disclosing AI tool usage when you produce a product where the writing is the end result (in this case, the website I'm being sent to) is disrespectful to your readers and users.

    `The quickest way to see QSOE run — no hardware, no -kernel juggling.`

    `Real hardware, real disk.`

    `A working plan, not a contract: milestones may shift as the work reveals what's really next.`

Went over a few of these with a pretty keen eye, and they aren't that particularly interesting. The Docker one is just a weird bug, it's not a vulnerability, and certainly not a "0-day" (which is a pretty loaded term and people expect bad stuff to happen).

The nghttp2 nghttpx one is more interesting, and could potentially be used for phishing, but it's very hard to line up properly because the request queue is non-deterministic so basically impossible to target a specific victim (assuming proxy traffic).

The VLC one is just a straight-up crash/bug. And VLC crashes all the time when using weird codecs, so that's nothing new.

Am I missing something here?

Likely doable with metaparameter tuning (used to work on a team with data scientists that were routinely doing this in various situations). Seems like a cool idea.

In a world where Fira Code, Hack, JetBrains Mono, and like a zillion others (of equal, if not greater, quality) are offered for free, this is obviously a pure marketing play and it's sad we live in a world where even fucking fonts are so heavily monetized.

Usually you need to be well-published/cited in the field, so a minor would likely not qualify. People joke around, but philosophers are some of the smartest people I've ever met, and it's not even particularly close. (I graduated ~10 years ago, so most of them are sadly lawyers or in academia these days, though some are engineers or entrepreneurs.)

The irony of someone writing a blog post purely to rage-bait (or rage-engage?) against "slop grenades." Slop grenades can also be made by humans you know, and I'd argue this post is at least a flashbang.

There's the killing again.

Do you not understand how ecosystems work? Or how populations of predator/prey are in various (usually) oscillatory states?

Humans have already stolen so much from nature and the animals

I'm confused, are you saying humans are somehow not part of nature?

The problem is that Redis tries very hard to position itself as a persistent data store

What are you talking about? On their website, the top 3 use cases (under the Platform menu) are: caching, streaming, and session management. Literally all of these three are volatile.

Considering how complex and error prone this is, I don’t want it in my stack.

Have you ever used Redis before? I've literally never had to manage clustering or had any issues with it, and I've been using Redis for like 15 years (including for games where state had to live in multiple regions and could change on a 30- or 60-tick basis).

1) Wrap your client library so that it's impossible to store anything without an expiry date. You don't want 6-months-old data suddenly coming up in your app!

No need for this client-side complexity, as you should be using `allkeys-lru`. FWIW, should likely be doing this anyway, as (generally speaking) all data stored in Redis is usually regarded as volatile because of what Redis actually is.

Memcached is meant to be a lightweight memory cache, which makes sense, but contrary to the article's claim that "Redis is brought into a stack as a cache, and it is run with the assumption that people treat it that way"—I have very very rarely experienced this. Redis is brought into a stack because (most importantly!) it's fast and (almost as importantly!) because it's simple. I don't think this article is written by AI, but (and I'm trying to be charitable here), it's just like.. dumb.

Dealing with memcached downtime is incredibly easy, because client libraries generally ignore connection exceptions. For instance, a simple get will just return the default value (or none) if the server is down.

This is a terrible idea in the context of things that might use Redis. If you use Redis with some kind of complex state (say, a document if you're working on a Notion clone, for instance), wtf even is a "default value"? In fact, I actually also want to know when the thing is down.

Clustering memcached is wonderful, because memcached actually has no clustering built-in.

Yeah bro, this is yet another one of the reasons people use Redis: it handles consensus and clustering for you. What even is this article? It's a master class in straw-manning architectural decisions: most people use hammers as hammers, but screwdrivers make great hammers too, especially if you also need to screw stuff in! I mean.. technically true?

The paper is correct, but I think that anyone that knows anything about LLMs knows this:

Role tags were a formatting trick that became the security architecture and the cognitive scaffolding of modern LLMs.

LLMs are basically some `f(x) → y` where x and y are strings. That's it. Nothing more to it. If you feed it private x (like secret keys) or do dangerous stuff with y (like running arbitrary non-sandboxed code), that's on you.

Also, roles were never really meant to be a "security architecture," they were just meant to (a) make training/fine-tuning easier, and (b) make conversational LLMs more useful.

Instead we have a majority of society that wants to see AI fail.

Do you talk to regular people? I work out of coffee shops routinely and literally like 90% of laptops have ChatGPT or Claude open. I was shocked at how many of my friends love the silliest of AI features (like Slack bot summarizing your day or your upcoming meetings), and a lot of decks, proposals, SOW's, etc. are (at least in part) generated with AI these days.