Claude escribiendo un controlador de macOS para mi obscura impresora HP hecha solo para Windows

Artículo original ↗ Discusión en Hacker News ↗

Un experimento usando el modelo de IA Claude para conseguir que una impresora láser HP, solo para Windows, funcione en macOS desencadena reflexiones más amplias sobre cómo los grandes modelos de lenguaje pueden revivir hardware no compatible, desde impresoras y escáneres hasta mandos de juego y dispositivos industriales. Los comentaristas comparten numerosos ejemplos de uso de IA para hacer ingeniería inversa de protocolos, adaptar controladores de Linux o Windows y construir herramientas de nicho que nunca habrían tenido tiempo o conocimientos para crear por sí solos. Otros cuestionan las afirmaciones de marketing de que la IA “escribió un controlador” cuando en realidad envolvió componentes existentes de Linux, planteando dudas sobre la exactitud, la seguridad, el consumo energético y lo que esto significa para el trabajo tradicional de programación de bajo nivel.

Resultado principal

  • El hilo analiza el uso de un LLM (Claude) para hacer que una impresora láser HP/Samsung solo USB funcione en macOS pese a no tener controlador del fabricante.
  • La solución inicial reutilizaba el componente “Unified Linux Driver” (ULD) de HP dentro de Docker, conectándolo con la impresión de macOS.
  • Tras las críticas, el proyecto se actualizó a una configuración “totalmente nativa de macOS”: extrayendo el filtro rastertospl del controlador de Linux, integrándolo en la pila CUPS de macOS, más un pequeño puente USB.

¿Es realmente un “controlador”?

  • Algunos sostienen que esto no es un controlador real para macOS, sino un envoltorio containerizado o de userland alrededor de un binario de Linux ya existente.
  • Otros responden que cualquier capa de software que permita al sistema operativo comunicarse con el hardware califica como controlador, aunque incruste otro sistema operativo o binario.
  • Los críticos llaman engañoso al titular/README y lo ven como una maniobra de marketing; los defensores dicen que lo único que importa es “la impresora no funcionaba, ahora sí”.

Los LLM como herramientas de ingeniería inversa

  • Muchos comparten historias similares de éxito: escribir o adaptar controladores y herramientas para:
    • Mandos de juego y botones extra, interfaces MIDI, escáneres, impresoras, lámparas BLE, pantallas de tinta electrónica, controladores de carritos de golf, cámaras USB, impresoras de etiquetas, aplicaciones de audio/vídeo, viejos formatos CAD, etc.
  • Patrón común: proporcionar especificaciones, capturas USB/Bluetooth, volcado de firmware o referencias previas; el LLM itera a través de muchos pasos tediosos.
  • La ingeniería inversa se describe repetidamente como un “punto óptimo” para los LLM: bien especificada, verificable y tediosa.

Escepticismo, riesgo y compensaciones

  • Se plantean preocupaciones sobre:
    • Seguridad (launchers con privilegios de root, ejecución de código opaco, stacks containerizados).
    • Mantenibilidad y falta de subida al upstream de correcciones generadas por IA.
    • Exageración: a veces las soluciones podrían encontrarse con proyectos existentes o con un poco de búsqueda en Google.
    • Costes energéticos y de recursos frente a simplemente comprar una impresora nueva.
  • Otros señalan que los LLM a menudo fallan o entran en bucles en casos más difíciles; el éxito no está garantizado.

Reflexiones más amplias

  • La discusión se amplía hacia:
    • El bloqueo de proveedor y las APIs de hardware restringidas (NFC, UWB, escáneres, impresoras).
    • La esperanza de que la IA haga de nuevo más real la creación de herramientas a medida y el “computing personal”.
    • Preocupaciones sobre el futuro del trabajo de controladores de bajo nivel, pero también entusiasmo por resucitar hardware antiguo.