LEDs de discos duros y máquinas ruidosas
Los LEDs parpadeantes del disco duro, el ruido de los ventiladores y otras señales de hardware “ruidoso” antes daban a los desarrolladores una intuición inmediata de lo que hacían sus máquinas, desde el thrashing del swap hasta procesos defectuosos. Con los portátiles silenciosos de hoy, los SSD y las CPU potentes, muchos sostienen que esa retroalimentación se ha perdido, lo que ha llevado a software sobredimensionado e ineficiente y a una mayor necesidad de herramientas de monitorización explícitas, pantallas de estado personalizadas o métricas dentro de la app. Otros responden que los gráficos de CPU y disco de bajo nivel son un pobre sustituto de una observabilidad adecuada a nivel de aplicación, y señalan compromisos como el mayor consumo energético, las preocupaciones de privacidad y el riesgo de obsesionarse con detalles de rendimiento irrelevantes.
Pérdida de la retroalimentación física (ruido, LEDs, ventiladores)
- A muchos les faltan los LEDs del disco duro, el aumento de velocidad de los ventiladores y el coil whine como señales de “sexto sentido” de bajo esfuerzo para detectar bloqueos, swap, procesos desbocados o malware.
- Algunos describen que podían predecir bloqueos o eventos de juego a partir de los sonidos del HDD o de los ventiladores, o que usaban el ruido del módem y la interferencia RF como indicadores de actividad.
- Otros no sienten nostalgia por el hardware ruidoso y encontraron que los indicadores del pasado eran distractores o poco útiles, especialmente cuando los ventiladores siempre encendidos ahogaban todo lo demás.
Monitores modernos de software y hardware
- Sustitutos populares: herramientas de la barra de menús de macOS (iStat Menus, MenuMeters, el de código abierto “Stats”), extensiones de GNOME (system-monitor-next, tophat), herramientas de Linux (conky, multiload-ng, GKrellM), herramientas de Windows (Rainmeter, XMeters, gráficos en la bandeja de Task Manager) y monitores basados en SSH/terminal.
- Algunos prefieren herramientas minimalistas, bajo demanda (htop, dstat) porque los gráficos en movimiento constante son visualmente molestos.
- Otros quieren más retroalimentación: pantallas USB externas, teclados RGB como displays de actividad, LCDs en refrigeradores de CPU o paneles LED y módulos LCD personalizados (por ejemplo, mediante lcdproc).
Energía, rendimiento y filosofía de las métricas
- Preocupa que las actualizaciones de la UI cada 1 segundo impidan estados de sueño profundo y perjudiquen la duración de la batería, especialmente en portátiles; se cita a iStat Menus como algo que reduce notablemente la duración de la batería en macOS.
- Otros sostienen que las máquinas de desarrollo pueden permitirse esa sobrecarga si eso conduce a software más eficiente y a un menor uso total de energía en producción.
- Un bando insiste en que las métricas de bajo nivel (CPU, E/S de disco) son malas alertas primarias; en su lugar, abogan por las “golden signals” (latencia, errores, rendimiento) y métricas específicas del dominio, con las estadísticas del sistema como datos de apoyo.
- Otro bando valora las métricas de bajo nivel siempre visibles para detectar rápidamente código que se comporta mal o explosiones de logging durante el desarrollo.
Hardware, bloat y empatía por los usuarios
- Varios señalan que las máquinas modernas, silenciosas y potentes, y los SSD ocultan ineficiencias; el código ingenuo o pesado en CPU a menudo solo se convierte en un problema de nube o de coste de hardware.
- Quejas sobre el bloat de la web/front-end, los tiempos de compilación largos y los desarrolladores que usan máquinas sobredimensionadas que enmascaran problemas reales de rendimiento, especialmente en redes y hardware más lentos.
Privacidad y actividad en segundo plano
- Las luces de estado antes ayudaban a distinguir “mi trabajo” de actividad sospechosa o no deseada; ahora la telemetría constante en segundo plano y las actualizaciones automáticas hacen que los indicadores de actividad sean menos interpretables.
- Se sugieren sistemas operativos de código abierto y stacks autoalojados como formas de recuperar la confianza, aunque se reconoce que verificar la ausencia de telemetría no es trivial.