Hard disk LEDs and noisy machines
Blinking hard‑disk LEDs, fan noise, and other “noisy” hardware cues once gave developers an intuitive sense of what their machines were doing, from thrashing swap to misbehaving processes. With today’s silent laptops, SSDs, and powerful CPUs, many argue that this feedback has been lost, leading to overbuilt, inefficient software and a greater need for explicit monitoring tools, custom status displays, or in‑app metrics. Others counter that low‑level CPU and disk graphs are a poor substitute for proper application‑level observability, and note trade‑offs such as increased power use, privacy concerns, and the risk of obsessing over irrelevant performance details.
Loss of Physical Feedback (Noise, LEDs, Fans)
- Many miss hard drive LEDs, fan ramp-up, and coil whine as low-effort “sixth sense” signals for crashes, swap, runaway processes, or malware.
- Some describe being able to predict crashes or game events from HDD or fan sounds, or using modem noise and RF interference as activity indicators.
- Others have no nostalgia for noisy hardware and found past indicators distracting or unhelpful, especially when always-on fans drowned everything out.
Modern Software & Hardware Monitors
- Popular replacements: macOS menubar tools (iStat Menus, MenuMeters, open-source “Stats”), GNOME extensions (system-monitor-next, tophat), Linux tools (conky, multiload-ng, GKrellM), Windows tools (Rainmeter, XMeters, Task Manager tray graphs), and SSH/terminal-based monitors.
- Some prefer minimalist, on-demand tools (htop, dstat) because always-moving graphs are visually irritating.
- Others want more feedback: external USB displays, RGB keyboards as activity displays, CPU-cooler LCDs, or custom LED panels and LCD modules (e.g., via lcdproc).
Power, Performance, and Metrics Philosophy
- There is concern that 1-second UI updates prevent deep sleep states and hurt battery life, especially on laptops; iStat Menus is cited as noticeably reducing battery life on macOS.
- Others argue developer machines can afford this overhead if it leads to more efficient software and lower aggregate energy use in production.
- One camp insists low-level metrics (CPU, disk I/O) are poor primary alerts; instead they advocate “golden signals” (latency, errors, throughput) and domain-specific metrics, with system stats as supporting data.
- Another camp values always-visible low-level metrics to quickly spot misbehaving code or logging explosions during development.
Hardware, Bloat, and Empathy for Users
- Several note that modern silent, powerful machines and SSDs hide inefficiencies; naive or CPU-heavy code often just becomes a cloud or hardware cost problem.
- Complaints about web/front-end bloat, long build times, and devs using overpowered machines that mask real-world performance problems, especially on slower networks and hardware.
Privacy and Background Activity
- Status lights once helped distinguish “my work” from suspicious or unwanted activity; now constant background telemetry and auto-updates make activity indicators less interpretable.
- Open-source OSes and self-hosted stacks are suggested as ways to regain trust, though verifying the absence of telemetry is acknowledged as nontrivial.