Una parola dal nostro ufficio di traduzione: di solito tutti cercano di tradurre i materiali e le pubblicazioni più recenti, e noi non facciamo eccezione. Ma i terminali non sono qualcosa che si aggiorna ogni settimana. Pertanto, abbiamo tradotto per voi l'articolo di Antoine Bopre, pubblicato nella primavera del 2018: nonostante l'età piuttosto "avanzata" per i nostri standard moderni, secondo noi, il materiale non ha perso affatto la sua rilevanza. Inoltre, nell'originale si tratta di una serie di due articoli, ma abbiamo deciso di unirli in un unico grande post.
I terminali occupano un posto speciale nella storia del computer, ma negli ultimi decenni sono stati "costretti" a sopravvivere insieme alla linea di comando di fronte alla diffusione dei più comuni interfacce grafiche. hanno sostituito i loro , che, a loro volta, erano una modifica dei sistemi a schede perforate e relè. Le moderne distribuzioni vengono fornite con una vasta gamma di emulatori di terminale di tutte le forme e colori. E mentre molti si accontentano del terminale standard fornito dal loro ambiente di lavoro, alcuni sono orgogliosi di utilizzare software apertamente esotico per eseguire la propria shell o editor di testo preferiti. Ma, come vedremo in questo articolo, non tutti i terminali sono stati creati allo stesso modo: variano notevolmente in funzionalità, dimensioni e prestazioni.
Alcuni terminali presentano falle di sicurezza davvero sorprendenti e, inoltre, la maggior parte ha un insieme di funzionalità completamente diverse, dal supporto per l'interfaccia con schede agli script. Anche se 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 performance.
Ecco i terminali che ho esaminato:
Potrebbe non trattarsi delle versioni più recenti, poiché mi sono limitato a build stabili al momento della scrittura, che ho potuto installare su Debian 9 o Fedora 27. L'unica eccezione è Alacritty. Questo terminale discende da quelli con accelerazione GPU ed è scritto in un linguaggio insolito e nuovo per questo compito: Rust. Ho escluso dalla mia recensione i terminali web (inclusi quelli su ), poiché i test preliminari hanno mostrato le loro prestazioni estremamente basse.
Supporto Unicode
Ho iniziato i miei test con il supporto Unicode. Il primo test dei terminali è stato visualizzare una stringa di Unicode da : «é, Δ, Й, ק, م, ๗, あ, 叶, 葉 e 말». Questo semplice test verifica se il terminale può funzionare correttamente in tutto il mondo. Il terminale xterm non visualizza il carattere arabo nella configurazione predefinita:
Di default, xterm utilizza un classico font «fisso», che, secondo , ha un «ampio supporto Unicode dal 1997». In questo font, succede qualcosa che fa sì che il simbolo venga visualizzato come un riquadro vuoto e solo ingrandendo il testo a 20+ punti il simbolo inizia finalmente a essere visualizzato correttamente. Tuttavia, tale «correzione» compromette la visualizzazione di altri simboli Unicode:
Queste schermate sono state catturate su Fedora 27, poiché quest'ultima ha fornito i migliori risultati rispetto a Debian 9, dove alcune versioni più vecchie dei terminali (e in particolare mlterm) non riuscivano a gestire i font in modo adeguato. Per fortuna, questo è stato risolto in versioni successive.
Ora notate la visualizzazione della linea in xterm. Si scopre che il simbolo Mem e quello successivo Semitic appartengono agli scritture di orientamento RTL (), quindi tecnicamente dovrebbero essere visualizzati da destra a sinistra. I browser web, come Firefox 57, gestiscono correttamente la riga sopra riportata. Un esempio più semplice di testo RTL è la parola «» in ebraico (). afferma quanto segue:
«Molti programmi informatici non riescono a visualizzare correttamente il testo bidirezionale. Ad esempio, il nome ebraico «Sara» è composto dai caratteri sin (ש) (che appare a destra), poi res (ר) e infine he (ה) (che deve apparire a sinistra)».
Molti terminali non superano questo test: terminali derivati da Alacritty, VTE di Gnome e XFCE, urxvt, st e xterm visualizzano «Sara» al contrario, come se scrivessimo questo nome come «Aras».
Un'altra problematica dei testi bidirezionali è che devono essere allineati in qualche modo, specialmente quando ci sono misture di testi RTL e LTR. Gli script RTL devono partire dal lato destro della finestra del terminale, ma cosa dovrebbe accadere per i terminali che lavorano di default con l'inglese LTR? La maggior parte di essi non dispone di meccanismi speciali e allinea tutto il testo a sinistra (incluso Konsole). Le eccezioni sono pterm e mlterm, che rispettano gli standard e allineano tali righe a destra.
Protezione da inserimento
La prossima caratteristica critica che ho identificato per me stesso è la protezione da inserimento. Anche se è ampiamente noto che incantesimi di tipo:
$ curl http://example.com/ | shsono comandi di esecuzione codice push, pochi sanno che comandi nascosti possono infiltrarsi nella console quando si copia e incolla dal browser, anche dopo un attento esame. dimostra chiaramente come un comando apparentemente innocuo:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitsi trasforma, incollando dal sito di Horn nel terminale, in questo sgradevole risultato:
git clone /dev/null;
clear;
echo -n "Ciao ";
whoami|tr -d 'n';
echo -e '!nQuella è stata una cattiva idea. Non copiare codice da siti web di cui 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 spostato in un blocco , che è stato spostato fuori dalla vista dell'utente tramite CSS.
è chiaramente progettato per neutralizzare tale attacco. In questa modalità, i terminali racchiudono il testo incollato in un paio di sequenze speciali di escape per informare la shell sull'origine di quel testo. In questo modo, la shell riceve un segnale per ignorare i caratteri speciali che il testo incollato potrebbe contenere. Tutti i terminali, fino al venerabile xterm, supportano questa funzione, ma l'incollaggio in modalità Bracketed richiede il supporto della shell o dell'applicazione in esecuzione sul terminale. Ad esempio, i software che utilizzano (lo stesso Bash) richiedono un file ~ / .inputrc:
set enable-bracketed-paste onSfortunatamente, il sito di test di Horn mostra anche come eludere 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 proprie. Ad esempio, nei miei tentativi non sono riuscito a completare con successo i test di Konsole anche con una corretta configurazione .inputrc file. Questo significa che puoi facilmente causare 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 configurazione accurata è meno comune, specialmente se hai molte di queste macchine remote.
Una buona soluzione a questo problema è il plugin di conferma dell'inserimento per il terminale urxvt, che semplicemente chiede il permesso per inserire qualsiasi testo che contenga nuove righe. Non ho trovato una soluzione più sicura per l'attacco testuale descritto da Horn.
Schede e profili
Una funzionalità popolare al momento è il supporto dell'interfaccia a schede, che definiremo come una finestra del terminale contenente al suo interno diversi terminali. Questa funzione varia a seconda dei diversi terminali; mentre i terminali tradizionali come xterm non supportano affatto le schede, incarnazioni più moderne del terminale come Xfce Terminal, GNOME Terminal e Konsole offrono questa funzionalità. Anche Urxvt supporta le schede, ma solo se si utilizza un plugin. Tuttavia, in termini di supporto per le schede, il leader indiscusso è Terminator: non solo supporta le schede, ma può anche disporre i terminali in ordine arbitrario (vedi immagine sotto).
Un'altra caratteristica di Terminator è la possibilità di "raggruppare" queste schede insieme e inviare gli stessi comandi da tastiera a più terminali contemporaneamente, fornendo uno strumento rudimentale per eseguire operazioni di massa su più server. Una funzione 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 in combinazione con i profili: ad esempio, potresti avere una scheda per la posta elettronica, un'altra per la chat e così via. Questo è ben supportato dal terminale Konsole e GNOME Terminal. Entrambi consentono a ciascuna scheda di avviare automaticamente il proprio profilo. Terminator supporta anch'esso i profili, ma non sono riuscito a trovare un modo per avviare automaticamente programmi specifici all'apertura di una certa scheda. Altri terminali non hanno affatto il concetto di "profilo".
Ruches
L'ultimo argomento che tratterò nella prima parte di questo articolo è l'aspetto dei terminali. Ad esempio, GNOME, Xfce e urxvt supportano la trasparenza, ma recentemente hanno disattivato il supporto per le immagini di sfondo, costringendo alcuni utenti a passare a terminali alternativi. . Personalmente, mi va bene anche utilizzare semplicemente Xresources, che imposta un insieme di colori di sfondo base per urxvt. Tuttavia, i temi di colore non standard possono causare problemi. Ad esempio, con le applicazioni e , poiché già utilizzano i propri colori.
non supportava i colori, e i nuovi spesso erano limitati a una tavolozza di 256 colori. Per gli utenti esperti che stilizzano i propri terminali, le richieste della shell o della barra di stato in modi complessi possono diventare una fastidiosa limitazione. traccia quali terminali supportano il "True Color". I miei test confermano che st, Alacritty e i terminali basati su VTE supportano perfettamente il True Color. Altri terminali, invece, non si comportano altrettanto bene e non riescono nemmeno a mostrare 256 colori. Qui sotto puoi vedere la differenza nel supporto del True Color nei terminali GNOME, st e xterm, che gestiscono bene questa funzione con la loro paletta a 256 colori, e urxvt, che non solo fallisce il test, ma mostra anche simboli sfarfallanti al posto di essi.
Alcuni terminali analizzano anche il testo alla ricerca di modelli URL per rendere i link cliccabili. Questo si applica a tutti i terminali derivati da VTE, mentre urxvt richiede un modulo plug-in speciale che trasforma gli URL in clickabili sia con un clic che tramite una combinazione di tasti. Altri terminali che ho testato mostrano gli URL in modi diversi.
Infine, una nuova tendenza nei terminali è l'opzionalità del buffer di scorrimento. Ad esempio, in st non c'è un buffer di scorrimento; si presuppone che l'utente utilizzi un multiplexer di terminale, come tmux e .
In Alacritty mancano anche i buffer di scorrimento inverso, ma la sua supporto a causa di «un ampio feedback» degli utenti su questo tema. A parte queste eccezioni, ogni terminale che ho potuto trovare e che ho testato supporta lo scorrimento inverso.
Risultati intermedi
Nella seconda parte del materiale (nel originale erano due articoli distinti, — nota dell'autore.) confronteremo le prestazioni, l'uso della memoria e la latenza. Ma possiamo già vedere che alcuni dei terminali esaminati presentano seri difetti. Ad esempio, gli utenti che lavorano regolarmente con script RTL possono notare mlterm e pterm, in quanto gestiscono meglio compiti simili. Anche Konsole ha dimostrato di avere buone performance. 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 per la sua particolare implementazione della sicurezza contro questo tipo di attacchi, che trovo decisamente utile. Chi cerca funzionalità avanzate dovrebbe dare un'occhiata a Konsole. Infine, è importante notare che VTE è una base eccellente per i terminali, garantendo supporto per i colori, riconoscimento degli URL e così via. A prima vista, il terminale predefinito fornito con il proprio ambiente preferito potrebbe soddisfare tutte le esigenze, ma lasciamo questa questione aperta finché non approfondiamo le prestazioni.
Continuiamo la conversazione
In realtà, le prestazioni dei terminali possono sembrare un problema fittizio, tuttavia, come si è rivelato, alcuni di essi mostrano una sorprendente latenza per un software di così fondamentale importanza. Inoltre, esamineremo ciò che tradizionalmente viene chiamato "velocità" (in realtà, si tratta della velocità di scorrimento) e il consumo di memoria del terminale (tenendo presente che oggi non è così critico come decenni fa).
Latenza
Dopo un'attenta analisi delle prestazioni dei terminali, sono giunto alla conclusione che il parametro più importante in questo contesto è la dimensione del ritardo (ping). Nel mio articolo Pavel Fatin ha esaminato il ritardo di vari editor di testo e ha accennato al fatto che i terminali in questo senso possono funzionare più lentamente degli editor di testo più veloci. È stata proprio questa allusione a portarmi, infine, a condurre i miei test e scrivere questo articolo.
Ma che cos'è il ritardo e perché è così importante? Nel suo articolo, Fatin lo ha definito come «il ritardo tra la pressione del tasto e il corrispondente aggiornamento dello schermo» e ha citato , in cui si afferma: «Il ritardo nel feedback visivo sullo schermo del computer ha un importante impatto sul comportamento della dattilografa e sulla sua soddisfazione».
Fatin spiega che un tale ping ha conseguenze più profonde che semplicemente soddisfacenti: «la digitazione diventa più lenta, si verificano più errori, aumenta la tensione degli occhi e dei muscoli». In altre parole, una maggiore latenza può portare a errori di battitura, oltre a una diminuzione della qualità del codice, poiché comporta un'ulteriore carico cognitivo per il cervello. Ma ciò che è ancora peggio, il ping «aumenta la tensione degli occhi e dei muscoli», il che, a quanto pare, implica in futuro (a quanto pare, l'autore si riferisce a problemi con i muscoli oculari, la schiena, le mani e, naturalmente, la vista, — nota dell'autore.) a causa di uno stress ripetitivo.
Alcuni di questi effetti sono noti da tempo, e i risultati , pubblicati già nel 1976 nella rivista Ergonomics, indicano che una latenza di 100 millisecondi «diminuisce significativamente la velocità di digitazione». Recentemente, nel manuale dell'utente di GNOME, è stata introdotta di 10 millisecondi, e se si va oltre, dimostra che l'ideale è 1 millisecondo.
Fatin ha effettuato i suoi test sui programmi di editing del 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 la latenza di input (tastiera, controller USB e così via) e di output (buffer della scheda video, monitor). Secondo Fatin, nelle configurazioni tipiche essa è di circa 20 ms. Con attrezzature da gaming, è possibile raggiungere un valore di soli 3 millisecondi. Dato che abbiamo già un hardware così veloce, l'applicazione non dovrebbe aggiungere ulteriore latenza. L'obiettivo di Fatin è portare la latenza dell'applicazione a 1 millisecondo, o addirittura raggiungere un insieme senza , come in .
Ecco i risultati delle mie misurazioni, insieme ad alcuni risultati di Fatin, per dimostrare che il mio esperimento è in linea con i suoi test:
La prima cosa che mi ha colpito è stato il miglior tempo di risposta dei vecchi programmi, come xterm e mlterm. Con la peggiore latenza di registrazione (2,4 ms), hanno ottenuto risultati migliori del terminale moderno più veloce (10,6 ms per st). Nessun terminale moderno scende al di sotto della soglia di 10 millisecondi. In particolare, Alacritty non soddisfa i requisiti per il "più veloce fra gli emulatori di terminale esistenti", anche se i suoi risultati sono migliorati rispetto al primo controllo del 2017. In effetti, gli autori del progetto e stanno lavorando per migliorare le prestazioni. È anche importante notare che Vim, utilizzando GTK3, è notevolmente più lento rispetto alla sua controparte GTK2. Da questo si può dedurre che GTK3 crea una latenza aggiuntiva, e ciò si riflette su tutti gli altri terminali che lo utilizzano (Terminator, Xfce4 Terminal e GNOME Terminal).
Tuttavia, le differenze potrebbero non essere visibili all'occhio. Come spiega Fatin: «non è necessario essere consapevoli della presenza di ritardi affinché questi abbiano un effetto su di voi». Fatin avverte anche dello scarto standard: «qualsiasi variazione nella durata del ritardo (tremolio) crea un'ulteriore pressione a causa della loro imprevedibilità».
Il grafico sopra è stato ottenuto su una versione pulita di Debian 9 (stretch) con . Questo ambiente produce i migliori risultati nei test di misurazione dei ritardi. Si è scoperto che GNOME introduce 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 cita come esempio , che introduce un ritardo elaborando tutti gli eventi di input in modo sincrono. Per impostazione predefinita, GNOME è dotato anche di un manager di finestre , che crea un ulteriore livello di buffer, influenzando il ping e aggiungendo almeno 8 millisecondi di ritardo.
Velocità di scorrimento
Il test seguente è una verifica 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 semplicemente nel generare la stessa stringa di testo utilizzando il comando seq. Altri test includono la verifica di Thomas E. Dick (incluso nel xterm), nel quale viene ripetutamente . In un'altra revisione delle prestazioni dei terminali usa una stringa di byte casuali in codifica base32, che viene visualizzata nel terminale con il comando cat. Lu considera questo test «un riferimento così inutile come è possibile immaginare» e propone di usare invece l'output del terminale come principale indicatore. Diki descrive anche il suo test come fuorviante. Tuttavia, entrambi gli autori riconoscono che la larghezza di banda della finestra del terminale può essere problematica. Lu ha riscontrato il blocco di Emacs Eshell durante la visualizzazione di file di grandi dimensioni, mentre Diki ha ottimizzato il terminale per eliminare la lentezza visiva di xterm. Pertanto, in questo test c'è ancora un certo senso, ma poiché il processo di rendering varia notevolmente da terminale a terminale, può essere utilizzato anche come componente di test per verificare altri parametri.
Qui possiamo vedere che rxvt e st si distaccano rispetto ai concorrenti, seguito da Alacritty, molto più recente e sviluppato con un focus sulle prestazioni. A seguire ci sono Xfce (famiglia VTE) e Konsole, che funzionano quasi il doppio più velocemente. Ultimo è xterm, che risulta cinque volte più lento di rxvt. Durante il test, xterm mostrava anche forti disturbi, rendendo difficile leggere il testo, anche se si trattava della stessa riga. Konsole è risultato veloce, ma a volte 'imbrogliava': il display si bloccava di tanto in tanto, mostrando il testo in parte o non mostrandolo affatto. Altri terminali mostravano le righe con chiarezza, inclusi st, Alacritty e rxvt.
Diki spiega che le differenze nelle prestazioni sono legate al design dei buffer di scorrimento nei diversi terminali. In particolare, accusa rxvt e altri terminali di 'non seguire le regole generali':
A differenza di xterm, rxvt non ha cercato di visualizzare tutti gli aggiornamenti. Se è in ritardo, rinuncerà ad alcuni aggiornamenti per recuperare il tempo perso. Questo ha avuto un impatto maggiore sulla velocità apparente di scorrimento rispetto all'organizzazione della memoria interna. Un difetto consisteva nel fatto che l'animazione ASCII era piuttosto imprecisa.
Per correggere questa apparente lentezza di xterm, Dick suggerisce di utilizzare la risorsa , che permette a xterm di scartare alcuni aggiornamenti dello schermo per non rimanere indietro rispetto al flusso. I miei test confermano che fastScroll migliora le prestazioni e porta xterm al livello di rxvt. Tuttavia, è un rimedio piuttosto grossolano, come spiega lo stesso Dick: "a volte xterm — come konsole — sembra fermarsi, mentre aspetta un nuovo set di aggiornamenti dello schermo dopo che alcuni 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 pertinenza di considerare la velocità di scorrimento come parametro di prestazione, questo test consente di simulare il carico sui terminali, il che, a sua volta, ci permette di misurare altri parametri, come l'uso della memoria o del disco. Le metriche sono state ottenute eseguendo il test indicato. seq sotto il monitoraggio del processo Python. Raccoglieva dati dai contatori. per ru_maxrss, la somma ru_oublock e ru_inblock e un semplice timer per il tempo.
In questo test, ST si posiziona al primo posto con un consumo medio di memoria di 8 MB, il che non sorprende, considerato che l'idea principale del progetto è la semplicità. Consuma leggermente 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 vanno da 40 a 60 MB, il che è piuttosto elevato. Questo consumo può essere spiegato dal fatto che questi terminali utilizzano librerie di livello superiore, come GTK. Konsole si posiziona ultimo con un enorme consumo di 65 MB di memoria durante i test, anche se ciò può essere giustificato dal suo ampio set di funzionalità.
Rispetto ai risultati precedenti ottenuti dieci anni fa, tutti i programmi richiedono notevolmente più memoria. Prima Xterm necessitava di 4 MB, ora ne richiede 15 MB solo per avviarsi. Un aumento simile è presente anche in rxvt, che ora richiede di base 16 MB. Il terminale Xfce occupa 34 MB, tre volte di più rispetto a prima, mentre GNOME Terminal richiede solo 20 MB. Certo, tutti i test precedenti sono stati eseguiti su architettura a 32 bit. Al LCA 2012, Rusty Russell , ha osservato che ci sono molte altre ragioni più sottili che possono spiegare l'aumento del consumo di memoria. Detto ciò, viviamo in un'epoca in cui abbiamo interi gigabyte di memoria, quindi ci organizzeremo in qualche modo.
Tuttavia, non riesco a scrollare via la sensazione che allocare più memoria a un software fondamentale come un terminale sia uno spreco di risorse. Questi programmi dovrebbero essere tra i più leggeri, in grado di funzionare su qualsiasi "scatola", anche su una scarpa, se mai arriveremo al punto in cui dovranno essere dotati di sistemi Linux (e sapete che succederà). Ma con queste cifre, l'uso della memoria diventerà un problema in futuro in qualsiasi ambiente quando si avvieranno più terminali, a parte i casi con i più leggeri e limitati nelle funzionalità. Per compensare questo, GNOME Terminal, Konsole, urxvt, Terminator e Xfce Terminal hanno una modalità Daemon che consente di gestire più terminali attraverso un singolo 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: non mi aspettavo di vedere nulla qui, ma si è scoperto che alcuni terminali scrivono i dati più voluminosi su disco. In effetti, la libreria VTE tiene effettivamente su disco un buffer di scorrimento (questa caratteristica , e questo continua ancora oggi). Ma a differenza delle vecchie implementazioni, ora, perlomeno, questi dati sono criptati con AES256 GCM (). Ma sorge una domanda legittima, cosa c'è di così speciale nella libreria VTE che richiede un approccio così non convenzionale all'implementazione…
Conclusione
Nella prima parte dell'articolo abbiamo scoperto che i terminali basati su VTE dispongono di un buon insieme di funzionalità, ma ora vediamo che ciò comporta alcuni costi per garantire le loro prestazioni. Al momento, la memoria non è un problema, poiché tutti i terminali VTE possono essere gestiti tramite un processo Daemon che ne controlla il consumo. Tuttavia, i vecchi sistemi, che hanno limitazioni fisiche sulla quantità di RAM e di buffer del kernel, potrebbero ancora avere bisogno di versioni più precedenti dei terminali, poiché consumano risorse significativamente inferiori. Sebbene i terminali VTE si siano comportati bene nei test di larghezza di banda (scrolling), la loro latenza di visualizzazione dei dati sullo schermo supera la soglia stabilita nel manuale utente di GNOME. È probabile che gli sviluppatori di VTE debbano tenere conto di questo. Considerando che anche per i nuovi utenti Linux l'incontro con il terminale è inevitabile, potrebbero renderlo più user-friendly. Per i geek esperti, passare dal terminale predefinito potrebbe significare anche una minore affaticamento visivo e la possibilità di evitare infortuni e malattie professionali in futuro a causa di sessioni lavorative prolungate. Sfortunatamente, solo i vecchi xterm e mlterm ci portano al magico limite di latenza di 10 millisecondi, che per molti è inaccettabile.
Le misurazioni di controllo hanno anche mostrato che, a causa dello sviluppo degli ambienti grafici Linux, gli sviluppatori hanno dovuto fare alcuni compromessi. Alcuni utenti potrebbero considerare i normali gestori di finestre, poiché offrono una notevole diminuzione del ping. Sfortunatamente, non sono riuscito a misurare la latenza di Wayland: il programma Typometer, che ho utilizzato, è stato creato per prevenire ciò che Wayland è progettato a proteggere: la sorveglianza su altre finestre. Spero che il compositing di Wayland sia più performante di X.org e mi auguro che in futuro qualcuno troverà un modo per valutare il livello di latenza in questo ambiente.
Fonte: habr.com
