I extracted the /buddy generator from the claude code source code leak. I will probably update some things once the official release is completed tomorrow. But until then, you can use the site to see all the potential buddies.
The creator of fff.nvim[0], Dmitriy Kovalenko, had an interesting analysis of this on Xitter[1]. The TL;DR of this is that Anysphere/Cursor is being somewhat disingenuous and does not include the index-creation and recreation time in the comparison nor do they include the CPU or memory overhead, where rg (and his tool, fff.nvim) are indexless.
This is interesting and I’d like to see a follow-up from Cursor, but the tone is unbearable and egregiously misrepresent the Cursor blog post, I guess for a circle of followers who won’t bother to check the original anyway and is just there for the dunking.
> So how cursor came up with such a beautiful solution only in 2026? Is everyone around dumb and never did anything like this before?
Cursor post doesn’t claim anything original, they attribute every approach discussed to someone else, including the one they claim to have settled on:
> Here's another very smart idea. You may have seen it used in ClickHouse for their regular expression operator, and also at GitHub, in the new Code Search feature that shipped a couple years ago and which does allow matching regular expressions. It's called Sparse N-grams, and it is the sweetest of the middle grounds.
The very next sentence in the fff article is amusing
> No, actually all the theory in the blog post they made (that makes sense) is coming from the paper https://swtch.com/~rsc/regexp/regexp4.html that is stated behind google code search project.
Because 1. the paper is prominently cited in the original, and 2. no it doesn’t cover all the subsequent optimizations discussed. “That makes sense” is doing a lot of work apparently.
Now, the main claims in the fff article are:
- Few/no people need to search entire repos that large;
- For large repos (no one needs to search), fff’s index is smaller (~100MB for chromium vs ~1GB for Cursor) and faster to create (~8s vs ~4m) and still fast (~100ms vs ?).
But all the comparisons are weirdly fixated on the MAX_FILE_SIZE query used for algorithm demonstration purposes in the original. That’s hardly a fucking regex search. Readers have no idea of how, say, MAX_.+_SIZE does after reading that rebuttal.
So, again, interesting, unbearable tone and egregious misrepresentation, would like a follow up.
> FEX allows you to run x86 applications on ARM64 Linux devices, similar to qemu-user and box64. It offers broad compatibility with both 32-bit and 64-bit binaries, and it can be used alongside Wine/Proton to play Windows games.
> It supports forwarding API calls to host system libraries like OpenGL or Vulkan to reduce emulation overhead. An experimental code cache helps minimize in-game stuttering as much as possible. Furthermore, a per-app configuration system allows tweaking performance per game, e.g. by skipping costly memory model emulation. We also provide a user-friendly FEXConfig GUI to explore and change these settings.
> On the technical side, FEX features an advanced binary recompiler that supports all modern extensions of the x86(-64) instruction set, including AVX/AVX2. The heart of this recompiler is a custom IR that allows us to generate more optimized code than a traditional splatter JIT. A comprehensive system call translation layer takes care of differences between the emulated and host operating systems and implements even niche features like seccomp. A modular core enables FEX to be used as a WoW64/ARM64EC backend in Wine.
I've tested it on an Ampere workstation, and was trying it on a Pi, but it seems with Trixie, there may be some bugs with both that and box64 right now, I was having trouble with both of them.
They make CrossOver, which is a productized version of Wine that lets you run Windows software on MacOS. They also work closely with Valve, who have just announced Steam Frame (a device that runs SteamOS on ARM).
> The main corporate sponsor of Wine is CodeWeavers, which employs Julliard and many other Wine developers to work on Wine and on CrossOver, CodeWeavers' supported version of Wine.
They took their sweet time but both the project lead Ryan Houdek as well as Valve developer Pierre-Loup Griffais (username Plagman here in the comments) have now come out saying that FEX-Emu was not just sponsored by Valve but is actually their project and that they approached suitable developers with the idea who they have been paying for the development: https://www.gamingonlinux.com/2025/12/valve-have-been-fundin...
As the random commenter I agree. By "support" I meant that they have a line of product and a strategy that relies on FEX to work and work as seamlessly as possible.
If they contribute to FEX at even a fraction of what they did to wine and Proton it is indeed huge.
It would be cool if we can use LLVM to lift the x86 code into LLVM bitcode and go to different platforms easily with ostate of the art optimizations, won't it?
Been there, done that during my PhD (code: [1]). Works reasonably well, except for compile times (for which I implemented a caching strategy). However, due to calling conventions, using LLVM isn't going to give the best possible performance. Some features like signal handling are extremely hard to implement with LLVM (I didn't, therefore). Although the overall performance results have been good, it's not an approach that I could strongly recommend.
Sadly compile times of LLVM-based recompilers make it impractical for competitive x86 emulation. We're not just talking a few single-frame stutters here and there, but considerable startup delays and pauses in-game.
LLVM's optimization passes also are less useful than you might think, since the vast majority of them is motivated by source->binary translation (like clang). They don't have much effect when recompiling an already optimized binary to another architecture.
Is this a safe place to complain about the emoji picker on macOS? The one on Sonoma was... Fine, if not very laggy. But macOS 26 Beta replaced it with the CHARACTER VIEWER. A separate application that does auto focus into the search box and does not auto quit after selection. Those are table stakes for a picker.
1. Certainly this is a submarine-pr article for Goldfish
2. I've noticed the rise. We had a Big Blue open up in our medium-sized town. Perhaps Swim schools are the new automated car wash of PE real estate speculation
Uses pretext (https://github.com/chenglou/pretext) for the text layout