Due parole dal nostro ufficio traduzioni: di solito tutti si sforzano di tradurre i materiali e le pubblicazioni più recenti, e noi non facciamo eccezione. Ma i terminali non sono qualcosa che viene aggiornato ogni settimana. Perciò abbiamo tradotto per voi l'articolo di Antoine Bopré, pubblicato nella primavera del 2018: nonostante il suo «età» piuttosto significativa per gli standard attuali, riteniamo che il materiale non abbia perso attualità. Inoltre, l'originale è una serie di due articoli, ma abbiamo deciso di unirli in un unico grande post.
I terminali occupano un posto particolare nella storia dei computer, ma negli ultimi decenni hanno dovuto letteralmente «sopravvivere» insieme alla riga di comando, mentre le interfacce grafiche si diffondevano ovunque. hanno sostituito i loro , che a loro volta erano una modifica dei sistemi a schede perforate e commutatori. Le moderne distribuzioni sono fornite con una varietà di emulatori di terminale di tutti i tipi e colori. E mentre molti si accontentano tranquillamente del terminale standard fornito dal loro ambiente di lavoro, alcuni usano con orgoglio software manifestamente esotico per avviare la loro shell o il loro editor di testo preferito. Ma, come vedremo in questo articolo, non tutti i terminali sono stati creati allo stesso modo: differiscono notevolmente per funzionalità, dimensioni e prestazioni.
Alcuni terminali presentano vulnerabilità di sicurezza sorprendentemente gravi, oltre al fatto che la maggior parte offre insiemi di funzionalità notevolmente diversi, dal supporto per interfacce a schede agli script. Sebbene noi , questo articolo è un aggiornamento del materiale precedente che aiuterà i lettori a determinare quale terminale utilizzare nel 2018. Nella prima metà dell'articolo vengono confrontate le funzionalità, mentre nella seconda viene valutata la prestazione.
Ecco i terminali che ho esaminato:
Potrebbe non trattarsi delle versioni più recenti, poiché mi sono limitato a build stabili al momento della scrittura del materiale, che sono riuscito a installare su Debian 9 o Fedora 27. L'unica eccezione è Alacritty. È un discendente dei terminali con accelerazione GPU e scritto in un linguaggio insolito e nuovo per questo compito: Rust. Ho escluso dalla mia revisione i terminali web (inclusi, e su ), poiché i test preliminari hanno mostrato prestazioni estremamente basse.
Supporto Unicode
Ho iniziato i miei test con il supporto Unicode. Il primo test dei terminali è stato visualizzare la seguente stringa Unicode da : «é, Δ, Й, ק, م, ๗, あ, 叶, 葉 e 말». Questo semplice test mostra se il terminale può funzionare correttamente in tutto il mondo. Il terminale xterm non visualizza il carattere arabo nella configurazione predefinita:
Per impostazione predefinita, xterm utilizza un carattere 'monospaziato' classico che, secondo , ha «una copertura Unicode sostanziale dal 1997». In questo carattere accade qualcosa che fa visualizzare il simbolo come un riquadro vuoto e solo aumentando la dimensione del carattere a 20+ punti il simbolo comincia finalmente a essere visualizzato correttamente. Tuttavia, tale 'correzione' compromette la visualizzazione di altri simboli Unicode:
Questi screenshot sono stati realizzati su Fedora 27, poiché questa aveva fornito risultati migliori rispetto a Debian 9, dove alcune versioni più vecchie dei terminali (in particolare — mlterm) non potevano funzionare correttamente con i caratteri. Per fortuna, questo è stato risolto nelle versioni più recenti.
Ora, presta attenzione alla visualizzazione della stringa in xterm. Risulta che il carattere Mem e quello successivo Semitic appartengono a script di scrittura RTL (), quindi tecnicamente dovrebbero essere visualizzati da destra a sinistra. I browser web, come Firefox 57, elaborano correttamente la stringa sopra riportata. Un'opzione più semplice di testo RTL è la parola «» in ebraico (). afferma quanto segue:
«Molti programmi per computer non possono visualizzare correttamente il testo bidirezionale. Ad esempio, il nome ebraico 'Sara' è composto dai caratteri sin (ש) (che appare a destra), poi resh (ר) e infine he (ה) (che dovrebbe apparire a sinistra)».
Molti terminali non superano questo test: Alacritty, terminali derivati da VTE di Gnome e XFCE, urxvt, st e xterm mostrano "Sara" in ordine inverso, come se scrivessimo questo nome come "Aras".
Un altro problema dei testi bi-direzionali è che devono essere allineati in qualche modo, specialmente quando si tratta di mescolare testi RTL e LTR. Gli script RTL dovrebbero iniziare dal lato destro della finestra del terminale, ma cosa dovrebbe succedere per i terminali che lavorano per default con l'inglese LTR? La maggior parte di essi non dispone di meccanismi speciali e allineano tutto il testo a sinistra (incluso Konsole). Un'eccezione è rappresentata da pterm e mlterm, che seguono gli standard e allineano tali righe a destra.
Protezione da incolla
La seguente caratteristica critica che ho identificato è la protezione da incolla. Anche se è ampiamente noto che comandi del tipo:
$ curl http://example.com/ | shsono comandi push per l'esecuzione di codice, pochi sanno che comandi nascosti possono infiltrarsi nella console tramite copia e incolla da un browser web, anche dopo un'attenta ispezione. dimostra brillantemente come un comando apparentemente innocuo:
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitsi trasformi, se incollato dal sito di Horn nel terminale, in un brutto scherzo:
git clone /dev/null;
clear;
echo -n "Hello ";
whoami|tr -d 'n';
echo -e '!nQuella è stata una brutta idea. Non copiare codice da siti web che non ti fidi!
Ecco la prima riga del tuo /etc/passwd: ';
head -n1 /etc/passwd
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitCome funziona? Il codice dannoso è stato estratto in un blocco , che è stato spostato fuori dalla vista dell'utente tramite CSS.
è esplicitamente progettata per neutralizzare attacchi simili. In questa modalità, i terminali racchiudono il testo incollato in una coppia di sequenze di escape speciali, per informare la shell della provenienza di questo testo. In questo modo, la shell riceve un segnale che può ignorare i caratteri speciali che può contenere il testo incollato. Tutti i terminali, fino all'odierno xterm, supportano questa funzione, ma l'incolla in modalità Bracketed necessita del supporto della shell o dell'applicazione in esecuzione nel terminale. Ad esempio, il software che utilizza (lo stesso Bash), ha bisogno di un file ~ /.inputrc:
set enable-bracketed-paste onPurtroppo, il sito di test di Horna mostra anche come aggirare questa protezione attraverso la formattazione del testo e terminare prematuramente l'applicazione della modalità Bracketed. Questo funziona perché alcuni terminali filtrano in modo errato le sequenze di escape prima di aggiungere le loro. Ad esempio, nei miei non sono riuscito a completare con successo i test di Konsole anche tenendo conto di una configurazione corretta. .inputrc file. Ciò significa che puoi facilmente subire danni alla configurazione del sistema a causa di un'applicazione non supportata o di una shell configurata in modo errato. Questo è particolarmente pericoloso quando si accede a server remoti, dove una cura meticolosa della configurazione è rara, soprattutto se hai molte di queste macchine remote.
Una buona soluzione a questo problema è un plugin di conferma per l'inserimento nel terminale urxvt, che semplicemente richiede il permesso di inserire qualsiasi testo che contiene nuove righe. Non ho trovato un'opzione più sicura per l'attacco testuale descritto da Horna.
Schede e profili
Una funzionalità oggi molto popolare è il supporto per l'interfaccia a schede, che definiremo come una finestra del terminale che contiene altri terminali. Questa funzionalità varia a seconda del terminale e, sebbene i terminali tradizionali come xterm non supportino affatto le schede, incarnazioni più moderne del terminale come Xfce Terminal, GNOME Terminal e Konsole la offrono. Anche Urxvt supporta le schede, ma solo se si utilizza un plugin. Tuttavia, dal punto di vista del supporto delle schede, il leader indiscusso è Terminator: non solo supporta le schede, ma può anche disporre i terminali in modo arbitrario (vedi immagine qui sotto).
Un'altra caratteristica di Terminator è la possibilità di "raggruppare" queste schede insieme e inviare le stesse pression del tasto a più terminali contemporaneamente, fornendo uno strumento rudimentale per eseguire operazioni di massa su più server contemporaneamente. Una funzionalità simile è anche implementata in Konsole. Per utilizzare questa funzione in altri terminali, è necessario utilizzare software di terze parti, come , o .
Le schede funzionano particolarmente bene insieme ai profili: ad esempio, puoi avere una scheda per la tua email, un'altra per la chat e così via. Questo è ben supportato dai terminali Konsole e GNOME Terminal. Entrambi permettono a ogni scheda di avviare automaticamente il proprio profilo. Terminator supporta anche i profili, ma non sono riuscito a trovare un modo per avviare automaticamente programmi specifici all'apertura di una scheda particolare. Altri terminali non hanno affatto il concetto di "profilo".
Ruches
L'ultimo aspetto che esaminerò nella prima parte di questo articolo è l'aspetto dei terminali. Ad esempio, GNOME, Xfce e urxvt supportano la trasparenza, ma recentemente hanno ritirato il supporto per le immagini di sfondo, il che ha costretto alcuni utenti a passare a terminali alternativi. . Personalmente, mi accontento anche di una configurazione semplice. Xresources, che imposta un set di colori di base per lo sfondo di urxvt. Tuttavia, i temi colorati non standard possono causare problemi. Ad esempio, con le applicazioni e , poiché utilizzano già i propri colori.
non supportava i colori, e i nuovi spesso si limitano a una palette di 256 colori. Per gli utenti esperti che stilizzano i loro terminali, le richieste di shell o le barre di stato in modi complessi possono diventare una limitazione sgradevole. tiene traccia dei terminali che supportano il "True Color". I miei test confermano che st, Alacritty e i terminali basati su VTE supportano perfettamente il True Color. Altri terminali si comportano male in questo senso e in pratica non mostrano nemmeno 256 colori. Di seguito puoi vedere la differenza tra il supporto del True Color nei terminali GNOME, st e xterm, che gestiscono bene questa esigenza con la loro palette a 256 colori, e urxvt, che non solo non supera il test, ma mostra persino simboli lampeggianti al suo posto.
Alcuni terminali analizzano anche il testo per modelli di URL per rendere i collegamenti cliccabili. Questo vale per tutti i terminali derivati da VTE, mentre urxvt richiede un modulo di collegamento speciale che trasformi gli indirizzi URL con un clic o tramite una combinazione di tasti. Altri terminali che ho testato visualizzano gli URL in modi diversi.
Finalmente, una nuova tendenza nei terminali è l'opzionalità del buffer di scorrimento. Ad esempio, in st non c'è un buffer di scorrimento; si presume che l'utente utilizzi un multiplexer di terminale, come tmux e .
In Alacritty mancano anche i buffer di scorrimento inverso, ma il suo supporto a causa di «ampi feedback» su questo argomento da parte degli utenti. A parte queste eccezioni, ogni terminale che ho verificato e che sono riuscito a trovare supporta lo scorrimento inverso.
Risultati intermedi
Nella seconda parte del materiale (nel testo originale si trattava di due articoli separati, ndr.) confronteremo le prestazioni, l'uso della memoria e la latenza. Ma vediamo già che alcuni dei terminali esaminati hanno seri difetti. Ad esempio, gli utenti che lavorano regolarmente con script RTL possono prestare attenzione a mlterm e pterm, poiché gestiscono queste attività meglio di altri. Anche Konsole ha dimostrato di essere molto valido. Gli utenti che non lavorano con script RTL possono scegliere qualcos'altro.
Dal punto di vista della protezione contro l'inserimento di codice dannoso, urxvt si distingue grazie alla sua implementazione particolare, che a mio avviso è decisamente utile. Chi cerca qualche funzionalità avanzata dovrebbe dare un'occhiata a Konsole. Infine, vale la pena notare che VTE è una base eccellente per i terminali, che garantisce supporto per i colori, riconoscimento degli URL e così via. A prima vista, il terminale predefinito fornito con il tuo ambiente preferito potrebbe soddisfare tutte le esigenze, ma lasciamo aperta questa questione finché non analizziamo le prestazioni.
Continuiamo la conversazione
In generale, le prestazioni dei terminali possono sembrare un problema esagerato; tuttavia, come si è rivelato, alcuni di essi mostrano una latenza sorprendentemente alta per un software di questo tipo fondamentale. Inoltre, esamineremo ciò che viene tradizionalmente chiamata «velocità» (in realtà, è la velocità di scorrimento) e il consumo di memoria del terminale (considerando che oggi non è così critico come decenni fa).
Ritardo
Dopo un'attenta analisi delle prestazioni dei terminali, sono giunto alla conclusione che il parametro più importante in questo senso è la dimensione della latenza (ping). Nel mio articolo Pavel Fatin ha esaminato il ritardo di vari editor di testo e ha accennato al fatto che i terminali potrebbero funzionare più lentamente rispetto ai più veloci editor di testo. È stata proprio questa osservazione a portarmi, infine, a lanciare i miei test e a scrivere questo articolo.
Ma che cos'è il ritardo e perché è così importante? Nel suo articolo, Fatin lo definisce come «il ritardo tra la pressione di un tasto e l'aggiornamento corrispondente dello schermo» e cita , in cui si afferma: «Il ritardo del feedback visivo sullo schermo del computer ha un'importante influenza sul comportamento del dattilografo e sulla sua soddisfazione».
Fatin spiega che questo ping ha conseguenze più profonde, oltre alla semplice soddisfazione: «la digitazione diventa più lenta, ci sono più errori, e aumenta la tensione degli occhi e dei muscoli». In altre parole, un ritardo maggiore può portare a errori di battitura e a una diminuzione della qualità del codice, poiché comporta un carico cognitivo aggiuntivo per il cervello. Ma ciò che è ancora peggio è che il ping «aumenta la tensione degli occhi e dei muscoli», il che, a quanto pare, implica in futuro (presumibilmente, l'autore si riferisce a problemi agli occhi, alla schiena, alle braccia e, naturalmente, alla vista, — nota del traduttore.) a causa della tensione ripetitiva.
Alcuni di questi effetti sono noti da tempo e i risultati , pubblicati già nel 1976 nella rivista Ergonomics, indicano che un ritardo di 100 millisecondi «diminuisce significativamente la velocità di digitazione». Recentemente, nella guida dell'utente GNOME è stato stabilito di 10 millisecondi, e se si vuole andare oltre, dimostra che l'ideale è 1 millisecondo.
Fatin ha condotto i suoi test sugli editor di testo; ha creato uno strumento portatile chiamato , che ho utilizzato per controllare il ping negli emulatori di terminale. Tieni presente che il test è stato condotto in modalità simulazione: in realtà, dobbiamo considerare anche il ritardo dell'input (tastiera, controller USB e così via) e dell'output (buffer della scheda video, monitor). Secondo Fatin, nelle configurazioni tipiche è di circa 20 ms. Con l'hardware da gaming, è possibile raggiungere un valore di appena 3 millisecondi. Poiché abbiamo già questo hardware veloce, l'applicazione non dovrebbe introdurre ulteriori ritardi. L'obiettivo di Fatin è quello di ridurre il ritardo dell'applicazione a 1 millisecondo, o addirittura raggiungere il set senza , come in .
Ecco i risultati delle mie misurazioni, oltre ad alcuni risultati di Fatin per dimostrare che il mio esperimento è in linea con i suoi test:
La prima cosa che mi ha colpito è stata la migliore reattività dei vecchi programmi, come xterm e mlterm. Con il peggiore ritardo di registrazione (2,4 ms), hanno mostrato risultati migliori rispetto al terminale moderno più veloce (10,6 ms per st). Nessun terminale moderno scende sotto la soglia di 10 millisecondi. In particolare, Alacritty non soddisfa i requisiti per essere 'il terminale più veloce esistente', anche se i suoi risultati sono migliorati da quando è stato testato per la prima volta nel 2017. Infatti, gli autori del progetto e stanno lavorando per migliorare le prestazioni visive. È anche importante notare che Vim, che utilizza GTK3, è significativamente più lento rispetto al suo analogo GTK2. Da ciò si può dedurre che GTK3 crea un ritardo aggiuntivo, e questo si riflette su tutti gli altri terminali che lo utilizzano (Terminator, Xfce4 Terminal e GNOME Terminal).
Tuttavia, per l'occhio, le differenze potrebbero non essere visibili. Come spiega Fatin: 'non è necessario essere consapevoli della presenza del ritardo affinché esso abbia effetto su di te'. Fatin avverte anche riguardo alla deviazione standard: 'qualsiasi variazione nella durata del ritardo (tremolio) crea un carico aggiuntivo a causa della loro imprevedibilità'.
Il grafico sopra è stato ottenuto su Debian 9 (stretch) puro con . Questo ambiente fornisce i migliori risultati nei test di rilevamento della latenza. Si è scoperto che GNOME genera un ping aggiuntivo di 20 ms per tutte le misurazioni. Una possibile spiegazione è la presenza di programmi con elaborazione sincrona degli eventi di input. Fatin porta come esempio questo caso , che introduce latenza elaborando tutti gli eventi di input in modo sincrono. Per impostazione predefinita, GNOME è anche dotato di un gestore delle finestre , che crea un ulteriore livello di buffering, che influisce sul ping e aggiunge almeno 8 millisecondi di latenza.
Velocità di scorrimento
Il test successivo è un controllo tradizionale della "velocità" o della "larghezza di banda", che misura quanto rapidamente il terminale può scorrere una pagina mostrando una grande quantità di testo sullo schermo. La meccanica del test varia; il test originale consisteva nel generare semplicemente la stessa stringa di testo utilizzando il comando seq. Altri test includono la verifica di Thomas E. Dick (in accompagnamento a xterm), nel quale viene ripetutamente . In un'altra revisione delle prestazioni dei terminali utilizza una stringa di byte casuali in codifica base32, che viene emessa nel terminale utilizzando cat. Liu considera questo test "un benchmark così inutile da essere immaginabile" e propone di utilizzare invece il feedback del terminale come principale indicatore. Dick definisce anche il suo test fuorviante. Tuttavia, entrambi gli autori riconoscono che la larghezza di banda della finestra del terminale può essere problematica. Liu ha scoperto che Emacs Eshell si blocca durante la visualizzazione di grandi file, e Dick ha ottimizzato il terminale per eliminare la lentezza visiva di xterm. Pertanto, in questo test c'è ancora una certa logica, ma poiché il processo di rendering varia notevolmente da terminale a terminale, può comunque essere utilizzato come componente di test per verificare altri parametri.
Qui vediamo che rxvt e st emergono rispetto ai concorrenti, seguiti da Alacritty, molto più recente e progettato per le prestazioni. A seguire ci sono Xfce (famiglia VTE) e Konsole, che funzionano quasi due volte più velocemente. Ultimo in classifica è xterm, che è cinque volte più lento di rxvt. Durante il test, xterm mostrava anche un forte sfarfallio, rendendo difficile distinguere il testo, anche se si trattava della stessa riga. Konsole si è rivelato veloce, ma a volte ha mostrato dei
Diki spiega che le differenze nelle prestazioni sono legate al design dei buffer di scorrimento in diversi terminali. In particolare, accusa rxvt e altri terminali di "non seguire le regole generali":
"A differenza di xterm, rxvt non cercava di visualizzare tutti gli aggiornamenti. Se era in ritardo, scartava alcuni aggiornamenti per recuperare il tempo perso. Ciò ha avuto un impatto maggiore sulla velocità apparente dello scorrimento che sull'organizzazione della memoria interna. Un inconveniente era che l'animazione ASCII risultava piuttosto imprecisa."
Per risolvere questa apparente lentezza di xterm, Diki suggerisce di usare la risorsa , che permette a xterm di scartare alcuni aggiornamenti dello schermo per non rimanere indietro. I miei test confermano che fastScroll migliora le prestazioni e porta xterm allo stesso livello di rxvt. Tuttavia, si tratta di una soluzione piuttosto grezza, come spiega lo stesso Diki: "a volte xterm - come anche konsole - sembra fermarsi, poiché aspetta un nuovo set di aggiornamenti dello schermo dopo che alcuni di essi sono stati rimossi." In questo senso, sembra che altri terminali abbiano trovato il miglior compromesso tra velocità e integrità del display.
Consumo di risorse
Indipendentemente dalla validità di considerare la velocità di scorrimento come un indicatore di prestazioni, questo test permette di simulare il carico sui terminali, il che, a sua volta, ci consente di misurare altri parametri, come l'utilizzo della memoria o del disco. Le metriche sono state ottenute eseguendo il test specificato seq sotto il monitoraggio di un processo Python. Raccoglieva i dati dei contatori per ru_maxrss, la somma ru_oublock e ru_inblock e un semplice cronometro di tempo.
In questo test, ST occupa il primo posto con il più basso consumo medio di memoria a 8 MB, il che non sorprende, considerando che l'idea fondamentale del progetto è la semplicità. Consume un po' di più mlterm, xterm e rxvt — circa 12 MB. Un altro risultato notevole è Alacritty, che richiede 30 MB per funzionare. Seguono i terminali della famiglia VTE con valori che variano da 40 a 60 MB, il che è abbastanza. Questo consumo può essere spiegato dal fatto che questi terminali utilizzano librerie di livello superiore, come GTK. Konsole è ultimo con un colossale consumo di 65 MB di memoria durante i test, anche se questo può essere giustificato dal suo ampio set di funzionalità.
Rispetto ai risultati precedenti, ottenuti dieci anni fa, tutti i programmi hanno iniziato a consumare visibilmente più memoria. Prima Xterm richiedeva 4 MB, ora ne richiede 15 solo per avviarsi. Anche rxvt ha visto un aumento simile del consumo, richiedendo ora 16 MB di default. Il terminale Xfce occupa 34 MB, il che è tre volte di più rispetto a prima, mentre GNOME Terminal richiede solo 20 MB. Ovviamente, tutti i test precedenti sono stati effettuati su architettura a 32 bit. A LCA 2012, Rusty Russell , ci sono molte altre ragioni più sottili che possono spiegare l'aumento del consumo di memoria. Con tutto ciò, stiamo vivendo un'epoca in cui abbiamo interi gigabyte di memoria, quindi riusciremo a gestirlo in qualche modo.
Tuttavia, non posso liberarmi dalla sensazione che allocare più memoria per un software così fondamentale come il terminale sia uno spreco di risorse. Questi programmi dovrebbero essere i più leggeri tra i più leggeri, in grado di funzionare su qualsiasi "scatola", anche su un paio di scarpe, se mai arriveremo al punto in cui saranno equipaggiati con sistemi Linux (e sai che sarà così). Ma con questi numeri, l'uso della memoria diventerà in futuro un problema in qualsiasi ambiente all'avvio di più terminali, tranne nel caso di alcuni dei più leggeri e limitati nelle funzionalità. Per compensare ciò, GNOME Terminal, Konsole, urxvt, Terminator e Xfce Terminal hanno una modalità Daemon, che consente di gestire più terminali tramite un unico processo, limitando così il loro consumo di memoria.
Durante i miei test, sono giunto a un altro risultato inaspettato riguardo alla lettura e scrittura su disco: mi aspettavo di non vedere nulla, ma si è scoperto che alcuni terminali registrano i dati più voluminosi su disco. Infatti, la libreria VTE mantiene un buffer di scorrimento su disco (questa caratteristica , e questo accade ancora oggi). Ma a differenza delle vecchie implementazioni, adesso, perlomeno, questi dati sono criptati con AES256 GCM (). Ma sorge una domanda legittima: cosa c'è di così speciale nella libreria VTE che richiede questo approccio non standard all'implementazione…
Conclusione
Nella prima parte dell'articolo abbiamo scoperto che i terminali basati su VTE hanno un buon insieme di funzionalità, ma ora vediamo che ciò comporta alcuni costi per garantire le loro prestazioni. Ora la memoria non è un problema, poiché tutti i terminali VTE possono essere gestiti tramite un processo Daemon che limita il loro appetito. Tuttavia, i vecchi sistemi, con limiti fisici sulla quantità di memoria RAM e sul buffer del kernel, potrebbero avere ancora bisogno di versioni precedenti dei terminali, poiché consumano notevolmente meno risorse. Anche se i terminali VTE si sono comportati bene nei test di banda (scorrimento), il loro ritardo nella visualizzazione dei dati sullo schermo è superiore alla soglia stabilita nel manuale dell'utente GNOME. Probabilmente gli sviluppatori di VTE dovrebbero tenerne conto. Considerato che, anche per gli utenti alle prime armi con Linux, l'incontro con il terminale è inevitabile, potrebbero renderlo più amichevole per l'utente. Per i geek esperti, passare dal terminale predefinito potrebbe anche significare una riduzione della tensione visiva e la possibilità di evitare infortuni professionali e malattie in futuro a causa di sessioni lavorative prolungate. Sfortunatamente, solo i vecchi xterm e mlterm ci portano alla magica soglia di ping di 10 millisecondi, che per molti è inaccettabile.
Le misurazioni di controllo hanno anche mostrato che, a causa dello sviluppo di ambienti grafici Linux, gli sviluppatori hanno dovuto fare alcuni compromessi. Alcuni utenti potrebbero voler considerare i gestori di finestre tradizionali, poiché offrono una significativa riduzione del ping. Purtroppo, non sono riuscito a misurare la latenza su Wayland: il programma Typometer, che ho utilizzato, è stato creato per ciò che Wayland cerca di evitare: la sorveglianza di altre finestre. Spero che il compositing di Wayland sia più performante di X.org e anche che, in futuro, qualcuno trovi un modo per valutare il livello di latenza in questo ambiente.
Fonte: habr.com
