If your alias is john.doe@duck.com and you wish to send an email to jane.doe@example.com, you can do so by sending an email from your forwarding address to jane.doe_at_example.com_john.doe@duck.com. What we did here is replace the @ in the receiver address with _at_ and then append our alias, again separated with a _. This lets this continue being a valid email while being unambiguous for DuckDuckGo’s routing infrastructure. I tried it out and immediately got the confirmation that my support ticket had been accepted! After the initial hurdle replying normally will continue to work.

Simply go to the website on the Kobo, memorize the 4 digit code it generates then go to the same website on your other device, enter the code and upload your file. Within a few seconds it should show up on the Kobo as a downloadable link, and it has the additional options to convert your eBook into a native format for the target device. Super convenient!

I currently use obsidian-periodic-notes to manage my daily notes and have mostly left the weekly/monthly option untouched, until now.

To actually collect the necessary journal entries, I relied on Dataview which I’ve used previously to get good at Marvel Snap. I wanted to minimize the changes I needed to make in my day-to-day workflow so I started with the restriction that at most I would be willing to tack on #weekly at the end of a journal entry that was noteworthy.

Dataview was able to beautifully navigate this limitation and with a little bit of JavaScript I now have a template that I can plug into Periodic Notes and get a roundup of the whole week in one click. Here’s how it looks with just today’s entries highlighted:

The relevant DataViewJS code is this:

(() => {
  const TAG = "#weekly";

  const m = dv.current().file.name.match(/^(\d{4})-W(\d{2})$/);
  if (!m) {
    dv.paragraph("Weekly note filename must be like `2025-W50.md`.");
    return;
  }

  function isoWeekStartISO(year, week) {
    // Compute ISO week start (Monday) in UTC, then return YYYY-MM-DD
    const simple = new Date(Date.UTC(year, 0, 1 + (week - 1) * 7));
    const dow = simple.getUTCDay(); // 0..6, Sun..Sat

    const start = new Date(simple);
    if (dow <= 4) start.setUTCDate(simple.getUTCDate() - dow + 1);
    else start.setUTCDate(simple.getUTCDate() + (8 - dow));

    // YYYY-MM-DD
    return start.toISOString().slice(0, 10);
  }

  const year = Number(m[1]);
  const week = Number(m[2]);

  const start = dv.date(isoWeekStartISO(year, week));
  const end = start.plus({ days: 7 });

  const pages = dv.pages('"Daily"')
    .where(p => p.file.day && p.file.day >= start && p.file.day < end)
    .sort(p => p.file.day, "asc");

  let any = false;

  for (const p of pages) {
    const bullets = (p.file.lists ?? []).filter(li => (li.text ?? "").includes(TAG));
    if (!bullets.length) continue;

    any = true;

    // [[YYYY-MM-DD]]
    dv.paragraph(p.file.link.toString());

    // - Line 1
    // - Line 2
    dv.list(
      bullets
        .map(li => li.text ?? "")
        .map(t => t.replace(TAG, "").replace(/\s+/g, " ").trim())
        .filter(Boolean)
    );

    dv.paragraph("");
  }

  if (!any) dv.paragraph(`No ${TAG} bullets found for ${m[1]}-W${m[2]}.`);
})();

The code is relatively simple: It finds the week number from the current file name, gathers the range of dates for that week, inspects each file for lines that contain #weekly, and then neatly lays them out grouped by date.

On the server being migrated out of

# Switch to the Postgres user
sudo -i su - postgres
# Export just the roles so the imported database can have the right ownership
# I also edited this to only keep the role for the db I was moving
pg_dumpall --roles-only > roles.sql
# Export the actual database in Postgres' binary format so its smaller
pg_dump -d atticd -Fc --create > atticd.dump

Once I had both files I used rsync to ship them over to the new server

On the server being migrated to

sudo -i su - postgres
# Set up roles first
psql < roles.sql
# The `-d postgres` is required because pg_restore
# wants to connect to at least one existing database before
# doing anything, so we give it the one that exists by default
# at least on NixOS.
pg_restore -d postgres ./atticd.dump

And that’s it! After this I just enabled the service on the new server and it picked up the existing database right away.

I wish I had the session transcript to share for this but OpenCode doesn’t show my old session anymore so I can’t share it.

Yesterday I threw GPT-5 via GitHub Copilot at a relatively simple problem: My Prometheus alerts give me a relatively useless message when an alert fires from the prometheus-blackbox-exporter. I would like to see the URL that it’s failing to reach. I used OpenCode to drive this in an agentic manner.

