Wednesday, August 26, 2026

SSH Commit Signing — Setup Notes

SSH Commit Signing — Setup Notes

Why

The infrastructure GitHub repo enforces an org-wide ruleset called "Signed commits in all branches" (required_signatures, scope: all refs, no bypass for anyone — including admins). Unsigned commits/pushes will be rejected on any branch.

GitHub's required_signatures rule accepts GPG, SSH, or S/MIME signatures interchangeably — it just checks for a verified signature, not a specific type. SSH is the simplest option since most devs already have an SSH key for GitHub auth (though GitHub treats "Authentication Key" and "Signing Key" as separate key roles — you must add your key as a signing key, even if it's already registered as an auth key).

1. Get or generate an SSH key

Reuse your existing GitHub auth key, or generate a dedicated signing key:

# check for an existing key
ls -la ~/.ssh/id_ed25519.pub

# or generate a new one (ed25519 recommended)
ssh-keygen -t ed25519 -C "your_email@example.com" -f ~/.ssh/id_ed25519_signing

2. Tell Git to use SSH for signing

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true

Optional — sign tags too:

git config --global tag.gpgsign true

3. Register the key with GitHub as a signing key

  1. Copy the public key: cat ~/.ssh/id_ed25519.pub
  2. GitHub → Settings → SSH and GPG keys → New SSH key
  3. Key type: Signing Key (not "Authentication Key" — a key can be added twice, once for each role, if you want to reuse the same key)

Create an allowed-signers file so git log --show-signature and local verification work, not just GitHub's UI:

echo "your_email@example.com $(cat ~/.ssh/id_ed25519.pub)" >> ~/.ssh/allowed_signers
git config --global gpg.ssh.allowedSignersFile ~/.ssh/allowed_signers

5. Verify it works

git commit --allow-empty -m "test: verify SSH commit signing"
git log --show-signature -1

Push the commit and check GitHub shows a "Verified" badge on it.

Notes

  • commit.gpgsign true signs every commit automatically — no need to pass -S each time.
  • If you use multiple machines, each needs its own key added to GitHub as a signing key (or copy the same private key, less ideal).
  • If a commit shows "Unverified" on GitHub after this, the most common cause is the key being registered as Authentication only, or the git author email not matching a verified email on your GitHub account.

Tuesday, February 10, 2026

disk size linux

Linux Root Disk Usage Checker

Linux Root Disk Usage Checker

Quick reference for checking and cleaning up a 100% full root (/) filesystem. Use with caution—avoid deleting system files!

Check Overall Usage

df -h /
df -h

Shows root filesystem usage in human-readable format (GB/MB).

Find Largest Directories

sudo du -h --max-depth=1 / | sort -rh | head -n 10

Lists top 10 largest top-level directories under /. Drill deeper: sudo du -h --max-depth=1 /var | sort -rh.
Common culprits: /var/log, /var/cache, /tmp, /home.

Locate Largest Files

sudo du -ah / 2>/dev/null | sort -rh | head -n 20

Shows 20 largest files system-wide (ignores permission errors).

Large files only: sudo find /var -type f -size +100M -exec ls -lh {} \;

Interactive Analyzer (ncdu)

Install:

# Debian/Ubuntu
sudo apt update && sudo apt install ncdu

# Fedora/RHEL
sudo dnf install ncdu

Run:

sudo ncdu /

Navigate with arrows, 'd' to delete, 'q' to quit. Perfect for visual exploration.

Safe Cleanup Tips

  • Logs: sudo journalctl --vacuum-time=7d (systemd) or sudo rm -rf /var/log/*.old
  • Cache: sudo apt autoclean (Debian) or check /var/cache
  • Temp: sudo rm -rf /tmp/* (safe if no processes using files)
  • Never delete: /bin, /etc, /lib, /sbin, /usr

Quick Copy-Paste Workflow

  1. df -h /
  2. sudo du -h --max-depth=1 / | sort -rh | head -n 10
  3. sudo ncdu /

Copy this entire HTML file and paste into your Google Blogger/HTML editor for instant blog post!

Wednesday, January 7, 2026

Optimizing Colima for Apple Silicon (M1/M2/M3) Macs - Switch from Intel Emulation to Native Performance

Published: January 7, 2026

If you're running Colima on an Apple Silicon Mac and experiencing slow performance, you might be running it in Intel emulation mode. This guide will show you how to switch to native ARM64 performance for dramatically better speed and efficiency.

The Problem

Many developers unknowingly run Colima with Intel emulation (x86_64), which:

  • ❌ Uses software emulation (slow)
  • ❌ Consumes more battery
  • ❌ Increases CPU usage
  • ❌ Results in slower container operations

The Solution

Use Apple's native Virtualization.framework with VirtioFS for optimal performance.

The Optimal Command

colima start --vm-type=vz --mount-type=virtiofs

Why This Works

--vm-type=vz (Apple Virtualization.framework):

  • ✅ Native ARM64 performance (no emulation)
  • ✅ Better macOS integration
  • ✅ Lower resource usage
  • ✅ Hardware acceleration
  • ✅ Improved battery life

--mount-type=virtiofs (VirtioFS):

  • ✅ Fastest file I/O compared to 9p or sshfs
  • ✅ Better performance for bind mounts
  • ✅ Optimal for development workflows

Step-by-Step Migration

1. Check Your Current Setup

colima list

Look for profiles running with x86_64 architecture.

2. Stop Intel Emulation Profiles

colima stop <profile-name>
# Example: colima stop intel

3. Delete Old Profiles (if needed)

colima delete <profile-name>
# Example: colima delete default

4. Start with Optimal Configuration

colima start --vm-type=vz --mount-type=virtiofs --arch=aarch64 --cpu=4 --memory=4 --disk=60

5. Verify the Configuration

colima status

You should see:

  • arch: aarch64
  • macOS Virtualization.Framework
  • mountType: virtiofs

Performance Comparison

ConfigurationArchitecturePerformanceBattery Usage
Intel Emulationx86_64🐌 Slow🔋 High
Native ARM64aarch64⚡ Fast🔋 Low

Additional Optimizations

Memory and CPU Allocation

Adjust based on your system specs:

# For 16GB+ RAM systems
colima start --vm-type=vz --mount-type=virtiofs --cpu=6 --memory=8

# For 32GB+ RAM systems  
colima start --vm-type=vz --mount-type=virtiofs --cpu=8 --memory=12

Persistent Configuration

Create a config file at ~/.colima/default/colima.yaml:

vmType: vz
mountType: virtiofs
cpu: 4
memory: 4
disk: 60
arch: aarch64
runtime: docker

Troubleshooting

"Cannot Update VM Type" Error

If you get this error, you need to delete the existing profile:

colima delete default --force
colima start --vm-type=vz --mount-type=virtiofs

Docker Context Issues

Ensure Docker is using the correct context:

docker context ls
docker context use colima

Verification Test

Run this to confirm everything is working:

docker run --rm hello-world

The output should show (arm64v8) indicating native ARM64 images are being used.

Benefits You'll Notice

  • 🚀 Faster container startup times
  • Improved build performance
  • 🔋 Better battery life
  • 🏃‍♂️ Snappier development workflow
  • 💾 Lower memory usage

Conclusion

By switching to --vm-type=vz --mount-type=virtiofs, you're leveraging Apple's native virtualization technology for optimal Docker performance on Apple Silicon Macs. This simple change can dramatically improve your development experience.


System Requirements:

  • Apple Silicon Mac (M1, M2, M3, or newer)
  • macOS 13.0 (Ventura) or later
  • Colima 0.6.0 or later

Resources:

Happy coding! 🎉