15 puntos por GN⁺ 2025-09-08 | 1 comentarios | Compartir por WhatsApp
  • El driver ftape es el único driver de kernel open source de Linux capaz de recuperar datos de cintas de respaldo (QIC-80) de los años 90
  • Sin embargo, este driver dejó de mantenerse después del año 2000, por lo que solo podía usarse en entornos Linux antiguos
  • Con Claude Code, se refactorizó el código fuente antiguo para adaptarlo al kernel de Linux moderno y se convirtió con éxito en un módulo de kernel independiente
  • Durante el proceso, Claude convirtió automáticamente funciones y estructuras obsoletas a la API moderna, mientras el usuario analizaba manualmente los resultados para corregir algunos errores de configuración
  • A partir de esta experiencia usando un agente de programación con IA, se obtuvieron ideas sobre cómo amplificar la capacidad del programador y hacer onboarding rápidamente en nuevas tecnologías y frameworks

Contexto: recuperación de cintas de respaldo antiguas y el driver ftape

  • Recuperar datos de cartuchos de cinta como QIC-80 es uno de los pasatiempos del autor
  • Estas cintas suelen requerir unidades de cinta especiales conectadas al controlador de disquete
    • Estas unidades se usaban principalmente en los años 90 por pequeños negocios o usuarios particulares para respaldos
    • Este enfoque, basado en el controlador de disquete, permitía una implementación barata sin un adaptador SCSI dedicado, pero tenía varias desventajas como la limitación de velocidad (500 Kbps) y un protocolo no estándar
  • Para comunicarse con este hardware de cinta, en Linux es indispensable el driver de kernel ftape
    • Como solo ftape puede leer los datos binarios crudos puros, es imprescindible para la recuperación
  • Pero el driver ftape dejó de mantenerse desde alrededor del año 2000, así que no podía usarse en kernels modernos de Linux
    • Por eso, cada vez que se quería recuperar datos, había que arrancar manualmente una distribución Linux antigua (como CentOS 3.5)

Comienza la modernización del driver de kernel con Claude Code

  • Se le pidió a Claude Code, junto con una explicación del repositorio, que modernizara el driver para que pudiera compilarse en kernels actuales
  • Claude identificó y reemplazó funciones y estructuras obsoletas para ajustarlas a la API y la arquitectura actuales del kernel
    • Tras varias rondas de feedback y correcciones manuales, se completó un driver que compilaba sin errores
  • Al principio, el código solo podía compilarse dentro del árbol completo del código fuente del kernel, pero con una solicitud adicional generó automáticamente un sistema de compilación para módulo externo e independiente
    • Gracias a eso, fue posible crear por separado un módulo de kernel en formato .ko y comenzar las pruebas con hardware real

Proceso de resolución de problemas

  • El módulo de kernel se cargó correctamente, pero aparecieron problemas de detección y comunicación con la unidad
    • Como eran tareas que requerían permisos de sudo, Claude no podía ejecutarlas repetidamente por sí mismo, así que se le compartieron manualmente los logs de dmesg para rastrear el problema
  • Comparando los logs con casos previos exitosos, Claude detectó un bug relacionado con la falta de configuración del puerto I/O predeterminado y con la inicialización de parámetros
    • El valor por defecto pasó de -1 a 0xffff, lo que impedía la detección; al restablecer la dirección correcta, el problema se resolvió
  • Finalmente, el módulo se cargó correctamente y se logró volcar los datos de una cinta de prueba

Qué deja esta experiencia de colaboración con un agente de programación con IA

  • La interacción con Claude Code se sintió como "colaborar con un desarrollador junior", parecida a trabajar con un ingeniero real
    • El usuario igual tuvo que liderar activamente las decisiones de arquitectura, la detección de problemas y la dirección del trabajo
  • Cuanto más específicos y orientados al dominio sean los keywords y pedidos, más efectivo resulta
  • La productividad de un agente de IA aumenta drásticamente cuando recibe el tipo de tarea adecuado, por lo que hace falta criterio para entender sus límites y fortalezas
  • La IA logró multiplicar la capacidad del autor. Un trabajo que a mano habría tomado semanas se completó en pocos días solo con conversaciones cotidianas y feedback
    • En el proceso también se aprendieron habilidades realmente útiles, como prácticas modernas de desarrollo de kernel, arquitectura x86 y nuevas herramientas de línea de comandos
  • Se enfatiza que también acelera mucho el onboarding y la adaptación inicial a nuevos frameworks (como Rust o Flutter)

Conclusión: ftape vuelve a la vida

  • Después de 25 años, ftape vuelve a poder compilarse y usarse en Linux moderno
  • El autor sigue haciendo mejoras adicionales y pruebas, y además de unidades basadas en disquete, confirmó soporte para dispositivos basados en puerto paralelo
  • El hardware físico sigue siendo casi el mismo que antes, pero el sistema operativo cambió de CentOS 3.5 a Xubuntu 24.04

