Hay tecnologías que desaparecen sin hacer ruido y otras que, por mucho que pasen las décadas, se quedan viviendo en un rincón del mundo real. El GPIB —siglas de General Purpose Interface Bus, también conocido como HP-IB— pertenece a la segunda categoría. Nació en 1972 de la mano de Hewlett-Packard para resolver un problema muy concreto: conectar ordenadores con instrumentos de laboratorio de forma robusta y controlable, mucho antes de que el USB se convirtiera en el estándar universal y cuando Ethernet aún no era sinónimo de “conectar cualquier cosa”.
Ahora, más de medio siglo después, ese bus “de laboratorio” protagoniza un giro inesperado: los controladores de GPIB dejan de estar en la zona de pruebas del kernel y pasan a integrarse en el árbol principal de Linux con la llegada del ciclo de Linux 6.19. En términos prácticos, significa una cosa: quienes todavía dependan de equipos y tarjetas GPIB —laboratorios, universidades, centros de calibración o aficionados al hardware clásico— ganan una base más sólida para seguir trabajando en sistemas modernos.
De estándar de laboratorio a reliquia útil
GPIB fue, durante años, el conector que mandaba en instrumentación. Su diseño respondía a un mundo donde lo importante era la fiabilidad: la capacidad de encadenar dispositivos, controlar equipos de medida y automatizar pruebas sin depender de soluciones frágiles. Con el tiempo, el estándar terminó formalizándose como IEEE 488, y su presencia se consolidó en osciloscopios, multímetros, generadores de señal y un largo etcétera.
Para el gran público, el bus puede sonar a arqueología informática, pero su historia tiene un punto curioso: además de ser un “idioma” habitual en laboratorio, también aterrizó en la informática doméstica en cierta medida. Modelos como los Commodore figuran en el relato popular del IEEE-488, precisamente porque en esa era muchas marcas experimentaban con buses paralelos y soluciones de periféricos externas cuando todavía no había consenso sobre “lo correcto”.
Lo sorprendente es que, incluso hoy, GPIB no está muerto. En instrumentación es frecuente encontrar equipos que siguen funcionando tras décadas, y reemplazarlos no siempre es tan simple: a veces el dispositivo es caro, otras está calibrado o integrado en un flujo de trabajo, y en muchos casos “si funciona, no se toca”. El resultado es que el mundo real ha seguido necesitando GPIB mucho más tiempo del que dictaba la moda tecnológica.
Qué cambia con Linux 6.19: salir del “staging” importa
La clave de esta noticia no es solo que exista soporte: es dónde vive ese soporte dentro del kernel. En Linux, los controladores que aún no cumplen los estándares de calidad, mantenimiento o limpieza de código suelen residir en staging, una especie de sala de espera técnica. Funciona como un aviso para navegantes: “esto está aquí para mejorar, pero todavía no es el soporte ‘de pleno derecho’ que el kernel considera maduro”.
Según la información publicada por desarrolladores y medios especializados, GPIB llevaba un tiempo en staging y ha pasado por un trabajo de limpieza y maduración. El paso definitivo llega en el ciclo de Linux 6.19, cuando el responsable del área de staging, Greg Kroah-Hartman, confirma que gpib (junto a otros componentes) sale de staging y entra en la parte “real” del kernel.
Traducido a lenguaje no técnico: el soporte deja de ser “experimental” dentro del ecosistema del kernel y pasa a considerarse suficientemente sólido como para mantenerse como un componente normal del sistema. Para quienes operan equipos de medida antiguos o tarjetas GPIB en entornos actuales, la diferencia se nota en estabilidad, mantenimiento y futuro: cuando algo está plenamente integrado, resulta más fácil que se adapte a cambios internos del kernel, que reciba revisiones y que no quede “colgado” en cada salto de versión.
Un bus paralelo de 8 MB/s que aún tiene trabajo que hacer
Parte de la ironía es que GPIB no era, ni pretende ser, una autopista moderna. Aun así, su rendimiento histórico sigue llamando la atención: se le atribuye un techo de alrededor de 8 MB/s, con capacidad para conectar múltiples dispositivos en un bus compartido y longitudes de cable que en su época resultaban prácticas para entornos técnicos. Frente a USB-C, PCIe o redes de alta velocidad, suena modesto. Frente a la realidad de muchos instrumentos de medida —que no necesitan mover gigabytes por segundo—, es más que suficiente.
En el mundo de la instrumentación, además, el valor no siempre está en la velocidad bruta. Está en la predictibilidad: enviar un comando, esperar una respuesta, sincronizar equipos, registrar lecturas y repetir procesos con fiabilidad. Esa es la razón por la que GPIB sobrevivió tanto tiempo, incluso cuando aparecieron interfaces más cómodas o más “universales”.
Por qué llega ahora: mantenimiento, legado y una comunidad que no olvida
Que un estándar de 1972 termine encontrando un lugar estable en el kernel en 2025 no es magia, sino un reflejo de cómo funciona el software libre: la compatibilidad suele llegar cuando alguien la necesita lo suficiente como para mantenerla. En este caso, el paso por staging sugiere que el código ha sido revisado, adaptado y alineado con las expectativas del kernel moderno.
El impacto es doble. Por un lado, es una victoria silenciosa para quienes viven en el día a día de laboratorios y equipamiento técnico: significa poder ejecutar Linux actual sin depender de parches raros, árboles externos o soluciones a medias. Por otro, tiene un punto cultural: Linux vuelve a demostrar que su relación con el hardware no es solo “lo último”, sino también lo “duradero”. Si existe comunidad y mantenimiento, el sistema operativo puede convertirse en un puente entre generaciones tecnológicas.
En una época en la que gran parte del software se diseña para ciclos de vida cortos, que un bus veterano encuentre soporte estable dentro del kernel es casi un gesto político —en el buen sentido—: la historia importa, y la utilidad también.
Un cierre de ciclo con utilidad real
El titular fácil sería decir que “Linux abraza el pasado”. Pero la realidad es más interesante: Linux abraza lo que todavía se usa. Y GPIB, aunque sea viejo, sigue formando parte de un tipo de infraestructura que no aparece en redes sociales, pero sostiene mediciones, calibraciones, pruebas y automatizaciones en miles de entornos.
La llegada de estos controladores al “kernel de verdad” en el ciclo de Linux 6.19 cierra un círculo histórico: un estándar nacido para instrumentación en los años setenta gana un soporte más formal en uno de los sistemas operativos más extendidos del planeta. Para algunos será nostalgia; para otros, pura continuidad operativa.
Preguntas frecuentes
¿Qué es GPIB (HP-IB o IEEE-488) y para qué se utilizaba?
Es un bus de comunicación paralelo creado por Hewlett-Packard en 1972 para conectar ordenadores con instrumentos de laboratorio (osciloscopios, multímetros, equipos de prueba) y automatizar mediciones de forma fiable. Más tarde se estandarizó como IEEE-488.
¿Qué significa que el controlador GPIB salga de “staging” en Linux 6.19?
Que deja de estar en una zona considerada de pruebas o maduración y pasa a integrarse como parte normal del kernel. Suele implicar mejor mantenimiento, mayor estabilidad y menos riesgo de roturas con cambios internos en futuras versiones.
¿A quién le afecta hoy que Linux tenga soporte estable para GPIB?
Principalmente a laboratorios, universidades, centros de calibración y empresas con instrumentación antigua o tarjetas GPIB, además de aficionados que conservan hardware clásico. Permite seguir usando equipos veteranos con sistemas Linux modernos.
¿Cómo se conectan equipos GPIB a un PC con Linux actualmente?
Depende del hardware: existen tarjetas/controladoras GPIB y también adaptadores externos. Con soporte estable en el kernel, el objetivo es que esas controladoras funcionen mejor integradas, sin depender tanto de código externo o configuraciones experimentales.
Imágenes de la Wikipedia.
