Stats is a native macOS menu bar system monitor that provides real-time hardware and software metrics for CPU, GPU, RAM, Disk, Network, Battery, Sensors (temperature/voltage/fan), Bluetooth, and Clock. Built entirely in Swift with AppKit, it uses private IOKit, SMC, and IOReport APIs to collect system data, and offers highly customizable widgets (mini, line/bar/pie charts, tachometer, text, etc.) drawn directly in the menu bar. The architecture is modular: each monitored subsystem lives in its own 'Module' directory with a consistent structure (main.swift, readers, popup, settings, notifications, portal). A shared 'Kit' framework provides reusable components including a reader base class with interval management and history persistence via bundled LevelDB, a thread-safe key-value store wrapper, and a set of custom drawing chart widgets. The app also supports remote monitoring via an optional cloud service (System Stats), privileged helper for fan control, macOS widget extensions, and extensive localization (40+ languages). The codebase demonstrates strong engineering practices with clean abstractions, encapsulation, and reusability, though some modules exhibit boilerplate duplication and the project relies on several deprecated or private APIs that may require updates for future macOS releases.
The system-monitoring-center is a Linux desktop application for real-time system resource monitoring and management. It provides a tabbed interface displaying CPU, memory, disk, network, GPU, sensors, processes, services, users, and system information. The application allows users to monitor performance metrics, manage processes and services, and view detailed hardware information through a modular architecture. Built with Python and Tkinter using the Sun Valley theme, the application follows a modular structure where each tab (CPU, Memory, etc.) implements a consistent interface (tab_gui, initial_func, loop_func). Core system data is gathered by the Libsysmon module via /proc, /sys, and system commands (dmidecode, lspci, etc.). The GUI features interactive charts, process/service management capabilities, and supports internationalization across 15+ languages. Configuration is managed through a version-aware system in Config.py. Key reusable components include Common.py for generic GUI utilities (sortable treeviews, search entries, charting canvases) and Config.py for persistent settings management. The application demonstrates good engineering practices with clear separation of concerns, active maintenance, and low technical drift despite Linux-specific dependencies.
GPU-T is a Linux desktop utility for comprehensive GPU information and monitoring, positioned as a GPU-Z alternative for Linux. It provides real-time sensor data (clocks, temperatures, power, fan speeds), static hardware specifications from JSON databases and sysfs, and detection of API capabilities (Vulkan, OpenCL, CUDA, etc.) through a modular probe system. The application follows the MVVM pattern with Avalonia UI and features a sidecar process for NVIDIA-specific NVAPI/NVML interactions to ensure stability and isolate native interop. Hardware detection relies on sysfs paths, external tool execution, and vendor-specific databases, with user override capabilities for hardware specifications. The modular design separates concerns into probes for hardware polling, advanced providers for feature detection, and utilities for common tasks like settings management and shell command execution.
react-use is a comprehensive library of 100+ React hooks organized into categories: Sensors (battery, geolocation, mouse, scroll, intersection), UI (audio, video, fullscreen, slider), Animations (raf, spring, tween, interval), Side-effects (async, debounce, throttle, storage), Lifecycles (effect once, event, mount/unmount), and State management (toggle, counter, list, map, set). The library is built with TypeScript, uses a factory pattern for creating reusable hook generators (createReducer, createStateContext, createGlobalState, createMemo, createBreakpoint), and includes Storybook stories for visual testing. Each hook is implemented as a standalone module in src/ with corresponding tests and documentation. The architecture follows a flat structure where hooks compose primitive React hooks (useState, useEffect, useRef) with browser APIs, using utility functions for event handling and state resolution. The codebase demonstrates solid engineering practices with proper SSR support, isomorphic layout effects, and careful ref management to prevent memory leaks. However, the project shows signs of medium technical drift with outdated dependencies (React 17 in dev deps while peer deps claim universal support), deprecated hooks still present, and some hooks using obsolete browser APIs.
Gobot is a Go framework for robotics, physical computing, and the Internet of Things. It provides a consistent hardware abstraction layer (HAL) over dozens of single-board computers (Raspberry Pi, BeagleBone, Intel Edison, Jetson, etc.), microcontrollers (Arduino via Firmata, Digispark), and communication protocols (GPIO, I2C, SPI, BLE, serial, MQTT, NATS, MAVLink). The architecture is modular: platform-specific adaptors implement core interfaces (DigitalPinner, PWMPinner, I2cBusAdaptor, etc.) and are composed from reusable building blocks in the `platforms/adaptors` package. Drivers for sensors, actuators, displays, and robots (Sphero, Parrot drones, DJI Tello, GoPiGo3) are organized by bus type (gpio, i2c, spi, ble, aio, onewire, serial) and share a common lifecycle pattern with event publishing and command registration. A built-in HTTP API server (with optional basic auth and CORS) exposes robot state and commands over REST and Server-Sent Events, and includes an embedded web UI (Robeaux). The framework supports both high-level orchestration via `Robot` and `Manager` and low-level 'metal' usage for direct hardware control. External dependencies include `periph.io` for GPIO, `tinygo.org/x/bluetooth` for BLE, `gocv.io/x/gocv` for computer vision, and `go.bug.st/serial` for serial communication. The codebase is extensively tested with mock filesystem and syscall infrastructure, and uses functional options for configuration throughout.
LibreHardwareMonitor is a free, open-source hardware monitoring application for Windows (with partial Linux support) that reads temperatures, fan speeds, voltages, loads, clock speeds, and other sensor data from CPUs, GPUs, motherboards, storage devices, network adapters, power supplies, batteries, and various fan/water cooling controllers. The architecture is a Windows Forms desktop application (LibreHardwareMonitor.Windows.Forms) backed by a reusable .NET library (LibreHardwareMonitorLib) that abstracts hardware access through interfaces (IHardware, ISensor, IControl) and a visitor pattern for traversal. Key entry points include the MainForm UI, the Computer class that orchestrates hardware enumeration, and an embedded HTTP server providing REST/JSON and Prometheus endpoints. Data flows from low-level hardware interfaces (LPC I/O, MSR, SMN, SMBus, HID, NVAPI, ADL, WMI, IPMI, SMART) through sensor objects with min/max tracking and history compression, to the UI tree view, system tray icons, logging, and web clients. External dependencies include the Aga.Controls tree view library, HidSharp for USB HID, PawnIO kernel driver for low-level I/O, and several platform-specific native APIs. The codebase is large and well-structured with clear separation of concerns, but contains some monolithic files, outdated JavaScript libraries (jQuery 1.7.2, Knockout 2.1.0), and hardcoded hardware-specific mappings that require ongoing maintenance.
This repository is a comprehensive IoT device driver library for .NET nanoFramework. It provides bindings for hundreds of sensors, actuators, displays, and communication modules (e.g., BME280, SSD1306, NFC, Modbus, cellular modems, GPS). The architecture is a collection of independent driver projects, each with its own samples, tests, and documentation. Shared utility libraries (e.g., System.Device.Model, NumberHelper, SpanByte compatibility shims) support cross-cutting concerns. The codebase is actively maintained with frequent commits, but the sheer number of drivers (300+) leads to varying quality, some code duplication (e.g., SpanByte classes in multiple locations), and partially auto-generated code. Networking components like DHCP server, DNS server, and Home Assistant MQTT integration extend the library beyond raw sensor access. The primary use case is building embedded IoT applications on microcontrollers (ESP32, STM32) running nanoFramework.
This repository is a large collection of bare-metal firmware projects for STM32 microcontrollers (F0, F1, F3, G0, G4 families), authored by Edward V. Emelianov. It contains dozens of independent example and application projects covering USB CDC virtual serial ports, CAN bus gateways, sensor drivers (BMP280, MLX90640, DHT22, DS18B20, etc.), stepper motor control, servo control, LED displays, and more. The code is written in C with direct register access (no HAL) and uses a custom USB stack with ring-buffer-based I/O. Each project is self-contained with its own main.c, hardware initialization, and command parser, typically communicating over USB or UART with a simple text-based protocol. The architecture is monolithic per project: a main loop processes periodic tasks (ADC sampling, sensor reads, CAN message handling) and responds to commands received via USB or UART. Key entry points are the main.c files in each project directory. Data flows involve sensor acquisition (ADC, I2C, SPI), optional processing (median filtering, dew point calculation), and output via USB CDC, CAN, or UART. External dependencies are minimal: only an ARM GCC toolchain and the STM32 CMSIS-like headers provided in the inc/ folder. The repository also includes KiCad PCB designs and gerber files for many projects, indicating a full hardware+software development cycle. While the code is functional and covers a wide range of embedded use cases, it suffers from significant code duplication (ringbuffer.c, usb.c, strfunc.c are copy-pasted across many projects) and lacks a centralized library or build system. Deprecated folders and multiple versions of similar projects (e.g., chronometer_v2, chronometer_v3) add clutter. The repository is best viewed as a personal collection of working examples and prototypes rather than a polished framework. However, several components (ring buffer, string utilities, USB stack) are well-implemented and could be extracted for reuse in other STM32 projects.