Referencia

  • El código fuente del proyecto ftape está disponible en GitHub
  • En el blog personal del autor también puede verse la lista de equipos de su colección

1 comentarios

 
GN⁺ 2025-09-08
Opiniones de Hacker News
  • Yo cargaba el módulo manualmente y luego copiaba y pegaba a mano la salida de dmesg en un ciclo para Claude
    Una de las principales razones por las que uso Claude es que puede iniciar procesos de larga duración y leer su salida para depurar
    Aquí había varias formas de saltarse ese paso manual; por ejemplo, canalizar dmesg a un puerto UDP local y hacer que Claude iniciara un listener

  • Me parece un buen caso de uso
    Creo que al usar estas herramientas se obtienen dos efectos principales
    Primero, en frameworks que ya conozco, Claude hace pattern matching de las partes repetitivas muy rápido y me sube muchísimo la productividad
    Segundo, también permite hacer onboarding mucho más rápido cuando estás aprendiendo un framework nuevo; eso ayuda especialmente en empresas grandes que usan stacks variados
    Para entender bien lo que la IA puede hacer, hay que invertir bastante tiempo en tecnologías y frameworks que cambian rápido
    Si no has usado Claude Code o Claude 4.0 durante más de 100 horas, quizá no alcances a ver bien su potencial
    El escenario de “alguien que no es programador se pone a codear a puro instinto y se mete en problemas” probablemente sea lo normal en X (antes Twitter), pero cuando un desarrollador con experiencia le dedica tiempo de forma constante, la experiencia es completamente distinta

    • Ese es el punto clave
      Yo uso Claude Code todos los días, sin falta, como herramienta principal para hacer cambios en codebases existentes
      A base de prueba y error armé mi propio proceso, y gracias a eso aumentaron mucho mi productividad y mis ganas de intentar experimentos grandes
      En particular, me encanta que si yo diseño por adelantado la estructura de datos, el esquema y las APIs internas, Claude Code luego me arma la UI de herramientas internas casi de una sola pasada
      Me permite pensar de forma más abstracta, lejos del trabajo repetitivo o de la complejidad del framework, y eso ha sido un gran punto de inflexión en mis 16 años de carrera

    • Exacto
      Básicamente el autor le pidió a Claude que portara un driver de Linux 2.4 a 6.8
      Como hay suficiente material relacionado en línea, Claude resolvió la mayor parte del trabajo y la experiencia del autor solo hizo falta en las partes realmente complejas y centrales
      La idea de “usar la IA como herramienta para amplificar explosivamente tus habilidades” aquí pega muy fuerte
      Si tu capacidad base aquí es 0, aunque la multipliques con IA seguirá cerca de 0, o incluso puede dar productividad negativa

    • En nuestro equipo también hay gente que, con LLM, se anima a probar áreas nuevas, pero incluso dándole a todos Claude 4 thinking agent, sigue saliendo muchísimo código fuera de lugar
      Si durante casi toda tu carrera de programación te acostumbraste al pattern matching, entonces el agente LLM está haciendo pattern matching encima de ese pattern matching, y para compañeros que no tienen esa experiencia termina siendo más bien un dolor de cabeza
      Los agentes LLM hacen mucho más rápido el pattern matching que puede hacer una persona, pero en términos generales no me parece que sean particularmente superiores a los humanos

    • No solo sirve para explorar frameworks nuevos, también para lenguajes nuevos
      Nuestro equipo usa Ruby, y como Ruby es fácil de leer, ni siquiera hace falta aprender bien la sintaxis; simplemente le pedimos al LLM que escriba el código y nosotros tomamos las decisiones
      Aunque no conozcas Ruby, puedes empezar a escribir de inmediato código a un nivel aceptable para el equipo, así que puedes ser productivo enseguida incluso en un entorno desconocido
      (Aclaración: los compañeros revisan los Pull Request)

    • La frase “herramienta que amplifica explosivamente tus habilidades” la sentí muchísimo esta semana mientras hacía un proyecto pequeño diez veces seguidas
      Su verdadero valor aparece cuando yo le doy guía y luego integro de forma prolija el marcado, los estilos, el JS y demás cosas que la IA generó de forma desordenada
      En entornos como startups, donde las convenciones de código son débiles, es difícil aplicar pedidos de pattern matching, pero imagino que en codebases fuertes y maduras el efecto debe ser totalmente distinto

  • Creo que hay que redactar prompts usando palabras clave lo más específicas posible y centradas en el dominio
    Si te falta comprensión técnica de cierto lenguaje o framework, el prompt queda ambiguo, y el LLM rellena esos huecos por su cuenta, así que es fácil terminar con resultados distintos a lo que querías
    Esa ambigüedad es precisamente la causa de los bugs
    Esa es la otra cara de la “amplificación explosiva”

    • Si solo dijera “la clase C necesita un constructor de tupla”, esperaría que Claude respondiera algo como “a ver, espera un momento…”
  • Al leer este tipo de textos, me hace pensar que antes de adoptar LLM se hacía muchísimo menos trabajo del que realmente se necesitaba

    • Yo sigo pensando que el cuello de botella no es la “ejecución”, sino las “ideas con mercado”
      No hay tantas cosas por las que la gente realmente quiera pagar

    • El problema no es siempre que falte trabajo, sino que faltan personas con la experiencia y el conocimiento previos necesarios para hacerlo
      Si no tienes experiencia en desarrollo de kernel, por más buenos que sean tus prompts, será difícil obtener un resultado como el del autor
      En teoría parece que, con el poder de los LLM, sería posible “modernizar” todos los drivers viejos para kernels nuevos, pero en la práctica siempre hace falta supervisión humana, y además de gente experta; y la cantidad real de especialistas así es muy pequeña comparada con la cantidad de drivers que hay que mantener
      Hay una buena conversación e entrevista entre Alan Kay y Joe Armstrong donde mencionan el problema de que la mayoría del código no se desarrolla de una forma en la que puedas simplemente cambiar el target y compilar, porque no existe una especificación
      Si hubiera una especificación formal aparte del código, portar un driver a un nuevo kernel sería fácil en la forma de “recompilar la especificación”
      Pero como hoy se parte del código viejo y no de una especificación, en el proceso de mover código previo a código moderno el LLM solo hace pattern matching sobre código parecido; no entiende ni garantiza el significado real, y por eso la habilidad humana sigue siendo indispensable

  • Ya tenía la intuición de que la IA iba a bajar la barrera de entrada para hacer kernel hacking
    Cada vez siento más que eso es verdad
    Pronto podría ampliarse mucho el soporte para hardware embedded/ARM, e incluso aparecer nuevos OS ligeros para dispositivos inteligentes

    • Si usas bien la IA, puedes subir de nivel muy rápido
      Pero la mayoría le pide a la IA que “le construya toda la casa”, cuando en realidad funciona mejor si la usas como “algo que te ayuda a martillar”
  • Me parece un buen ejemplo de un desarrollador que entiende bien el papel y los límites de la IA, y la usa de forma apropiada
    En particular, me llamó la atención que, gracias a su escepticismo, hizo el driver como un módulo separado

  • Quiero señalar una “pista importante” que nadie más mencionó
    El autor dice claramente: “No hay que exagerar el resultado de Claude, porque yo ya tenía algo de experiencia con módulos de kernel y manejo bien C”
    O sea, no fue realmente que al tercer intento el módulo de kernel quedó listo; hubo muchas idas y vueltas en la conversación y el código se corrigió varias veces a mano
    También dice que, si no hubiera entendido la estructura interna básica de un módulo de kernel, jamás habría podido modernizarlo; ese es un contexto que siempre hay que tener presente, uses la herramienta de generación de código que uses
    Además, escribió que colaborar con Claude Code se siente “parecido a trabajar con un ingeniero junior”, pero que como hace todo lo que le pides y si le marcas un error enseguida se disculpa o te halaga, se parece menos a un ingeniero real y más a un estilo adulador
    Y por último, el autor dice que “si realmente hubiera querido, podría haber hecho este trabajo solo, pero habría tenido que volver a aprender cómo se desarrollaba para kernels de hace 25 años”
    Eso vuelve a poner sobre la mesa que la esencia del trabajo de modernización está en “entender con precisión la solución legacy y detectar qué hace falta”
    Y me parece especialmente interesante que también se señale como ventaja el hecho de poder saltarse ese aprendizaje

    • Esa actitud que marca fronteras, como de gatekeeping, es dañina
      Me gusta mucho cuando un agente me explica proyectos que yo no conozco
      Hace poco cloné el código fuente de Firefox y usé qwen-code para preguntar por las funciones de IA de Firefox y cómo están implementadas, y aprendí muchísimo
      La forma de aprender se volvió mucho mejor
  • Creo que es un cambio que empodera más a la gente
    El autor ha hecho side projects con pasión durante mucho tiempo, y una mejora de herramientas es algo realmente bueno
    Pero cuando el área es demasiado de nicho, puede faltar apoyo de la comunidad, y ahí un LLM puede ayudar a resolver problemas muy personalizados
    Poco a poco está bajando la barrera de entrada, y va a llegar una época en la que incluso personas con menos base técnica podrán resolver por sí mismas problemas más simples y específicos
    Es un cambio positivo que permite que más gente se anime a intentar cosas

  • Me da curiosidad cómo cambió la velocidad después de la actualización

    • Como el mismo hardware se controla con el mismo driver, la velocidad debería ser la misma