Qualche parola dal nostro ufficio di traduzione: di solito tutti si impegnano a tradurre i materiali e le pubblicazioni più recenti e noi non facciamo eccezione. Ma i terminali non sono qualcosa che viene aggiornato una volta alla settimana. Pertanto, abbiamo tradotto per voi un articolo di Antoine Beaupré, pubblicato nella primavera del 2018: nonostante la sua notevole “età” per gli standard moderni, a nostro avviso, il materiale non ha perso affatto la sua attualità. Inoltre, originariamente questa era una serie di due articoli, ma abbiamo deciso di combinarli 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 riga di comando poiché le interfacce grafiche sono diventate onnipresenti. sostituito il proprio , che, a loro volta, erano una modifica dei sistemi basati su schede perforate e interruttori a levetta. Le distribuzioni moderne sono dotate di una varietà di emulatori di terminali di tutte le forme e colori. E mentre molti si accontentano del terminale standard fornito dal loro ambiente di lavoro, alcuni utilizzano con orgoglio software addirittura esotici per eseguire la loro shell o editor di testo preferito. Ma, come vedremo da questo articolo, non tutti i terminali sono stati creati con la stessa immagine: differiscono molto per funzionalità, dimensioni e prestazioni.
Alcuni terminali presentano buchi di sicurezza decisamente sorprendenti, inoltre la maggior parte ha un insieme di funzioni completamente diverse, dal supporto per un'interfaccia a schede allo scripting. Sebbene noi , questo articolo è un aggiornamento del materiale precedente che aiuterà i lettori a determinare quale terminale utilizzare nel 2018. La prima metà dell'articolo confronta le funzionalità e la seconda metà valuta le prestazioni.
Ecco i terminali che ho recensito:
Queste potrebbero non essere le versioni più recenti, dal momento che al momento in cui scrivo ero limitato alle build stabili, che ho potuto implementare su Debian 9 o Fedora 27. L'unica eccezione è Alacritty. È un discendente dei terminali accelerati dalla GPU ed è scritto in un linguaggio insolito e nuovo per questo compito: Rust. Ho escluso i terminali web dalla mia recensione (compresi quelli su ), perché i test preliminari hanno mostrato le loro prestazioni estremamente scarse.
Supporto Unicode
Ho iniziato i miei test con il supporto Unicode. Il primo test dei terminali è stato quello di visualizzare la stringa Unicode da : “é, Δ, И, ק, م, ๗, あ, 叶, 葉 e 말.” Questo semplice test mostra se il terminale può funzionare correttamente in tutto il mondo. Il terminale xterm non visualizza i caratteri arabi nella configurazione predefinita:
Per impostazione predefinita, xterm utilizza il classico carattere "fisso", che, secondo , ha "una copertura Unicode sostanziale dal 1997". C'è qualcosa in questo carattere che fa sì che il carattere appaia come una cornice vuota ed è solo quando il carattere del testo viene aumentato a più di 20 punti che il carattere finalmente inizia a essere visualizzato correttamente. Tuttavia, questa "correzione" interrompe la visualizzazione di altri caratteri Unicode:
Questi screenshot sono stati acquisiti in Fedora 27, poiché forniva risultati migliori rispetto a Debian 9, dove alcune versioni precedenti di terminali (in particolare mlterm) non erano in grado di gestire correttamente i caratteri. Fortunatamente questo è stato risolto nelle versioni successive.
Ora notiamo come viene visualizzata la riga in xterm. Si scopre che il simbolo Mem e il successivo semitico fare riferimento agli script in stile RTL (), quindi tecnicamente dovrebbero essere visualizzati da destra a sinistra. I browser Web come Firefox 57 gestiscono correttamente la riga precedente. Una versione più semplice del testo RTL è la parola "" in ebraico (). dice quanto segue:
“Molti programmi per computer non sono in grado di visualizzare correttamente il testo bidirezionale. Ad esempio, il nome ebraico "Sarah" è composto dai caratteri sin (ש) (che appare a destra), poi resh (ר) e infine he (ה) (che dovrebbe apparire a sinistra)."
Molti terminali falliscono questo test: Alacritty, terminali Gnome e XFCE derivati da VTE, urxvt, st e xterm visualizzano "Sara" in ordine inverso, come se avessimo scritto il nome come "Aras".
Un altro problema con i testi bidirezionali è che devono essere allineati in qualche modo, soprattutto quando si tratta di mescolare testi RTL e LTR. Gli script RTL dovrebbero essere eseguiti dal lato destro della finestra del terminale, ma cosa dovrebbe succedere ai terminali che utilizzano per impostazione predefinita l'inglese LTR? La maggior parte di essi non ha meccanismi speciali e allinea tutto il testo a sinistra (anche in Konsole). Le eccezioni sono pterm e mlterm, che aderiscono agli standard e allineano a destra tali linee.
Protezione dall'inserimento
La prossima caratteristica critica che ho identificato è la protezione anti-inserimento. Sebbene sia ampiamente noto che incantesimi come:
$ curl http://example.com/ | shsono comandi push per l'esecuzione del codice, poche persone sanno che i comandi nascosti possono intrufolarsi nella console quando si copia e incolla da un browser Web, anche dopo un'attenta ispezione. mostra brillantemente quanto sia innocuo il comando:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitsi trasforma in una tale seccatura quando viene incollato dal sito Web di Horn nel terminale:
git clone /dev/null;
clear;
echo -n "Hello ";
whoami|tr -d 'n';
echo -e '!nThat was a bad idea. Don'"'"'t copy code from websites you don'"'"'t trust!
Here'"'"'s the first line of your /etc/passwd: ';
head -n1 /etc/passwd
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitCome funziona? Il codice dannoso è incluso nel blocco , che viene spostato fuori dalla vista dell'utente utilizzando i CSS.
è chiaramente progettato per neutralizzare tali attacchi. In questa modalità, i terminali racchiudono il testo incollato in una coppia di speciali sequenze di escape per comunicare alla shell l'origine del testo. Questo dice alla shell che può ignorare i caratteri speciali che il testo incollato può contenere. Tutti i terminali fino al venerabile xterm supportano questa funzionalità, ma incollare in modalità Bracketed richiede il supporto della shell o dell'applicazione in esecuzione sul terminale. Ad esempio, il software che utilizza (stesso Bash), necessita di un file ~/.inputrc:
set enable-bracketed-paste onSfortunatamente, il sito di test di Horn mostra anche come aggirare questa protezione attraverso la formattazione del testo stesso e finire prematuramente per applicare ad esso la modalità Tra parentesi. Funziona perché alcuni terminali non filtrano correttamente le sequenze di escape prima di aggiungerne di proprie. Ad esempio nel mio non sono mai riuscito a portare a termine con successo i test di Konsole anche con la configurazione corretta .inputrc file. Ciò significa che puoi facilmente danneggiare la configurazione del tuo sistema a causa di un'applicazione non supportata o di una shell configurata in modo errato. Ciò è particolarmente pericoloso quando si accede a server remoti, dove un accurato lavoro di configurazione è meno comune, soprattutto se si hanno molte macchine remote di questo tipo.
Una buona soluzione a questo problema è il plugin di conferma incolla per il terminale urxvt, che chiede semplicemente il permesso di inserire qualsiasi testo che contenga ritorni a capo. Non ho trovato un'opzione più sicura per l'attacco testuale descritto da Horn.
Schede e profili
Una caratteristica popolare in questo momento è il supporto per un'interfaccia a schede, che definiremo come una finestra di terminale contenente diversi altri terminali. Questa funzione differisce per i diversi terminali e, sebbene i tradizionali terminali xterm non supportino affatto le schede, incarnazioni di terminali più moderne come Xfce Terminal, GNOME Terminal e Konsole hanno questa funzione. Urxvt supporta anche le schede, ma solo se usi un plugin. Ma in termini di supporto delle schede in sé, Terminator è il leader indiscusso: non solo supporta le schede, ma può anche disporre i terminali in qualsiasi ordine (vedi immagine sotto).
Un'altra caratteristica di Terminator è la capacità di "raggruppare" queste schede insieme e inviare le stesse sequenze di tasti a più terminali contemporaneamente, fornendo uno strumento rozzo per eseguire operazioni di massa su più server contemporaneamente. Una funzionalità simile è implementata anche in Konsole. Per utilizzare questa funzionalità in altri terminali, è necessario utilizzare software di terze parti come , o .
Le schede funzionano particolarmente bene se abbinate ai profili: ad esempio, puoi avere una scheda per la posta elettronica, un'altra per la chat e così via. Questo è ben supportato da Konsole Terminal e GNOME Terminal. Entrambi consentono a ciascuna scheda di avviare automaticamente il proprio profilo. Terminator supporta anche i profili, ma non sono riuscito a trovare un modo per avviare automaticamente determinati programmi quando apri una scheda specifica. Altri terminali non hanno affatto il concetto di “profilo”.
Increspature
L'ultima cosa di cui parlerò nella prima parte di questo articolo è l'aspetto dei terminali. Ad esempio GNOME, Xfce e urxvt supportano la trasparenza, ma recentemente hanno abbandonato il supporto per le immagini di sfondo, costringendo alcuni utenti a passare al terminale . Personalmente ne sono felice ed è semplice Xrisorse, che imposta il set base di colori di sfondo per urxvt. Tuttavia, anche i temi colore non standard possono creare problemi. Per esempio, con applicazioni и , poiché utilizzano già i propri colori.
non supportava i colori e quelli nuovi erano spesso limitati a una tavolozza di 256 colori. Per gli utenti avanzati che modellano i propri terminali, i prompt della shell o le barre di stato in modi complessi possono rappresentare una fastidiosa limitazione. tiene traccia di quali terminali hanno il supporto "True Color". I miei test confermano che i terminali basati su Alacritty e VTE supportano perfettamente True Color. Altri terminali non se la passano molto bene in questo senso e, infatti, non visualizzano nemmeno 256 colori. Di seguito puoi vedere la differenza tra il supporto True Color nei terminali GNOME, st e xterm, che fanno un buon lavoro con la loro tavolozza di 256 colori, e urxvt, che non solo fallisce il test, ma mostra anche alcuni caratteri lampeggianti al loro posto.
Alcuni terminali analizzano anche il testo per individuare i modelli URL per rendere i collegamenti selezionabili. Questo vale per tutti i terminali derivati da VTE, mentre urxvt richiede un plugin speciale che trasformerebbe gli URL con un clic o utilizzando una scorciatoia da tastiera. Altri terminali Ho testato gli URL di visualizzazione in altri modi.
Infine, una nuova tendenza nei terminali è l'opzionalità dello scroll buffer. Ad esempio, st non ha un buffer di scorrimento; si presuppone che l'utente utilizzerà un multiplexer terminale come tmux e .
Anche Alacritty non dispone di buffer per il backscroll, ma il suo supporto grazie al "vasto feedback" su questo argomento da parte degli utenti. A parte questi nuovi arrivi, ogni terminale che ho testato e che ho trovato supporta lo scorrimento inverso.
subtotali
Nella seconda parte del materiale (nell'originale si trattava di due articoli diversi - ca. sentiero) confronteremo prestazioni, utilizzo della memoria e latenza. Ma possiamo già vedere che alcuni dei terminali in questione presentano gravi carenze. Ad esempio, gli utenti che lavorano regolarmente con script RTL potrebbero voler prendere in considerazione mlterm e pterm, poiché sono più bravi a gestire attività simili rispetto ad altri. Anche Konsole si è comportata bene. Gli utenti che non lavorano con gli script RTL possono scegliere qualcos'altro.
In termini di protezione contro l'inserimento di codice dannoso, urxvt si distingue per la sua speciale implementazione di protezione contro questo tipo di attacco, che mi sembra decisamente conveniente. Per coloro che cercano qualche fronzolo, vale la pena dare un'occhiata a Konsole. Infine, vale la pena notare che VTE è un'ottima base per terminali, che garantisce il supporto dei colori, il riconoscimento degli URL e così via. A prima vista, il terminale predefinito fornito con il tuo ambiente preferito potrebbe soddisfare tutti i requisiti, ma lasciamo aperta questa domanda finché non ne comprendiamo le prestazioni.
Continua la conversazione
In generale, le prestazioni dei terminali di per sé possono sembrare un problema inverosimile, ma a quanto pare, alcuni di essi mostrano una latenza sorprendentemente elevata per un software di questo tipo. Successivamente esamineremo anche quella che viene tradizionalmente chiamata “velocità” (in realtà, questa è la velocità di scorrimento) e il consumo di memoria del terminale (con l'avvertenza che questo non è così critico oggi come lo era decenni fa).
ritardo
Dopo uno studio approfondito delle prestazioni del terminale, sono giunto alla conclusione che il parametro più importante a questo riguardo è la latenza (ping). Nel suo articolo Pavel Fatin ha esaminato la latenza di vari editor di testo e ha lasciato intendere che i terminali a questo riguardo potrebbero essere più lenti degli editor di testo più veloci. È stato questo suggerimento che alla fine mi ha portato a eseguire i miei test e a scrivere questo articolo.
Ma cos’è la latenza e perché è così importante? Nel suo articolo Fatin lo definisce come “il ritardo tra la pressione di un tasto e il corrispondente aggiornamento dello schermo” e lo cita , che afferma: “Il ritardo nel feedback visivo sullo schermo di un computer ha un impatto importante sul comportamento e sulla soddisfazione del dattilografo”.
Fatin spiega che questo ping ha conseguenze più profonde della semplice soddisfazione: “la digitazione diventa più lenta, si verificano più errori e la tensione oculare e muscolare aumenta”. In altre parole, un grande ritardo può portare a errori di battitura e anche a una minore qualità del codice, poiché comporta un carico cognitivo aggiuntivo sul cervello. Ma quel che è peggio è che il ping "aumenta lo sforzo degli occhi e dei muscoli", il che sembra implicare in futuro (Apparentemente, l'autore intende problemi ai muscoli degli occhi, della schiena, delle braccia e, ovviamente, della vista - ca. sentiero) a causa di stress ripetitivo.
Alcuni di questi effetti sono noti da molto tempo e i risultati , pubblicato nel 1976 sulla rivista ergonomica, affermava che un ritardo di 100 millisecondi "compromette notevolmente la velocità di battitura". Più recentemente, è stata introdotta la Guida per l'utente di GNOME in 10 millisecondi e se vai oltre, allora mostra che 1 millisecondo è l'ideale.
Fatin ha condotto i suoi test sugli editor di testo; ha creato uno strumento portatile chiamato , che ho usato per testare il ping negli emulatori di terminale. Tieni presente che il test è stato condotto in modalità simulazione: in realtà dobbiamo tenere conto sia della latenza di input (tastiera, controller USB, ecc.) che di output (buffer della scheda video, monitor). Secondo Fatin, nelle configurazioni tipiche è di circa 20 ms. Se disponi di un'attrezzatura da gioco, puoi raggiungere questa cifra in soli 3 millisecondi. Dato che disponiamo già di un hardware così veloce, l'applicazione non deve aggiungere la propria latenza. L'obiettivo di Fatin è portare la latenza dell'applicazione a 1 millisecondo o addirittura ottenere la composizione senza , come in .
Ecco i risultati delle mie misurazioni, così come alcuni risultati di Fatin, per dimostrare che il mio esperimento concorda con i suoi test:
La prima cosa che mi ha colpito è stato il miglior tempo di risposta dei programmi più vecchi come xterm e mlterm. Con la latenza di registro peggiore (2,4 ms), hanno funzionato meglio del terminale moderno più veloce (10,6 ms per st). Nessun terminale moderno scende al di sotto della soglia dei 10 millisecondi. In particolare, Alacritty non riesce a soddisfare l'affermazione "l'emulatore di terminale più veloce disponibile", sebbene i suoi punteggi siano migliorati rispetto alla sua prima recensione nel 2017. Infatti, gli autori del progetto e stiamo lavorando per migliorare la visualizzazione. Va anche notato che Vim che utilizza GTK3 è un ordine di grandezza più lento della sua controparte GTK2. Da ciò possiamo concludere che GTK3 crea ulteriore latenza, e questo si riflette in tutti gli altri terminali che lo utilizzano (Terminator, Terminale Xfce4 e Terminale GNOME).
Tuttavia, le differenze potrebbero non essere evidenti alla vista. Come spiega Fatin, “non devi essere consapevole del ritardo affinché abbia un effetto su di te”. Fatin mette in guardia anche sulla deviazione standard: “qualsiasi disturbo nella latenza (jitter) crea ulteriore stress a causa della sua imprevedibilità”.
Il grafico sopra è ripreso su Debian 9 puro (stretch) con . Questo ambiente produce i migliori risultati nei test di latenza. A quanto pare, GNOME crea un ping aggiuntivo di 20 ms per tutte le misurazioni. Una possibile spiegazione di ciò è la presenza di programmi con elaborazione sincrona degli eventi di input. Fatin fornisce un esempio di un caso del genere , che aggiunge un ritardo elaborando tutti gli eventi di input in modo sincrono. Per impostazione predefinita, GNOME viene fornito anche con un gestore di 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 tradizionale test di "velocità" o "larghezza di banda", che misura la velocità con cui il terminale può scorrere una pagina visualizzando grandi 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 il test di Thomas E. Dickey (manutentore di xterm), che ripetutamente . In un'altra recensione delle prestazioni del terminale utilizza una stringa codificata base32 di byte casuali, che viene inviata al terminale utilizzando cat. Luu ritiene che un test del genere sia "un punto di riferimento tanto inutile quanto si possa immaginare" e suggerisce invece di utilizzare la risposta del terminale come metrica primaria. Dickey definisce anche il suo test fuorviante. Tuttavia, entrambi gli autori riconoscono che la larghezza di banda della finestra del terminale può rappresentare un problema. Luu ha riscontrato che Emacs Eshell si bloccava durante la visualizzazione di file di grandi dimensioni e Dickey ha ottimizzato il terminale per eliminare la lentezza visiva di xtrerm. Quindi c'è ancora qualche merito in questo test, ma poiché il processo di rendering è molto diverso da terminale a terminale, può anche essere utilizzato come componente di test per testare altri parametri.
Qui vediamo l'rxvt e lo st superare la concorrenza, seguiti dal più recente Alacritty, progettato con particolare attenzione alle prestazioni. Seguono Xfce (famiglia VTE) e Konsole, che sono quasi due volte più veloci. L'ultimo è xterm, che è cinque volte più lento di rxvt. Durante il test, anche xterm si è increspato molto, rendendo difficile vedere il testo che passa anche se era la stessa riga. Konsole era veloce, ma a volte era complicato: il display si bloccava di tanto in tanto, mostrando il testo parziale o non mostrandolo affatto. Altri terminali mostravano chiaramente le stringhe, inclusi st, Alacritty e rxvt.
Dickey spiega che le differenze di prestazioni sono dovute alla progettazione dei buffer di scorrimento nei diversi terminali. In particolare accusa rxvt e gli altri terminali di "non seguire le regole generali":
“A differenza di xterm, rxvt non ha tentato di visualizzare tutti gli aggiornamenti. Se rimane indietro, rifiuterà alcuni aggiornamenti per recuperare il ritardo. Ciò ha avuto un impatto maggiore sulla velocità di scorrimento apparente che sull'organizzazione della memoria interna. Uno svantaggio era che l'animazione ASCII era un po' imprecisa."
Per correggere questa lentezza percepita di xterm, Dickey suggerisce di utilizzare la risorsa , consentendo a xterm di eliminare alcuni aggiornamenti dello schermo per tenere il passo con il flusso. I miei test confermano che fastScroll migliora le prestazioni e porta xterm alla pari con rxvt. Questa è, tuttavia, una stampella piuttosto rozza, come spiega lo stesso Dickey: "a volte xterm - come konsole - sembra bloccarsi mentre attende una nuova serie 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 dal fatto che abbia senso considerare la velocità di scorrimento come un parametro di prestazione, questo test ci permette di simulare il carico sui terminali, che a sua volta ci permette di misurare altri parametri come la memoria o l'utilizzo del disco. Le metriche sono state ottenute eseguendo il test specificato ss sotto il monitoraggio del processo Python. Ha raccolto i dati del contatore per ru_maxrss, Quantità ru_oublock и ru_inblock e un semplice timer.
In questo test, l'ST è al primo posto con il consumo medio di memoria più basso di 8 MB, il che non sorprende considerando che l'idea principale del design è la semplicità. mlterm, xterm e rxvt consumano un po' di più - circa 12 MB. Un altro risultato degno di nota è Alacritty, che richiede 30 MB per essere eseguito. Poi ci sono i terminali della famiglia VTE con cifre da 40 a 60 MB, che non sono pochi. Questo consumo può essere spiegato dal fatto che questi terminali utilizzano librerie di livello superiore, ad esempio GTK. Konsole arriva ultimo con un enorme consumo di memoria di 65 MB durante i test, anche se questo può essere giustificato dalla sua gamma molto ampia di funzionalità.
Rispetto ai risultati precedenti ottenuti dieci anni fa, tutti i programmi hanno iniziato a consumare notevolmente più memoria. Xterm richiedeva 4 MB, ma ora richiede 15 MB solo all'avvio. C'è un aumento simile nel consumo per rxvt, che ora richiede 16 MB. Il terminale Xfce occupa 34 MB, ovvero tre volte più grande di prima, ma il terminale GNOME richiede solo 20 MB. Naturalmente tutti i test precedenti sono stati effettuati su architettura a 32 bit. All'LCA 2012 Rusty Russell , che ci sono molte ragioni più sottili che potrebbero spiegare l'aumento del consumo di memoria. Detto questo, viviamo in un'epoca in cui abbiamo gigabyte di memoria, quindi in qualche modo ce la faremo.
Tuttavia, non posso fare a meno di pensare che allocare più memoria a qualcosa di così fondamentale come il terminale sia uno spreco di risorse. Questi programmi dovrebbero essere i più piccoli tra i più piccoli, dovrebbero poter girare su qualsiasi “scatola”, anche su una scatola da scarpe, se mai dovessimo arrivare al punto in cui dovranno essere dotati di sistemi Linux (e voi sapete che sarà così ). Ma con questi numeri, l’utilizzo della memoria diventerà un problema in futuro in qualsiasi ambiente che utilizzi più terminali diversi da quelli più leggeri e con capacità limitate. Per compensare ciò, GNOME Terminal, Konsole, urxvt, Terminator e Xfce Terminal dispongono di una modalità Daemon che consente di controllare più terminali attraverso un unico processo, limitando il consumo di memoria.
Durante i miei test, sono arrivato a un altro risultato inaspettato riguardo alla lettura-scrittura del disco: mi aspettavo di non vedere nulla qui, ma si è scoperto che alcuni terminali scrivono i dati più voluminosi su disco. Pertanto, la libreria VTE mantiene effettivamente un buffer di scorrimento sul disco (questa funzionalità , e questo sta ancora accadendo). Ma a differenza delle implementazioni precedenti, ora almeno questi dati vengono crittografati utilizzando AES256 GCM (). Ma sorge una domanda ragionevole: cosa c'è di così speciale nella libreria VTE da richiedere un approccio così non standard all'implementazione...
conclusione
Nella prima parte dell'articolo, abbiamo scoperto che i terminali basati su VTE hanno un buon set di funzionalità, ma ora vediamo che questo comporta alcuni costi in termini di prestazioni. Adesso la memoria non è più un problema perché tutti i terminali VTE possono essere controllati attraverso un processo Daemon, che ne limita l'appetito. Tuttavia, i sistemi più vecchi che hanno limitazioni fisiche sulla quantità di RAM e buffer del kernel potrebbero ancora aver bisogno di versioni precedenti dei terminali, poiché consumano molte meno risorse. Sebbene i terminali VTE abbiano ottenuto buoni risultati nei test di throughput (scorrimento), la loro latenza di visualizzazione è superiore alla soglia impostata nella Guida dell'utente di GNOME. Gli sviluppatori VTE dovrebbero probabilmente tenerne conto. Se teniamo conto del fatto che anche per gli utenti Linux alle prime armi l'incontro con un terminale è inevitabile, possono renderlo più facile da usare. Per i geek esperti, il passaggio dal terminale predefinito può anche significare meno affaticamento degli occhi e la possibilità di evitare futuri infortuni e malattie legate al lavoro dovuti a lunghe sessioni di lavoro. Purtroppo solo i vecchi xterm e mlterm ci portano alla soglia magica del ping di 10 millisecondi, cosa inaccettabile per molti.
Le misurazioni benchmark hanno inoltre dimostrato che, a causa dello sviluppo degli ambienti grafici Linux, gli sviluppatori hanno dovuto scendere a numerosi compromessi. Alcuni utenti potrebbero voler considerare i normali gestori di finestre poiché forniscono una significativa riduzione del ping. Sfortunatamente, non è stato possibile misurare la latenza per Wayland: il programma Typometer che ho utilizzato è stato creato per ciò che Wayland è progettato per impedire: spiare altre finestre. Spero che il compositing di Wayland funzioni meglio di X.org, e spero anche che in futuro qualcuno trovi un modo per misurare la latenza in questo ambiente.
Fonte: habr.com