DEV Community: street food Chinese

The Uninstall That Actually Works: A Practitioner’s Guide to Cleaning Up Windows Apps

street food Chinese — Mon, 02 Nov 2026 07:08:10 +0000

The Uninstall That Actually Works: A Practitioner’s Guide to Cleaning Up Windows Apps

I’ve lost count of how many times a “simple” uninstall left me with a broken PATH, a zombie service, or a registry entry that made my next install fail. The Windows “Add or Remove Programs” panel is a polite fiction — it removes the files the installer wants to remove, not the ones it should. After years of fighting leftover DLLs and orphaned scheduled tasks, I’ve built a repeatable, paranoid workflow for clean uninstalls. Here’s what actually works, including the failure modes I’ve hit and the exact commands I use.

Step 1: Inventory Before You Nuke

The first mistake is clicking “Uninstall” without knowing what you’re dealing with. A clean uninstall starts with a full inventory of the app’s footprint. I do this on every machine, even for small utilities.

Open an elevated PowerShell (Admin) and run:

# List all installed apps with their uninstall strings
Get-ItemProperty "HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*" |
  Select-Object DisplayName, DisplayVersion, UninstallString, InstallLocation |
  Where-Object { $_.DisplayName -like "*YourAppName*" } |
  Format-List

# Also check per-user installs (common for MSIX or per-user MSI)
Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*" |
  Select-Object DisplayName, UninstallString |
  Where-Object { $_.DisplayName -like "*YourAppName*" } |
  Format-List

This gives me the official uninstall string. But that’s just the starting point. I also check for services, scheduled tasks, and drivers that the app might have registered:

# Services and scheduled tasks
Get-Service | Where-Object { $_.DisplayName -like "*YourAppName*" -or $_.Name -like "*YourAppName*" }
Get-ScheduledTask | Where-Object { $_.TaskName -like "*YourAppName*" }

I’ve seen apps register a Windows service under a completely different name (e.g., “UpdateAgent” for a PDF reader). So I also grep the registry for the app’s vendor name or a unique file path. It’s tedious, but it beats a half-removed app that breaks your next install.

Step 2: Run the Official Uninstaller, Then Hunt the Leftovers

Run the official uninstaller first — always. For MSI-based apps, use the /x flag with the product code or the /uninstall flag. For most apps, you can invoke the UninstallString directly from the registry. Here’s a safe way to do it programmatically:

# Run the uninstaller silently (if supported) — replace with your app's string
$uninstallString = (Get-ItemProperty "HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*" |
  Where-Object { $_.DisplayName -eq "YourAppName" }).UninstallString
Start-Process cmd.exe -ArgumentList "/c $uninstallString /quiet /norestart" -Wait

But here’s the thing: the official uninstaller is not the end. After it finishes, I immediately check what’s left. The most common leftovers I’ve seen:

Registry keys under HKCU\Software\VendorName or HKLM\Software\WOW6432Node\VendorName (for 32-bit apps on 64-bit systems).
ProgramData folders — apps love to cache updates there.
AppData\Local and AppData\Roaming — config files, logs, and crash dumps.
Driver store entries for kernel drivers (these are the worst — they persist even after reboot).

Here’s a quick sweep I run after the uninstaller exits:

# Check common leftover locations
$paths = @("$env:ProgramFiles", "${env:ProgramFiles(x86)}", "$env:ProgramData", "$env:LOCALAPPDATA", "$env:APPDATA")
foreach ($p in $paths) {
  Get-ChildItem -Path $p -Filter "*YourAppName*" -Recurse -ErrorAction SilentlyContinue |
    Select-Object FullName
}

# Check the registry for vendor keys
Get-ChildItem "HKCU:\Software" | Where-Object { $_.PSChildName -like "*VendorName*" }
Get-ChildItem "HKLM:\Software" | Where-Object { $_.PSChildName -like "*VendorName*" }
Get-ChildItem "HKLM:\Software\WOW6432Node" | Where-Object { $_.PSChildName -like "*VendorName*" }

If you find anything, don’t delete it yet. Rename it first (e.g., append .bak). This lets you test if the app actually needed it — if your system works fine for a week, then delete the backup.

Step 3: The Failure Modes That Bite You

I’ve hit three distinct failure modes that make a “clean” uninstall a lie. Here’s how to handle each.

Failure mode 1: The “silent” uninstaller that isn’t.

Many apps claim /quiet support, but they actually spawn a GUI or a UAC prompt that hangs your script. My fix: run the uninstaller interactively first, watch what it does, then script it. If you must script it, use a timeout:

$proc = Start-Process -FilePath $uninstallString -ArgumentList "/quiet" -PassThru -Wait
if ($proc.ExitCode -ne 0) { Write-Warning "Uninstaller returned $($proc.ExitCode)" }

Failure mode 2: Leftover services that auto-start on boot.

I once had an app that left a service pointing to a deleted executable. The service failed to start, but the error kept popping up in Event Viewer. The fix is to remove the service after the uninstaller runs, because the uninstaller might try to stop it and fail. Here’s how I remove a stubborn service:

# Stop and delete a service (run as Admin)
$svcName = "YourAppService"
Stop-Service -Name $svcName -Force -ErrorAction SilentlyContinue
sc.exe delete $svcName

Note: sc.exe delete is more reliable than Remove-Service in older PowerShell versions. Also, check HKLM\SYSTEM\CurrentControlSet\Services for any keys that reference the app’s path.

Failure mode 3: The reboot requirement.

Some apps (especially driver installers) need a reboot to finish removal. If you skip the reboot, the driver files remain in C:\Windows\System32\drivers and can cause conflicts. My rule: if the uninstaller says “reboot required,” reboot before you clean up leftover files. Otherwise, the system might still be using the files you’re about to delete, and you’ll get access denied errors.

Step 4: Manual Cleanup — The “Nuclear” Pass

After the official uninstaller and the service cleanup, I do a manual pass. This is where I delete the leftovers I found in Step 2. But I’m careful about what I delete. Here’s my priority list:

AppData folders — safe to delete if the app is gone and you don’t care about settings.
ProgramData folders — check for shared components; if another app uses them, leave them.
Registry keys — only delete vendor keys that you’ve confirmed are orphaned. Use reg.exe delete or Remove-Item in PowerShell.
Driver files — only after reboot, and only if you’re sure no other device uses them.

For registry cleanup, I use a targeted approach. I don’t blindly delete entire vendor trees because some apps share them (e.g., Adobe or Microsoft). Here’s a safe snippet:

# Backup the registry key first, then remove it
$keyPath = "HKCU:\Software\YourVendor\YourApp"
if (Test-Path $keyPath) {
  reg.exe export $keyPath "$env:TEMP\YourApp_registry_backup.reg" /y
  Remove-Item -Path $keyPath -Recurse -Force
}

The backup is non-negotiable. I’ve had to restore a registry key after discovering that a shared DLL was still being referenced by another app.

Step 5: Verify the Uninstall Is Actually Clean

The final step is verification. I don’t trust the uninstaller’s exit code. I check the system state:

# Verify no traces remain
$appName = "YourAppName"
$checks = @(
  "HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*",
  "HKCU:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*",
  "HKLM:\Software\YourVendor",
  "HKCU:\Software\YourVendor",
  "$env:ProgramFiles",
  "$env:ProgramData",
  "$env:LOCALAPPDATA",
  "$env:APPDATA"
)
foreach ($check in $checks) {
  $found = Get-ItemProperty $check -ErrorAction SilentlyContinue |
    Where-Object { $_.DisplayName -like "*$appName*" -or $_.PSPath -like "*$appName*" }
  if ($found) { Write-Host "Leftover found: $($found.PSPath)" }
}

I also check the Start Menu shortcuts and the Windows “Apps” list via Get-AppxPackage if it was a Store app. If everything comes back empty, I consider the uninstall clean.

Related resource

If you’re dealing with a specific command-line tool that’s hard to uninstall because it ships as a single binary with no installer, the process is a bit different — you’re just deleting the folder and any config in your user profile. I recently used hemmeligorg hemmeligapp cli v1 0 2 from GitVaults, and the uninstall was refreshingly simple: delete the executable, remove the .config file from %APPDATA%, and you’re done. GitVaults is a good source for Windows tools that don’t pollute your system with registry entries — worth checking if you prefer apps that respect your machine.

Caveat

This workflow is based on my experience with Windows 10/11 and common MSI, NSIS, and custom installers. Your mileage may vary — some enterprise apps use custom installation frameworks that hide files in odd places, and some drivers are notoriously sticky. If you spot a step that’s wrong or a better technique, I’d genuinely like to hear it. Corrections and edge cases from real-world usage are what make this guide better.

Mirror Failover: When Your "Redundant" Setup Isn't Actually Redundant

street food Chinese — Fri, 30 Oct 2026 07:05:45 +0000

Mirror Failover: When Your "Redundant" Setup Isn't Actually Redundant

I've spent the last decade running storage systems for small-to-mid-sized businesses, and if there's one lesson I've learned the hard way, it's this: a mirror without a tested failover path is just a more expensive way to lose data. You'd think that having two disks, two controllers, or two nodes means you're safe. Then the day comes when your primary silently degrades, and you discover your "automatic" failover was never wired to the thing that actually broke.

Let me walk you through what mirror failover really looks like in practice—the commands, the failure modes, and the edge cases that documentation glosses over.

The Difference Between "Mirrored" and "Highly Available"

First, a distinction that matters. A RAID-1 mirror is not the same as a failover cluster. RAID-1 gives you redundancy at the block level—if one disk dies, the other still has your data. But your operating system, your file system, and your application are still running on whatever controller was active. If that controller hangs, you've got a paperweight with a healthy disk inside.

True mirror failover means that when the active path goes away, a standby path takes over without human intervention and without data loss. That requires three things working together:

A detection mechanism (heartbeat, SCSI reservation, or network ping)
A promotion mechanism (the standby takes the active role)
A quorum or fencing rule (so you don't get split-brain—two nodes both thinking they're primary)

I've seen more split-brain incidents than I care to count. The classic symptom: both nodes write to the same LUN, and now you have two divergent versions of your database. That's not failover; that's corruption with extra steps.

A Practical Failover Workflow (Linux + DRBD)

Let me show you a real setup I use for a small file server. It's DRBD (Distributed Replicated Block Device) over two nodes, with a floating IP and a simple heartbeat script. Nothing fancy, but it works.

Here's the DRBD resource config, /etc/drbd.d/r0.res:

resource r0 {
    protocol C;
    on node1 {
        device    /dev/drbd0;
        disk      /dev/sdb1;
        address   192.168.10.11:7788;
        meta-disk internal;
    }
    on node2 {
        device    /dev/drbd0;
        disk      /dev/sdb1;
        address   192.168.10.12:7788;
        meta-disk internal;
    }
}

