Casciian: interfaces TUI en Java (con sabor Turbo Vision) y listas para ir a producción por SSH

Hay una idea que se perdió con la moda de las interfaces web: no todo necesita un navegador.

Para muchas herramientas —sobre todo las que viven en servidores— lo que uno quiere es:

• Un binario pequeño.

• Cero dependencias raras.

• Correr por SSH sin abrir puertos.

• Una interfaz usable, con menús, ventanas y ratón.

Eso es exactamente el hueco que viene a llenar Casciian.

Repositorio: https://github.com/crramirez/casciian

 

---

El problema real: “solo necesito una UI… pero en el servidor”

En el día a día aparecen herramientas que sí necesitan interfaz, pero donde una web app sería sobredimensionar el problema:

• Instaladores y asistentes (wizard) para configurar servicios.

• Herramientas internas para operar una plataforma.

• Consolas de administración para entornos aislados.

• Utilidades que quieres distribuir como “un comando más” de Linux.

La web te obliga a meter infraestructura, TLS, autenticación, despliegues, dependencia del navegador, y el clásico “abre otro puerto”.

Con una TUI bien hecha, la propuesta de valor es directa:

• Acceso inmediato por SSH.

• Cero superficie extra (no abres nada adicional en red).

• Experiencia consistente incluso en entornos sin GUI.

---

¿Qué es Casciian?

Casciian es una librería para construir interfaces tipo GUI dentro de un terminal (TUI), compatible con la mayoría de terminales modernos y con una estética muy familiar si creciste con Turbo Vision.

Está hecha en Java, con un enfoque muy específico:

• Cero dependencias externas.

• Diseñada para compilarse a código nativo con GraalVM.

• Optimizada para que una app real (por ejemplo, un editor de texto) pueda quedar en el orden de ~18 MB como binario nativo, con libc como única dependencia externa.

• Empaquetada como DEB, ese mismo ejemplo puede rondar ~6 MB.

El objetivo es simple: que puedas escribir una herramienta en Java y distribuirla como si fuera un comando de sistema, con una UI usable y moderna dentro del terminal.

---

Lo que puedes construir (sin inventarte la rueda)

Casciian soporta los conceptos básicos de una GUI “de verdad” dentro del terminal:

• Barra de menús.

• Ventanas.

• Cuadros de diálogo.

• Campos de texto.

• Listas.

• Botones.

• Soporte completo de ratón.

• Gestos típicos como mover ventanas, seleccionar, navegar y operar controles.

Esto no es “un simple menú de consola”. Es una UI de aplicaciones, sólo que renderizada en texto.

    

---

Por qué el enfoque “nativo con GraalVM” importa

Java es excelente para productividad, pero para utilidades tipo CLI/TUI hay dos problemas clásicos:

1. Distribución: pedirle al usuario “instala Java” es fricción.

2. Tamaño: meter módulos como java.desktop solo para cosas que realmente no necesitas, infla el binario.

Casciian está pensada para evitar ambos:

• Compilas con GraalVM, obtienes un binario nativo.

• El resultado puede ser lo suficientemente pequeño como para entrar en un paquete DEB/RPM que se siente “normal”.

En otras palabras: time-to-value alto para el usuario final, sin que tú sacrifiques el stack de Java.

---

De dónde viene Casciian: Jexer (2013) y una decisión consciente

