orf/gping

This system is a high-performance network latency monitoring tool, rewritten in Rust, that visualizes ping results in a terminal interface. It supports both standard ICMP and configurable TCP pinging across a wide range of operating systems, including Linux, macOS, Windows, and various BSD variants. The application features cloud-specific endpoint shortcuts, customizable graph statistics such as jitter and P95 latency, and extensible command execution capabilities.

The pinggraph package has been removed from the codebase. This change deletes the \\_\init\\_.py\, \pinger.py\, and \termsize.py\ files, eliminating the functionality that previously provided terminal-based network latency visualization and terminal size detection.

pinggraph · high confidence

The gping application has been rewritten to introduce several new capabilities and behavioral changes. Users can now perform TCP pings (with configurable ports and RST handling) alongside standard ICMP. The tool supports cloud-specific shorthands (e.g., \aws:eu-west-1\, \gcp:me-central2\) to automatically resolve and ping cloud endpoints. The graph display now includes additional statistics in the header: average latency, jitter (calculated chronologically), P95 latency, and timeout counts. Users can customize the vertical axis scale with \--ymin\ and \--ymax\ options, and apply custom colors to graph entries by name or hex code. The interface also supports custom margins, a \--clear\ flag to reset the terminal on exit, and generic command execution via \--cmd\. Platform-specific behaviors have been adjusted, such as disabling ping options on Windows and using a 1-second default interval on OpenBSD.

gping · high confidence

The pinger library has been rewritten to support TCP-based pinging (allowing users to probe specific ports and configure how connection refused responses are handled) alongside the existing ICMP functionality. It now includes native support for BSD variants (FreeBSD, OpenBSD, NetBSD, DragonFly) and Alpine Linux, while improving Linux detection to explicitly reject unsupported ping implementations like inetutils. The library also introduces a fake pinger implementation for testing, adds examples for both standard and TCP pinging, and refactors the internal architecture to use a trait-based Pinger interface with lazy-regex for parsing.

pinger · high confidence

The application has been rewritten in Rust, replacing the previous Python implementation. This migration introduces new capabilities such as TCP pinging, command execution graphing via the --cmd flag, and AWS region support, while removing the Python package structure (setup.py, MANIFEST) in favor of a Cargo-based build system, Dockerfile, and comprehensive installation documentation for various platforms.

(repo-wide) · high confidence

This change introduces the initial committed state for gping version 1.21.0, establishing a Rust workspace structure that separates the main application (gping) from the core ping execution logic (pinger). The gping application now depends on the local pinger library (version 2.2.0) and utilizes the ratatui terminal UI framework (version 0.30.2) for graphing, alongside clap for command-line argument parsing. The pinger library itself is a cross-platform tool for executing and parsing ping commands, featuring support for Windows via the winping crate and configurable fake-ping behavior for testing.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 59 → 62 (+2.6)
• Rubric changed (rubric-2026.09.8 → rubric-2026.09.17) — scores are not directly comparable.

• Code Health 94 → 94 (+0.0)
• Architecture 100 → 95 (-4.9)
• Maturity 40 → 61 (+20.4)
• Readiness 66 → 50 (-16.2)
• Security 73 → 78 (+4.5)

• Documentation: no architecture or design documentation (README.md)

• Inconsistent high-level API entry points. run_ping takes raw command and arguments, while ping and get_pinger take structured PingOptions. The existence of run_ping suggests a low-level execution path, but ping and get_pinger are ambiguous: ping likely executes immediately, while get_pinger returns a Pinger instance (which must then be started). This mixes imperative execution with builder patterns without clear distinction.
• Inconsistent use of Color type for arguments. with_raw_arguments and run_ping both use Color (likely a typo for Vec<String> or similar) for arguments, but PingOptions also has raw_arguments: f32. This is a type mismatch: f32 cannot hold raw string arguments. This is a critical inconsistency in the API design.
• Off the main sequence: pinger
• Outdated: clap
• Outdated: rand
• Outdated: thiserror
• Redundant constructors with inconsistent parameter types and naming. new and new_ipv4/new_ipv6 accept impl ToString for the target, while from_target accepts a concrete Target type. This creates confusion about which constructor to use and why from_target exists alongside the new family. Additionally, having separate new_ipv4 and new_ipv6 constructors is redundant if the PingOptions struct already has a mode: PingMode field that can be set via with_mode.

• 1 commits — 1 feature/other, 0 fixes

• (root) — 1 commit

• change: Add WinGet installation instructions (#597)

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

orf/gping was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.