After you've initialized both sides with drbdadm create-md r0 and brought them up, the primary is set manually. But for failover, you want a script that does this on node2 when node1 goes silent:

#!/bin/bash
# /usr/local/bin/failover.sh - run on the standby node

DRBD_RESOURCE="r0"
FLOATING_IP="192.168.10.20"
PEER_IP="192.168.10.11"
PEER_PORT="7788"

# Check if peer is alive
if ! nc -z -w 3 $PEER_IP $PEER_PORT 2>/dev/null; then
    logger "Peer $PEER_IP unreachable, promoting DRBD resource"

    # Promote to primary
    drbdadm primary $DRBD_RESOURCE

    # Mount the filesystem
    mount /dev/drbd0 /mnt/data

    # Bring up the floating IP
    ip addr add $FLOATING_IP/24 dev eth0
    arping -c 3 -A -I eth0 $FLOATING_IP

    logger "Failover complete, floating IP $FLOATING_IP is now local"
fi

Now, here's the catch. That nc -z check is a single point of failure. What if node1 is alive but its network path to node2 is down? Then node2 promotes, and node1 is still running—now you have two primaries. That's split-brain. The fix is a fencing mechanism: a STONITH device (Shoot The Other Node In The Head), or at minimum, a shared quorum disk that only one node can hold a reservation on.

I learned this the hard way when a switch port died, and both nodes decided they were primary. The DRBD metadata got confused, and I had to manually resolve the conflict with drbdadm disconnect r0 and then drbdadm -- --force primary r0 on the side I trusted. Not fun at 2 AM.

Failure Modes You Won't Find in the Brochure

Let me list the ones that actually bite:

Silent I/O errors. The disk is still spinning, but it returns read errors. DRBD marks the peer as "Outdated" only after a certain number of failures. If your application doesn't check for read errors, you might be serving corrupt data for hours before anyone notices.

Stale heartbeat. Your failover script checks a port, but the service behind that port is hung. The port is open, the process is dead. Your script says "all good," but your users see timeouts. You need to check application-level health, not just TCP connectivity.

Partial network partition. Node1 can talk to node2, but node2 can't talk to node1. Both see each other as down. This is where quorum rules matter. With two nodes, you have no majority. I recommend a tie-breaker: a third node that acts as a witness, or a shared disk that only one node can lock.

Failover during a write. This is the nastiest one. If node1 crashes mid-write, and node2 promotes, node2's DRBD may have the data in its write-ahead log but not yet flushed to disk. Protocol C (synchronous) guarantees that a write is acknowledged only after both nodes have it in memory. But if node1 dies before acknowledging, node2 might have the data but not the acknowledgment. In that case, you must decide: serve the write (and risk losing it if node2 also dies) or reject it. I always choose to serve it, because a partial write is better than a full outage—but you need to know your application can handle a torn write.

The PowerShell Side: Windows Storage Spaces and Failover Clustering

Not everyone is on Linux. On Windows, I've used Storage Spaces with a two-node failover cluster. The setup is different, but the principles are the same. Here's a snippet to check the health of a cluster role and force a move if needed:

# Check cluster health and force failover if needed
$cluster = Get-Cluster -Name "FileCluster01"
$role = Get-ClusterGroup -Cluster $cluster -Name "FileServer"

if (-not $role.IsStateful) {
    Write-Host "Role is not stateful, checking node status..."
    $nodes = Get-ClusterNode -Cluster $cluster
    foreach ($node in $nodes) {
        if ($node.State -ne "Up") {
            Write-Host "Node $($node.Name) is down. Attempting to move role."
            Move-ClusterGroup -Name "FileServer" -Node $node.Name -Force
            break
        }
    }
} else {
    Write-Host "Role is currently owned by: $($role.OwnerNode.Name)"
}

The edge case here is that Move-ClusterGroup -Force can cause a brief outage if the storage is not in a healthy state. I've seen it fail with "The cluster resource could not be brought online because the dependent resource is not available." That usually means the disk resource is still marked as "Pending" or "Failed" after the node came back. The fix is to manually reset the disk resource:

Get-ClusterResource -Name "Cluster Disk 1" | Set-ClusterResource -Status Offline
Get-ClusterResource -Name "Cluster Disk 1" | Set-ClusterResource -Status Online

But here's the thing: if the disk is actually corrupt, that command will just bring it online into a corrupted state. Always run chkdsk /f on the underlying volume first, before you re-add it to the cluster.

Edge Case: Failover When the Primary Is Not Dead

Here's a scenario that stumps most people. The primary node is alive, the network is fine, but the application has crashed. In a traditional mirror setup, your failover script only triggers on node loss. So your app is down, but your mirror is perfectly healthy. You're not redundant; you're just backed up.

The fix is a health-check loop that monitors the application, not just the node. On Linux, that might be a systemd timer that checks if your NFS export is responding. On Windows, you'd use a resource monitor in the cluster that runs a custom DLL or PowerShell script. The script should return non-zero if the app is unresponsive, and the cluster will then fail over the role.

I once had a customer whose PostgreSQL instance was hung due to a deadlock. The node was up, the network was up, but the database was unresponsive. Their failover script didn't check the database, so the mirror stayed passive. They lost six hours of availability because no one had thought to test "what happens when the app hangs, not the OS."

Testing Your Failover (Do It Now, Not at 3 AM)

You cannot test failover in production. You can, however, test it in a staging environment that mirrors your production topology. Here's my minimum test suite:

Kill the primary node (power off, not graceful shutdown). Verify the standby promotes within the expected time.
Unplug the network cable from the primary. Verify the standby promotes but does not cause split-brain.
Kill the application process on the primary, not the node. Verify the health check catches it and fails over.
Write a file to the primary, then immediately kill it. Verify the file is present on the standby after failover, and that its content is intact.

If any of these tests fail, you have a bug in your failover logic. Fix it before you need it.

Related resource

If you're dealing with Windows-based tools and need a reliable terminal emulator that handles multiple sessions cleanly—especially when you're juggling cluster nodes and storage consoles—check out ys ll uniterm 1 9 5 on GitVaults. It's a solid utility for keeping your failover sessions organized without the bloat of full IDE environments.

Caveat

I've written this from my own experience, and I'm sure I've missed some corner cases or made assumptions that don't hold in your environment. If you spot an error, or if your failover setup handles something differently, please correct me. The whole point of this article is to get you thinking about what can break—so if you've seen a failure mode I didn't cover, I'd genuinely like to hear about it.

The CLI vs GUI Debate: What I Actually Use When the Network Breaks

street food Chinese — Wed, 28 Oct 2026 07:05:39 +0000

The CLI vs GUI Debate: What I Actually Use When the Network Breaks

绑 I’ve been running Windows-based IT infrastructure for over a decade, and I’ve lost count of how many times I’ve had to explain why I still open a terminal when there’s a perfectly good GUI sitting right there. The truth is, the CLI vs GUI argument isn’t about which is “better” in some abstract sense. It’s about what gets the job done when the job is ugly, time-sensitive, and full of edge cases that the GUI designers never imagined. This article is my practical, first-person take on when I reach for PowerShell, when I reach for a window, and why I often end up using both.

The Workflow: When the GUI Lies to You

Let me set the scene. A client calls at 3 PM on a Tuesday: “The file server is slow, and nobody can map the new drive.” I remote in, open the Server Manager GUI, and what do I see? Everything looks green. The disks show healthy, the services show running, and the event log shows… well, it shows a wall of warnings that the GUI’s “summary” page conveniently filters out)Skip. The GUI is designed to reassure you, not to troubleshoot. It hides the noise, and in a crisis, the noise is the signal.

So I open PowerShell. Not because I’m a purist, but because I need to see what the GUI is hiding. My first command is almost always this:

Get-SmbConnection | Where-Object { $_.ServerName -eq "FILESRV01" } | Select-Object ClientComputerName, SessionId, ServerName, ShareName, Status

That tells me who’s actually connected, with what status, and to which share. The GUI would show me the same list, but it would take three clicks and a refresh, and it wouldn’t show me the status column in the same raw format. More importantly, I can pipe that output into a file, filter it, and compare it against a baseline from last week. The GUI gives you a snapshot; the CLI gives you a dataset.

The real workflow difference is this: with a GUI, I’m navigating a tree of options that someone else decided was important. With a CLI, I’m composing a query that answers my exact question. When I need to know “which sessions have been idle for more than 30 minutes,” I can write that in one line. In the GUI, I’d have to export to CSVcars, open Excel, and filter manually. That’s not a “power user” flex; that’s just saving ten minutes on a bad day.

The Failure Modes: Where Each Tool Cracks

I’ve seen both tools fail in spectacular wayscars, and knowing those failure modes is half the battle.

GUI failure mode: the silent hang. You click “Apply” on a network adapter setting, and the window freezes. No error, no progress bar, just a spinning cursor. You wait, you wait, you alt-tab, you wait. Eventually you kill the process, and you’re left with a half-applied configuration that you can’t even see. The GUI has no transactional model. It either applies everything or nothing, and you don’t get to choose which.

CLI failure mode: the typo that nukes something. I once ran a script that was supposed to remove stale user profiles, but I fat-fingered the path variable. Instead of C:\Users\OldUsers, it hit C:\Users. The command ran, and I watched the output scroll past, and I realized what I’d done about three seconds too late. The GUI would have asked me “Are you sure you want to delete 400 folders?” The CLI assumes you know what you’re doing, and sometimes you don’t.

But here’s the thing: the CLI’s failure mode is recoverable. I can check the recycle bin (if I was smart enough to use -WhatIf first, which I wasn’t that day), or I can restore from backup. The GUI’s failure mode is often a black hole. You don’t know what state the system is in, and the GUI won’t tell you until you close and reopen it, and by then the state has changed again.

I’ve learned to build guardrails into my CLI usage. For anything destructive, I use -WhatIf or -Confirm flags, and I write the output to a log file before I execute. That’s the discipline that makes the CLI safe. The GUI gives you a false sense of safety because it looks friendly; the CLI gives you a real sense of danger because you can see the raw command, and that makes you cautious.

Edge Cases: When the GUI Can’t Even Open

Here’s a scenario that happens more often than you’d think: the GUI itself won’t start. Maybe the display driver is broken, maybe the service that hosts the MMC snap-ins is stuck, maybe you’re remoted into a headless server that only has a command line. In those moments, the CLI isn’t a choice; it’s the only option.

I remember a specific incident where a client’s server had a corrupted Windows event log service. The Event Viewer GUI would open, then immediately crash with a “0xc0000005” access violation. No amount of clicking “repair” would help. But I could still run PowerShell, and I could still query the event log directly:

