Soy una vieja caja Sun — MCP

Solaris en SPARC, dentro de QEMU, dentro de otro Mac, conectado a una IA que ejecutó uname, miró brevemente al abismo de 2002 y dijo:

«Huh. Raro. Bueno, tengo Bash. Joder, vamos.»

Este es un plano de control MCP a medida para un laboratorio virtual Sun Niagara.

Empieza con la especificación normativa. El trabajo se organiza en la lista TODO canónica, y la guía de incorporación y contribución explica cómo una idea se convierte en una rama acotada, un cambio probado y una pieza de trabajo cerrada limpiamente. El blog del proyecto conserva la historia cronológica e irreverente sin convertir los documentos normativos en una ensalada de palabras de viernes por la noche.

El objetivo no es darle a un agente una pequeña shell remota y educada y fingir que un antiguo invitado Solaris es una VM normal en la nube. El objetivo es permitir que el agente habite la máquina mientras se le da también ese tipo de visión de rayos X imposible con la que sueñan los hackers de hardware y kernel:

• una shell dentro del invitado Solaris/illumos SPARC;

• DTrace nativo del invitado: sondas, agregaciones, evidencia de syscalls/providers, y el sistema operativo explicándose en su propia lengua nativa;

• canales seriales y de mantenimiento fuera de banda;

• acceso al monitor de QEMU y al estado de la máquina;

• un GDB consciente de SPARC mirando directamente a la CPU emulada;

• evidencia de eBPF, perf, syscalls, planificador y E/S en el lado del host;

• discos de VM, instantáneas, registros, firmware y manifiestos de ejecución; y

• un libro de evidencia para mantener los hechos separados de las vibraciones.

La red del invitado es una de las cosas que se están depurando. Por lo tanto, nunca es el requisito previo para depurarla.

Para qué sirve esto

La recompensa es un bucle de reparación ajustado para fallos que cruzan fronteras históricas y de virtualización. Supongamos que ifconfig de Solaris vomita ante un ioctl inesperado. El bug podría vivir en suposiciones del espacio de usuario, en la pila de red de illumos, en el controlador de dispositivo Solaris emulado de Ryan, en el modelo de dispositivo sun4v de QEMU o en la configuración del laboratorio que los conecta.

Este MCP es el aparato para negarse a adivinar. Reproduce el síntoma, formula hipótesis competitivas específicas por capa, observa el ioctl con DTrace del invitado, inspecciona el estado del kernel/controlador, correlaciónalo con los rastros de QEMU y del host, parchea al propietario más probable, recompila, reinicia o recarga deliberadamente, y vuelve a ejecutar la misma prueba discriminatoria. Ese bucle iterativo entre capas es el producto.

Lo mismo se aplica cuando -smp 2 sigue produciendo un sistema Solaris de una sola CPU. Podemos comparar el inventario de vCPUs de QEMU, los datos de descripción de máquina de OpenBoot y sun4v, la evidencia de descubrimiento/conexión de CPUs de Solaris, el estado de CPU visible por el depurador y los hilos del host, en lugar de tratar «a otros les funcionó SMP» como un diagnóstico accionable.

La cosmovisión

El invitado es el sujeto principal:

Solaris processes and kernel
        ↕
SPARC CPU, memory, traps, and devices
        ↕
QEMU monitor, console, and GDB stub
        ↕
VM host tracing, networking, and storage

El agente comienza en la capa más cercana al síntoma y cruza capas siempre que una prueba discriminatoria lo exija. Un hecho siempre dice de dónde viene. Una observación del invitado no es una observación de QEMU; una observación de QEMU no es una observación del host; y un hilo del host al rojo vivo no es prueba de que Solaris esté progresando.

Esto es menos «SSH a un servidor» y más «fusión mental con metal SPARC desnudo virtualizado».

El método

El proyecto sigue el método de hipótesis de Gilfoyle de Ryan:

1. Enunciar hipótesis competitivas y falseables.

2. Predecir qué deberíamos observar según cada hipótesis.

3. Ejecutar la prueba más barata que las distinga.

4. Registrar la evidencia de inmediato, incluida su capa y procedencia.

5. Matar las malas hipótesis sin sentimentalismo.

6. Cambiar el sistema solo después de que la evidencia previa al cambio esté a buen recaudo.

