⏱️ Lectura: 11 min
La línea de comandos cumple medio siglo siendo un mosaico de celdas de texto. Cada caracter, cada cursor parpadeante, cada salto de línea: todo bidimensional y monocromo en su esencia. Ratty, un nuevo emulador de terminal renderizado por GPU, propone romper esa frontera mostrando gráficos 3D directamente dentro de la consola.
📑 En este artículo
El proyecto, disponible en ratty-term.org, sigue la estela de Alacritty, Kitty y Ghostty al delegar el dibujado en la tarjeta gráfica, pero suma una capa que ningún terminal mainstream ofrece hoy: incrustar escenas tridimensionales inline, junto al texto, sin abrir ventanas auxiliares.
TL;DR
- Ratty es un emulador de terminal renderizado completamente por GPU disponible en ratty-term.org.
- Soporta gráficos 3D inline dentro de la propia línea de comandos, capacidad inexistente en xterm o iTerm2.
- Sigue a Alacritty, Kitty y Ghostty: descargar el render del CPU a la GPU para reducir latencia.
- Permite mostrar modelos 3D, ejes coordenados y previsualizaciones interactivas sin abrir una ventana externa.
- Es código abierto y multiplataforma; el sitio oficial linkea binarios y repositorio fuente.
- Posiciona el terminal como contenedor de medios enriquecidos, no solo texto, similar a un notebook Jupyter.
Qué es Ratty
Ratty se presenta como un emulador de terminal con dos diferenciadores: un pipeline de render basado en GPU y soporte nativo para gráficos 3D embebidos en la consola. Su autor lo resume con un guiño visual —el ratón y el queso que figuran en el sitio— pero detrás del logo amistoso hay una propuesta técnica concreta: tratar el terminal como un contenedor de medios enriquecidos en vez de una cuadrícula fija de glyphs.
El emulador apunta a quienes ya viven en la línea de comandos —desarrolladores, administradores de sistemas, científicos de datos— y necesitan inspeccionar contenido que no es texto: un modelo en formato STL, una escena exportada desde Blender, un mesh generado por un script o un plot tridimensional sin tener que cambiar de contexto a un visor externo.
Por qué importa: contexto e historia
El terminal de Unix nace como un periférico físico —el famoso VT100 de DEC, de 1978— y durante décadas su software emulador apenas duplicó esa lógica: una cuadrícula de celdas de texto, cada una con un caracter y atributos básicos de color o estilo. xterm en los 80, rxvt, gnome-terminal, iTerm2: todas variaciones del mismo paradigma.
La inflexión llegó en 2017 con Alacritty, escrito en Rust por Joe Wilm, que delegó el dibujado a OpenGL y demostró que un terminal podía ser fluido a 144 Hz sin saturar el CPU. Kitty, de Kovid Goyal, siguió esa pista y agregó el kitty graphics protocol, una extensión que permite enviar imágenes inline al terminal mediante secuencias de escape. WezTerm sumó multiplexación y configuración via Lua. Y en 2024 Ghostty, el terminal de Mitchell Hashimoto (fundador de HashiCorp), elevó el listón de UX al integrarse con macOS, Linux y Windows con la misma calidad.
Ratty se inscribe en ese linaje pero hace una apuesta más ambiciosa: si el terminal ya tiene una GPU activa para componer su grid, ¿por qué limitarse a texto plano? La 3D inline es la conclusión natural de tratar a la consola como un compositor moderno.
Cómo renderiza un emulador de terminal moderno
Para entender qué hace distinto a Ratty conviene revisar el flujo típico de un emulador GPU. En un terminal clásico, cada vez que la aplicación que corre adentro (un bash, un htop, un editor) escribe a la PTY, el emulador interpreta la secuencia, actualiza un buffer de celdas en memoria y le pide al sistema operativo que repinte la región afectada. El CPU hace casi todo el trabajo, byte a byte.
En un terminal acelerado por GPU el camino es muy distinto:
- Los glyphs de la fuente se precompilan en un atlas de texturas cargado en VRAM.
- Cada celda visible se convierte en un quad (dos triángulos) con coordenadas UV apuntando al glyph correspondiente del atlas.
- Un shader recorre todos los quads en una sola pasada y los compone contra el fondo, manejando color, negritas, ligaduras y subrayados.
- El frame final se entrega al compositor del sistema, idealmente sincronizado con el refresh rate del monitor.
El resultado: latencia de input por debajo de los 10 ms, scroll suave incluso en logs masivos y cero cuellos de botella en el CPU. Ratty hereda ese pipeline y extiende los quads del grid para incluir viewports 3D: regiones rectangulares dentro del terminal que renderizan una escena completa, con su propia cámara, iluminación y geometría.
graph LR
A["Shell stdin/stdout"] --> B[PTY]
B --> C["Bucle de eventos Ratty"]
C --> D{"texto o media?"}
D -->|texto| E["Atlas de glyphs"]
D -->|3D| F["Escena tridimensional"]
E --> G["Compositor GPU"]
F --> G
G --> H["Frame final"]💭 Clave: el desafío no es renderizar 3D —cualquier juego lo hace— sino mantener la sincronía entre las celdas de texto y las regiones de media, de modo que el scroll, la selección con mouse y el copy-paste sigan comportándose como en un terminal tradicional.
Un ejemplo concreto de uso
Imaginemos un desarrollador trabajando con assets 3D que necesita verificar rápidamente que un archivo .glb se cargó correctamente. En un terminal tradicional tendría que abrir Blender, una página web con un visor, o un script que dispare un viewer externo. En Ratty bastaría con algo como:
# Windows (PowerShell), macOS y Linux (bash/zsh)
$ ratty view modelo.glbEl comando inyecta una región 3D inline dentro de la línea siguiente al prompt, mostrando el modelo con un control de cámara mínimo (rotar con drag del mouse, zoom con scroll). Al terminar, un Enter cierra el viewport y se vuelve al prompt limpio. El terminal nunca dejó de ser un terminal: el output forma parte del scrollback igual que cualquier mensaje de texto.
Para un científico de datos que trabaja con simulaciones, el flujo equivalente sería pipear un dataset directo al terminal:
$ python simulate.py | ratty plot3d --type=scatterSin GUI, sin notebook, sin cambio de contexto. Es la misma idea que en su momento popularizaron Jupyter y los rich displays de IPython, pero llevada al terminal puro.
Comparación con la competencia
El ecosistema de terminales acelerados ya está poblado, y Ratty no aparece en un vacío. Vale la pena compararlo contra los principales actores:
- Alacritty — pionero del render GPU, minimalista, sin tabs ni splits, sin gráficos. Escrito en Rust con OpenGL.
- Kitty — soporta el protocolo de gráficos inline (imágenes 2D, no 3D), tiling propio, scripting en Python. Su graphics protocol fue adoptado por WezTerm y Ghostty.
- WezTerm — multiplexor + emulador, configurable en Lua, soporta imágenes inline via protocolo Kitty.
- Ghostty — el más reciente del grupo (lanzado oficialmente a finales de 2024), enfocado en UX nativa de cada sistema operativo. Soporta imágenes pero no 3D.
- Ratty — el primer emulador que apuesta abiertamente por escenas 3D interactivas inline dentro del flujo de texto.
La diferencia clave es de filosofía. Alacritty quiere ser el terminal más rápido posible; Kitty quiere ser el más completo; Ghostty el más amigable. Ratty, en cambio, redefine qué es un terminal: deja de ser una cuadrícula de texto y se convierte en un compositor de medios.
Implicaciones para developers en LATAM
Para la comunidad de desarrolladores hispanohablante el lanzamiento tiene varias lecturas. Primero, refleja que el software de sistemas open source sigue siendo terreno abierto a la innovación pese a la dominancia comercial de IDEs y notebooks propietarios. Segundo, muestra que las herramientas de productividad de uso diario —el terminal, el editor, el shell— todavía tienen margen para reinventarse, y eso es relevante para founders y equipos que evalúan dónde construir.
En la práctica, un emulador con render 3D inline puede acortar el feedback loop en flujos donde hoy hay fricción: revisar mallas exportadas desde un pipeline de gráficos, debuggear shaders, inspeccionar escenas de un motor de videojuegos, o simplemente plotear resultados de un script de Python sin levantar Matplotlib en una ventana aparte. La diferencia entre 10 segundos para abrir una GUI y medio segundo para ver el resultado inline se acumula a lo largo del día.
💡 Tip: si trabajás con assets 3D o simulaciones, probá Ratty junto a un script wrapper que detecte la extensión del archivo y elija el visor apropiado. Es un patrón que ya usan muchos developers confzfybat.
Limitaciones y compromisos
Ningún diseño es gratuito. La integración GPU-text trae varias contrapartidas que conviene tener claras antes de adoptar el terminal en producción:
- Consumo de VRAM — mantener escenas 3D activas exige memoria gráfica que un terminal tradicional no necesita. En laptops con GPU integrada el costo se nota.
- Sesiones remotas — un SSH a un servidor sin GPU no puede aprovechar el render 3D del lado del servidor. La media debe transmitirse al cliente, lo que abre preguntas sobre protocolos de transporte y ancho de banda.
- Accesibilidad — lectores de pantalla y herramientas de asistencia están pensados para texto, no para escenas 3D embebidas. Es un área donde Ratty deberá especificar cómo se comporta.
- Compatibilidad — herramientas tradicionales como
tmux,screenovimno conocen el protocolo de medios. Conviene verificar que el escape sequence handling sea retrocompatible. - Estabilidad de drivers — un bug en el stack gráfico puede afectar al uso diario del terminal. En consolas tradicionales eso es impensable.
⚠️ Ojo: antes de reemplazar tu terminal principal por Ratty, evaluá si tus integraciones críticas —tmux, mosh, scripts CI— funcionan correctamente. Un emulador exótico no debería ser obstáculo para hacer un git push a las 3 a.m.
Qué sigue para Ratty y el ecosistema
El gran reto de Ratty no es técnico sino de adopción. Para que la 3D inline se vuelva una capacidad esperada del terminal, otros emuladores tendrían que adoptar un protocolo común —similar a lo que hizo el kitty graphics protocol con las imágenes 2D— y herramientas como tmux, los multiplexores SSH y los editores deberían entender ese protocolo. Sin estandarización, la innovación se queda como curiosidad técnica.
La buena noticia es que el espacio se mueve. La adopción de sixel, el protocolo Kitty y los rich displays en VS Code muestran que la cuadrícula 2D de los 80 está siendo desafiada en varios frentes. Ratty empuja un paso más y obliga a la conversación: si la GPU ya está activa, ¿cuál es el límite razonable de lo que podemos mostrar?
Para developers que hoy viven a medio camino entre el terminal y un notebook, la respuesta puede definir cómo será su entorno de trabajo en los próximos cinco años.
📖 Resumen en Telegram: Ver resumen
Preguntas frecuentes
¿Ratty reemplaza a mi terminal actual?
Puede hacerlo si te interesa la 3D inline, pero como cualquier herramienta exótica conviene probarlo en paralelo con tu emulador principal antes de migrar flujos críticos.
¿Funciona con tmux y SSH?
El soporte exacto depende de cómo Ratty implemente los escape sequences. Las funciones de texto son retrocompatibles, pero el render 3D necesita la GPU local del cliente, no se transmite tal cual sobre SSH.
¿En qué sistemas operativos corre?
El sitio oficial linkea descargas; tradicionalmente los terminales modernos cubren Linux, macOS y Windows, aunque conviene revisar la lista actual en ratty-term.org.
¿Es código abierto?
Sí: el sitio oficial expone el repositorio fuente además del binario, lo que permite auditarlo, contribuir y forkearlo.
¿Qué ventaja real tiene la 3D inline frente a abrir un visor aparte?
Reduce el cambio de contexto: para flujos repetitivos —como verificar archivos exportados, inspeccionar geometría o plotear datos— ahorrarse abrir una ventana cada vez se acumula en minutos por día.
¿Compite directamente con Ghostty o Kitty?
Compite en el espacio de terminales acelerados por GPU, pero su diferenciador es la 3D inline. Kitty y Ghostty siguen siendo mejores opciones si solo necesitás texto y eventualmente imágenes 2D.
Referencias
- Sitio oficial de Ratty — descarga, blog y código fuente.
- Alacritty en GitHub — el pionero del render GPU en terminales.
- Kitty graphics protocol — la especificación que popularizó las imágenes inline en terminal.
- Ghostty — terminal acelerado por GPU lanzado por Mitchell Hashimoto en 2024.
- WezTerm — multiplexor + emulador con soporte de imágenes inline.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
0 Comentarios