Perché un desktop sopra SSH.

«Tutto questo lo faccio già con ssh e vim»

È vero. Ogni singola cosa di questa pagina si può fare con una sessione SSH, una shell e un editor che già conosci a memoria. Se amministri un solo server, sei a tuo agio con vim e il tuo lavoro sta dentro un terminale, questo non fa per te, e preferiamo che tu resti con quello che hai.

Lo strato grafico non c'è perché il terminale sia insufficiente. C'è perché un terminale è un'interfaccia sequenziale, e certi compiti non lo sono. Sorvegliare un trasferimento mentre leggi un log mentre modifichi un file di configurazione sono tre finestre in qualsiasi desktop, e tre riquadri di tmux più parecchia disciplina in un terminale.

Dove lo strato grafico si guadagna davvero il posto

Quattro situazioni, a partire da quelle che ci raccontano più spesso.

• Spostare file, e vederlo succedere. Copiare una cartella tra due posti con scp ti lascia un cursore che lampeggia e un po' di speranza. L'Esploratore lo fa con una coda di operazioni, una percentuale dal vivo per ogni trasferimento e una rinomina invece di una sovrascrittura silenziosa quando a destinazione c'è già qualcosa con quel nome. Con una cartella da 4 GB su una linea lenta, «sta ancora andando?» è una domanda vera.
• Leggere codice che non hai scritto tu. Modificare un file che conosci è lavoro per vim. Capire una base di codice sconosciuta — saltare tra file, seguire un include, cercare in tutto un albero — è lavoro per un albero dei file e delle schede. È quello che ti dà un editor Monaco sul filesystem remoto, senza scaricare nulla in locale.
• Atterrare su un server che non hai mai visto. È l'argomento più forte. Termal riconosce cosa sta girando sulla macchina — Plesk, cPanel, semplicemente nginx o Apache — elenca i siti che serve con la versione di PHP che ciascuno usa davvero, mostra i servizi e i container in esecuzione e trova i file di log. Arrivare allo stesso quadro a mano significa una dozzina di comandi e sapere dove ogni distribuzione nasconde le cose.
• Provare dalla posizione di rete del server stesso. Un percorso interno che risponde sul server e da nessun'altra parte è scomodo da ispezionare da un terminale. Il client HTTP esegue curlsul server e ti dispone intestazioni e corpo. Il browser va oltre: per impostazione predefinita naviga dal tuo computer, ma puoi spostare la sua uscita di rete sul server; il traffico passa allora per un tunnel SOCKS5 aperto sulla connessione SSH che hai già, e un indicatore nella barra degli strumenti ti dice in quale dei due modi sei. Con gli strumenti per sviluppatori agganciati a ogni scheda, una pagina raggiungibile solo dall'interno diventa qualcosa che guardi invece di qualcosa che deduci.

E tutto questo su una sola connessione

È la parte che conta dal punto di vista dell'architettura, ed è il motivo per cui il desktop non è solo un guscio sopra un mucchio di chiamate SSH.

Termal OS mantiene un pool di connessioni SSH riutilizzabili — una per server, con keepalive, e tutto viaggia lì sopra: le metriche, l'esploratore di file, il terminale, l'editor, i log seguiti dal vivo. Aprire il gestore di file non apre una seconda sessione. Nessuna porta in più, nessun agente, nessuna seconda autenticazione e niente installato sulla macchina. Dal punto di vista del server sei un singolo accesso SSH che fa cose ordinarie.

Questo vincolo è anche ciò che fa funzionare il desktop su hosting dove non hai root e non puoi installare nulla: hosting condiviso, hosting gestito, la macchina di un cliente. Un pannello di amministrazione grafico che avesse bisogno di un demone lì non servirebbe a niente.

Cosa c'è davvero nel desktop

Un gestore di finestre con barra delle applicazioni, menu di avvio e icone sul desktop, e 23 applicazioni. Quelle che fanno il lavoro:

