Por qué un escritorio sobre SSH.

«Todo esto ya puedo hacerlo con ssh y vim»

Puedes. Absolutamente todo lo que hay en esta página es posible con una sesión SSH, un shell y un editor que ya te sabes. Si administras un solo servidor, te manejas con soltura en vim y tu forma de trabajar cabe en un terminal, esto no es para ti, y preferimos que te quedes con tu montaje.

La capa gráfica no está ahí porque el terminal se quede corto. Está ahí porque un terminal es una interfaz secuencial, y hay tareas que no lo son. Vigilar una transferencia mientras lees un registro mientras editas una configuración son tres ventanas en cualquier escritorio, y tres paneles de tmux más mucha disciplina en un terminal.

Dónde se gana de verdad su sitio la capa gráfica

Cuatro situaciones, empezando por las que más nos cuentan.

• Mover archivos, y verlo ocurrir. Copiar un directorio entre dos sitios con scp te deja un cursor parpadeando y algo de esperanza. El Explorador lo hace con una cola de tareas, un porcentaje en vivo por transferencia, y un renombrado en vez de una sobrescritura silenciosa cuando en el destino ya hay algo con ese nombre. Con una carpeta de 4 GB por un enlace lento, «¿seguirá funcionando?» es una pregunta real.
• Leer código que no has escrito tú. Editar un archivo que conoces es trabajo para vim. Entender una base de código desconocida -saltar entre archivos, seguir un include, buscar por todo un árbol- es trabajo para un árbol de archivos y unas pestañas. Eso es lo que te da un editor Monaco sobre el sistema de archivos remoto, sin descargarte nada en local.
• Aterrizar en un servidor que no habías visto nunca. Este es el caso más fuerte. Termal detecta qué está corriendo la máquina -Plesk, cPanel, nginx o Apache a secas-, lista los sitios que sirve con la versión de PHP que usa realmente cada uno, muestra los servicios y contenedores en marcha, y encuentra los archivos de registro. Llegar a esa misma foto a mano son una docena de comandos y saber dónde esconde cada distribución las cosas.
• Probar desde la posición de red del propio servidor. Una ruta interna que responde en el servidor y en ningún otro sitio es incómoda de inspeccionar desde un terminal. El cliente HTTP ejecuta curlen el servidor y te presenta las cabeceras y el cuerpo. El navegador va más lejos: por defecto navega desde tu propia máquina, pero puedes cambiar su salida de red al servidor; el tráfico viaja entonces por un túnel SOCKS5 abierto sobre la conexión SSH que ya tienes, y una etiqueta en la barra de herramientas te dice en cuál de las dos estás. Con las herramientas de desarrollo acopladas en cada pestaña, una página que solo existe puertas adentro pasa a ser algo que miras en vez de algo que deduces.

Todo ello sobre una sola conexión

Esta es la parte que importa desde el punto de vista de la arquitectura, y es la razón por la que el escritorio no es una simple carcasa sobre un montón de llamadas SSH.

Termal OS mantiene un grupo de conexiones SSH reutilizables -una por servidor-, con keepalive, y todo viaja por ahí: las métricas, el explorador de archivos, el terminal, el editor, el seguimiento de registros. Abrir el gestor de archivos no abre una segunda sesión. No hay ningún puerto extra, ni agente, ni una segunda autenticación, ni nada instalado en la máquina. Desde el punto de vista del servidor, eres un único inicio de sesión SSH haciendo cosas corrientes.

Esa restricción es también lo que hace que el escritorio funcione en alojamientos donde no tienes root ni derecho a instalar nada: alojamiento compartido, alojamiento gestionado, la máquina de un cliente. Un panel de administración gráfico que necesitara un demonio ahí no serviría de nada.

Qué hay realmente en el escritorio

Un gestor de ventanas con barra de tareas, menú de inicio e iconos de escritorio, y 23 aplicaciones. Las que hacen el trabajo:

• Explorador: explorador SFTP: copiar, mover, subir, descargar una carpeta como archivo comprimido, permisos, arrastrar y soltar, cola de transferencias con progreso.
• Terminal: un shell PTY de verdad, no una cajita para lanzar comandos.
• Termal Code: Monaco (el editor de VS Code) con árbol de archivos y pestañas, editando directamente sobre el sistema de archivos remoto.
• Navegador: varias pestañas, marcadores, descargas, ver código fuente, y herramientas de desarrollo acopladas en cada pestaña.
• Monitor, Procesos, Registros: métricas en vivo, una lista de procesos desde la que puedes matarlos, y seguimiento de registros con detección automática de los archivos habituales de Apache, nginx, PHP, MySQL y syslog.
• Petición web, Zip, Git, FTP, Papelera: las herramientas pequeñas que, si no, te devuelven al shell a mitad de tarea.
• Copiloto: preguntas en lenguaje llano, respondidas con un comando y una explicación. No se ejecuta nada hasta que haces clic, y con tu propia clave de API.

También hay un cliente de correo, notas, una calculadora, un conversor, un selector de color y unos cuantos juegos. Trece de las veintitrés vienen desactivadas por defecto -solo la Tienda de aplicaciones, los Ajustes, el Explorador y la Papelera son fijos- porque un primer arranque que enterrara el explorador de archivos bajo un menú de juegos sería, él solo, un argumento en contra de toda la idea. Activa lo que uses.

La parte que deberían mirar los desarrolladores

El escritorio es extensible, y el modelo de extensiones es lo más interesante que hay en la base de código.

Una aplicación de terceros se ejecuta dentro de un iframe aislado. No puede tocar directamente el sistema de archivos, la red ni el portapapeles. Cada llamada privilegiada va por mensaje al anfitrión, que la contrasta con los permisos que la aplicación declaró en su manifiesto, y solo hay seis: fs.read, fs.write, net, storage, clipboard, webview. Se te muestran al instalarla. La regla, en el propio comentario de cabecera del runtime, no se anda con rodeos: del iframe no se fía nadie, el anfitrión lo valida todo.

Aquí eso importa más que en la mayoría de sistemas de complementos, porque estas aplicaciones se ejecutan contra servidores a los que tú has dado acceso SSH. Una tienda de aplicaciones donde un complemento pudiera leerte las claves sin hacer ruido sería indefendible.

Y el SDK no es una API aparte, de segunda, añadida para los de fuera: la calculadora integrada se registra mediante Termal.app(), el mismo punto de entrada público que usa una aplicación de terceros. Con el SDK vienen ocho aplicaciones de ejemplo completas, desde una de notas hasta un contenedor de webview o un widget de servidor.

La referencia completa -manifiesto, runtime, diálogos, selectores de archivos, almacenamiento, red, webview, portapapeles, control de ventanas, traducciones, empaquetado- está en la página de Termal App Studio.

Lo que no es

• No sustituye a tu terminal. Lleva uno dentro, y lo vas a usar. Si tu trabajo ya cabe en un shell, el escritorio no te añade nada que necesites.
• No es un protocolo de escritorio remoto. No hay X11, ni VNC, ni RDP, ni servidor gráfico en el lado del cable donde está tu máquina. El gestor de ventanas se ejecuta en local, dentro de la aplicación; por la conexión SSH solo cruzan el tráfico de archivos, de shell y de métricas.
• No funciona siempre. La recogida de datos sigue con la ventana cerrada, pero la aplicación tiene que estar en marcha en una máquina despierta. Cierra el portátil y se para: mira la comparativa con Netdata, que es donde más pesa esto.
• No es para mil servidores. De unos pocos a unas pocas decenas. Solo Linux por SSH: sin SNMP, sin Windows y sin descubrimiento de red.