Porquê um ambiente de trabalho sobre SSH.

«Isto tudo já consigo fazer com ssh e vim»

Consegues. Absolutamente tudo o que está nesta página é possível com uma sessão SSH, uma shell e um editor que já sabes de cor. Se administras um só servidor, te desenvolves bem em vim e a tua maneira de trabalhar cabe num terminal, isto não é para ti, e preferimos que fiques com o que já tens.

A camada gráfica não está aqui porque o terminal seja insuficiente. Está aqui porque um terminal é uma interface sequencial, e há tarefas que não o são. Vigiar uma transferência enquanto lês um registo enquanto editas uma configuração são três janelas em qualquer ambiente de trabalho, e três painéis de tmux mais muita disciplina num terminal.

Onde a camada gráfica ganha mesmo o seu lugar

Quatro situações, a começar pelas que mais nos contam.

• Mover ficheiros, e ver isso acontecer. Copiar uma diretoria entre dois sítios com scp dá-te um cursor a piscar e alguma esperança. O Explorador fá-lo com uma fila de tarefas, uma percentagem em direto por transferência, e uma mudança de nome em vez de uma substituição silenciosa quando no destino já existe algo com esse nome. Com uma pasta de 4 GB por uma ligação lenta, «será que ainda está a andar?» é uma pergunta a sério.
• Ler código que não foste tu a escrever. Editar um ficheiro que conheces é trabalho para o vim. Perceber uma base de código desconhecida -saltar entre ficheiros, seguir um include, procurar por toda uma árvore- é trabalho para uma árvore de ficheiros e uns separadores. É isso que te dá um editor Monaco sobre o sistema de ficheiros remoto, sem descarregares nada para local.
• Aterrar num servidor que nunca viste. Este é o caso mais forte. O Termal deteta o que a máquina está a correr -Plesk, cPanel, nginx ou Apache e mais nada-, lista os sites que serve com a versão de PHP que cada um usa realmente, mostra os serviços e contentores em funcionamento, e encontra os ficheiros de registo. Chegar a esse mesmo retrato à mão são uma dúzia de comandos e saber onde é que cada distribuição esconde as coisas.
• Testar a partir da posição de rede do próprio servidor. Uma rota interna que responde no servidor e em mais lado nenhum é incómoda de inspecionar a partir de um terminal. O cliente HTTP executa o curlno servidor e apresenta-te os cabeçalhos e o corpo. O navegador vai mais longe: por omissão navega a partir do teu próprio computador, mas podes mudar a sua saída de rede para o servidor; o tráfego passa então por um túnel SOCKS5 aberto sobre a ligação SSH que já tens, e um distintivo na barra de ferramentas diz-te em qual das duas estás. Com as ferramentas de programação acopladas em cada separador, uma página que só existe portas adentro passa a ser algo que olhas em vez de algo que deduzes.

Tudo isto numa só ligação

Esta é a parte que importa do ponto de vista da arquitetura, e é a razão pela qual o ambiente de trabalho não é uma simples casca sobre um monte de chamadas SSH.

O Termal OS mantém um conjunto de ligações SSH reutilizáveis -uma por servidor-, com keepalive, e tudo viaja por aí: as métricas, o explorador de ficheiros, o terminal, o editor, o acompanhamento de registos. Abrir o gestor de ficheiros não abre uma segunda sessão. Não há nenhuma porta extra, nem agente, nem uma segunda autenticação, nem nada instalado na máquina. Do ponto de vista do servidor, és um único início de sessão SSH a fazer coisas correntes.

Essa restrição é também o que faz o ambiente de trabalho funcionar em alojamentos onde não tens root nem direito a instalar seja o que for: alojamento partilhado, alojamento gerido, a máquina de um cliente. Um painel de administração gráfico que precisasse de um serviço residente não serviria ali de nada.

O que há realmente no ambiente de trabalho

Um gestor de janelas com barra de tarefas, menu iniciar e ícones no ambiente de trabalho, e 23 aplicações. As que fazem o trabalho:

