Kyle Daigle, COO of Github, responding to an tweet with some data about the insane amount of code GH sees as the result of AI:

There were 1 billion commits in 2025. Now, it’s 275 million per week, on pace for 14 billion this year if growth remains linear (spoiler: it won’t.)

GitHub Actions has grown from 500M minutes/week in 2023 to 1B minutes/week in 2025, and now 2.1B minutes so far this week.

I learned, in the light of the axios compromise that a good deal of package managers support setting a minimum release age for packages:

~/.npmrc
min-release-age=7 # days
ignore-scripts=true

~/Library/Preferences/pnpm/rc
minimum-release-age=10080 # minutes

~/.bunfig.toml
[install]
minimumReleaseAge = 604800 # seconds

For Python with uv (which by now should be the default):

~/.config/uv/uv.toml
exclude-newer = "7 days"

Alas, pip only supports filtering by date, and only in version v26.0 and later, with:
pip install --uploaded-prior-to=2026-03-31 SomePackage.

That is a bit annoying so a shortcut for the 7-day gating would be
pip install --uploaded-prior-to=$(date -v-7d -u "+%Y-%m-%d") SomePackage.

There’s also pip-time-machine which helps you find out version for packages before a certain date.

The first step of Visual Studio Code install is deceptively simple: download the .deb file, double-click to open.

Trying to log into accounts causes a notification/error:

You’re running in a GNOME environment but the OS keyring is not available for encryption. Ensure you have gnome-keyring or another libsecret compatible implementation installed and running.

The keyring troubleshooting page provides some clues but it’s a bit clumsy to figure it out.

1. Problem 1: libsecret is not installed on a fresh Linux Mint v22.3.
   Solution: install with apt install libsecret-1-0 libsecret-1-dev libsecret-tools (not sure all of them are required).
2. A bit buried in the docs is this bit: “and ensure the default keyring (usually referred to as Login keyring) is unlocked”.
   Problem 2: there was no “Login” password keyring visible in Seahorse (the keyring manager).
   Solution: First, it’s very possible a restart (of gnome-keyring) after installing libsecret might have auto-fixed this issue, but I went ahead to try to create that and failed: the UI was not showing the new keyring, so restart was in the cards anyway.
   After restarting the computer, I was able to create the new Login password keyring and Visual Studio Code worked without any issues. It didn’t even require the --password-store="gnome-keyring" argument or startup setting.

Also thanks to this SO answer and this one too.

Claude has documentation on this, but I find the Azure Foundry’s documentation more useful because the instructions are more up-to-date with their UI (currently changing once more).

The one thing I wasn’t so comfortable with is setting the keys and all in env vars. If any process has access to the environment, it can extricate these values, even by mistake, and that’s not desirable.

Luckily, the ~/.claude/settings.json file support settings these, so here’s my example:

{
  "env": {
    "CLAUDE_CODE_USE_FOUNDRY": 1,
    "ANTHROPIC_FOUNDRY_BASE_URL": " https://<project-name>-resource.services.ai.azure.com/anthropic",
    "ANTHROPIC_FOUNDRY_API_KEY": "<key>",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "claude-sonnet-4-6",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "claude-opus-4-6"
  }
}

Couple of notes:

1. You can set either ANTHROPIC_FOUNDRY_RESOURCE or ANTHROPIC_FOUNDRY_BASE_URL. It’s a bit confusing because you create a project, say named foo-bar in Foundry, but the resource name is foo-bar-resource.
   At the end of the day copying the URL from the Foundry site seemed more straightforward.
2. I think it’s advisable to set names of the models deployed explicitly, hence ANTHROPIC_DEFAULT_SONNET_MODEL because Claude Code may have different defaults.
   I got this message on my first run: “The model claude-sonnet-4-5 is not available on your foundry deployment. Try /model to switch to claude-sonnet-4, or ask your admin to enable this model.”, and, fair enough, I had claude-sonnet-4-6 deployed.

The Bluetooth Manager in Linux Mint 22.3 detects the Logitech K380 keyboard, but doesn’t display the pairing code, or doesn’t display it for long enough (supposedly 10 seconds, but I didn’t see it at all).

There are two approaches:

1. The script from ValeriaRoyal/logitech-k380-bluetooth-linux-fix is the simplest version. Scans for the code and gives you 60 seconds to enter it.
   I didn’t try this one, but if I were to do it again it would be my first option.

2. From this StackExchange answer – using bluetoothctl, which comes installed on Linux Mint.

For the latter, the steps are:

$ bluetoothctl
Agent registered

[some prompt]# agent on
Agent is already registered

[some prompt]# scan on
Discovery started
....

Pay attention in the output for the input-keyboard line and get its MAC address. Then turn the scan off and pair the device:

[some prompt]# scan off
Discovery stopped
[some prompt]# trust <mac address>
...
[some prompt]# pair <mac address>
pair <mac address>
Attempting to pair with <mac address>
[CHG] Device <mac address> Connected: yes
[Keyboard K380]# [agent] Passkey: 987123

Enter the passkey it displays on your keyboard and it should be working!