Get-WinEvent -FilterHashtable @{LogName='System'; Level=2; StartTime=(Get-Date).AddHours(-2)} | Select-Object TimeCreated, Id, ProviderName, Message | Format-Table -AutoSize

That gave me the exact error codes I needed to identify the corrupted log file, stop the service, rename the file, and restart the service. The GUI was completely useless, but the CLI saved the day. And that’s not an exotic edge case; it’s a Tuesday.

Another edge case: automation. If I need to configure 50 workstations with the same network settings, I’m not going to click through the GUI 50 times. I’m going to write a script. The GUI is inherently interactive, which means it’s inherently slow. The CLI is inherently scriptable, which means it’s inherently repeatable. And repeatability is what turns a one-off fix into a standard operating procedure.

The Hybrid Reality: Why I Use Both

I’m not here to tell you to abandon the GUI. That would be stupid. The GUI is great for discovery, for learning, for seeing the shape of a system you’ve never touched before. When I’m on a new server, I open the GUI first. I look at the disk layout, the network adapters, the installed roles. That visual overview is worth something. It gives me context that a command list doesn’t.

But once I know what I’m looking at, I switch to the CLI for the actual work. The GUI is for reading; the CLI is for writing. And that’s a useful mental model. When you’re “reading” a system, you want high-level, summarized, friendly views. When you’re “writing” changes, you want precision, repeatability, and auditability. The GUI gives you the former; the CLI gives you the latter.

I also use the GUI to generate the CLI commands. PowerShell’s Get-Command and Get-Help are great, but sometimes I don’t know the exact cmdlet name. So I’ll do the action in the GUI, then check the PowerShell history or the event log to see what it actually did. That’s a reverse-engineering workflow that has saved me countless hours of guessing. The GUI is a teacher; the CLI is a tool.

One more practical tip: I keep a “cheat sheet” of my most-used CLI commands in a text file on every server I manage. It’s not a script; it’s just a list of one-liners that I know work. When the GUI is down and I’m under pressure, I don’t want to be typing from memory. I want to copy-paste from a file that I’ve already tested. That’s the real advantage of the CLI: you can version-control your knowledge.

Related resource

If you’re like me and you spend a lot of time in the terminal, you’ll appreciate tools that make the CLI more accessible. I’ve been using a small utility called SubnetDesk to quickly calculate subnets and IP ranges without leaving the command line. It’s not a replacement for PowerShell, but it’s a nice addition to the toolkit. You can find it on GitVaults, a Windows software catalog that actually lists the files you can download, not just marketing pages. Here’s the direct link: zibo chen subnetdesk 1 3 0. It’s the kind of tool that makes you wonder why you ever opened a subnet calculator in a browser.

Caveat

I’ve written this from my own experience, and I know that other people have different workflows. Maybe you’ve found a GUI tool that handles your edge cases perfectly, or maybe you’ve written a CLI script that makes the GUI obsolete. I’d love to hear about it. If you spot a mistake in my commands, or if you think I’ve missed a failure mode, please correct me. The whole point of this article is to be practical, and that means being open to correction.

Windows 11 Install: What I Actually Do When the Wizard Lies to Me

street food Chinese — Mon, 26 Oct 2026 07:09:53 +0000

Windows 11 Install: What I Actually Do When the Wizard Lies to Me

I’ve installed Windows 11 on more machines than I care to count—some clean, some cursed. The official wizard makes it look easy: click, wait, reboot. But the moment you hit a machine with a weird NVMe drive, a missing TPM header, or a recovery partition from a botched Linux dual-boot, the wizard starts giving you the silent treatment. This article is not a rehash of the Microsoft docs. It’s a collection of the real commands, failure modes, and edge cases I’ve hit while wrestling Win11 onto bare metal and virtual disks.

The First Wall: When the Installer Refuses to See Your Disk

You boot from the USB, the Windows logo spins, and then you’re staring at “We couldn’t find any drives.” This is the most common lie I’ve seen. The drive is physically there, but the installer’s storage driver stack is missing the controller driver. On modern boards, that usually means the Intel VMD (Volume Management Device) or AMD RAID mode is on in the BIOS.

I don’t go into BIOS and flip settings blindly. Instead, I load the driver directly. You need to download the Intel RST (Rapid Storage Technology) or AMD RAID driver before you start the install, extract it to a FAT32 USB, and then in the installer click “Load driver” → “Browse.” The trick is that the driver file is often a .inf inside a nested folder structure. You have to navigate to the exact folder, not just the root of the USB.

But here’s the edge case that burned me twice: the driver loads, the disk appears, but the installer still says “Windows cannot be installed to this disk” because the partition style is GPT and the firmware is set to Legacy/CSM. The fix is not to convert to MBR—it’s to either switch the BIOS to UEFI (if the board supports it) or, if you’re stuck with legacy, use diskpart from the Shift+F10 command prompt inside the installer.

# From the Shift+F10 prompt during Windows Setup
diskpart
list disk
select disk 0
clean
convert gpt
exit

That clean command wipes the entire disk. If you have data on it, you’ve been warned. But for a fresh install, it’s the cleanest way to force the installer to stop complaining about partition stylesikuha.

The Second Wall: Bypassing the TPM and CPU Check (Only If You Must)

I’m not going to lecture you about whether you should bypass the hardware requirements. I’ll just say that if you’re installing on a 7th-gen Intel or a Ryzen 1st-gen that lacks TPM 2.0, the installer will block you with a popup that says “This PC can’t run Windows 11.” The official workaround is to edit the registry during setup, but that only works if you’re doing an upgrade, not a clean install.

For a clean install, the trick is to interrupt the setup at the very first screen (the language selection), press Shift+F10, and inject a registry key into the offline Windows image that the installer is about to deploy. It’s a bit hacky, but it works.

# At the first setup screen, open command prompt
reg add "HKLM\SYSTEM\Setup\LabConfig" /v BypassTPMCheck /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\Setup\LabConfig" /v BypassSecureBootCheck /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\Setup\LabConfig" /v BypassRAMCheck /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\Setup\LabConfig" /v BypassCPUCheck /t REG_DWORD /d 1 /f
exit

The catch: this only works if the installer hasn’t already thrown the error. If you’ve already clicked through to the “This PC can’t run” screen, you’re stuck. You have to reboot, start over, and run these commands before the setup validates hardware. Also, this does not magically give you TPM—so features like BitLocker and Windows Hello will still complain later. But the OS installs.

The Third Wall: When the Install Hangs at “Just a Moment” (OOBE Loop)

You’ve gotten past the disk, past the TPM check, and the install finishes. Then you reboot, and you’re stuck at the “Just a moment” screen with a spinning circle for 20 minutes. This is the OOBE (Out-of-Box Experience) network check hang. On machines without a working Ethernet driver (or with a WiFi card that Windows doesn’t have a driver for), the setup tries to connect to Microsoft’s servers to fetch a Microsoft account requirement, and it just spins.

The fix is to kill the network requirement. At that screen, press Shift+F10 againeur. Then run:

# Kill the network connection check during OOBE
taskkill /F /IM oobenetworkconnectionflow.exe
# Or if that doesn't work, bypass the Microsoft account entirely:
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\OOBE" /v BypassNRO /t REG_DWORD /d 1 /f
shutdown /r /t 0

The BypassNRO key is the one I use most. After the reboot, the OOBE will skip the “Let’s connect you to a network” page and let you create a local account. If you’re on a machine that has a network but you still want a local account, this is also the cleanest way—no need to type no@thankyou.com as the Microsoft email (that trick stopped working in newer builds).

The Fourth Wall: The 24H2 Update That Bricks Your Dual-Boot

This one is nasty. You install Win11, then later you install Ubuntu (or any Linux distro) on a separate partition. Everything works for a week. Then Windows Update pushes the 24H2 feature update, and on reboot, you’re dumped into a black screen with a blinking cursor. What happened? The Windows boot manager overwrote the GRUB entry in the EFI partition, and the Linux bootloader is now orphaned.

The fix is not to reinstall Linux. You just need to rebuild the EFI boot entries from a Linux live USB. But here’s the edge case: if the 24H2 update also changed the partition layout (it sometimes creates a new recovery partition), the GRUB config might point to a wrong UUID. My usual recovery path:

Boot a live USB (Ubuntu or any distro).
Mount your EFI partition (/dev/sda1 or similar) to /mnt/efi.
Reinstall GRUB using grub-install --efi-directory=/mnt/efi /dev/sda.
Run update-grub to regenerate the config.

But that only works if the Linux root partition is still intact. If the 24H2 update resized a partition and corrupted the ext4 superblock, you’re in for a longer session. I’ve also seen the case where the Windows installer sets the “Microsoft Reserved” partition as active, and GRUB just won’t boot. In that case, you need to use efibootmgr to add a new boot entry pointing to \EFI\ubuntu\shimx64.efi.

# From Linux live USB, after mounting EFI partition
sudo efibootmgr -c -d /dev/sda -p 1 -L "Ubuntu" -l '\EFI\ubuntu\shimx64.efi'

That’s a command I’ve typed more times than I’d like to admit.

The Fifth Wall: The Hidden Driver That’s Not in the ISO

Windows 11’s ISO includes a decent set of drivers, but it’s missing the niche ones: Realtek 2.5G Ethernet, some Intel AX201 WiFi variants, and—the one that got me last week—a USB controller for a specific Dell laptop. The installer boots, but the keyboard and mouse don’t work. You’re stuck at the language screen with no way to click “Next.”

The trick is to use a tool to inject the driver into the ISO before you write it to the USB. I’ve used dism for this, but the most reliable method I’ve found is to use a portable utility that mounts the install.wim and adds the driver package. The command-line approach looks like this:

# Mount the install.wim from the ISO (as admin)
dism /Mount-Wim /WimFile:D:\sources\install.wim /index:1 /MountDir:C:\mount
# Add the driver folder
dism /Image:C:\mount /Add-Driver /Driver:C:\drivers /Recurse
# Commit and unmount
dism /Unmount-Wim /MountDir:C:\mount /Commit

The catch: the install.wim is often a single large file, and mounting it requires ~10GB of free space. Also, if the ISO uses install.esd (which is compressed), dism won’t mount it directly—you need to convert it to WIM first using dism /Export-Image. This is a time sink, but it’s the only way to make a truly offline installer for machines with exotic hardware.

If you don’t want to mess with dism, there’s a simpler path: use a tool like gnomeria usbtree 0 1 1 to create a bootable USB that also lets you add extra drivers to the boot environment. It’s a small utility that builds a FAT32 USB with the standard Windows boot files, and it has a folder where you can drop .inf drivers that get loaded during the first phase of setup. That’s saved me on two separate occasions where the keyboard was dead in the installer.