At one point, the LLM hallucinated a subject field in the Prometheus Alertmanager config for email alerts. I pointed out the error, after which it changed the subject to correctly be headers { Subject = "..."; }; instead. A few iterations on other parts of the config later, it randomly went back to that line and reverted it back to the wrong subject field saying that the right version was actually incorrect.

This happened around the 45K tokens mark in its context window, which is well under the claimed values. Ultimately this was an easy mistake to fix again, but I was relatively surprised to see the LLM repeat a mistake within the same session.

TL;DR: nix flake archive --json | jq -r '.inputs[].path' | xargs nix --verbose copy --to ssh://user@host

Due to unfortunate circumstances my homelab server is running on a relatively slow internet connection while I’m at home. To alleviate the problems this causes with NixOS updates, I build and deploy the new generations for it from my desktop. This works in most cases, except when an update ends up restarting Tailscale or OpenSSH which cuts off my SSH session and leaves the machine in a bad state.

As a workaround for that problem I now copy the built closure to the Nix Store of the machine and do an nh os switch inside a tmux session there so it can run to completion without having to download everything. This usually works, but it does need to redownload inputs which seems a little wasteful so I searched around for ways to get the Nix Store paths of all my Flake inputs and came up with this small solution that lets me skip even more network I/O for the homelab.

I changed the locale in my NixOS configuration from en_US to en_GB to appease the spell checker on my desktop. When I deployed this updated configuration to one of my servers, all my services immediately fell over.

I had the sense to look at journalctl right away which made it very apparent what the problem was:

Oct 29 18:27:00 wailord postgres[3593]: [3593] FATAL:  database locale is incompatible with operating system
Oct 29 18:27:00 wailord postgres[3593]: [3593] DETAIL:  The database was initialized with LC_COLLATE "en_US.UTF-8",  which is not recognized by setlocale().
Oct 29 18:27:00 wailord postgres[3593]: [3593] HINT:  Recreate the database with another locale or install the missing locale.

(Yes my server is called wailord, I was loving Cobblemon when it was provisioned)

The solution was to simply add en_US back to i18n.supportedLocales and a rebuild fixed everything right up.

Over time I plan to backfill this with the contents of my Obsidian Vault’s “TIL” folder and then just use this public listing for the purpose, since it’s equally accessible to me via the excellent Sveltia CMS.

This was the result of cascading surprises: setting package.includes causes gitignore to no longer be considered, and "README.md" in package.includes actually works like "**/README.md"’ and picks up the READMEs from the repositories in .direnv/flake-inputs/.

Upstream issue: https://github.com/rust-lang/cargo/issues/12294#issuecomment-2171044946

This used to be a first party feature within the official gitlab-runner binary but they deleted it citing maintenance burden. What a shame.

# file_list.txt
file 'source1.mp4'
file 'source2.mp4'

$ ffmpeg -f concat -safe 0 -i file_list.txt -c copy output.mp4

GParted requires the presence of ntfs3g on $PATH to enable NTFS support.

When moving Windows installations across disks the reason why stuff doesn’t boot is that the Windows EFI for the old disk is sitting around in your /boot partition so the systemd-boot option I pick tries to boot into a non-existent installation. The fix for this is to go and delete the Microsoft folder from /boot/EFI and replace it with the one in your new disk and it’ll be fixed.

To extend an NTFS partition in Windows just use the good old diskmgmt.msc and it can just extend it while the disk is online!

To move the Windows recovery partition around, run reagentc /disable to disable the recovery agent, then go into GParted to move the partition to the end and then boot back into #Windows. Do the necessary partition changes then run reagentc /enable to enable it.

This is extremely helpful on NixOS where packages can sometimes re-use upstream systemd unit files and inject NixOS specific options through an override file.

# for URL https://git.msfjarvis.dev/msfjarvis/pass-store
$ pass-git-helper get
< protocol=https
< host=git.msfjarvis.dev
< path=msfjarvis/pass-store
> protocol=https
> host=git.msfjarvis.dev
> username=msfjarvis
> password=hunter2

This is resolved by restarting the gnome-keyring-daemon using the command gnome-keyring-daemon -r -d.

One solution suggested for this was setting remotes.<name>.tagOpt = "--no-tags" but that didn’t do the job for me.

The thing that worked for me was to conditionally disable pruneTags for just the origin remote so it would not try to clear out the tags pulled from upstream. Achieved by running git config --local remotes.origin.pruneTags false.

Lost entirely too much time to this.

I’ve configured Zed to use itself as my commit editor from the integrated terminal, which makes for a nicer experience in the IDE than having to use the terminal text editor.