El origen de Casciian está en Jexer (https://jexer.sourceforge.io/index.html), un proyecto iniciado en 2013 por Autumn Lamonte.

Jexer es más ambicioso:

• Puede incrustar imágenes junto con texto (corriendo en terminal).

• También tiene una interfaz Swing cuando el programa corre localmente.

Yo quería usar Jexer para crear herramientas que corrieran en Linux, pero con dos restricciones claras:

• Que no requieran Java instalado.

• Que no terminen siendo demasiado grandes.

Así que hice el trabajo (con ayuda de GitHub Copilot) de separar las dependencias AWT/Swing del core, de forma que el soporte de terminal pudiera vivir sin java.desktop.

Cuando le presenté esto a Autumn, ella tomó una decisión bien pragmática:

• Crear una variante llamada Casciian (por ASCII)

• Partiendo sin dependencias AWT/Swing desde el inicio.

• Quitando el soporte de imágenes (porque ese camino empuja de vuelta a dependencias que aquí no queremos).

Ese trabajo lo dejó en dominio público y me dejó como maintainer.

Yo, por mi parte, le añadí una licencia Apache 2.0 para los cambios que yo he ido incorporando a partir de ahí.

---

Del 0.4 al 1.0: foco en “que funcione impecable por SSH”

Autumn dejó Casciian en la versión 0.4. Yo he trabajado hasta llevarlo a 1.0.

El foco de estos cambios no fue “meter features por meter”, sino lo que realmente paga dividendos en el mundo real:

• Corrección de bugs.

• Ajustes para que las apps por SSH funcionen lo mejor posible.

• Mejoras de compatibilidad y experiencia de uso en terminal.

Esto es importante porque la TUI se siente o no se siente. En un servidor no hay margen para una UX frágil.

---

Prueba de concepto: casdial (un clon de dialog, pero con esteroides)

Como prueba de concepto hice casdial:

• Un clon del comando dialog.

• Orientado a que scripts bash puedan tener una TUI.

• Pero aprovechando todo el músculo de Casciian, incluyendo soporte completo de ratón.

Repositorio: https://github.com/crramirez/casdial

A día de hoy ya tiene release con soporte a:

• --msgbox

• --yesno

• --menu

Y lo más interesante: el release incluye paquetes DEB y RPM que traen solo el ejecutable, como cualquier herramienta típica de Linux.

casdial --msgbox "Esto es un mensaje" 5 30 

casdial --yesno "¿Desea continuar?" 3 30 

casdial --menu "Seleccione una opción" 10 30 3 "UNO" "Uno" "DOS" "Dos" "TRES" Tres 

---

Un template listo para arrancar

Además del demo, también armé un template tipo Hello World para que puedas comenzar un proyecto Java con interfaz de texto sin pelearte con el setup.

https://github.com/crramirez/casciian-app-template

---

Casos de uso: dónde Casciian brilla

Si quieres una regla simple:

Si la herramienta vive en un servidor y tu usuario entra por SSH, Casciian es un “fit” natural.

Ejemplos concretos:

• Consolas internas de administración.

• Instaladores interactivos.

• Herramientas DevOps que hoy son un script + prompts improvisados.

• UI para servicios que no deberían exponerse vía web.

La ventaja competitiva aquí es operativa: menos moving parts, menos ataque superficial, menos cosas que mantener.

---

Cómo empezar

• Casciian: https://github.com/crramirez/casciian

• Casdial: https://github.com/crramirez/casdial
  
  

    

---

Roadmap (propuesta)

Este es el tipo de cosas que normalmente definen si una librería TUI termina siendo “de hobby” o “de producción”:

• Más widgets del ecosistema dialog.

• Refinar edge cases de terminales y multiplexores.

• Documentación con ejemplos completos.

• Seguir refinando el código para mejorar su eficiencia, tamaño y mantenibilidad.

---

Casciian no intenta competir con un framework web. No es ese el juego.

Casciian busca algo más específico y muy útil: interfaces amigables en terminal para tus herramientas Java, con distribución ligera, sin dependencias externas y con una experiencia que se siente como una GUI clásica.

Si te suena a “esto era obvio y nadie lo estaba resolviendo así”, es precisamente por eso que me metí en el proyecto.

Cómo los agentes de IA están reescribiendo la forma de contribuir a proyectos open-source

Durante años, contribuir al open-source ha sido un lujo que muchos desarrolladores no siempre podemos permitirnos. No por falta de ganas, sino por falta de tiempo. Entrar en un repo nuevo implica leer código, entender la arquitectura, seguir el estilo del proyecto, ejecutar el build, interpretar los pipelines, preparar pruebas unitarias, documentar… un trayecto que fácilmente consume días. Hoy, con los agentes de IA —en particular GitHub Copilot Agent— ese proceso se está transformando de forma radical.

Y el open-source juega un papel clave: es el terreno donde estos agentes funcionan con su máximo potencial.

El open-source es el entorno natural para los agentes de IA

Cuando trabajas con código propietario, siempre existe la barrera mental (y legal) de qué puede leer la IA, qué no, y hasta dónde es seguro dejarla inspeccionar. En el open-source todo eso desaparece. Copilot puede leer el código completo, sin restricciones. No hay riesgos legales ni zonas grises. Simplemente trabaja.

A esto se suma un punto obvio pero crucial: gran parte del entrenamiento original de estos modelos se hizo precisamente con código open-source. Conocen los patrones, el estilo, las convenciones. Se mueven como pez en el agua.

Además, la mayoría de estos proyectos están diseñados para ser compilables con instrucciones claras: un BUILDING.md, unos pipelines de GitHub Actions, dependencias estándar y entornos reproducibles. Para un agente, esto es oro puro. Puede entender cómo funciona el flujo, instalar lo necesario en segundos y ejecutar builds o tests en su propio entorno Linux sin que tengas que mover un dedo.

La colaboración sin fricción: tú solo das instrucciones

La productividad aquí no viene del “autocomplete”, sino de delegar directamente trabajo real. Solo haces clic en:

1. Open Agents Panel

2. Seleccionas repositorio

3. Seleccionas rama

4. Das la orden

A partir de ahí, el agente lee el código, identifica dónde tocar, genera cambios, añade pruebas, actualiza documentación y abre la pull request. Si algo no te convence, basta comentar en la PR con un @copilot y decirle qué corregir.

Y cuando la PR sale del estado de draft, Copilot hace un code review automático. Si además tienes conectado OpenAI Codex en el repo, también interviene. Dos revisores automáticos trabajando para ti.

Todo esto sin necesidad de clonar el repo. Sin abrir tu IDE. Sin compilar nada localmente. Literalmente puedes contribuir desde el móvil mientras vas en el metro.

Ejemplo real: un aporte a PowerToys Advanced Paste usando solo IA

Un caso concreto: hice una contribución a PowerToys Advanced Paste para mostrar una “mota” de color cuando el texto del portapapeles o historial era un valor hex como #FFFFFF. El pull request está aquí:

https://github.com/crramirez/PowerToys/pull/1 🠊 https://github.com/microsoft/PowerToys/pull/43990

El cambio implicaba tocar UI y algo de lógica. Lo sorprendente es que casi todo lo generó Copilot Agent. Yo solo validé el resultado: abrí el proyecto en mi PC para ver cómo quedaba visualmente. Nada más.

Si el cambio no hubiese sido de UI, ni siquiera habría necesitado descargar el código. La colaboración entera se podría haber hecho desde la web.

El nuevo modelo de contribución

Esto cambia por completo la propuesta de valor del open-source. Ahora:

• Puedes contribuir en minutos a proyectos que antes te intimidaban.

• No necesitas estudiar el código base a fondo.

• Los agentes entienden estilo, arquitectura y patrones del repo.

• Las tareas repetitivas (tests, docs, estructurar commits) desaparecen.

• El coste de entrada se reduce prácticamente a cero.

• Puedes participar desde el navegador o desde el móvil.

La IA no sustituye al colaborador: amplifica su capacidad. Nos permite centrarnos en la intención y delegar la ejecución técnica y el “grunt work”. Y para las comunidades open-source esto es un multiplicador de productividad enorme.

El futuro de la contribución ya no es quién tiene tiempo, sino quién tiene intención. El resto lo hace el agente.

Mejorando el rendimiento de WSL2 con Zswap (actualizado para kernel 6.x)

WSL2 se ha consolidado como el entorno ideal para desarrollar en Linux desde Windows. Pero cuando se ejecutan cargas pesadas —compilaciones grandes, contenedores, bases de datos o herramientas de IA ligera— la memoria puede saturarse y el rendimiento cae por el uso intensivo del swap. Aquí es donde zswap aporta una mejora clara y medible.

Esta guía actualiza el artículo original y lo alinea con el kernel 6.x de WSL2, que cambia el modo en que se empaquetan los módulos y elimina componentes del kernel 5.x. Además, integra el nuevo script que automatiza la compilación del kernel con zswap habilitado.

Qué es zswap y por qué es útil en WSL2

zswap es una capa de compresión en memoria que se activa antes de escribir datos en el swap. En lugar de enviar una página directamente al archivo de intercambio, el kernel la comprime y la almacena en RAM. Solo si es necesario, la página termina escrita en el swap real.

En WSL2 esto marca una diferencia aún mayor porque el swap se almacena en un archivo *.vhdx, no en un disco físico. Escribir y leer ese archivo introduce una penalización extra, por lo que reducir esas operaciones mejora la fluidez del sistema.

Beneficios directos:

• Menos escrituras al archivo de swap → menos latencia.

• Mayor estabilidad cuando la memoria está al límite.

• Mejor rendimiento en compilaciones y entornos con muchos procesos.

• Reducción del desgaste del SSD.

Por qué zram no es la mejor opción en WSL2

zram crea un disco comprimido en RAM. Eso consume memoria de forma permanente y compite con tus aplicaciones. Cuando ya existe una partición de swap, como es el caso en WSL2, puede pasar que las páginas más viejas se queden en ZRAM y las nuevas en SWAP, perdiendo el sentido de la compresión. En cambio, ZSWAP usa la RAM de forma dinámica y trabaja sobre el swap existente, lo que lo hace más adecuado para WSL2. Si se deshabilita el swap, ZRAMsi puede ser una buena opción, pero aún así hay que configurarlo en la distro. ZSWAP trabaja automáticamente.

Cambios clave en kernel 6.x de WSL2

1. Eliminación de CONFIG_FRONTSWAP

El kernel 6.x ya no incluye FRONTSWAP, por lo que ciertas configuraciones usadas en kernel 5.x dejan de ser aplicables.

2. Nuevo modelo de módulos: modules.vhdx

A partir de kernel 6.x, WSL2 separa el kernel de sus módulos. Para usar un kernel personalizado necesitas dos archivos:

• bzImage → kernel compilado

• modules.vhdx → volumen con los módulos

En kernel 5.x esto no era necesario.

3. Script actualizado con detección automática

El repositorio oficial del script:
https://github.com/dhanar10/wsl2-kernel-zswap

El script detecta automáticamente el kernel que estás utilizando y ajusta la compilación:

• Kernel 5.x → añade soporte de FRONTSWAP

• Kernel 6.x → omite FRONTSWAP y genera modules.vhdx

Cómo habilitar zswap en WSL2 (kernel 6.x)

Paso 1. Descargar el script

curl -O https://raw.githubusercontent.com/dhanar10/wsl2-kernel-zswap/main/build.sh
less build.sh

Luego ejecútalo:

bash build.sh

O bien:

curl https://raw.githubusercontent.com/dhanar10/wsl2-kernel-zswap/main/build.sh | bash

Qué genera el script

Tras la compilación tendrás:

arch/x86/boot/bzImage
modules.vhdx

Ambos son obligatorios para kernel 6.x.

Paso 2. Instalar los archivos en Windows

Copia los resultados a una ubicación accesible, por ejemplo:

bzImage       →  C:\bzImage
modules.vhdx  →  C:\modules.vhdx

Paso 3. Configurar .wslconfig

Edita:

%UserProfile%\.wslconfig

Incluye:

[wsl2]
kernel=C:\\bzImage
kernelModules=C:\\modules.vhdx

Reinicia WSL:

wsl --shutdown

Paso 4. Verificar zswap

En WSL:

cat /sys/module/zswap/parameters/enabled

Debe mostrar:

Y

Comprueba también:

cat /sys/module/zswap/parameters/compressor
cat /sys/module/zswap/parameters/zpool

Ajuste recomendado: vm.swappiness = 133

Para mejorar aún más el rendimiento, es beneficioso establecer un valor alto de swappiness. El valor recomendado al usar zswap en WSL2 es 133. Este valor indica al sistema que comprima activamente las páginas de memoria, priorizando la caché del sistema de archivos y optimizando el rendimiento incluso en situaciones de poca memoria.

Para hacerlo permanente:

sudo bash -c 'echo "vm.swappiness=133" >> /etc/sysctl.conf'
sudo sysctl -p

Cómo monitorear el ahorro de RAM

#!/bin/bash
# Función para calcular el ahorro de RAM
calculate_zswap_savings() {
    local stored_pages=$(cat /sys/kernel/debug/zswap/stored_pages)
    local pool_total_size=$(cat /sys/kernel/debug/zswap/pool_total_size)
    local page_size=$(getconf PAGE_SIZE 2>/dev/null || echo 4096)
    local ram_uncompressed=$((stored_pages * page_size))
    local ram_saved=$((ram_uncompressed - pool_total_size))
    echo "Páginas almacenadas: $stored_pages"
    echo "Tamaño total del pool: $(numfmt --to=iec --suffix=B $pool_total_size)"
    echo "RAM sin comprimir: $(numfmt --to=iec --suffix=B $ram_uncompressed)"
    echo "RAM ahorrada: $(numfmt --to=iec --suffix=B $ram_saved)"
}
echo "Estadísticas de Zswap:"
echo "----------------------"
calculate_zswap_savings

Resultados esperados

Con kernel 6.x y zswap activado puedes esperar:

• Menos uso de swap real.

• Reducción de latencia en compilaciones y contenedores.

• Menos tiempo perdido gestionando memoria cuando el sistema está muy cargado.

Conclusión

Habilitar zswap en WSL2 con kernel 6.x ofrece mejoras claras en estabilidad y rendimiento, especialmente bajo cargas exigentes. El nuevo script simplifica la compilación e instalación del kernel y sus módulos, permitiendo activar zswap con un proceso mucho más limpio que en versiones anteriores.