Resumen

  • Xinu era un sistema operativo compacto pero completo que los estudiantes podían construir por etapas y arrancar en placas de experimentación.
  • El laboratorio de Purdue automatizaba la asignación de placas, la carga de imágenes y el acceso a la consola serie. Así hacía más repetible el paso hasta un sistema en ejecución, pero no medía cuánto aprendían los estudiantes.

Randy Bond recuerda una escena concreta: en la primavera de 1984, durante su último año en Purdue, cursó Sistemas Operativos con Doug Comer y utilizó la primera edición del libro de Xinu. Décadas después describió la construcción de un sistema desde sus fundamentos como una experiencia decisiva para su carrera como ingeniero de software integrado. Es el recuerdo retrospectivo de un estudiante, no una evaluación de toda la clase. Aun así, muestra la apuesta educativa de Comer: resulta más fácil razonar sobre un sistema cuando el alumno puede seguir cómo se construye y luego arrancar el resultado. El relato de Purdue sobre Bond conserva ese recuerdo; los materiales del proyecto muestran la infraestructura que lo acompañaba.

El prefacio del libro parte de un problema conocido: los estudiantes pueden aprender los servicios que ofrece un sistema operativo y seguir pensando que su interior es una caja negra. La respuesta de Comer no fue simplemente reducir el tema. Propuso un sistema cuyos componentes se construían en una jerarquía deliberada, desde una máquina desnuda, para que sus dependencias pudieran verse. El prefacio de Xinu presenta la gestión de procesos y memoria, la sincronización, las entradas y salidas independientes del dispositivo, los controladores, los protocolos y los sistemas de archivos como partes de un diseño ejecutable, no como una lista de funciones.

Xinu era pequeño, pero Purdue no lo describe como un juguete ni como Unix con otro nombre. El nombre significa “Xinu Is Not Unix” y el sitio advierte que su diseño interno es distinto. La afirmación didáctica es más limitada: un sistema compacto puede exponer los componentes habituales de un sistema operativo y las abstracciones que los conectan. Eso le da al curso una implementación concreta que inspeccionar. No demuestra que exista una sola arquitectura válida ni que quien construya Xinu comprenda todos los sistemas comerciales. La descripción de Purdue expone tanto el alcance como los límites del proyecto.

El laboratorio físico convertía el libro en algo más que una secuencia de diagramas y listados de código. Los estudiantes compilaban y enlazaban una imagen en estaciones Linux convencionales. Un conjunto distinto de equipos conectaba las placas de experimentación con Ethernet, mecanismos de reinicio remoto y un multiplexor de puertos serie. El software asignaba una placa disponible, descargaba la imagen, abría una ventana para la consola y arrancaba el sistema. Así, el estudiante podía pasar de editar a ejecutar sin reconstruir a mano todo el camino físico en cada intento. La descripción del laboratorio de Purdue detalla esos pasos.

Esa separación es la superficie operativa que hace distintivo el método. El frente ofrecía herramientas conocidas; el fondo convertía la ejecución física en un recurso compartido. Automatizar la asignación y la descarga reducía tareas repetitivas, pero no automatizaba el razonamiento del estudiante. Un arranque correcto demostraba que una imagen había llegado a una placa y comenzado a ejecutarse. Por sí solo no probaba que el estudiante entendiera planificación, memoria, interrupciones o acceso a dispositivos. Las afirmaciones deben ser prudentes justo en esa frontera entre ejecución observable y comprensión demostrada.

El acceso al hardware también era una decisión de diseño. El prefacio decía que, cuando se escribió, las placas Galileo y BeagleBone Black seleccionadas costaban menos de 50 dólares. La cronología del proyecto registra que en 2014 el laboratorio se rediseñó con 120 placas Galileo donadas y unas pocas BeagleBone Black. Son datos históricos, no precios actuales ni un coste publicado por estudiante. Las fuentes no ofrecen ocupación de placas, tiempos de espera, tasas de fallo ni gastos de soporte. Demuestran que se montó un laboratorio compartido de bajo coste, no permiten calcular su economía total.

El trabajo tampoco fue individual. Comer escribió el libro y orientó el sistema, pero el prefacio agradece a estudiantes de posgrado sus ports y controladores, identifica a Rajas Karandikar y Jim Lembke como autores de controladores Galileo y del sistema de descarga en varias etapas, y enumera a estudiantes que detectaron problemas y aportaron código. La cronología de Purdue también atribuye a Dave Stevens trabajo con Comer en una implementación completa de TCP/IP.

Presentar Xinu como invención de una sola persona borraría el modelo de enseñanza que documentan las fuentes: colaboradores y alumnos modificaban el sistema mientras trabajaban con él.

La opción de usar una máquina virtual ayuda, pero no equivale a trabajar con las placas. Purdue explica que la versión de VirtualBox sustituye algunas operaciones de entrada y salida asignadas a memoria por un manejo adaptado a puertos y utiliza otro controlador Ethernet. Una máquina virtual reduce la barrera del hardware, pero también cambia la interfaz que se pone a prueba. Todo informe debería indicar si el resultado procede de una placa física o de un emulador.

El legado que puede sostenerse es concreto. Xinu combinó una implementación legible con un camino repetible desde el código fuente hasta el hardware, de modo que los estudiantes pudieran observar más del sistema que lo que revela una API. El recuerdo de Bond documenta el efecto que tuvo en una persona. Los materiales del proyecto describen el código, el laboratorio y usos comunicados por terceros, pero no prueban mejoras educativas en un estudio controlado ni ofrecen un censo independiente de adopciones posteriores. Ejecutar el código hacía verificable la lección; no convertía un registro de arranque en un estudio de aprendizaje.

Fuentes