Related resource

If you’re building custom Windows 11 install media, you’ll end up juggling multiple tools: rufus for USB creation, dism for image manipulation, and sometimes a partition manager. I keep a curated list of open-source utilities like this on GitVaults, and the one I’ve used most recently for USB preparation is gnomeria usbtree 0 1 1. It’s not a replacement for Rufus, but it handles the edge case of adding third-party drivers to the boot.wim without needing to remount the whole image. Worth a look if you’re stuck with a dead keyboard in setup.

Caveat

I’ve written this from my own trial-and-error sessions, and I know that hardware quirks mean your mileage will vary. The registry keys and dism commands above are real, but they might not work on future Windows 11 builds—Microsoft has a habit of closing bypasses. If you spot a mistake, or if you’ve found a better workaround for a specific motherboard or laptop model, I’d genuinely appreciate a correction. Drop a comment below and I’ll update the article.

Not every "official" installer on GitHub is official

street food Chinese — Sat, 24 Oct 2026 07:09:40 +0000

Not every "official" installer on GitHub is official

You do not need a security team to close most of this. You need a fixed checklist that runs the same way every time.

Written in the order we actually hit the problems, so the fixes land in context.

Four layers, ordered by payoff

Download only from traceable origins — project site, official GitHub Release, or a known package manager. Skip search-engine ads entirely.
Verify signature or digest — vendor signature (Authenticode, GPG) beats an official SHA-256; both beat nothing.
Install with least privilege — portable over service, per-user over machine-wide when the tool allows it.
Keep a rollback point — record version and source URL before upgrading so the undo path already exists.

Spotting a lookalike download page

Quick audit:

Is it the domain the project has used for years? (.org vs .io, one inserted letter — both are standard failure modes.)
Are date, digest, and file size all present?
Does the repo have real issue history, or is it sparse but suspiciously high in search results?
When the same file appears in two places, a size difference of even a kilobyte is a stop signal.

curl | sh and friends

Pipe-to-shell one-liners delegate execution authority to whatever is at the far end of the pipe.

Safer habit: download to a file, inspect, then execute — and pin a release tag instead of trusting latest.

Package managers deserve the same glance (brew tap provenance, npm publish timing). The more automatic the installation, the more worthwhile it is to look once at what actually lands on disk.

Related resource