• Explorador: explorador SFTP: copiar, mover, enviar, descarregar uma pasta como ficheiro comprimido, permissões, arrastar e largar, fila de transferências com progresso.
• Terminal: uma shell PTY a sério, não uma caixinha para lançar comandos.
• Termal Code: o Monaco (o editor do VS Code) com árvore de ficheiros e separadores, a editar diretamente sobre o sistema de ficheiros remoto.
• Navegador: vários separadores, marcadores, descarregamentos, ver código-fonte, e ferramentas de programação acopladas em cada separador.
• Monitor, Processos, Registos: métricas em direto, uma lista de processos a partir da qual podes terminá-los, e acompanhamento de registos com deteção automática dos ficheiros habituais do Apache, nginx, PHP, MySQL e syslog.
• Pedido web, Zip, Git, FTP, Reciclagem: as ferramentas pequenas que, de outro modo, te mandam de volta para a shell a meio da tarefa.
• Copiloto: perguntas em linguagem corrente, respondidas com um comando e uma explicação. Nada corre enquanto não clicares, e com a tua própria chave de API.

Há também um cliente de correio, notas, uma calculadora, um conversor, um seletor de cor e alguns jogos. Treze das vinte e três vêm desativadas por omissão -só a Loja de aplicações, as Definições, o Explorador e a Reciclagem são fixos- porque um primeiro arranque que enterrasse o explorador de ficheiros debaixo de um menu de jogos seria, por si só, um argumento contra toda a ideia. Ativa o que usares.

A parte que os programadores deviam ver

O ambiente de trabalho é extensível, e o modelo de extensões é a coisa mais interessante que há na base de código.

Uma aplicação de terceiros corre dentro de um iframe isolado. Não pode tocar diretamente no sistema de ficheiros, na rede nem na área de transferência. Cada chamada privilegiada vai por mensagem ao anfitrião, que a confronta com as permissões que a aplicação declarou no seu manifesto, e só há seis: fs.read, fs.write, net, storage, clipboard, webview. São-te mostradas no momento da instalação. A regra, no próprio comentário de cabeçalho do runtime, não anda com rodeios: do iframe não se fia ninguém, o anfitrião valida tudo.

Aqui isso conta mais do que na maioria dos sistemas de extensões, porque estas aplicações correm contra servidores a que foste tu a dar acesso SSH. Uma loja de aplicações onde uma extensão pudesse ler-te as chaves sem fazer barulho seria indefensável.

E o SDK não é uma API à parte, de segunda, acrescentada para os de fora: a calculadora integrada é registada através de Termal.app(), o mesmo ponto de entrada público que uma aplicação de terceiros usa. Com o SDK vêm oito aplicações de exemplo completas, desde uma de notas até um contentor de webview ou um widget de servidor.

A referência completa -manifesto, runtime, caixas de diálogo, seletores de ficheiros, armazenamento, rede, webview, área de transferência, controlo de janelas, traduções, empacotamento- está na página do Termal App Studio.

O que não é

• Não substitui o teu terminal. Traz um lá dentro, e vais usá-lo. Se o teu trabalho já cabe numa shell, o ambiente de trabalho não te acrescenta nada de que precises.
• Não é um protocolo de ambiente de trabalho remoto. Não há X11, nem VNC, nem RDP, nem servidor gráfico no lado do cabo onde está o teu computador. O gestor de janelas corre em local, dentro da aplicação; pela ligação SSH só passam o tráfego de ficheiros, de shell e de métricas.
• Não funciona sempre. A recolha de dados continua com a janela fechada, mas a aplicação tem de estar a correr numa máquina acordada. Fecha o portátil e ela para: vê a comparação com o Netdata, que é onde isto mais pesa.
• Não é para mil servidores. De uns poucos a umas poucas dezenas. Só Linux por SSH: sem SNMP, sem Windows e sem descoberta de rede.