2026-04-27 Mon

Linked references — 2 pages

Open the linked references

2026-04-26 Sun

  • visual selection to tmux was supposedly added by gpt-5.5 and Codex/Desktop to my dotfiles.
    • v -> rectangle-off + begin-selection
    • C-v -> rectangle-on + begin-selection
    • y / Y still use the existing pbcopy clipboard path.
Linked references — 1 page

Open the linked references

2026-04-25 Sat

  • Frustrations

    • Nix Performance Issues

      • I have a CI job which runs a daily update to keep my software up to date. It recently jumped from 7.5 min to timing out at 1.5 hrs. When I sync my system, it's taking longer and longer. It's impacting how often I run my nix sync, which is also impacting how often I configure my machine.
      • Part of the problem that caused the jump from 7.5 min to 1.5 hrs was because I switched to using Numtide/llm-agents.nix without configuring them to be a binary cache provider as they recommend. I was trying to install Codex/CLI through them, which is an Open Source Rust project. As a result, it was doing all the build activities Numtide already does in CI.
      • In this case, I was lucky, in a sense, because Numtide is a nix consulting firm, so they know what's what; they actually have a CICD/CI system that exports a Binary/Cache that's updated once a day. But in practice, I've been exploring the nix ecosystem using LLMs to write my flakes, and it didn't suggest that I add that caching setup, and I didn't even think to set that up.
      • Other dependencies like mise are much more out of date; nixos packages show the latest version at this time to be 2026.4.6, even though @jdx has released more than a dozen versions since then.

      • the problem with Nix is its Pur/ity

        • By design, nix is trying to build all software in a pure way, which is a very ambitious and lofty goal.
        • I love this goal, particularly for the reproducibility of software. It ensures that software can be built by people who are independent of the core maintainers. This part reminds me of how the IETF requires multiple, independent reference implementations to move a protocol forward.
        • Part of the design of this system is that the build dependencies are expressed in a terse functional programming language, Nix/Lang. Someone has to write the Nix/flake for each package, which describes how to build the package. Then someone else has to build it. And, preferably, it wouldn't need to be built more than once for each platform.
        • Most of the time, the person who describes how to build the software in a Nix/flake with Nix/Lang is just an enthusiast about the underlying software. They don't have tons of time to set up a robust build pipeline that includes tests. They are most likely just doing it for themselves. Once they get it working, they share that work with others.
        • But this means that the vast majority of people who use Nix/flakes are not getting binaries built by the people who made the software. This is very inefficient. The most knowledgable people about a particular piece of software are the core maintainers. Those maintainers often go out of their way to generate binaries for multiple platforms. And then, most of the time, as far as I understand it, nix doesn't use them, because it wants to build them.
        • For example, the mise Nix/flake here is maintained by a polish developer Person/Konrad Malik. It doesn't use any of the binaries that @jdx has GitHub/Actions generate.
          • If I look at their github surface area, they appear to be a competent dev, and I can see they are struggling with some of the things I am with nix; Person/Konrad Malik/GitHub/neovim-flake has
            • in the assumptions section,
              • keeps all Neovim config in lua as it's supposed to be
              • uses nix for system dependencies, plugins, and packaging
              • That way nix is a layer on top, just used for packaging and reproducibility. It does not interfere with the standard way to configure Neovim.
            • in the experimentation section,

              • One of the cons of using Neovim in nix is - no "dirty" modifications to Neovim to try something out quickly. Experimentation becomes harder. You always need to rebuild it, but nix build and then ./result/bin/nvim is quick and easy enough for it to not be a deal-breaker.

          • It's notable that in spite of the availability of options such as those explored in Username/luixos/YouTube/26/01/Neovim on NixOS - Nixvim vs NixCats vs NVF - nixvim, nixCats-nvim, nvf, Konrad chose to make his own nix flake!
        • As a relatively new adopter of Nix, I don't even know whether there's a convention for how to just "rely on the original binaries" when making a nix flake. It seems like it goes against the whole ethos of the nix ecosystem.
        • It's seems ironic to me that one of the reasons why people choose Nix instead of Docker is performance. They both provide increased reproducibility and require people to pay for that with increased complexity of abstractions. In addition to that base cost, Docker adds the cost of both build time performance issues and runtime overhead, particularly with filesystem mounts, but at least Docker has opinions about caching. Nix's build-time complexity has less industry support, and so individuals must decide where and how they will add caching.

      • More Beads/Bug/Dolt Difficulties

        • yet another instance of corruption, this time on Beads/v/1.0.2. By now I think about 40% of my usage of beads is fixing beads. Time to move to another Git-Friendly Task Management provider.

  • Gard/Diff

Linked references — 1 page

Open the linked references

2026-04-24 Fri

Linked references — 3 pages

Open the linked references

2026-04-23 Thu

  • exe.dev - see blog post crawshaw - 2026-04-22 - this is a bespoke micro neocloud provider made by an individual.
  • interesting discussions

  • with Adobe, the simplest things are the hardest

    • This morning I wanted to a lightweight edits of a movie file that was in Lightroom/Classic. I just needed to edit the start and end times and add some text.
      • Discovered that Adobe/Rush was discontinued (technically, it will no longer be available in September). Apparently Adobe no longer has a lightweight, desktop-native video editor; the closest thing is Adobe/Premiere/Pro, which is, needless to say, overkill for this use case.
      • I tried Adobe/Express/Web, which was fine, I guess, but upon downloading the video, it didn't preserve the creation time metadata from the original, so when I imported it back into Lightroom Classic, it wasn't adjacent to it in the gallery view, even though I manually renamed the file so as to be lexicographically adjacent to the one it was supposed to replace. I used Codex/CLI to set the metadata of the file to be the same as the original using ffmpeg and ffprobe, but it was still showing the date as Jan 1, 1904, even after right clicking on the folder and selecting Synchronize Folder ... > Synchronize Metadata. I directed codex to investigate, minutes passed, it produced a new candidate. For some reason, right clicking on the thumbnail in the gallery view > Metadata options were all greyed out, so I synchronized the folder again. It still showed as Jan 1, 1904. Then I right clicked on the thumbnail > Remove from Lightroom while leaving it on disk, then did Synchronize Folder again to re-add it. That worked.
    • in this process, I discovered (too late) that MacOS/Finder/View/Gallery has a MacOS/Finder/Video/Trim option, which could have potentially saved me some time.
    • I understand that in principle, I could have just iterated with ffmpeg at the CLI, but it makes me wonder how much time that really would have saved. Are there CLI/Tools for people who want to stay in the CLI but do simple video edits?
    • I also learned that if I make changes in Lightroom/Classic/View/Develop/HDR, they don't show up in Lightroom/Classic/View/Library - and apparently this is intentional? I think it encodes HDR configuration bits in the metadata of the image format, and then, if the display medium has HDR features, it uses those metadata to render it differently. But Adobe's own product doesn't display that in its own library view, so how can anyone reasonably expect those bits to be useful to other products?
Linked references — 1 page

Open the linked references

Earlier