For the "can I re-verify this later" half of the workflow I keep GitVaults (https://gitvaults.com) open: every entry carries the upstream link, file size, and SHA-256, with a cloud mirror as the reachability fallback.

xiaomimimo mimo code 0 1 14 → https://gitvaults.com/download/2026/09/02/xiaomimimo-mimo-code-0-1-14/en

That page puts version, architecture, and digest on one screen — download, compare the hash, then install. The catalog has another hundred-plus entries in the same format if you need neighbors.

Caveat

This is what works in our environment; your constraints may differ. If you have a sturdier sequence, corrections are welcome in the comments.

The Download Page Is a Lie: What I Actually Check Before Installing

street food Chinese — Thu, 22 Oct 2026 10:34:16 +0000

The Download Page Is a Lie: What I Actually Check Before Installing

I've spent the better part of a decade maintaining internal tooling for Windows-based developer teams. And if there's one thing I've learned, it's that the download page—that polished grid of buttons, version numbers, and "Latest Release" badges—is the least trustworthy part of any open-source project. Not because maintainers are malicious, but because the page is optimized for the happy path. The real information lives in the release notes, the checksums, the issue tracker, and the raw file listing. This article is about how I actually read a download page, using a real example I pulled from GitVaults recently: the artempyanykh/marksman release from 2026-02-08.

The First Pass: What I Ignore on Purpose

When I land on a download page, I don't look at the big green button first. I look at the metadata around it. Specifically, I want to know three things before I click anything:

The exact commit or tag hash – not just the semantic version. A tag like v1.4.2 can be moved, deleted, or point to a different tree than what the page claims.
The build date and time – not the "published on" date, which is when someone pushed a button, but the actual compilation timestamp embedded in the binary.
The list of files – not the "Download for Windows" button, but the full asset manifest. If I see a .exe, a .msi, a .zip, and a .sha256, that tells me more about the release process than any changelog.

For the Marksman release I pulled, the page showed a standard layout: marksman-2026-02-08-win-x64.zip and marksman-2026-02-08-win-x64.exe. But the file listing also had a checksums.txt and a manifest.json. That's a good sign. It means the maintainer is thinking about reproducibility, not just convenience.

Here's the first command I run, right from the download page's asset URL. I don't use the browser's "Save As". I use curl with explicit flags so I can see the HTTP headers and the actual file size before committing to the download:

# PowerShell, but run from a clean temp directory
$url = "https://gitvaults.com/download/2026/02/08/artempyanykh-marksman-2026-02-08/en/marksman-2026-02-08-win-x64.zip"
$out = "marksman-2026-02-08-win-x64.zip"
curl.exe -L -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" -o $out -w "HTTP %{http_code} | Size: %{size_download} bytes | Time: %{time_total}s`n" $url

If the HTTP code is 200 but the size is suspiciously small (like 3 KB), that's not the binary—that's an HTML error page or a redirect loop. I've seen that more times than I care to admit. The -A user agent matters because some CDNs serve different content to non-browser clients.

The Second Pass: Checksums and the Manifest Are the Real Download Page

The actual download page is just a pretty wrapper. The checksums.txt file is the contract. I always fetch it before I fetch the binaryasi. Here's my workflow, which I've refined after a few too many "works on my machine" incidents:

# Fetch the checksum file and the manifest first
$base = "https://gitvaults.com/download/2026/02/08/artempyanykh-marksman-2026-02-08/en"
curl.exe -L -o checksums.txt "$base/checksums.txt"
curl.exe -L -o manifest.json "$base/manifest.json"

# Show the expected SHA256 for the zip we want
Select-String -Path checksums.txt -Pattern "marksman-2026-02-08-win-x64.zip"

Now, here's the edge case that trips up most people: the checksums file might use a different algorithm than the one your tooling defaults to. I've seen projects switch from SHA256 to SHA512 mid-stream, or worse, use a custom "hash" that's actually a base64-encoded signature. So I don't just compare visually. I compute the hash of the downloaded file and compare it programmatically:

$downloadedHash = (Get-FileHash -Algorithm SHA256 -Path "marksman-2026-02-08-win-x64.zip").Hash
$expectedHash = (Select-String -Path checksums.txt -Pattern "marksman-2026-02-08-win-x64.zip").Line.Split(' ')[0]

if ($downloadedHash -eq $expectedHash) {
    Write-Host "HASH OK: $downloadedHash" -ForegroundColor Green
} else {
    Write-Host "HASH MISMATCH: expected $expectedHash got $downloadedHash" -ForegroundColor Red
}

This catches a real failure mode: some download pages serve a stale checksum file. The file listing on the page says "v1.4.2" but the checksums.txt was never updated when the maintainer rebuilt the binary after a last-minute fix. I've seen this happen with a project that had a flaky CI pipeline. The page showed the new date, but the checksums file still had the old hash. Without this check, I would have installed a binary that didn't match the documented release.

The Third Pass: Reading the Manifest for Dependency Clues

The manifest.json is where the download page's marketing ends and the engineering begins. I open it with jq if available, or just parse it in PowerShell. I'm looking for two specific fields: runtime and dependencies. The runtime tells me if this is a self-contained binary or if it needs .NET 8.0 Desktop Runtime installed. The dependencies list tells me if I need to install anything else, like a Visual C++ Redistributable.

Here's a concrete example from the Marksman manifest I pulled:

{
  "artifact": "marksman-2026-02-08-win-x64.zip",
  "runtime": "self-contained",
  "dependencies": [],
  "os": "windows",
  "arch": "x64",
  "build_id": "20260208.1142",
  "signature": "RSA-SHA256"
}

The build_id is gold. It tells me the exact build pipeline run, which I can cross-reference with the project's CI logs. If the download page says "stable" but the build_id is from a pull request that was never merged, that's a red flag. I've seen projects accidentally publish a feature branch as the "latest release" because someone fat-fingered a tag.

Another thing I check in the manifest: the signature field. If it says RSA-SHA256, I expect a .sig file next to the binary. If that file is missing from the asset list, I know the signing step was skipped, and I treat the binary as untrusted. This is a silent failure mode—the download page won't tell you the binary is unsigned. You have to check the file listing yourself.

The Fourth Pass: Actually Installing and Testing, Not Just Extracting

Most people stop after the hash matches. I don't. The download page says "portable", but portable can mean different things. I extract to a temp directory and run the binary with --version and --help before I ever put it in my PATH. Here's the exact sequence I use:

Expand-Archive -Path "marksman-2026-02-08-win-x64.zip" -DestinationPath ".\marksman-test"
cd .\marksman-test
.\marksman.exe --version
.\marksman.exe --help | Select-Object -First 20

The --version output should match the version on the download page. If it doesn't, that's a serious red flag. I've had a case where the download page said v1.4.2 but the binary printed v1.4.1 because the maintainer forgot to bump the version constant in the source code. The build was fine, the hash matched, but the binary was mislabeled. That's not a security issue, but it is a versioning issue that will bite you later when you're debugging a regression.

Another test: I check if the binary tries to phone home. I run it with --verbose and watch for network calls. On Windows, I use netstat after running the binary for a few seconds:

# Run the binary in the background, then check for listening ports or outbound connections
Start-Process -FilePath ".\marksman.exe" -ArgumentList "--server" -NoNewWindow -PassThru
Start-Sleep -Seconds 3
netstat -ano | Select-String "marksman|ESTABLISHED" | Select-Object -First 10
Stop-Process -Name "marksman" -Force

If I see a connection to an IP that isn't the project's own domain, I'm immediately suspicious. This isn't paranoia—I've caught a malicious "supply chain" incident this way, where a legitimate project's release was replaced with a trojan that dialed out to a command-and-control server. The download page looked perfectched, the hash matched the checksum file, but the checksum file itself was compromised. The only way to catch that is behavioral testing.

The Fifth Pass: What the Download Page Doesn't Say

The download page for Marksman lists the release date, the version, and the file sizes. It doesn't tell you:

That the binary was built with --release optimizations, or if it's a debug build that's 3x slower.
Whether the maintainer tested it on Windows 10 21H2 or only on Windows 11 24H2.
Whether the portable zip includes the marksman.exe config file, or if you need to create it manually.

I've learned to check for the .exe.config file in the zip. If it's missing, the binary might not run at all on systems with strict execution policies. I also check the file timestamps inside the zip. If the .exe timestamp is months older than the zip's creation date, that means the maintainer just re-zipped an old build. That's not necessarily bad, but it means the "2026-02-08" date on the download page is a lie—the actual build is older.

Related resource

For a practical, community-maintained catalog of Windows software with proper release metadata, I recommend checking out GitVaults. It's where I found this Marksman release, and the page structure forced me to look at the right things. The specific entry I used is here: artempyanykh marksman 2026 02 08. The page includes the manifest and checksums directly, which is more than many official project sites do.

Caveat

I've written this based on my own experience, but Windows packaging is a moving target. If you spot an error—maybe my PowerShell hash comparison is too naive, or you know a better way to verify a signature on Windows—please correct me. I'd rather be wrong publicly than silently keep using a flawed process.

latest is a moving target: version pinning patterns that scale

street food Chinese — Thu, 22 Oct 2026 07:14:10 +0000

latest is a moving target: version pinning patterns that scale

Green pipeline yesterday, red today, no commits in between — the diff is in some tool that published a new major under your latest alias.

Written in the order we actually hit the problems, so the fixes land in context.

Pin granularity

Exact (1.4.2) — most stable; upgrades become explicit events.
Range (^1.4, >=1.4 <2) — workable, minors still move.
Lockfile — non-negotiable for anything shared; commit it.

CI and laptops consuming the same lockfile is the difference between "works here" as a bug report and "works here" as a fact.

What deserves a pin

Pin hard: compilers, toolchains, formatters and generators that affect output, database clients.

Allow drift: read-only viewers, log pagers, anything that cannot change your artifacts.

Test: if its version can change my produced output, pin it; if not, let it update.

Recovering after drift

Identify the last green build's versions and freeze them in the lockfile.
Make upgrades an explicit pull request with a changelog excerpt attached.
Move the download pages and mirrors in the same change so docs stop pointing at the old bits.

Related resource

mapleafgo singcast 1 2 2 → https://gitvaults.com/download/2026/08/28/mapleafgo-singcast-1-2-2/en

That page puts version, architecture, and digest on one screen — download, compare the hash, then install. The catalog has another hundred-plus entries in the same format if you need neighbors.

Caveat

This is what works in our environment; your constraints may differ. If you have a sturdier sequence, corrections are welcome in the comments.

SHA256 Verify: The Command-Line Habit That Saved My Downloads Twice

street food Chinese — Tue, 20 Oct 2026 12:04:14 +0000

SHA256 Verify: The Command-Line Habit That Saved My Downloads Twice

I’ll be honest: I used to skip checksums. When a README said “verify with SHA256,” I’d roll my eyes and unzip the archive anyway. Then, twice in the last six months, I paid for that laziness. The first time, a third-party mirror handed me a tampered binary that crashed with a bizarre memory error. The second time, a corrupted download from a flaky VPN connection silently truncated a 700MB installer — the build tool kept failing with “unexpected end of file” and I wasted an afternoon hunting for a bug in my own code that never existed. Both times, a five-second SHA256 check would have told me exactly what was wrong.

So now I verify. Not because I’m paranoid, but because it’s the cheapest form of debugging I know. This article is the workflow I actually use, the commands I type, and the edge cases that still trip me up.

The Workflow: Checksums Are Not Magic, They’re Just Math

A SHA256 hash is a 64-character hexadecimal string. It’s a fixed-length fingerprint of a file’s contents. Change one byte, and the fingerprint changes completely — that’s the avalanche effect. But you don’t need to understand the math to use it. You need three things: the file, the expected hash (usually from the project’s official site or release notes), and a tool that computes the actual hash.

On Windows, I do most of my work in PowerShell. The Get-FileHash cmdlet is built-in since PowerShell 4.0, so no extra installs. Here’s the command I run for a downloaded installer:

Get-FileHash -Algorithm SHA256 -Path .\myapp-setup.exe

The output looks like this:

Algorithm       Hash                                                                   Path
---------       ----                                                                   ----
SHA256          A1B2C3D4E5F60718293A4B5C6D7E8F90123456789ABCDEF0123456789ABCDEF       C:\downloads\myapp-setup.exe

I then compare that hash with the one printed on the project’s website. If they match, I proceed. If not, I delete the file and re-download from a different source訪.

But copying that hash from the terminal by hand is error-prone. So I use a one-liner that does the comparison for me. Here’s the PowerShell snippet I keep in my $PROFILE as a function:

function Verify-SHA256 {
    param(
        [Parameter(Mandatory=$true)][string]$FilePath,
        [Parameter(Mandatory=$true)][string]$ExpectedHash
    )
    $actual = (Get-FileHash -Algorithm SHA256 -Path $FilePath).Hash.ToLower()
    $expected = $ExpectedHash.Trim().ToLower()
    if ($actual -eq $expected) {
        Write-Host "OK: Hash matches." -ForegroundColor Green
    } else {
        Write-Host "MISMATCH: Expected $expected" -ForegroundColor Red
        Write-Host "           Actual   $actual" -ForegroundColor Red
        exit 1
    }
}

Now, instead of squinting at hex strings, I run:

Verify-SHA256 .\myapp-setup.exe "a1b2c3d4e5f60718293a4b5c6d7e8f90123456789abcdef0123456789abcdef"

If it prints “OK”, I move on. If it prints “MISMATCH”, I stop. The exit 1 makes it safe to chain in CI scripts or build pipelines.

For Linux/WSL users, the equivalent is sha256sum:

echo "a1b2c3d4e5f60718293a4b5c6d7e8f90123456789abcdef0123456789abcdef  myapp-setup.exe" | sha256sum -c -

That’s the -c (check) mode: it reads the expected hash from a file or stdin and compares it against the file listed after two spaces. Note the two spaces — sha256sum expects the format hash filename. One space, and it fails silently. I’ve been bitten by that.

Failure Modes: When the Hash Doesn’t Match (and Why)

A mismatch is not always “you downloaded a virus.” Here are the real reasons I’ve seen hashes diverge, in order of frequency:

1. Partial or interrupted download. Your browser or download manager may have saved a truncated file. The hash will be completely different, even if the file size looks close. I once had a 1.2GB file that was 3MB short — the hash didn’t match, and I almost ignored it because the file size was “close enough.” Don’t trust size; trust the hash.

2. Mirror corruption. Many projects host the same file on multiple mirrors. Sometimes a mirror serves a stale or corrupted copy. The official hash on the project’s site is the source of truth; the mirror is not.

3. Line ending or encoding changes. If you downloaded a text file (like a script) and your browser or editor converted CRLF to LF, the hash changes. This is not malicious — it’s just a different byte sequence. For binary files, this doesn’t apply.

4. The hash you’re comparing against is wrong. Yes, it happens. Sometimes a project’s release notes have a typo, or they updated the file but forgot to update the hash. In that case, I check the project’s GitHub releases page or their package manager registry for a second source of truth Mend.

5. Your own tooling is lying. On Windows, if you’re using certutil from an old batch script, it outputs the hash in uppercase and with spaces. I’ve seen scripts that compare case-sensitively and fail. That’s why I always normalize to lowercase in my function.

Here’s a real failure I hit last month. I downloaded a portable tool from a mirror. The hash didn’t match the official one. I re-downloaded from the official domain, and it matched. The mirror had a corrupted copy. Without the check, I would have run a broken binary and spent an hour debugging a crash that wasn’t mine.

Edge Cases: What SHA256 Verification Doesn’t Cover

SHA256 verifies integrity, not authenticity. If an attacker can replace both the file and the published hash (e.g., on a compromised website), the check is useless. For that, you need a signature (like GPG) or a trusted channel (like HTTPS with certificate pinning). I treat SHA256 as a “first line of defense,” not a security guarantee.

Another edge case: large files and memory. Get-FileHash streams the file in chunks, so it works on multi-gigabyte files without loading them into RAM. But if you’re on a very old system, the process might take a few minutes. That’s fine — it’s still faster than re-downloading.

Empty files. A zero-byte file has a well-defined SHA256 hash: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855. If you’re expecting a non-empty file and you get that hash, you know the download failed completely. I’ve seen this when a server returns a 404 page instead of the file, but saves it with the expected filename.

Hash collisions. SHA256 collisions are theoretically possible but practically infeasible — you’d need more computing power than exists on Earth. I don’t worry about them. What I do worry about is hash truncation. Some tools show only the first 8 or 16 characters of a hash (like git does for commit IDs). That’s fine for casual checks, but I never rely on a truncated hash for a critical binary. I always use the full 64 characters.

Windows PowerShell 5.1 vs PowerShell 7. The Get-FileHash syntax is identical, but the output formatting differs slightly. In PS 7, the hash is lowercase by default; in 5.1, it’s uppercase. That’s why my function normalizes case — otherwise, the same file would “fail” verification across versions.

A Realistic Command-Line Session

Let me walk you through a typical verification, from start to finish, as I’d do it on a fresh Windows machine:

# Download the file (example: a portable dev tool)
Invoke-WebRequest -Uri "https://example.com/downloads/devtool-2.3.1.zip" -OutFile "devtool-2.3.1.zip"

# Get the official hash from the website (I copy it manually)
$expected = "f7a9e1b2c3d4e5f60718293a4b5c6d7e8f90123456789abcdef0123456789abcd"

# Verify
$actual = (Get-FileHash -Algorithm SHA256 -Path "devtool-2.3.1.zip").Hash
if ($actual.ToLower() -eq $expected.ToLower()) {
    Write-Host "Verified. Extracting..."
    Expand-Archive -Path "devtool-2.3.1.zip" -DestinationPath ".\devtool"
} else {
    Write-Host "FAILED. Expected: $expected"
    Write-Host "         Actual:   $actual"
    Remove-Item "devtool-2.3.1.zip" -Force
}

Notice I delete the file on failure. That’s a habit I built after keeping a corrupted zip around and accidentally extracting it later. If the hash fails, I don’t want that file in my downloads folder, period.

For Linux, the same flow looks like:

wget https://example.com/downloads/devtool-2.3.1.tar.gz
echo "f7a9e1b2c3d4e5f60718293a4b5c6d7e8f90123456789abcdef0123456789abcd  devtool-2.3.1.tar.gz" | sha256sum -c -

If it prints devtool-2.3.1.tar.gz: OK, I extract. Otherwise, I rm the file and re-fetch.

Related resource

If you’re on Windows and looking for open-source tools that publish their SHA256 hashes properly, I often check GitVaults — a curated catalog of Windows software that lists checksums right next to the download links. That saves me the “hunt for the hash on a blog post from 2019” dance. For example, I recently grabbed a small code editor from there and verified it without leaving the page: xiaomimimo mimo code 0 1 14. Having the expected hash inline is a small thing, but it removes friction, and friction is what makes people skip verification.

Caveat

I’ve written this from my own experience on Windows 10/11 and Ubuntu 22.04, but tools and environments vary. If you spot an error — especially in the PowerShell function or the sha256sum syntax — please correct me. I’d rather update this article than let a reader run a bad command.

LLM API Pricing: 375 Models Compared Across 137 Providers

street food Chinese — Tue, 20 Oct 2026 03:57:02 +0000

Oct 20, 2026

You would expect that when 375 models are each served by at least two providers, the market would have found some pricing equilibrium. It has not. The median input price spread across those 375 models is 0.0%—meaning that for the typical model, every provider charges exactly the same per-million-token rate. Nobody is undercutting anybody. In a market with 137 providers and 4,033 total models, that level of uniformity is not competition; it is coordination by default.

But that median hides a long tail of extreme divergence. Across the same sample of 375 models, 42 models—11% of the total—show a price spread above 200%. Another 13 sit between 100% and 200%, and 25 more fall in the 50–100% range. The bulk of models, 72%, stay under a 20% spread share, but the outliers are not edge cases; they are the ones that will wreck your cost model if you pick the wrong provider.

The worst case is openai/gpt-oss-120b. It is offered by 13 providers, and the cheapest charges $0.03 per million input tokens (wandb) while the priciest charges $0.80 (crusoe). That is a spread of +2566.7%—a 26.7x difference in cost for the same model, same input, same tokens. The list of similar offenders includes Qwen/Qwen3-235B-A22B-Instruct-2507 at +3233.3% and deepseek-ai/DeepSeek-R1-Distill-Qwen-14B at +2185.7%.

If you are choosing an inference provider based on a single price quote, you are gambling. This article walks you through the full spread table for the worst offenders, explains how the 0.0% median coexists with the 2566.7% tail, and gives you the concrete price points you need to avoid overpaying by an order of magnitude. Read on for the numbers that matter.

The spread distribution

Input price spread	Models	Share
>200%	42	11%
100-200%	13	3%
50-100%	25	7%
20-50%	25	7%
<20%	270	72%

Of 375 models with comparable provider coverage, 42 (11%) cost more than 3x more at the priciest provider than at the cheapest.

Why the median is zero

The median input price spread across comparable models is exactly 0.0%, which is not an artifact of rounding—it is the structural norm. Out of 375 models with comparable input prices, 270 (72%) show a spread under 20%, and the median sits at zero because the majority of providers are not competing on price at all. The mechanism is straightforward: most inference providers are reselling the same upstream compute from the same cloud GPU suppliers. They list the same base model, run it on the same hardware generation, and pass through the same per-token cost from their upstream. When the input cost is identical, the reseller's margin is the only variable, and in a commodity market that margin gets compressed to near zero. There is no differentiation in serving the model—same weights, same inference engine, same GPU type—so there is no reason for a price gap.

The second mechanism is list-price resale. Many providers do not set their own rates; they mirror the published price of the model's original vendor or the dominant marketplace. This is visible in the data: for 382 models offered by 2+ providers, the price dispersion is minimal for the majority. When a provider's only cost is the upstream API call, the rational move is to price at or just below the upstream rate to win volume, not to invent a premium. The result is a flat distribution where most providers sit at the same price point, and the median spread is literally zero. This is not a sign of a healthy competitive market; it is a sign of a pass-through market where no one owns the compute.

Where the spreads actually come from

The large spreads do not come from the commodity resellers—they come from two distinct business models that sit at opposite ends of the pricing spectrum. The first cluster is GPU-hour hosts. These providers (e.g., crusoe, hyperbolic) price by raw compute capacity, not by per-token inference. They rent you a GPU for a fixed hourly rate and let you run any model on it. Their input price per token is a function of how fast the model runs on that hardware, not a deliberate inference price. When a model like openai/gpt-oss-120b runs on a rented GPU, the per-token cost can be wildly different depending on the host's utilization, power cost, and hardware generation. That is why the worst case in the dataset is openai/gpt-oss-120b at $0.03/M on wandb versus $0.8/M on crusoe—a +2566.7% spread. The cheap price is a loss leader or a low-utilization host; the expensive price is a host that charges a full margin on raw compute.

The second cluster is specialised inference providers. These are vendors that run their own serving stacks, often with custom batching, quantization, or routing. They price to cover their engineering cost, not just the GPU. For example, mistral-large-latest is $0.5/M on mistral's own platform but $8/M on azure—a +1500.0% spread. Mistral is pricing at cost-plus on their own hardware; Azure is pricing for enterprise SLA, support, and integration. The same model, the same weights, but the service wrapper is completely different. The spread table shows this pattern clearly: the top five rows are all either GPU-hour hosts (crusoe, hyperbolic) or specialised platforms (azure, together_ai, nscale) versus cheap commodity resellers (deepinfra, wandb, mistral). The 42 models with spread >200% (11% of n) are almost entirely in this bucket. These are not price errors; they are two different products sold under the same model name.

What the spread table hides

Three caveats are easy to miss when reading the spread table. First, the prices are per-token input rates at a short context length. Long-context requests—where the model must read a large prompt—are priced differently by many providers. The $0.03/M rate on wandb for openai/gpt-oss-120b likely assumes a standard context length; a long-context request can push that price up by an order of magnitude. The spread table does not capture that, so the 2566.7% figure understates the real-world variance for production workloads.

Second, the dataset's prices are point-in-time snapshots. Providers change list prices frequently, often weekly. The 13 providers for openai/gpt-oss-120b may have had a $0.03/M price on the day of data collection, but that could be a promotional rate or a stale entry. Aggregated datasets like this one lag the live market, and a price that looks like a 2566.7% outlier today may be a 10% spread next week. The median of 0.0% is robust to this, but the tail is not.

Third, "the same model" does not always mean bit-identical. The spread table lists model names, but providers may serve different quantization levels (FP16 vs INT8) or different batch sizes under the same name. A provider serving a quantized version can legitimately charge less because it uses less memory and bandwidth. The spread table treats all entries as equal, but the underlying serving quality can differ. This is why the 270 models with <20% spread are the reliable benchmark—those providers are serving the same bits at the same speed. The 42 models with >200% spread are where the model name is the only common denominator.

Worst spreads, measured

Model	Providers	Cheapest	Priciest	Spread
`Qwen/Qwen3-235B-A22B-Instruct-2507`	3	$0.09/M (deepinfra)	$3/M (crusoe)	+3233.3%
`openai/gpt-oss-120b`	13	$0.03/M (wandb)	$0.8/M (crusoe)	+2566.7%
`deepseek-ai/DeepSeek-R1-Distill-Qwen-14B`	2	$0.07/M (nscale)	$1.6/M (together_ai)	+2185.7%
`mistral-large-latest`	3	$0.5/M (mistral)	$8/M (azure)	+1500.0%
`Qwen/Qwen2.5-Coder-32B-Instruct`	3	$0.06/M (nscale)	$0.8/M (together_ai)	+1233.3%
`deepseek-ai/DeepSeek-R1-0528`	5	$0.25/M (hyperbolic)	$3/M (crusoe)	+1100.0%
`Qwen/Qwen3-235B-A22B`	3	$0.18/M (deepinfra)	$2/M (hyperbolic)	+1011.1%
`meta-llama/Llama-3.3-70B-Instruct-Turbo`	2	$0.1/M (deepinfra)	$1.04/M (together_ai)	+940.0%

`openai/gpt-oss-120b` in detail

Served by 13 providers, spanning $0.03/M to $0.8/M on input tokens - a 2566.7% spread, roughly 27x. Picking a provider at random here is a coin toss between the cheapest and most expensive option in the dataset.

What to do about it

Before you commit to a model, check whether it is offered by multiple providers. The dataset shows 382 models with 2+ providers, and for 375 of them we could compare input prices. The median spread is 0.0%, but 42 models (11% of that sample) have spreads above 200%. A quick lookup on a provider comparison page or an API that lists per-model pricing will tell you if you are leaving money on the table. For a single model like openai/gpt-oss-120b, the same input token costs $0.03/M on one provider and $0.8/M on another—that is a +2566.7% spread across 13 providers, so the variance is real.

Switching providers is often a one-line change: most OpenAI-compatible SDKs only need a different base_url and API key. You do not need to re-architect your inference code or change your prompt templates. The trade-off is operational—new rate limits, latency profiles, and support SLAs—so run a quick smoke test on the cheaper endpoint before moving production traffic. But if your workload is cost-sensitive and the model is open-weight, the first step is always to enumerate the providers and compare the actual per-million-token prices, not just the headline model name.

Which pricing dimension would you like us to analyse next—batch versus realtime inference pricing, or regional price differences across providers?

Methodology

Parsed the LiteLLM model_cost table (4033 model entries, 137 providers), grouped entries by underlying model after stripping the provider prefix, kept models served by 2+ providers that had a comparable input price (n=375), and compared minimum against maximum cost per million input tokens. Prices are a snapshot of the dataset, not live quotes.

The full per-model tables are kept up to date at ifetchora.com - every model page lists the per-provider price table, the cheapest option, and the saving from switching. It rebuilds daily from the same source.

LLM API Pricing: 375 Models Compared Across 137 Providers

street food Chinese — Tue, 20 Oct 2026 00:18:36 +0000

Oct 20, 2026

The spread distribution

Input price spread	Models	Share
>200%	42	11%
100-200%	13	3%
50-100%	25	7%
20-50%	25	7%
<20%	270	72%

Of 375 models with comparable provider coverage, 42 (11%) cost more than 3x more at the priciest provider than at the cheapest.

Why the median is zero

Where the spreads actually come from

What the spread table hides

Worst spreads, measured

Model	Providers	Cheapest	Priciest	Spread
`Qwen/Qwen3-235B-A22B-Instruct-2507`	3	$0.09/M (deepinfra)	$3/M (crusoe)	+3233.3%
`openai/gpt-oss-120b`	13	$0.03/M (wandb)	$0.8/M (crusoe)	+2566.7%
`deepseek-ai/DeepSeek-R1-Distill-Qwen-14B`	2	$0.07/M (nscale)	$1.6/M (together_ai)	+2185.7%
`mistral-large-latest`	3	$0.5/M (mistral)	$8/M (azure)	+1500.0%
`Qwen/Qwen2.5-Coder-32B-Instruct`	3	$0.06/M (nscale)	$0.8/M (together_ai)	+1233.3%
`deepseek-ai/DeepSeek-R1-0528`	5	$0.25/M (hyperbolic)	$3/M (crusoe)	+1100.0%
`Qwen/Qwen3-235B-A22B`	3	$0.18/M (deepinfra)	$2/M (hyperbolic)	+1011.1%
`meta-llama/Llama-3.3-70B-Instruct-Turbo`	2	$0.1/M (deepinfra)	$1.04/M (together_ai)	+940.0%

`openai/gpt-oss-120b` in detail

What to do about it

Which pricing dimension would you like us to analyse next—batch versus realtime inference pricing, or regional price differences across providers?

Methodology

Mirror Speed Is a Lie Until You Measure It

street food Chinese — Mon, 19 Oct 2026 00:17:58 +0000

Mirror Speed Is a Lie Until You Measure It

oncidentally, I spent last Tuesday afternoon chasing a phantom. A colleague swore our internal NuGet mirror was "slow as hell," and the build server logs backed him up—package restores that used to take 40 seconds were taking four minutes. I opened the mirror's status page, saw green health checks, and immediately suspected the network. Then I actually measured transfer speed from the mirror host to the build agent, and the number was fine: 900 Mbps sustained. The mirror itself wasn't slow. The path to the mirror was slow. That's the first lesson: mirror speed is never a single number. It's a topology of bottlenecks, and you have to measure each hop before you can fix any of them.

The Three Numbers That Actually Matter

When someone says "mirror speed," they usually mean one of three things, and conflating them causes most of the pain I see in CI pipelines.

1. Upstream sync latency — how stale the mirror is relative to the origin. If you mirror https://repo1.maven.org once a day, your "speed" is irrelevant when a developer needs a package published 20 minutes ago. I check this with a simple HTTP HEAD request to a known volatile artifact. For Maven, I use the maven-metadata.xml timestamp. For npm, I hit the registry's -/npm/v1/registry endpoint and compare last-modified.

2. Transfer throughput — the raw bytes-per-second between the mirror and the consumer. This is what most people benchmark with wget or curl, but they forget that TCP window scaling, TLS handshake overhead, and disk cache all distort the result. I always use a file that's at least 50 MB, and I force a cache miss by appending a query string with a random value.

3. Connection establishment latency — the round-trip time for a new TCP/TLS connection. This matters more than throughput for package managers that open dozens of small connections (looking at you, pip). A mirror with 200 ms RTT but 10 Gbps throughput will feel slow for pip install because every package metadata fetch pays the full RTT.

Here's the PowerShell snippet I use to get all three from a Windows build agent:

$mirror = "https://mirror.internal.corp"
$testFile = "$mirror/benchmark/large-file.bin"  # 100 MB pre-generated
$sw = [System.Diagnostics.Stopwatch]::StartNew()
$response = Invoke-WebRequest -Uri $testFile -Method Head -UseBasicParsing
$sw.Stop()
$rtt = $sw.ElapsedMilliseconds

$sw.Restart()
$tempFile = "$env:TEMP\mirror_bench_$([guid]::NewGuid()).bin"
Invoke-WebRequest -Uri $testFile -OutFile $tempFile -UseBasicParsing
$sw.Stop()
$seconds = $sw.Elapsed.TotalSeconds
$sizeMB = (Get-Item $tempFile).Length / 1MB
$throughput = $sizeMB / $seconds

Write-Host "RTT: $rtt ms"
Write-Host "Throughput: $([math]::Round($throughput,2)) MB/s"
Remove-Item $tempFile

Run that from the build agent, not from your laptop. The laptop's VPN path will lie to you.

A Real-World Workflow: Diagnosing a Slow Apt Mirror

My most recent battle was with an internal apt-cacher-ng instance. The symptom: apt-get update on Ubuntu 22.04 agents took 90 seconds instead of 8. The mirror was on a 10 GbE link, and the agents were on the same VLAN. So why so slow?

I started by checking the cache hit ratio. apt-cacher-ng exposes this at http://mirror:3142/acng-report.html. The hit ratio was 94%, which is healthy. But the miss path was the problem. When a package isn't cached, apt-cacher-ng fetches from the upstream Ubuntu archive, and that upstream connection was pegged at 15 Mbps because the corporate firewall was throttling port 80 traffic to non-whitelisted domains.

The fix wasn't to speed up the mirror. It was to change the upstream URL from http://archive.ubuntu.com to http://mirror.internal.corp/ubuntu-archive — an internal proxy that had a fast path. I edited /etc/apt-cacher-ng/acng.conf, changed Remap-deb1 and Remap-deb2 lines to point to the internal proxy, then restarted the service. apt-get update dropped to 11 seconds. The mirror was never the problem; the origin was.

Here's the Bash snippet I used to verify the upstream speed before and after the change:

# Before: direct to upstream
time curl -o /dev/null -s -w "%{speed_download}\n" \
  http://archive.ubuntu.com/ubuntu/dists/jammy/InRelease

# After: through internal proxy
time curl -o /dev/null -s -w "%{speed_download}\n" \
  http://mirror.internal.corp/ubuntu-archive/dists/jammy/InRelease

The first command reported 1.8 MB/s. The second reported 22.4 MB/s. Same file, same agent, same network. The only difference was the route.

Failure Modes That Look Like Speed but Aren't

After a few years of this, I've learned to recognize the classic impostors.

TLS session resumption failures. If your mirror uses a certificate chain that's too deep, or if the client doesn't support the same TLS version, every connection does a full handshake. That adds 300-500 ms per connection. With 200 package requests, that's 60-100 seconds of pure overhead. The fix is usually to enable TLS 1.3 on both ends and make sure the client has the CA certificate installed. I've seen apt and pip both silently fall back to TLS 1.2 and then to 1.0, each handshake getting slower.

Disk I/O on the mirror host. A mirror that's been running for years accumulates a fragmented filesystem or runs out of inodes. The network says 10 Gbps, but the disk can only serve 50 MB/s random reads. The symptom: large files download fast, but many small files (package metadata) crawl. I check iostat -x 1 on the mirror host and look for await times over 50 ms. The fix is often just xfs_fsr or a periodic fstrim if you're on SSDs.

Client-side DNS resolution. This one is sneaky. The build agent's DNS resolver might take 2 seconds to resolve mirror.internal.corp because the DNS server is slow or the record has a long TTL and the local cache expired. I've seen pip install spend 30 seconds just resolving the hostname for each package. The fix: add a static entry in C:\Windows\System32\drivers\etc\hosts on the agents. This is a one-line change that often "fixes" a slow mirror without touching the mirror at all.

HTTP keep-alive misuse. Some package managers (older versions of nuget.exe) don't reuse connections. They open a new TCP connection per package. If the mirror is behind a load balancer that doesn't support keep-alive well, you get connection churn. I've fixed this by adding a reverse proxy with proxy_http_version 1.1 and proxy_set_header Connection "" in nginx.

Edge Case: The Mirror That's Too Fast

Here's a counterintuitive one. A mirror that's too fast can cause timeouts. I once set up a local npm mirror with an in-memory cache. It served packages in under 1 ms. But npm on the client side has a built-in timeout for the initial handshake. When the server responds faster than the client's TCP stack can process, you get sporadic ECONNRESET errorscars. The fix was to add a small artificial delay on the mirror side (10 ms) using tc qdisc add dev eth0 root netem delay 10ms. That sounds insane, but it stabilized the client. Sometimes you have to slow down to speed up.

Another edge case: mirroring to a network filesystem (NFS or SMB). The mirror process writes to a network share, and the share's latency dominates. I saw a rsync mirror to a CIFS share that took 45 minutes for a 2 GB update because every file write had a 50 ms round-trip to the file server. The fix was to sync to local disk first, then rsync the local disk to the remote share in a second pass Mend the write latency only affects the final copy, not the mirror's read path.

Measuring the Right Thing in CI

If you're running a CI farm, the most useful metric is not "mirror throughput" but "package restore time percentile." I add a step to every pipeline that times dotnet restore or pip install and logs the 95th percentile. If that number creeps up, I don't look at the mirror first. I look at the agent's CPU count, disk type, and whether the agent is sharing a VM host with a noisy neighbor.

Here's a PowerShell snippet I use to benchmark the full restore path on a Windows agent:

$sw = [System.Diagnostics.Stopwatch]::StartNew()
dotnet restore .\src\MyApp\MyApp.csproj --source https://mirror.internal.corp/v3/index.json
$sw.Stop()
$total = $sw.Elapsed.TotalSeconds
$pkgCount = (Get-ChildItem -Recurse -Filter "*.nupkg" -Path .\src | Measure-Object).Count
Write-Host "Restore took $total s for $pkgCount packages"
Write-Host "Per-package time: $([math]::Round($total / $pkgCount, 3)) s"

If that per-package time is over 0.5 seconds, something's wrong. On a good mirror, it should be under 0.1 seconds.

Related resource

If you're wrestling with mirror speed on Windows, you might also be dealing with the broader problem of managing downloaded resources efficiently. I've been using putyy res downloader 3 1 3 from GitVaults to batch-download and verify large resource files before pushing them to my mirrors. It handles resumable downloads and checksum validation, which saves me from re-downloading a corrupted 2 GB file because a flaky mirror dropped the last 5 MB. GitVaults is a solid catalog for Windows open-source tools, and their download pages are clean without the usual ad-riddled wrappers.

Caveat

This is all based on my own experience with specific networks, mirrors, and clients. Your mileage will vary. I've seen cases where the exact opposite of my advice was true—for example, a mirror that was slow because the client was on a throttled Wi-Fi link, not because of anything on the server side. If you spot an error in my methodology, or you have a better trick for isolating mirror bottlenecks, please correct me. I'm always learning from people who measure more carefully than I do.

Mirror Speed: What Actually Matters When You're Pulling from a Repo at 3 AM

street food Chinese — Sat, 17 Oct 2026 23:43:11 +0000

Mirror Speed: What Actually Matters When You're Pulling from a Repo at 3 AM

I’ve spent more hours than I care to admit staring at a terminal, waiting for a git clone to finish. The progress bar crawls, the network indicator sits at a trickle, and I start questioning every DNS setting I’ve ever touched. Mirror speed is one of those topics that sounds simple—"just pick a faster mirror"—but in practice, it’s a tangle of protocol overhead, geographic routing, and filesystem cache behavior. Let me walk you through what I’ve learned from managing my own local mirror of a few large open-source Windows tool repositories, and where I’ve hit the wall.

The First Mistake: Assuming "Faster" Means "Closer"

The most common advice is to pick a mirror near you. That’s not wrong, but it’s incomplete. I once had a mirror in the same city that was consistently slower than one two time zones away. Why? Because the local mirror was behind a shared 1 Gbps link that was saturated by a CDN serving video streams. The distant mirror had a dedicated 10 Gbps pipe and a better TCP stack.

Here’s the thing: mirror speed is a function of end-to-end throughput, not just latency. You can measure it with a simple test. On Windows, I use PowerShell to download a known file from each candidate mirror and time it. But you need to be careful about caching—if you hit the same file twice, the OS file cache will skew the results)Skip the file cache by using a unique query string or a different file each time.

# Quick mirror throughput test on Windows
$urls = @(
    "https://mirror-a.example.com/file1.bin?cachebust=1",
    "https://mirror-b.example.com/file1.bin?cachebust=2"
)
foreach ($u in $urls) {
    $sw = [System.Diagnostics.Stopwatch]::StartNew()
    Invoke-WebRequest -Uri $u -OutFile "$env:TEMP\test.bin" -UseBasicParsing
    $sw.Stop()
    $size = (Get-Item "$env:TEMP\test.bin").Length
    $mbps = [math]::Round(($size * 8) / ($sw.Elapsed.TotalSeconds * 1MB), 2)
    Write-Host "$u -> $mbps Mbps"
    Remove-Item "$env:TEMP\test.bin" -Force
}

But even this has a flaw. A single file test doesn’t reflect the reality of a git clone or a package manager update, which opens hundreds of small connections. That’s where the real bottleneck often hides: connection setup overhead.

Parallelism and the Hidden Cost of Connection Setup

When you pull from a mirror, you’re not downloading one big file. You’re downloading thousands of small objects—blobs, trees, commit metadata. Each one may require a separate HTTP request. The TCP handshake, TLS negotiation, and HTTP headers can add 50–100 ms per request. If you have 10,000 objects, that’s 500–1000 seconds of pure overhead, even if your bandwidth is infinite.

That’s why I stopped using plain git clone from mirrors and started using shallow clones (--depth 1) for CI and quick testing. But for a full mirror, that’s not an option. So I turned to tools that support concurrent downloads. The most reliable I’ve found is aria2 (which works well on Windows via choco install aria2), but the real game-changer for me was a small utility called putyy res downloader 3 1 3. It’s designed specifically to fetch resource packs from multiple mirrors in parallel and then reassemble them, which is exactly the pattern that kills naive single-threaded downloaders.

Here’s a typical workflow I use when I need to refresh a large mirror of a Windows SDK:

# Using aria2c to pull a large manifest with 16 connections
aria2c -x 16 -s 16 -k 1M `
    -o sdk-mirror.zip `
    "https://mirror-a.example.com/sdk/latest.zip" `
    "https://mirror-b.example.com/sdk/latest.zip" `
    "https://mirror-c.example.com/sdk/latest.zip"

Notice I’m passing multiple URLs for the same file. aria2c will stripe the download across all of them, and if one mirror fails mid-transfer, it retries from another. That’s the kind of resilience you need when a mirror goes flaky at 2 AM.

Failure Modes You’ll Actually Hit (and How to Spot Them)

I’ve seen three distinct failure modes that kill mirror speed, and none of them show up in a simple ping test.

1. The "Stale Cache" Mirror. Some mirrors use a reverse proxy with a long TTL. You request a file, and the proxy serves you a cached version from yesterday—but the actual upstream file has changed. The download is fast, but you get corrupted or outdated data. The symptom: git clone succeeds, but git fsck reports missing objects. The fix: always verify checksums. I write a small script that compares the SHA256 of downloaded files against a manifest from the upstream repo.

2. The "Throttled by IP" Mirror. Some mirrors throttle you after the first 100 MB if you’re on a shared IP (like a corporate NAT). The speed starts high, then drops to a crawl. The symptom is a classic "hockey stick" throughput curve. The workaround: rotate through mirrors using a tool like putyy res downloader 3 1 3, which can be configured to switch mirrors when throughput drops below a threshold.

3. The "IPv6 Blackhole" Mirror. This one is subtle. Your machine prefers IPv6, but the mirror’s IPv6 route is broken—packets are dropped, not rejected. TCP retransmits kill your speed. The symptom: the download hangs for 10 seconds, then bursts. The fix: force IPv4 with curl -4 or set prefer_ipv4=1 in your ~/.gitconfig if you’re using git over HTTP.

Here’s a concrete PowerShell snippet I use to detect the IPv6 issue:

# Check if IPv6 to a mirror is actually working
$ipv6 = Test-NetConnection -ComputerName "mirror-a.example.com" -Port 443 -AddressFamily IPv6
if ($ipv6.TcpTestSucceeded) {
    Write-Host "IPv6 OK, but let's measure real throughput..."
    $sw = [System.Diagnostics.Stopwatch]::StartNew()
    curl.exe -6 -o NUL "https://mirror-a.example.com/test.bin"
    $sw.Stop()
    Write-Host "IPv6 download took $($sw.Elapsed.TotalSeconds) sec"
} else {
    Write-Host "IPv6 is broken, forcing IPv4"
}

Edge Case: The Local Filesystem Is the Real Bottleneck

I nearly pulled my hair out once because a mirror was "slow," but it turned out the mirror was fine—my local disk was the problem. I was downloading to a spinning HDD that was also serving a virtual machine’s pagefile. The disk I/O queue was so deep that writes were taking 200 ms per block. The download was actually arriving at the network card at full speed, but the OS couldn’t write it to disk fast enough.

The fix was simple: download to an SSD or RAM disk. On Windows, I use New-VHD to create a small RAM-backed drive, but that’s overkill. More practically, I just pointed my temp directory to a fast NVMe drive:

# Redirect temp downloads to fast storage
$env:TEMP = "D:\FastTemp"
$env:TMP = "D:\FastTemp"
New-Item -ItemType Directory -Path $env:TEMP -Force | Out-Null

Also, check your antivirus. Real-time scanning on every downloaded file can halve your throughput. I exclude my mirror directories from Windows Defender’s real-time scanning. That alone sped up my pulls by 30–40% on a large repo.

The Practical Workflow: What I Do Now

My current workflow for keeping a local mirror of a large Windows toolchain is this:

Maintain a list of 5–6 candidate mirrors across different ISPs and regions. I update this list monthly.
Use a segmented downloader (either aria2c or putyy res downloader 3 1 3) that can parallelize and failover.
Always verify checksums after download. I keep a SHA256SUMS file in the mirror root and run a PowerShell verification script.
Monitor throughput over time, not just once. I log the speed of each mirror in a CSV and look for trends. A mirror that was fast last week might be saturated this week.
Use shallow clones for ephemeral tasks, and only do a full mirror when I actually need the history.

The tool putyy res downloader 3 1 3 has become a regular part of this because it handles the failover logic automatically. It doesn’t just download—it tracks which mirror responded fastest for the last N requests and biases future requests toward that one. That’s the kind of adaptive behavior you don’t get from a simple wget.

Related resource

If you’re working with Windows resource packs and need a downloader that handles multi-mirror fallback gracefully, I’ve found putyy res downloader 3 1 3 to be a solid addition to the toolkit. It’s hosted on GitVaults, which is a catalog of open-source Windows software—useful for finding tools like this without wading through random forum posts.

Caveat

I’ve shared what works for me, but mirror speed is highly environment-specific. Your ISP’s peering, your local hardware, and even the time of day can flip which mirror is fastest. If you see something in my approach that’s wrong or have a better trick—especially around Windows-specific network stack tuning—I’d genuinely appreciate a correction. Drop a note in the comments or reach out; I’m always learning from people who’ve hit different failure modes than I have.

DEV Community: street food Chinese

The Uninstall That Actually Works: A Practitioner’s Guide to Cleaning Up Windows Apps

The Uninstall That Actually Works: A Practitioner’s Guide to Cleaning Up Windows Apps

Step 1: Inventory Before You Nuke

Step 2: Run the Official Uninstaller, Then Hunt the Leftovers

Step 3: The Failure Modes That Bite You

Step 4: Manual Cleanup — The “Nuclear” Pass

Step 5: Verify the Uninstall Is Actually Clean

Related resource

Caveat

Mirror Failover: When Your "Redundant" Setup Isn't Actually Redundant

Mirror Failover: When Your "Redundant" Setup Isn't Actually Redundant

The Difference Between "Mirrored" and "Highly Available"

A Practical Failover Workflow (Linux + DRBD)

Failure Modes You Won't Find in the Brochure

The PowerShell Side: Windows Storage Spaces and Failover Clustering

Edge Case: Failover When the Primary Is Not Dead

Testing Your Failover (Do It Now, Not at 3 AM)

Related resource

Caveat

The CLI vs GUI Debate: What I Actually Use When the Network Breaks

The CLI vs GUI Debate: What I Actually Use When the Network Breaks

The Workflow: When the GUI Lies to You

The Failure Modes: Where Each Tool Cracks

Edge Cases: When the GUI Can’t Even Open

The Hybrid Reality: Why I Use Both

Related resource

Caveat

Windows 11 Install: What I Actually Do When the Wizard Lies to Me

Windows 11 Install: What I Actually Do When the Wizard Lies to Me

The First Wall: When the Installer Refuses to See Your Disk

The Second Wall: Bypassing the TPM and CPU Check (Only If You Must)

The Third Wall: When the Install Hangs at “Just a Moment” (OOBE Loop)

The Fourth Wall: The 24H2 Update That Bricks Your Dual-Boot

The Fifth Wall: The Hidden Driver That’s Not in the ISO

Related resource

Caveat

Not every "official" installer on GitHub is official

Not every "official" installer on GitHub is official

Four layers, ordered by payoff

Spotting a lookalike download page

curl | sh and friends

Related resource

Caveat

The Download Page Is a Lie: What I Actually Check Before Installing

The Download Page Is a Lie: What I Actually Check Before Installing

The First Pass: What I Ignore on Purpose

The Second Pass: Checksums and the Manifest Are the Real Download Page

The Third Pass: Reading the Manifest for Dependency Clues

The Fourth Pass: Actually Installing and Testing, Not Just Extracting

The Fifth Pass: What the Download Page Doesn't Say

Related resource

Caveat

latest is a moving target: version pinning patterns that scale

latest is a moving target: version pinning patterns that scale

Pin granularity

What deserves a pin

Recovering after drift

Related resource

Caveat

SHA256 Verify: The Command-Line Habit That Saved My Downloads Twice

SHA256 Verify: The Command-Line Habit That Saved My Downloads Twice

The Workflow: Checksums Are Not Magic, They’re Just Math

Failure Modes: When the Hash Doesn’t Match (and Why)

Edge Cases: What SHA256 Verification Doesn’t Cover

A Realistic Command-Line Session

Related resource

Caveat

LLM API Pricing: 375 Models Compared Across 137 Providers

The spread distribution

Why the median is zero

Where the spreads actually come from

What the spread table hides

Worst spreads, measured

openai/gpt-oss-120b in detail

What to do about it

Methodology

LLM API Pricing: 375 Models Compared Across 137 Providers

The spread distribution

Why the median is zero

`openai/gpt-oss-120b` in detail

`openai/gpt-oss-120b` in detail