← Posts

core-probe — A Hardware Diagnostic Toolkit Written in Go

March 16, 2026 — Ben Santora

You find an old machine. Maybe it’s been sitting in a closet for five years. Maybe someone handed it to you. The question is always the same: is this thing worth reviving, and for what?

You could google the CPU, check the RAM, estimate the disk, cross-reference Linux compatibility. Or you could drop a single binary on it, run it, and get an answer in three seconds.

That’s core-probe.

Download

Linux, x86-64.

curl -L https://bensantora.com/downloads/core-probe-linux-amd64 -o core-probe
chmod +x core-probe
./core-probe

Source: core-probe-source.tar.gz | core-probe-source.zip | github.com/bensantora-tech/core-probe

How Do You Build core-probe?

Requires Go 1.21+. The entire toolkit is a single source file with no external dependencies.

go install github.com/bensantora-tech/core-probe@latest

Or build from source for specific targets:

# Current machine
go build -o core-probe main.go

# Legacy 32-bit Linux
CGO_ENABLED=0 GOOS=linux GOARCH=386 go build -ldflags="-s -w" -o core-probe-x86 main.go

# Standard 64-bit Linux
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -ldflags="-s -w" -o core-probe-x64 main.go

# ARM (Raspberry Pi etc)
CGO_ENABLED=0 GOOS=linux GOARCH=arm go build -ldflags="-s -w" -o core-probe-arm main.go

CGO_ENABLED=0 produces a fully static binary. No shared libraries, no runtime dependencies. If the machine runs Linux at all, it runs core-probe.

What Does core-probe Check?

core-probe reads five things directly from the kernel — no shelling out to external tools, no assumptions about what’s installed.

CPU — model name, physical core count, logical thread count, architecture (32 or 64-bit), current frequency, and capability flags: SSE2, AES, and hardware virtualization (VMX/SVM). Physical cores are counted by tracking unique physical id + core id pairs in /proc/cpuinfo, so the count is accurate on multi-socket systems.

Memory — total RAM, available RAM, free RAM, and swap. Read directly from /proc/meminfo. Available vs. free is an important distinction on Linux — available accounts for reclaimable cache; free does not.

Disk — total capacity, free space, and usage percentage for each major mountpoint (/, /home, /data, /var). Bind mounts and pseudo-filesystems are filtered out by deduplicating on filesystem ID, so the same underlying device doesn’t appear twice.

Thermal — temperature in Celsius for each thermal zone found under /sys/class/thermal/. Zones at or above 85°C are flagged critical. Zones above 75°C are flagged high. If no thermal zones are present — common on older or embedded hardware — the score is neutral rather than penalized.

Environment — hostname, kernel version parsed from /proc/version, and whether glibc is present at any of the standard paths. The glibc check is a stat call, not execution — it tells you whether the machine can run dynamically linked binaries without actually running anything.

How Does the Scoring Work?

core-probe produces a score out of 100 across five categories:

Category	Max	What it measures
CPU	30	Core count, 64-bit support, virtualization capability
RAM	30	Total memory — the primary constraint on what software will run
Disk	20	Storage capacity and available space
Thermal	10	Whether the machine is running at safe temperatures
Kernel	10	How modern the Linux kernel is

The score maps to one of four verdicts:

Score	Verdict
75 – 100	EXCELLENT — Full revival candidate
55 – 74	GOOD — Viable for targeted deployment
35 – 54	MARGINAL — Single-purpose only
0 – 34	POOR — Parts or disposal recommended

Each verdict comes with a list of specific use cases the machine is actually suited for — web server, DNS/DHCP node, serial console server, and so on — scaled to what the hardware can realistically handle.

Why Does core-probe Need to Be a Static Binary?

Most software today won’t start on an old machine — not because the hardware is too slow, but because the binary links against glibc or other libraries at versions that don’t exist on a 2010-era system. The software refuses before it even runs.

core-probe is built with CGO_ENABLED=0, which tells the Go compiler to bundle everything into a self-contained file. There is nothing to install and no version conflicts. The same binary runs on a kernel 2.6 machine from 2004 and a current Debian install.

That matters specifically for diagnostics. The machine you’re evaluating is often the one least likely to have modern software available.

Sample Output

====================================================
   CORE-PROBE  //  Hardware Diagnostic Toolkit
   v2.0  //  github.com/bensantora-tech/core-probe
====================================================
   host arch : linux/amd64
====================================================

[ PROBING HARDWARE... ]

[ CPU ]
  model       : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
  phys cores  : 2
  logical     : 2
  bits        : 64-bit
  freq        : 3000 MHz
  features    : sse2

[ MEMORY ]
  total       : 3947 MB
  available   : 3201 MB
  free        : 2900 MB
  swap        : 2047 MB total / 2047 MB free

[ DISK ]
  /           476.3 GB total / 301.2 GB free / 37% used

[ THERMAL ]
  zone0 (x86_pkg_temp)      41.0 C  [ok]

[ ENVIRONMENT ]
  hostname    : oldbox
  kernel      : 5.4.0
  glibc       : detected at /lib/x86_64-linux-gnu/libc.so.6
  note        : dynamic linking available but not required by this binary

====================================================
[ WORTHINESS SCORE ]
----------------------------------------------------
  cpu         : 25 / 30
  ram         : 24 / 30
  disk        : 20 / 20
  thermal     : 10 / 10
  kernel      : 10 / 10
----------------------------------------------------
  TOTAL       : 89 / 100
----------------------------------------------------
  VERDICT     : EXCELLENT — Full revival candidate

[ RECOMMENDED USE CASES ]
  - Lightweight web server (nginx/caddy)
  - Git server / self-hosted CI
  - NAS with samba/nfs
  - VPN gateway / firewall

====================================================

For live system monitoring once you’ve decided to keep the machine, see newtop — per-thread CPU, memory, disk I/O, and network in a terminal UI. For socket and network exposure monitoring, see netsock.

FAQ

Q: What is core-probe? A single static binary that evaluates old Linux hardware. It reads /proc and /sys directly, scores the machine across five categories (CPU, RAM, disk, thermal, kernel), and prints a verdict with specific use case recommendations.

Q: Does core-probe require root or sudo? No. Everything it reads — /proc/cpuinfo, /proc/meminfo, /proc/version, /sys/class/thermal/* — is readable by any user on a standard Linux system.

Q: What Linux versions does core-probe support? Any Linux kernel 2.6 or later — roughly 2004 onward. The static binary has no library dependencies, so there’s nothing to break on old systems.

Q: Which binary should I download for my machine? If the machine is from after 2005 and is a regular PC or laptop, use the x64 binary. Use the x86 binary for pre-2005 32-bit hardware. Use the ARM binary for Raspberry Pi and similar single-board computers.

Q: How does core-probe count physical cores? It tracks unique physical id + core id pairs from /proc/cpuinfo. This correctly handles multi-socket systems and hyperthreaded CPUs — it reports physical cores, not logical threads.

Q: What happens if thermal sensors aren’t available? The thermal score is set to 5 out of 10 — neutral, not penalized. Older hardware often lacks kernel thermal zone support, and that shouldn’t count against the machine.

Tested on Debian/CrunchBang++. Go 1.21+. Linux only — reads /proc and /sys directly.