gavinhoward

As someone who has applied less than 6 weeks ago, this is great news. I can't wait to hear back!

I'm okay dropping the philosophy and just making something that truly does what Nix claims: atomic upgrades, fully-reproducible environments, etc. In fact, dropping the philosophy is exactly why I am making my own.

Your idea sounds interesting and (by your bio) right up your alley. I'd be interested to see the result.

Huh.

I'm no Nix user, but I want to build an alternative.

Do you think these problems could be fixed?

As a Neovim user, this stopped me dead with painful realization: I may have suffered the same thing but didn't realize it. There was a time when I could not undo something, and it was after a Neovim upgrade.

Unlike Dr. Chisnall, I started my editor journey on Neovim, so it wasn't a transition that bit me. However, if the format of the persistent undo file is unstable, and Neovim just deletes it when it doesn't recognize the previous format, then it seems conceivable (to me) that an upgrade after changing the format would delete the file too.

Ouch. This is making me think about getting off of Neovim. Yes, FOSS comes as-is, but if there's an alternative...

Not something I'm working on, but want to: a competitor to Perforce that will be cheaper and easier.

Unfortunately, I'm not sure that being better is enough to compete, so I'm sitting on it for now.

This is the first time I've heard a use for LLMs that I think might be good.

> Looks like operational transforms to me.

Sort of. I add provenance, which helps properly identify collisions, and require a well-defined order by stacking [1] changelists.

> The doc claims it's the first with this technique.

More like the first with the particular angle on the technique. I specifically mention patch theory as another side of the same coin.

> A 30 second search reminded me of Darcs, and taught me about Pijul, and Weave.

Darcs is Pijul's ancestor, and I mentioned Pijul. I also mentioned the weave and how reference sets scale better.

> The example in the doc uses text, and unfortunately I think it's for a reason.

Readability. Nothing more. The real stuff will be a compact binary format.

> I think with large, binary game assets, the most common operation is going to be strings of "replace A with B", and depending on your chunk size relative to the distribution of changes you make on your assets, I see it as pretty close to a wash, for efficiency.

Yore will dedup change data instead because as the Lore document itself identifies, dedupping content is hard using chunks; you either get dedupping or canonical addresses. Change data doesn't have one canonical address; the address is in the commit data instead.

Dedupping changes has another benefit. If most instances are "replace A with B," and A replaces B in multiple places, Yore will be able to store just one instance of A, no matter its size. This matters because the larger the chunk, the less likely it will match any other chunk.

> Especially considering that content-addressable blocks also solves de-duplication, which for a multi-game studio is probably going to be significant. Especially if they're managing multiple releases, patches, development branches, etc.

True, but that should be table stakes. The fact that Git does not is a poor reflection on Git, not an innovation in Lore.

[1]: https://www.stacking.dev/

The best answer I have is for you to read the "History Model" section of that design doc through the "Implementing CRDTs" subsection.

When it comes to large assets, wasting large chunks of space is a problem. If your chunks are 64 kib average (from the Lore document), but changes only average 1 kib (which could be a high estimate), then you will still run out of space 64 times faster and need to read 64 times more data off of the disk for certain operations.

It also makes diffing hard, as well as diff viewing.

As someone who has thought a lot about VCS design [1] [2], the chunking approach is the wrong one and will still waste space.

[1]: https://gavinhoward.com/uploads/designs/yore.md

[2]: My WIP VCS has been named Yore for at least two years; I did not copy Lore's name.

Because Git was faster.

This mattered because speed is the killer feature [1], and speed is often seen by users as a proxy for reliability [2].

[1]: https://bdickason.com/posts/speed-is-the-killer-feature/

[2]: https://craigmod.com/essays/fast_software/

> At this point if your VCS isn't a layer above git plumbing, nobody gonna waste time using it.

Probably true, but it's a shame because there are better ways of storing and processing the data, ways that natively handle binary files, semantics, and large files without falling over.

Okay, but if you combine the curried and tuple styles, and add a dash of runtime function pointers, you can solve the expression problem. [1]

[1]: https://gavinhoward.com/2025/04/how-i-solved-the-expression-...

Bram Cohen is awesome, but this feels a little bare. I've put much more thought into version control ([1]), including the use of CRDTs (search for "# History Model" and read through the "Implementing CRDTs" section).

[1]: https://gavinhoward.com/uploads/designs/yore.md

> For instance, you might think that big tech engineers are being deliberately demoralized as part of an anti-labor strategy to prevent them from unionizing, which is nuts. Tech companies are simply not set up to engage in these kind of conspiracies.

https://en.wikipedia.org/wiki/High-Tech_Employee_Antitrust_L...

I have had to put programming aside in 2025, probably for the rest of my life, so 2026 will be the year I reskill and reinvent myself.

But most importantly, I want to finally become as kind, patient, and charitable as I have always wanted to be.

Hey, where can I apply to a job like yours? I may not be smart enough, but I may be. And I am very interested in formal verification.

SAMS does do that. Read my article carefully; it also requires modification and distribution rights for users. See principles 0 and 1.

The title of the blog post downplays the absolute masterclass that this post is. It should be called "A Tale of Four Fuzzers: Best Practices for Advanced Fuzzing."

And if you don't have time, just go to the bullet point list at the end; that's all of the best practices, and they are fantastic.

I hope that FOSS work is never a burden, but that's too idealistic. For some, FOSS work is a burden on them and their loved ones.

To those for whom it is, please don't feel obligated to continue. I haven't, and I made this public so that others will be able to discard their feelings of obligation.

Let's get paid to hold up the sky.