Dataplicity LensLinux + macOS
GitHub
Lens / Architecture
For contributors

How Lens is organised.

An overview of the shared data model, platform collectors, session history, system checks and output code.

Dependency direction

The model owns canonical user-facing types. Platform collection produces the model; history derives rates; diagnostics consumes snapshots; output and UI render the same structures.

lens + specialist apps
↓ compose
lens-systemlens-uilens-outputlens-diagnostics
↓ consume
lens-corelens-historylens-platform-linuxlens-platform-macos
↓ produce / use
lens-model schema v2

No specialist duplicates collectors. No presentation crate directly reads platform interfaces or invokes operating-system commands.

Process identity survives PID reuse.

A process key combines PID and kernel start ticks. History joins only when both match. A disappeared process is skipped; a broken parent reference is bounded; a cycle cannot trap tree rendering.

rust
ProcessKey {
  pid: 8421,
  start_time_ticks: 783_204_119,
}

Platform data sources

The collectors read local kernel and operating-system interfaces. Partial source results remain visible while independent collections finish. The interactive overview shows host and process data first, then loads services, logs, storage, networking and hardware in the background.

  • Linux: /proc, systemd, journal, filesystems, network interfaces, ModemManager, thermal zones, hwmon, device tree, DMI, USB sysfs and serial device paths
  • Raspberry Pi: device-tree identity plus vcgencmd temperature, firmware and power/throttling state
  • macOS: native process, launchd, unified-log, filesystem, network and system-profiler interfaces
  • Hostname, kernel release, OS release and user mapping
Collection follows the current user.

Commands use the account's existing operating-system access and identify sources that need additional permission or tooling.

Bounded session history.

CPU uses process tick deltas relative to host tick deltas. I/O uses counter deltas over measured time. Buffers are bounded and counters saturate on decreases.

System checks

A finding has an identifier, severity, the data that triggered it, related entities and suggested actions. Findings are calculated from the local snapshot shown in the command output.

Operational model

  • Native Linux, Raspberry Pi OS and macOS collection
  • Named process signals and systemd service actions with dry-run, confirmation and verification
  • An explicit local diagnostic shell alongside live system data
  • Local operation under the invoking user's operating-system permissions
  • A shared schema-versioned snapshot for terminal, plain-text and JSON output

See platform compatibility for the native capability matrix and the command reference for the output and automation contract.