Milo

Appearance

std/sysinfo ​

System and process information: host name, CPU count and model, memory, load average, uptime, process and user ids, and the working directory. Each OS has its own implementation behind the one import path.

milo
from "std/sysinfo" import { hostname, cpuCount, cwd }

Example ​

milo
print($"{hostname()}: {cpuCount()} cpus, in {cwd()}")

API reference ​

std/sysinfo has one implementation per target (darwin, linux, windows); the resolver picks the one for the target you build for.

cpuCount ​

milo
pub fn cpuCount(): i64

cpuModel ​

milo
pub fn cpuModel(): string

Windows has no unprivileged, non-registry brand-string source, so report the processor architecture (honest and label-accurate) rather than a fabricated model.

cwd ​

milo
pub fn cwd(): string

egid ​

milo
pub fn egid(): u32

euid ​

milo
pub fn euid(): u32

freeMem ​

milo
pub fn freeMem(): i64

gid ​

milo
pub fn gid(): u32

hostname ​

milo
pub fn hostname(): string

loadAvg ​

milo
pub fn loadAvg(): [f64; 3]

Windows has no load-average metric; the darwin/linux arms return this array too, so keep the shape and report zeros rather than inventing a number.

osRelease ​

milo
pub fn osRelease(): string

The reliable OS version lives behind the registry (RtlGetVersion needs ntdll and a manifest to be truthful), which this arm deliberately avoids. Empty matches the POSIX failure return rather than reporting a version the API is known to lie about.

pid ​

milo
pub fn pid(): i32

ppid ​

milo
pub fn ppid(): i32

No getppid on Windows without a Toolhelp process walk; degrade to 0 like a failed /proc read rather than returning a fabricated parent.

setCwd ​

milo
pub fn setCwd(path: string): bool

totalMem ​

milo
pub fn totalMem(): i64

uid ​

milo
pub fn uid(): u32

Windows identities are SIDs, not numeric ids — there is no uid/gid/euid/egid to report, so these return u32 MAX as "no such concept here".

NOT 0, which is what they used to return. The comment justifying that said 0 "matches the darwin/linux failure return", and there is no such thing: getuid() cannot fail, so on the POSIX arms 0 means the process IS root. The standard portable guard — if uid() == 0 { … }, whether it refuses to run as root or unlocks a privileged path — therefore took the root branch unconditionally on Windows. That is precisely the "plausible-looking value" the port's convention exists to forbid (AGENTS.md); u32 MAX is not a uid any system issues, so a caller that ignores it gets a wrong answer that looks wrong rather than one that looks like root.

uptime ​

milo
pub fn uptime(): i64