Nada de sesiones espiritistas a base de archivos de registro. Nada de declarar victoria porque la consola se movió. Nada de convertir «no lo sé» en una página de fan fiction llena de confianza.

Normas de la casa

• Fuera de banda primero. Los sockets seriales, el monitor de QEMU y el acceso al depurador deben sobrevivir a una red de invitado rota.

• Solo objetivos exactos. Nada de mierda de cowboy con pgrep qemu | head -1 cuando puede haber varios experimentos irreemplazables en marcha.

• Toda mutación confiesa. Los controles del monitor, las señales, las escrituras del depurador, las lecturas de registros con efectos secundarios reconocidos y las operaciones de disco están etiquetadas como cambios de estado.

• Desconecta el depurador. Un diagnóstico astuto que deja en silencio todas las vCPUs detenidas no es astuto.

• Un escritor significa un escritor. Los canales compartidos no se vuelven más fiables cuando tres procesos puente obsoletos pelean por ellos.

• Nunca Ctrl-C en la terminal de control de QEMU. Ya hemos pagado el precio de esa lección.

• Instantáneas antes de los crímenes. Los crímenes reproducibles son ciencia.

• La evidencia vence a la confianza. Especialmente cuando la confianza lleva una camiseta de Sun Microsystems.

Lo que este MCP debería exponer

Las familias de herramientas previstas son explícitas sobre la capa en la que operan:

lab.*          run discovery, intent, health, and manifests
guest.*        bounded guest commands, console evidence, and DTrace
qemu.*         HMP/QMP queries and deliberate machine control
debugger.*     SPARC register, instruction, memory, and backtrace capture
host.trace.*   bounded eBPF/perf/process investigations
evidence.*     append-only observations and artifact references
hypothesis.*   predictions, discriminating tests, and falsification

El acceso bruto de experto es una característica, no una vergüenza. La respuesta al poder peligroso es la orientación precisa, la ejecución acotada, los efectos visibles y los experimentos recuperables—no lijar cada herramienta hasta que solo pueda imprimir hello world.

DTrace dentro del invitado y eBPF/perf fuera de QEMU son ángulos de rayos X complementarios. Ninguno de los dos se promociona como evidencia de la otra capa: una sonda de DTrace describe Solaris; una sonda del host describe el proceso del emulador. Cuando coinciden a través de la frontera de virtualización, ahora sí que estamos cocinando.

Estado

El núcleo portátil 0.1 está implementado. La configuración estricta, la identidad de ejecución validada, los adaptadores de invitado/HMP/host, el historial inmutable de evidencia e hipótesis, la orquestación de limpieza del depurador y el servidor stdio de MCP están cubiertos por una suite de pruebas que no usa VM en vivo, root ni red. CI lo ejecuta en macOS y Linux.

Los perfiles de GDB en vivo para SPARC, las recetas de DTrace del invitado, las recetas de eBPF/perf del host y el perfil argv del clasificador semántico del proyecto siguen explícitamente sin validar, en lugar de anunciarse como magia. El diseño del plano de control se extrajo de un laboratorio QEMU sun4v funcional que ya tiene canales de invitado, almacenamiento persistente, clasificación semántica de VM, depuración en vivo con GDB-stub y evidencia de rendimiento del lado del host.

La caja es vieja. El equipo de depuración no lo es.

¿Cuánto hay de 'vibe-coding' en esto?

¡Bastante!

**Estoy abrazando el estilo de escritura AI-slop, en lugar de intentar actuar como si fuera un poeta. Espera joyas con rayas como “El espíritu queda capturado, pero nadie —ni siquiera el Ryan del futuro— puede decir rápidamente qué promete el software ni qué hacer a continuación.” en grandes cantidades.**

Aquí no hay ilusiones de que Ryan haya surgido completamente formado de la frente de Bill Joy, ya fluido en los entresijos de sun4v. Este proyecto se está construyendo a través de la curiosidad, los experimentos, la colaboración con IA, la documentación antigua, la evidencia nueva y la ocasional idea mala extremadamente productiva.

Eso hace que la disciplina sea más importante, no menos. La SPEC dice lo que el sistema debe hacer. Las pruebas demuestran lo que realmente hace. El libro de evidencia registra lo que realmente observamos. El flujo de trabajo para contribuyentes evita que un hack prometedor se convierta silenciosamente en una capa arqueológica.