cross-posted from: https://leminal.space/post/34057102

Clik valves! I've been using these on my bike for a month, and I like them! The cores are compatible with Presta stems; so you can remove the core from your Presta valve, and put in Clik core. They also sell an adapter that threads onto a Schrader valve.

What are these good for? The stated benefits are:

• Ease of use: press the pump head on, and it clicks into place. With other valves you need to use a lock lever, or thread on the pump head. Not so with Clik. You also don't have the Presta lock nut loosening step.
• Less damage prone: the pin that extends out of a Presta valve can sometimes get bent. With Clik the pin is mostly recessed, like in a Schrader valve, so it's less likely to bend.
• More air flow compared to Presta.
• Supposedly Clik valves are less likely to be clogged by tire sealant in a tubeless setup.

For me only the first point matters. I've never damaged a Presta pin, and I don't use tubeless tires. Maybe I can inflate tires a little faster? It's hard to tell.

For those who do use tubeless tires: I heard a suggestion that Clik valves might make it easier to seat tires compared to Presta due to the increased airflow. But I've also heard that what you really want to do is remove the valve core entirely, and use an air compressor. Unfortunately I don't have personal experience to weigh in here.

But yes, the ease of use is worth it for me! I can click on the pump head and take it off one-handed. I get to skip the step of fiddling with the locking level while air is escaping. I went into this hoping to experience the satisfaction of a minor convenience on approximately a weekly basis, and that's exactly what I got.

That satisfaction is purchased at a price of about $6 per valve core, or about $3.40 if you buy in packs of 16. I'm hoping the cores will last a long time as I move them from tube to tube. I'll have to see if that pans out.

You need a special pump adapter

The trade-off is that you'll want to use a special pump head with Clik valves. The starter kit comes with an adapter that installs in a Schrader pump that does the job.

You can use a Presta pump head with Clik valves, so you aren't completely out of luck if you're away from your usual pump. But the Presta pump won't press the pin to open the valve, so you won't get an accurate tire pressure reading. And you're back to fiddling with that locking lever.

Schrader adapter

I didn't want to deal with taking the Clik adapter on and off the shared family bike pump; so I also got the Schrader adapters for my son's bike.

It is possible to remove Schrader valve cores. But it seems that instead of making a core that fits in a Schrader stem, Clik opted to make an adapter that sits on top of the existing Schrader core. In practice pumping with this adapter works just like pumping with a Clik core in a Presta stem.

Is it possible that having a pin in the adapter, that presses on the pin in the Schrader valve core has some fragility that might present in the future? I don't know! I'll update this post if I notice a problem.

Installation