• Esploratore: esploratore SFTP — copiare, spostare, caricare, scaricare una cartella come archivio, permessi, trascinamento, coda di trasferimenti con avanzamento.
• Terminale: una vera shell PTY, non una casella per lanciare comandi.
• Termal Code: Monaco (l'editor di VS Code) con albero dei file e schede, che modifica direttamente sul filesystem remoto.
• Browser: più schede, segnalibri, download, vista del sorgente e strumenti per sviluppatori agganciati a ogni scheda.
• Monitor, Processi, Log: metriche dal vivo, un elenco dei processi da cui puoi terminarli e log seguiti con individuazione automatica dei soliti file di Apache, nginx, PHP, MySQL e syslog.
• Richiesta web, Zip, Git, FTP, Cestino: i piccoli strumenti che altrimenti ti rispediscono alla shell a metà lavoro.
• Copilota: domande in linguaggio normale, risposte con un comando e una spiegazione. Non parte nulla finché non clicchi, e gira sulla tua chiave API.

Ci sono anche un client di posta, le note, una calcolatrice, un convertitore, un selettore di colori e qualche gioco. Tredici delle ventitré sono disattivate per impostazione predefinita — restano fissi solo l'App Store, le impostazioni, l'Esploratore e il Cestino — perché un primo avvio che seppellisce l'esploratore di file sotto un menu di giochi sarebbe già di per sé un argomento contro tutta l'idea. Attiva quello che usi.

La parte che gli sviluppatori dovrebbero guardare

Il desktop è estendibile, e il modello delle estensioni è la cosa più interessante che ci sia nella base di codice.

Un'applicazione di terze parti gira dentro un iframe isolato. Non può toccare direttamente il filesystem, la rete o gli appunti. Ogni chiamata privilegiata passa come messaggio all'host, che la confronta con i permessi dichiarati dall'applicazione nel suo manifesto — e sono solo sei: fs.read, fs.write, net, storage, clipboard, webview. Te li mostriamo al momento dell'installazione. La regola scritta nel commento in testa al runtime stesso è netta: dell'iframe non ci si fida mai, l'host verifica tutto.

Qui pesa più che nella maggior parte dei sistemi di plugin, perché queste applicazioni girano contro server ai quali hai concesso tu l'accesso SSH. Un negozio di applicazioni in cui un plugin potesse leggere in silenzio le tue chiavi sarebbe indifendibile.

E l'SDK non è un'API separata e di seconda scelta aggiunta per chi sta fuori: anche la calcolatrice integrata si registra con Termal.app(), lo stesso punto d'ingresso pubblico che usa un'applicazione di terze parti. Con l'SDK arrivano otto applicazioni d'esempio complete, da un'app per le note a un contenitore webview fino a un widget per il server.

Il riferimento completo — manifesto, runtime, finestre di dialogo, selettori di file, archiviazione, rete, webview, appunti, controllo delle finestre, traduzioni, pacchettizzazione — è sulla pagina di Termal App Studio.

Cosa non è

• Non sostituisce il tuo terminale. Ne contiene uno e lo userai. Se il tuo lavoro sta già dentro una shell, il desktop non aggiunge nulla che ti serva.
• Non è un protocollo di desktop remoto. Niente X11, niente VNC, niente RDP e nessun server grafico dal lato del cavo dove sta il tuo computer. Il gestore di finestre gira in locale, dentro l'applicazione; sulla connessione SSH passano solo il traffico dei file, della shell e delle metriche.
• Non è sempre acceso. La raccolta prosegue con la finestra chiusa, ma l'applicazione deve girare su una macchina sveglia. Chiudi il portatile e si ferma: vedi il confronto con Netdata, dove questo pesa di più.
• Non è per mille server. Da qualcuno a qualche decina. Solo Linux via SSH: niente SNMP, niente Windows, niente scoperta della rete.