The Clik starter kit comes with a tiny wrench with two openings to fit both Presta and Clik valve cores. (That's in addition to the pump head adapter I already mentioned, and two Clik cores.) It seems that Presta and Clik use different wrench sizes, so if you already have a Presta core wrench it might not fit the Clik cores.

Installation is easy: deflate the tire, remove one core, put in the other.

The Schrader adapters thread onto the valve, so that's one step. You don't need to deflate the tire for these.

Dust caps

Clik cores and Schrader adapters come with black rubber caps that also click on and off. These are nice! I have no complaints.

Just for fun I got some shiny aluminum dust caps that Clik also sells. I got the ones that thread on.

The aluminum caps do not fit on the Schrader adapters. That's something I wanted to check because I didn't think it was clear from the product description.

I was persuaded to get the aluminum caps because of the included features: they incorporate a tool to bleed air from the valve (a little fancier than using your finger), and a valve core wrench. The wrench opening seemed to be a little too small to me - I had considerable difficulty getting it onto a Clik valve core. So, kinda disappointing. The caps are shiny, which I don't mind. But if you just want functional dust caps, I think you'll be happy with the rubber ones.

Clik valves! I've been using these on my bike for a month, and I like them! The cores are compatible with Presta stems; so you can remove the core from your Presta valve, and put in Clik core. They also sell an adapter that threads onto a Schrader valve.

What are these good for? The stated benefits are:

• Ease of use: press the pump head on, and it clicks into place. With other valves you need to use a lock lever, or thread on the pump head. Not so with Clik. You also don't have the Presta lock nut loosening step.
• Less damage prone: the pin that extends out of a Presta valve can sometimes get bent. With Clik the pin is mostly recessed, like in a Schrader valve, so it's less likely to bend.
• More air flow compared to Presta.
• Supposedly Clik valves are less likely to be clogged by tire sealant in a tubeless setup.

For me only the first point matters. I've never damaged a Presta pin, and I don't use tubeless tires. Maybe I can inflate tires a little faster? It's hard to tell.

For those who do use tubeless tires: I heard a suggestion that Clik valves might make it easier to seat tires compared to Presta due to the increased airflow. But I've also heard that what you really want to do is remove the valve core entirely, and use an air compressor. Unfortunately I don't have personal experience to weigh in here.

But yes, the ease of use is worth it for me! I can click on the pump head and take it off one-handed. I get to skip the step of fiddling with the locking level while air is escaping. I went into this hoping to experience the satisfaction of a minor convenience on approximately a weekly basis, and that's exactly what I got.

That satisfaction is purchased at a price of about $6 per valve core, or about $3.40 if you buy in packs of 16. I'm hoping the cores will last a long time as I move them from tube to tube. I'll have to see if that pans out.

You need a special pump adapter

The trade-off is that you'll want to use a special pump head with Clik valves. The starter kit comes with an adapter that installs in a Schrader pump that does the job.

You can use a Presta pump head with Clik valves, so you aren't completely out of luck if you're away from your usual pump. But the Presta pump won't press the pin to open the valve, so you won't get an accurate tire pressure reading. And you're back to fiddling with that locking lever.

Schrader adapter

I didn't want to deal with taking the Clik adapter on and off the shared family bike pump; so I also got the Schrader adapters for my son's bike.

It is possible to remove Schrader valve cores. But it seems that instead of making a core that fits in a Schrader stem, Clik opted to make an adapter that sits on top of the existing Schrader core. In practice pumping with this adapter works just like pumping with a Clik core in a Presta stem.

Is it possible that having a pin in the adapter, that presses on the pin in the Schrader valve core has some fragility that might present in the future? I don't know! I'll update this post if I notice a problem.

Installation

The Clik starter kit comes with a tiny wrench with two openings to fit both Presta and Clik valve cores. (That's in addition to the pump head adapter I already mentioned, and two Clik cores.) It seems that Presta and Clik use different wrench sizes, so if you already have a Presta core wrench it might not fit the Clik cores.

Installation is easy: deflate the tire, remove one core, put in the other.

The Schrader adapters thread onto the valve, so that's one step. You don't need to deflate the tire for these.

Dust caps

Clik cores and Schrader adapters come with black rubber caps that also click on and off. These are nice! I have no complaints.

Just for fun I got some shiny aluminum dust caps that Clik also sells. I got the ones that thread on.

The aluminum caps do not fit on the Schrader adapters. That's something I wanted to check because I didn't think it was clear from the product description.

I was persuaded to get the aluminum caps because of the included features: they incorporate a tool to bleed air from the valve (a little fancier than using your finger), and a valve core wrench. The wrench opening seemed to be a little too small to me - I had considerable difficulty getting it onto a Clik valve core. So, kinda disappointing. The caps are shiny, which I don't mind. But if you just want functional dust caps, I think you'll be happy with the rubber ones.

There's a certain turn I make regularly, where I need to merge into a traffic lane to turn left on a moderately-trafficked road. I always feel like I don't get a good awareness of cars coming from behind by turning my head. I realized: I should have a mirror! Not just for that turn, but for safety generally. But what kind? I tried three: a bar-end, a bar-mount, and a glasses-mount. I thought I'd share my impressions.

(What actually happened is I liked the first mirror that I got, but my son snagged it. So I thought I'd try a different kind, but I didn't like that one. So all in all, three mirrors.)

The mirrors:

• the bar-end: a Mirrycle Mirror - $25
• the bar-mount: I got one that wasn't labeled for retail; but I'm pretty sure it's the same thing as this Cosmoing Anti-Glare Handlebar Mirror - $20
• the glasses / helmet mount: Take A Look Active Original Mirror - $22

The post picture shows the first two mirrors. Here is the Take A Look Active:

Field of View

The easiest factor to assess objectively is field-of-view (FOV). So I'll start there. There are three factors that affect FOV:

• mirror size (bigger means you see more)
• curvature (convex mirrors make objects appear more distant, but you see more)
• distance from your eye to the mirror (closer means you see more)

Here's a side-by-side comparison of the Mirrycle (the round one), and the (likely white-label) Cosmoing (the one that gives motorcycle vibes):

The Mirrycle has greater curvature, but the Cosmoing is bigger and closer, so you can see more.

I also managed to get a photo of the Take A Look that gives a fair representation of its FOV. (The white Jeep is parked slightly closer in this photo.)

The Take A Look is flat, and very small. It has the smallest FOV of the three, despite being much closer to my face. But it's easier to use small head movements to see different angles. More on that in a bit.

(While shopping I saw that there a couple of Etsy shops with glasses-mounted mirrors inside bottle caps, such as the Beer View Mirror. Those are tempting. AFAICT they also use flat mirrors, and look a little smaller than Take A Look. So the FOV is probably a little smaller.)

Viewing Angle

The Mirrycle sticks out the furthest from the bike, which gives it the best position for getting an angle to see directly behind you. The closer in the mirror, the more of the rear view is blocked by your body.

Even with the telescoping arm fully extended, the Cosmoing doesn't get out as far as the Mirrycle since it's reaching over my grip, brake lever, and motor controller. If I had been more committed I could have swapped positions of the mirror and motor controller to get another couple of inches. Maybe that would get it into a position to match the Mirrycle. I'm not sure.

The Take A Look is so close to my face that I have to angle it out quite a bit to get to a point where I'm not just looking at my ear. I generally have to tilt my head a little to compensate to see behind me.

Vibration

Any bumps can vibrate the mirrors in a way that makes them more difficult to see in.

The Mirrycle is great in this respect - it's steady even on a somewhat bumpy road. Probably because it clamps inside the bar very tightly.

The Cosmoing was terrible about vibrations in my testing. But that might be partly my fault. There is a spring inside the mounting arm that is probably intended to absorb vibrations, and I think I over-tightened the bolt on that connection. I didn't think to try a different adjustment until after I'd returned the mirror. I'm sorry; I'm not the best reviewer!

The Take A Look is quite good. I'm not sure it's as vibration-resistant as the Mirrycle, but vibrations don't bother me nearly as much as they did with the Cosmoing.

Installation

The Mirrycle inserts in the the end of a handlebar, and comes with a wedge that presses inside the bar via tension from a bolt that you adjust. It's very secure, and pretty easy to install. You need grips that are open on the end. Usually lock-on grips come with plugs that you can pop out, which will work nicely. If you have slide-on grips it's usually easy to cut the end, since it's just rubber. I've heard you can thwack the end with a mallet to make the handlebar punch through the grip. My son snagged this mirror, (he rides to school every day, he needs it more) but although he had Bontrager lock-on grips, they had closed ends that I found to be quite resistant to cutting. That turned into an excuse to give him the grips from my e-bike that I don't love, and to get Ergon grips for myself.

When I tested the Mirrycle on my e-bike I ran into a problem where the wedge hit a bump where the wire for my motor controller is routed through a hole to run inside the handlebar. Fortunately the Mirrycle comes with a smaller-sized wedge for narrower handlebars, and that wedge fit fine.

The Cosmoing clamps onto a handlebar simply enough. The product description indicates there is a joint right next to the clamp that rotates 360°. That's misleading: you have to entirely remove the bolt that runs through that joint to rotate it, and there is a spline that allows rotating in increments. That's the same connection that holds the spring that I mentioned.

The Take A Look has three rubberized legs that slide onto alternate sides of the temple of a pair of glasses. It can attach to a helmet with an adapter, which I didn't try. I always ride with a pair of basic safety glasses anyway, so attaching to those was convenient for me. It takes some slightly fiddly wire bending to set everything up the first time. Once it's set up it's quite secure while riding. It's pretty easy for me to take on and off the glasses, and to adjust. I do spend more time adjusting this mirror than the bicycle-mounted mirrors.

Trade-offs

The Cosmoing has the best FOV, and is the least goofy-looking option. But I was disappointed by the vibrations. Plus the shop charged me $40, which seemed like too much for what I found when I opened the box. That probably soured my impression. If proper spring adjustment really eliminates vibrations then I might be selling this one short.

The Mirrycle is the most stable, with the second-best FOV. It sticks out the farthest from the bike for the best viewing angle. It's the most difficult to remove or get out of the way if you want to do something like put your bike in a bike locker. (The Cosmoing mirror attachment rotates pretty easily, so you can rotate it out of the way.)

Edit: The Mirrycle can be adjusted on the go in all axes. The Cosmoing is more difficult to adjust on the Y-axis because the 360° joint for that axis requires removing a bolt. And putting that bolt back in is pretty difficult due to the spring that the bolt compresses.

The bike-mounted mirrors have much wider FOV than the glasses-mounted mirrors. But it's more difficult to move around to see different angles. If you happen to be turning the mirror won't be pointed in the right direction, which can make it temporarily unusable.

With the Take A Look I can use small head movements to see any angle I want, and this gets easier with practice. But I do have to tilt my head a little to get my ear out of the way, so I don't have much of a passive view of cars coming from behind.

I can easily use one Take A Look mirror with multiple bikes. During my testing I used a bike share service, and I rode my son's bike to the shop for service. I had my mirror with me both times.

My Impressions

I think the Mirrycle would give me the best chance of noticing a car coming from behind.

I think the Take A Look is the most flexible in terms of my ability to see where I want to see, and for use with multiple bikes.

I ended up settling on the Take A Look. I've been using it for about a month. That's given me time to get used to moving my head to see everything, quickly adjusting it when I put it on, and transporting it while I'm off the bike. It does get me the weirdest looks. Even the younger bike enthusiasts I've been hanging out with have to ask because they don't know what it is. And then I had one guy inform me that I can also look over my shoulder. But I can see behind me, and that's what matters!

BART trains have these spots for bikes, with adjustable straps to hold bikes upright. But with a strap or two secured the bike still rolls back and forth as the train moves, which lets it knock into things.

The way to prevent rolling is to hold down a brake lever. You can do that with a large velcro strap, or your hand. But if you don't have a strap, and you want to sit down, you can wrap your helmet straps the handle, and connect the buckle. If needed you can twist the straps to make them shorter. You don't have to press the lever all the way down, just enough to stop the wheel from rolling.

Is there a better place for bicycling shitposts?

Behold, the affordable and flexible (literally) cargo solution! The avocado cardboard produce box from Costco!

It holds multiple kilograms, while stationary!

I've been working on setting up storage for a new bike. The MIK adapter plate I'm planning to use for mounting arrived before the basket I plan to attach to it. In the interest of getting some kind of storage on there, but mostly because I wanted to tinker with the adapter plate, I grabbed the first cargo-shaped thing that came to hand.

I haven't had time to try ride testing this setup because the proper basket did actually just arrive.

cross-posted from: https://leminal.space/post/28955576

I learned how to do this recently, and I wanted to share. Once you know what to do VPN confinement is easy to set up on NixOS.

The scenario: you want selected processes to run through a VPN, but you want everything else to not run through the VPN. On Linux you can do this with a network namespace. That's a kernel feature that defines a network stack that is isolated from your default network stack. Processes can be configured to run in a new namespace, and when they do they cannot access the usual not-VPN-protected network interfaces. Network namespaces work along with other types of namespaces, like process namespaces, to allow Docker containers to function almost as though they are separate machines from the host system. Actually Docker containers are regular processes that are carefully isolated using namespaces, cgroups, and private filesystems. Because of that isolation Docker containers are a popular choice for VPN confinement. But since all you really need is network isolation you can skip the middleman, and use network namespaces directly.

There is a third-party NixOS module that automates this, VPN-Confinement. Here's an example that runs a Borg backup job through a VPN connection. (This example also uses the third-party sops-nix module to encrypt VPN credentials.)

{ config, ... }:

let
  vpnNamespace = "wg";
in
{
  # Define the network namespace for VPN confinement. Creates a VPN network
  # interface in the namespace; creates a bridge; sets up routing; creates
  # firewall rules to prevent DNS leaking. The VPN-Confinement module requires
  # using Wireguard as the VPN protocol.
  vpnNamespaces.${vpnNamespace} = {
    enable = true;
    wireguardConfigFile = config.sops.secrets.wireguard_config.path;
  };

  # Set up whatever service should run via VPN
  services.borgbackup.jobs.homelab = {
    paths = "/home/jesse";
    encryption.mode = "none";
    environment.BORG_RSH = "ssh -i /home/jesse/.ssh/id_ed25519";
    repo = "ssh://offsite.sitr.us/backups/homelab";
    compression = "auto,zstd";
    startAt = "daily";
  };

  # Modify the systemd unit for your service to run its processes in the VPN
  # namespace.
  #
  # - sets Service.NetworkNamespacePath in the systemd unit
  # - sets Service.InaccessiblePaths = [ "/run/nscd" "/run/resolvconf" ] to prevent DNS leaking
  # - adds a dependency to the unit that brings up the VPN network namespace
  #
  # I found the name of the systemd service that services.borgbackups.jobs
  # creates by looking at the Borg module source. You can find the source for
  # NixOS modules by searching for config options on https://search.nixos.org/options
  systemd.services.borgbackup-job-homelab = {
    vpnConfinement = {
      enable = true;
      inherit vpnNamespace;
      # `inherit vpnNamespace;` has the same effect as `vpnNamespace = vpnNamespace;`
      # I used a variable to be certain that the value here matches the name
      # I used to set up the namespace on line 11.
    };
  };

  # Load your wireguard config file however you want. Your VPN provider probably
  # supports wireguard, and will likely generate a config file for you.
  sops.secrets.wireguard_config = {
    sopsFile = ./secrets.yaml;
    owner = "root";
    group = "root";
  };
}

This setup assumes using the Wireguard VPN protocol, and assumes that programs you want to be VPNed are run by systemd. VPN providers mostly support Wireguard, including Tailscale. But my understanding is that Tailscale's mesh routing requires additional setup beyond creating a Wireguard interface. So you'd likely want a different setup for confinement with Tailscale. You can run the Tailscale client in a network namespace (there is a start on such a setup here); or you might use Tailscale's subnet router feature to blend VPN and local network traffic instead of selective confinement.

Normally when you turn on a VPN your VPN client software creates a network interface that transparently sends traffic through an encrypted tunnel, and configures a default route to send network traffic through that interface. So traffic from all programs is routed through the tunnel. VPN-Confinement creates that network interface in the isolated namespace, and sets that default route in the namespace, so that only programs running in the namespace are affected. There is much more detail in this blog post. The VPN-Confinement module differs from the setup in that post in a couple of ways: it has some extra setup to block DNS requests that aren't properly tunneled; it creates a network bridge instead of a simple virtual ethernet cable for port forwarding; and it provides more options for firewall and routing configuration.

VPN-Confinement has an option to forward ports from the default network stack into the VPN namespace. This is useful if you want all outbound traffic to go through the VPN, but you want to accept inbound traffic from programs on the host, or from other machines on your local network, or anywhere else. This is handy if, for example, you're running a program on a headless server that provides a web UI for remote administration. Here's an expanded VPN namespace example:

vpnNamespaces.${vpnNamespace} = {
  enable = true;
  wireguardConfigFile = config.sops.secrets.wireguard_config.path;

  # Forward traffic to specified ports from the default network namespace to
  # the VPN namespace.
  portMappings = [{ from = 8080; to = 8080; }];
  accessibleFrom = [
    # Accept traffic from machines on the local network, and route through the
    # mapped ports.
    "192.168.1.0/24"
  ];
};

Requests to mapped ports from the host machine need to be addressed to the network bridge that VPN-Confinement sets up. You can configure its addresses using the bridgeAddress and bridgeAddressIPv6 options. By default the addresses are 192.168.15.5 and fd93:9701:1d00::1. If you're configuring addresses elsewhere in your NixOS config you can use an expression like this:

url = "http://${config.vpnNamespaces.${vpnNamespace}.bridgeAddress}:8080/";

If you look at the source for VPN-Confinement you'll see that namespace configuration and routing require a lot of stateful ip commands. I think it would be nice if there were an alternative, declarative interface to iproute2. But VPN-Confinement is able to encapsulate the stateful stuff in systemd ExecStart and ExecStopPost scripts.

I ran into an issue where mDNS stopped working while the VPN network namespace was active. I fixed that problem by configuring Avahi to ignore VPN-Confinement's network bridge:

services.avahi.denyInterfaces = [ "${vpnNamespace}-br" ];

Edit 2025-11-23: I deleted a comment that implied that if the VPN namespace string doesn't match in the two places where it is used traffic won't be tunneled. I tested again, and if the names don't match the service that is supposed to be protected won't start. You'll see an error like, Failed to restart test-unit.service: Unit wrong-name.service not found.. If you bypass VPN-Confinement by hand, and set Service.NetworkNamespacePath to a path that doesn't exist the unit will fail with an error like, test-unit.service: Failed to open network namespace path /run/netns/wrong-name: No such file or directory.

Ok I'll come clean - this is my car

Logan Smith's Rust videos are excellent - I'm happy to see a new one is up!

Some app launchers these days run each app in a new systemd scope, which puts the app process and any child processes into their own cgroup. For example I use rofi which does this, and I noticed that fuzzel does also. That is handy for tracking and cleaning up child processes!

You can see how processes are organized by running,

$ systemctl --user status

I think that's a quite useful way to see processes organized. Looking at it I noticed a couple of scopes that shouldn't still be running.

Just for fun I wanted to use this to try to script a better killall. For example if I run $ killscope slack I want the script to:

1. find processes with the name "slack"
2. find the names of the systemd scopes that own those processes (for example, app-niri-rofi-2594858.scope)
3. kill processes in each scope with a command like, systemctl --user stop app-niri-rofi-2594858.scope

Step 2 turned out to be harder than I liked. Does anyone know of an easy way to do this? Ideally I'd like a list of all scopes with information for all child processes in JSON or another machine-readable format.

systemctl --user status gives me all of the information I want, listing each scope with the command for each process under it. But it is not structured in an easily machine-readable format. Adding --output json does nothing.

systemd-cgls shows the same cgroup information that is shown in systemctl --user status. But again, I don't see an option for machine-readable output.

systemd-cgtop is interesting, bot not relevant.

Anyway, I got something working by falling back on the classic commands. ps can show the cgroup for each process:

$  ps x --format comm=,cgroup= | grep '^slack\b'
slack           0::/user.slice/user-1000.slice/user@1000.service/app.slice/app-niri-rofi-2594858.scope
slack           0::/user.slice/user-1000.slice/user@1000.service/app.slice/app-niri-rofi-2594858.scope
slack           0::/user.slice/user-1000.slice/user@1000.service/app.slice/app-niri-rofi-2594858.scope
...

The last path element of the cgroup happens to be the scope name. That can be extracted with awk -F/ '{print $NF}' Then unique scope names can be fed to xargs. Here is a shell function that puts everything together:

function killscope() {
    local name="$1"
    ps x --format comm=,cgroup= \
        | grep "^$name\b" \
        | awk -F/ '{print $NF}' \
        | sort | uniq \
        | xargs -r systemctl --user stop
}

It could be better, and it might be a little dangerous. But it works!

A short post on how variable names can leak out of macros if there is a name collision with a constant. I thought this was a delightful read!

Difftastic is a diff tool that uses treesitter parsing to compare code AST nodes instead of comparing lines. After following the instructions for use with git I'm seeing some very nice diffs when I run git diff or run git show --ext-diff. I thought it would be nice to get the same output for hunk diffs in the fugitive status window, and in fugitive buffers in general (which use the git filetype). But I haven't seen any easy way to do it. Has anyone got a setup like this?

I can run a command in neovim like :Git show --ext-diff to get difftastic output in a buffer. I'm thinking maybe I can set up fugitive to use the --ext-diff flag by default, or set up some aliases. But there is no syntax highlighting for the difftastic outputs since the ANSI color codes that difftastic uses in interactive terminal output don't work in neovim, and the syntax highlighting for the git filetype assumes standard diff output which is not compatible with difftastic output. For me losing colors is not a worthwhile trade for the otherwise more readable diff output.

My best idea right now is to set up a new filetype called difftastic, and write a new treesitter grammar or syntax plugin for it. Then set up some kind of neovim configuration to feed output from difftastic into buffers with the new filetype.

There is an open neovim issue discussing adding syntax-aware diffs directly to neovim, but that doesn't seem to have gone anywhere.