{"id":37222,"date":"2019-10-31T22:16:26","date_gmt":"2019-10-31T19:16:26","guid":{"rendered":"https:\/\/prohoster.info\/blog\/obzor-emulyatorov-terminala\/"},"modified":"2019-10-31T22:16:26","modified_gmt":"2019-10-31T19:16:26","slug":"obzor-emulyatorov-terminala","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/obzor-emulyatorov-terminala","title":{"rendered":"Panoramica degli emulatori di terminale","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Due parole dal nostro ufficio traduzioni: di solito tutti si sforzano di tradurre i materiali e le pubblicazioni pi\u00f9 recenti, e noi non facciamo eccezione. Ma i terminali non sono qualcosa che viene aggiornato ogni settimana. Perci\u00f2 abbiamo tradotto per voi l'articolo di Antoine Bopr\u00e9, pubblicato nella primavera del 2018: nonostante il suo \u00abet\u00e0\u00bb piuttosto significativa per gli standard attuali, riteniamo che il materiale non abbia perso attualit\u00e0. Inoltre, l'originale \u00e8 una serie di due articoli, ma abbiamo deciso di unirli in un unico grande post.<\/i><\/p>\n

\"Panoramica
\n
\nI terminali occupano un posto particolare nella storia dei computer, ma negli ultimi decenni hanno dovuto letteralmente \u00absopravvivere\u00bb insieme alla riga di comando, mentre le interfacce grafiche si diffondevano ovunque. Emulatori di terminale<\/a><\/noindex> hanno sostituito i loro fratelli hardware<\/a><\/noindex>, che a loro volta erano una modifica dei sistemi a schede perforate e commutatori. Le moderne distribuzioni sono fornite con una variet\u00e0 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\u00e0, dimensioni e prestazioni.
\n<\/a><\/noindex><\/p>\n

Alcuni terminali presentano vulnerabilit\u00e0 di sicurezza sorprendentemente gravi, oltre al fatto che la maggior parte offre insiemi di funzionalit\u00e0 notevolmente diversi, dal supporto per interfacce a schede agli script. Sebbene noi abbiamo esaminato gli emulatori di terminale in un lontano passato<\/a><\/noindex>, questo articolo \u00e8 un aggiornamento del materiale precedente che aiuter\u00e0 i lettori a determinare quale terminale utilizzare nel 2018. Nella prima met\u00e0 dell'articolo vengono confrontate le funzionalit\u00e0, mentre nella seconda viene valutata la prestazione.<\/p>\n

Ecco i terminali che ho esaminato:<\/p>\n

\"Panoramica
\n
\nPotrebbe non trattarsi delle versioni pi\u00f9 recenti, poich\u00e9 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 \u00e8 Alacritty. \u00c8 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 Electron<\/a><\/noindex>), poich\u00e9 i test preliminari hanno mostrato prestazioni estremamente basse.<\/p>\n

Supporto Unicode<\/h4>\n

\nHo iniziato i miei test con il supporto Unicode. Il primo test dei terminali \u00e8 stato visualizzare la seguente stringa Unicode da un articolo su Wikipedia<\/a><\/noindex>: \u00ab\u00e9, \u0394, \u0419, \u05e7, \u0645, \u0e57, \u3042, \u53f6, \u8449 e \ub9d0\u00bb. Questo semplice test mostra se il terminale pu\u00f2 funzionare correttamente in tutto il mondo. Il terminale xterm non visualizza il carattere arabo Mem<\/a><\/noindex> nella configurazione predefinita:<\/p>\n

\"Panoramica
\n
\nPer impostazione predefinita, xterm utilizza un carattere 'monospaziato' classico che, secondo la stessa Wiki<\/a><\/noindex>, ha \u00abuna copertura Unicode sostanziale dal 1997\u00bb. 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:<\/p>\n

\"Panoramica
\n
\nQuesti screenshot sono stati realizzati su Fedora 27, poich\u00e9 questa aveva fornito risultati migliori rispetto a Debian 9, dove alcune versioni pi\u00f9 vecchie dei terminali (in particolare \u2014 mlterm) non potevano funzionare correttamente con i caratteri. Per fortuna, questo \u00e8 stato risolto nelle versioni pi\u00f9 recenti.<\/p>\n

Ora, presta attenzione alla visualizzazione della stringa in xterm. Risulta che il carattere Mem e quello successivo Semitic Qoph<\/a><\/noindex> appartengono a script di scrittura RTL (right-to-left<\/a><\/noindex>), quindi tecnicamente dovrebbero essere visualizzati da destra a sinistra. I browser web, come Firefox 57, elaborano correttamente la stringa sopra riportata. Un'opzione pi\u00f9 semplice di testo RTL \u00e8 la parola \u00abSara<\/a><\/noindex>\u00bb in ebraico (\u05e9\u05e8\u05d4<\/a><\/noindex>). La pagina Wiki sui testi bidirezionali<\/a><\/noindex> afferma quanto segue:<\/p>\n

\u00abMolti programmi per computer non possono visualizzare correttamente il testo bidirezionale. Ad esempio, il nome ebraico 'Sara' \u00e8 composto dai caratteri sin (\u05e9) (che appare a destra), poi resh (\u05e8) e infine he (\u05d4) (che dovrebbe apparire a sinistra)\u00bb.<\/p><\/blockquote>\n

\nMolti 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\".<\/p>\n

\"Panoramica
\n
\nUn altro problema dei testi bi-direzionali \u00e8 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 \u00e8 rappresentata da pterm e mlterm, che seguono gli standard e allineano tali righe a destra.<\/p>\n

\"Panoramica
\n<\/p>\n

Protezione da incolla<\/h4>\n

\nLa seguente caratteristica critica che ho identificato \u00e8 la protezione da incolla. Anche se \u00e8 ampiamente noto che comandi del tipo:<\/p>\n

$ curl http:\/\/example.com\/ | sh<\/code><\/pre>\n
\nsono 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. Sito di verifica di Giana Horn<\/a><\/noindex> dimostra brillantemente come un comando apparentemente innocuo:<\/p>\n
git clone git:\/\/git.kernel.org\/pub\/scm\/utils\/kup\/kup.git<\/code><\/pre>\n
\nsi trasformi, se incollato dal sito di Horn nel terminale, in un brutto scherzo:<\/p>\n
git clone \/dev\/null;\n    clear;\n\techo -n \"Hello \";\n\twhoami|tr -d 'n';\n\techo -e '!nQuella \u00e8 stata una brutta idea. Non copiare codice da siti web che non ti fidi! \n\tEcco la prima riga del tuo \/etc\/passwd: ';\n\thead -n1 \/etc\/passwd\n\tgit clone git:\/\/git.kernel.org\/pub\/scm\/utils\/kup\/kup.git<\/code><\/pre>\n
\nCome funziona? Il codice dannoso \u00e8 stato estratto in un blocco <\/b>, che \u00e8 stato spostato fuori dalla vista dell'utente tramite CSS.<\/p>\n
Modalit\u00e0 di incolla con parentesi<\/a><\/noindex> \u00e8 esplicitamente progettata per neutralizzare attacchi simili. In questa modalit\u00e0, 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\u00f2 ignorare i caratteri speciali che pu\u00f2 contenere il testo incollato. Tutti i terminali, fino all'odierno xterm, supportano questa funzione, ma l'incolla in modalit\u00e0 Bracketed necessita del supporto della shell o dell'applicazione in esecuzione nel terminale. Ad esempio, il software che utilizza GNU Readline<\/a><\/noindex> (lo stesso Bash), ha bisogno di un file ~ \/.inputrc<\/b>:<\/p>\n
set enable-bracketed-paste on<\/code><\/pre>\n
\nPurtroppo, il sito di test di Horna mostra anche come aggirare questa protezione attraverso la formattazione del testo e terminare prematuramente l'applicazione della modalit\u00e0 Bracketed. Questo funziona perch\u00e9 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<\/b> file. Ci\u00f2 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 \u00e8 particolarmente pericoloso quando si accede a server remoti, dove una cura meticolosa della configurazione \u00e8 rara, soprattutto se hai molte di queste macchine remote.<\/p>\n
Una buona soluzione a questo problema \u00e8 un plugin di conferma per l'inserimento nel terminale urxvt<\/b>, che semplicemente richiede il permesso di inserire qualsiasi testo che contiene nuove righe. Non ho trovato un'opzione pi\u00f9 sicura per l'attacco testuale descritto da Horna.<\/p>\n
Schede e profili<\/h4>\n
\nUna funzionalit\u00e0 oggi molto popolare \u00e8 il supporto per l'interfaccia a schede, che definiremo come una finestra del terminale che contiene altri terminali. Questa funzionalit\u00e0 varia a seconda del terminale e, sebbene i terminali tradizionali come xterm non supportino affatto le schede, incarnazioni pi\u00f9 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 \u00e8 Terminator: non solo supporta le schede, ma pu\u00f2 anche disporre i terminali in modo arbitrario (vedi immagine qui sotto).<\/p>\n
\"Panoramica
\n
\nUn'altra caratteristica di Terminator \u00e8 la possibilit\u00e0 di \"raggruppare\" queste schede insieme e inviare le stesse pression del tasto a pi\u00f9 terminali contemporaneamente, fornendo uno strumento rudimentale per eseguire operazioni di massa su pi\u00f9 server contemporaneamente. Una funzionalit\u00e0 simile \u00e8 anche implementata in Konsole. Per utilizzare questa funzione in altri terminali, \u00e8 necessario utilizzare software di terze parti, come Cluster SSH<\/a><\/noindex>, xlax<\/a><\/noindex> o tmux<\/a><\/noindex>.<\/p>\n
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\u00ec via. Questo \u00e8 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\".<\/p>\n
Ruches<\/h4>\n
\nL'ultimo aspetto che esaminer\u00f2 nella prima parte di questo articolo \u00e8 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. Tilix<\/a><\/noindex>. Personalmente, mi accontento anche di una configurazione semplice. Xresources<\/b>, che imposta un set di colori di base per lo sfondo di urxvt. Tuttavia, i temi colorati non standard possono causare problemi. Ad esempio, Solarized<\/a><\/noindex> non funzioni<\/a><\/noindex> con le applicazioni htop<\/a><\/noindex> e IPTraf<\/a><\/noindex>, poich\u00e9 utilizzano gi\u00e0 i propri colori.<\/p>\n
Il terminale originale VT100<\/a><\/noindex> 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. Gist<\/a><\/noindex> 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.<\/p>\n
\"Panoramica
\n
\nAlcuni 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.<\/p>\n
Finalmente, una nuova tendenza nei terminali \u00e8 l'opzionalit\u00e0 del buffer di scorrimento. Ad esempio, in st non c'\u00e8 un buffer di scorrimento; si presume che l'utente utilizzi un multiplexer di terminale, come tmux e GNU Screen<\/a><\/noindex>.<\/p>\n
In Alacritty mancano anche i buffer di scorrimento inverso, ma presto verr\u00e0 aggiunto<\/a><\/noindex> il suo supporto a causa di \u00abampi feedback\u00bb 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.<\/p>\n
Risultati intermedi<\/h4>\n
\nNella seconda parte del materiale (nel testo originale si trattava di due articoli separati, ndr.<\/i>) confronteremo le prestazioni, l'uso della memoria e la latenza. Ma vediamo gi\u00e0 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\u00e9 gestiscono queste attivit\u00e0 meglio di altri. Anche Konsole ha dimostrato di essere molto valido. Gli utenti che non lavorano con script RTL possono scegliere qualcos'altro.<\/p>\n
Dal punto di vista della protezione contro l'inserimento di codice dannoso, urxvt si distingue grazie alla sua implementazione particolare, che a mio avviso \u00e8 decisamente utile. Chi cerca qualche funzionalit\u00e0 avanzata dovrebbe dare un'occhiata a Konsole. Infine, vale la pena notare che VTE \u00e8 una base eccellente per i terminali, che garantisce supporto per i colori, riconoscimento degli URL e cos\u00ec via. A prima vista, il terminale predefinito fornito con il tuo ambiente preferito potrebbe soddisfare tutte le esigenze, ma lasciamo aperta questa questione finch\u00e9 non analizziamo le prestazioni.<\/p>\n
<\/p>\n
Continuiamo la conversazione<\/h4>\n
<\/i>
\nIn generale, le prestazioni dei terminali possono sembrare un problema esagerato; tuttavia, come si \u00e8 rivelato, alcuni di essi mostrano una latenza sorprendentemente alta per un software di questo tipo fondamentale. Inoltre, esamineremo ci\u00f2 che viene tradizionalmente chiamata \u00abvelocit\u00e0\u00bb (in realt\u00e0, \u00e8 la velocit\u00e0 di scorrimento) e il consumo di memoria del terminale (considerando che oggi non \u00e8 cos\u00ec critico come decenni fa).<\/p>\n
Ritardo<\/h4>\n
\nDopo un'attenta analisi delle prestazioni dei terminali, sono giunto alla conclusione che il parametro pi\u00f9 importante in questo senso \u00e8 la dimensione della latenza (ping). Nel mio articolo \u00abStampiamo con piacere\u00bb<\/a><\/noindex> Pavel Fatin ha esaminato il ritardo di vari editor di testo e ha accennato al fatto che i terminali potrebbero funzionare pi\u00f9 lentamente rispetto ai pi\u00f9 veloci editor di testo. \u00c8 stata proprio questa osservazione a portarmi, infine, a lanciare i miei test e a scrivere questo articolo.<\/p>\n
Ma che cos'\u00e8 il ritardo e perch\u00e9 \u00e8 cos\u00ec importante? Nel suo articolo, Fatin lo definisce come \u00abil ritardo tra la pressione di un tasto e l'aggiornamento corrispondente dello schermo\u00bb e cita \u00abGuida all'interazione dell'uomo con il computer\u00bb<\/a><\/noindex>, in cui si afferma: \u00abIl ritardo del feedback visivo sullo schermo del computer ha un'importante influenza sul comportamento del dattilografo e sulla sua soddisfazione\u00bb.<\/p>\n
Fatin spiega che questo ping ha conseguenze pi\u00f9 profonde, oltre alla semplice soddisfazione: \u00abla digitazione diventa pi\u00f9 lenta, ci sono pi\u00f9 errori, e aumenta la tensione degli occhi e dei muscoli\u00bb. In altre parole, un ritardo maggiore pu\u00f2 portare a errori di battitura e a una diminuzione della qualit\u00e0 del codice, poich\u00e9 comporta un carico cognitivo aggiuntivo per il cervello. Ma ci\u00f2 che \u00e8 ancora peggio \u00e8 che il ping \u00abaumenta la tensione degli occhi e dei muscoli\u00bb, il che, a quanto pare, implica lo sviluppo di infortuni professionali<\/a><\/noindex> in futuro (presumibilmente, l'autore si riferisce a problemi agli occhi, alla schiena, alle braccia e, naturalmente, alla vista, \u2014 nota del traduttore.<\/i>) a causa della tensione ripetitiva.<\/p>\n
Alcuni di questi effetti sono noti da tempo e i risultati la ricerca<\/a><\/noindex>, pubblicati gi\u00e0 nel 1976 nella rivista Ergonomics, indicano che un ritardo di 100 millisecondi \u00abdiminuisce significativamente la velocit\u00e0 di digitazione\u00bb. Recentemente, nella guida dell'utente GNOME \u00e8 stato stabilito un tempo di risposta accettabile<\/a><\/noindex> di 10 millisecondi, e se si vuole andare oltre, Microsoft Research<\/a><\/noindex> dimostra che l'ideale \u00e8 1 millisecondo.<\/p>\n
Fatin ha condotto i suoi test sugli editor di testo; ha creato uno strumento portatile chiamato Typometer<\/a><\/noindex>, che ho utilizzato per controllare il ping negli emulatori di terminale. Tieni presente che il test \u00e8 stato condotto in modalit\u00e0 simulazione: in realt\u00e0, dobbiamo considerare anche il ritardo dell'input (tastiera, controller USB e cos\u00ec via) e dell'output (buffer della scheda video, monitor). Secondo Fatin, nelle configurazioni tipiche \u00e8 di circa 20 ms. Con l'hardware da gaming, \u00e8 possibile raggiungere un valore di appena 3 millisecondi. Poich\u00e9 abbiamo gi\u00e0 questo hardware veloce, l'applicazione non dovrebbe introdurre ulteriori ritardi. L'obiettivo di Fatin \u00e8 quello di ridurre il ritardo dell'applicazione a 1 millisecondo, o addirittura raggiungere il set senza ritardi misurabili<\/a><\/noindex>, come in IntelliJ IDEA 15<\/a><\/noindex>.<\/p>\n
Ecco i risultati delle mie misurazioni, oltre ad alcuni risultati di Fatin per dimostrare che il mio esperimento \u00e8 in linea con i suoi test:<\/p>\n
\"Panoramica
\n
\nLa prima cosa che mi ha colpito \u00e8 stata la migliore reattivit\u00e0 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\u00f9 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\u00f9 veloce esistente', anche se i suoi risultati sono migliorati da quando \u00e8 stato testato per la prima volta nel 2017. Infatti, gli autori del progetto sono a conoscenza della situazione<\/a><\/noindex> e stanno lavorando per migliorare le prestazioni visive. \u00c8 anche importante notare che Vim, che utilizza GTK3, \u00e8 significativamente pi\u00f9 lento rispetto al suo analogo GTK2. Da ci\u00f2 si pu\u00f2 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).<\/p>\n
Tuttavia, per l'occhio, le differenze potrebbero non essere visibili. Come spiega Fatin: 'non \u00e8 necessario essere consapevoli della presenza del ritardo affinch\u00e9 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\u00e0'.<\/p>\n
\"Panoramica
\n
\nIl grafico sopra \u00e8 stato ottenuto su Debian 9 (stretch) puro con i3 window manager<\/a><\/noindex>. Questo ambiente fornisce i migliori risultati nei test di rilevamento della latenza. Si \u00e8 scoperto che GNOME genera un ping aggiuntivo di 20 ms per tutte le misurazioni. Una possibile spiegazione \u00e8 la presenza di programmi con elaborazione sincrona degli eventi di input. Fatin porta come esempio questo caso Workrave<\/a><\/noindex>, che introduce latenza elaborando tutti gli eventi di input in modo sincrono. Per impostazione predefinita, GNOME \u00e8 anche dotato di un gestore delle finestre Mutter<\/a><\/noindex>, che crea un ulteriore livello di buffering, che influisce sul ping e aggiunge almeno 8 millisecondi di latenza.<\/p>\n
\"Panoramica
\n<\/p>\n
Velocit\u00e0 di scorrimento<\/h4>\n
\nIl test successivo \u00e8 un controllo tradizionale della \"velocit\u00e0\" o della \"larghezza di banda\", che misura quanto rapidamente il terminale pu\u00f2 scorrere una pagina mostrando una grande quantit\u00e0 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 scaricato il file terminfo.src<\/a><\/noindex>. In un'altra revisione delle prestazioni dei terminali Den Liu<\/a><\/noindex> utilizza una stringa di byte casuali in codifica base32, che viene emessa nel terminale utilizzando cat. Liu considera questo test \"un benchmark cos\u00ec 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\u00f2 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'\u00e8 ancora una certa logica, ma poich\u00e9 il processo di rendering varia notevolmente da terminale a terminale, pu\u00f2 comunque essere utilizzato come componente di test per verificare altri parametri.<\/p>\n
\"Panoramica
\n
\nQui vediamo che rxvt e st emergono rispetto ai concorrenti, seguiti da Alacritty, molto pi\u00f9 recente e progettato per le prestazioni. A seguire ci sono Xfce (famiglia VTE) e Konsole, che funzionano quasi due volte pi\u00f9 velocemente. Ultimo in classifica \u00e8 xterm, che \u00e8 cinque volte pi\u00f9 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 \u00e8 rivelato veloce, ma a volte ha mostrato dei<\/p>\n
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\":<\/p>\n
\"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\u00f2 ha avuto un impatto maggiore sulla velocit\u00e0 apparente dello scorrimento che sull'organizzazione della memoria interna. Un inconveniente era che l'animazione ASCII risultava piuttosto imprecisa.\"<\/p><\/blockquote>\n
\nPer risolvere questa apparente lentezza di xterm, Diki suggerisce di usare la risorsa fastScroll<\/a><\/noindex>, 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\u00e9 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\u00e0 e integrit\u00e0 del display.<\/p>\n
Consumo di risorse<\/h4>\n
\nIndipendentemente dalla validit\u00e0 di considerare la velocit\u00e0 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<\/b> sotto il monitoraggio di un processo Python. Raccoglieva i dati dei contatori getrusage ()<\/a><\/noindex> per ru_maxrss<\/b>, la somma ru_oublock<\/b> e ru_inblock<\/b> e un semplice cronometro di tempo.<\/p>\n
\"Panoramica
\n
\nIn questo test, ST occupa il primo posto con il pi\u00f9 basso consumo medio di memoria a 8 MB, il che non sorprende, considerando che l'idea fondamentale del progetto \u00e8 la semplicit\u00e0. Consume un po' di pi\u00f9 mlterm, xterm e rxvt \u2014 circa 12 MB. Un altro risultato notevole \u00e8 Alacritty, che richiede 30 MB per funzionare. Seguono i terminali della famiglia VTE con valori che variano da 40 a 60 MB, il che \u00e8 abbastanza. Questo consumo pu\u00f2 essere spiegato dal fatto che questi terminali utilizzano librerie di livello superiore, come GTK. Konsole \u00e8 ultimo con un colossale consumo di 65 MB di memoria durante i test, anche se questo pu\u00f2 essere giustificato dal suo ampio set di funzionalit\u00e0.<\/p>\n
Rispetto ai risultati precedenti, ottenuti dieci anni fa, tutti i programmi hanno iniziato a consumare visibilmente pi\u00f9 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 \u00e8 tre volte di pi\u00f9 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 ha raccontato<\/a><\/noindex>, ci sono molte altre ragioni pi\u00f9 sottili che possono spiegare l'aumento del consumo di memoria. Con tutto ci\u00f2, stiamo vivendo un'epoca in cui abbiamo interi gigabyte di memoria, quindi riusciremo a gestirlo in qualche modo.<\/p>\n
Tuttavia, non posso liberarmi dalla sensazione che allocare pi\u00f9 memoria per un software cos\u00ec fondamentale come il terminale sia uno spreco di risorse. Questi programmi dovrebbero essere i pi\u00f9 leggeri tra i pi\u00f9 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\u00e0 cos\u00ec). Ma con questi numeri, l'uso della memoria diventer\u00e0 in futuro un problema in qualsiasi ambiente all'avvio di pi\u00f9 terminali, tranne nel caso di alcuni dei pi\u00f9 leggeri e limitati nelle funzionalit\u00e0. Per compensare ci\u00f2, GNOME Terminal, Konsole, urxvt, Terminator e Xfce Terminal hanno una modalit\u00e0 Daemon, che consente di gestire pi\u00f9 terminali tramite un unico processo, limitando cos\u00ec il loro consumo di memoria.<\/p>\n
\"Panoramica
\n
\nDurante 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 \u00e8 scoperto che alcuni terminali registrano i dati pi\u00f9 voluminosi su disco. Infatti, la libreria VTE mantiene un buffer di scorrimento su disco (questa caratteristica \u00e8 stata notata gi\u00e0 nel 2010<\/a><\/noindex>, e questo accade ancora oggi). Ma a differenza delle vecchie implementazioni, adesso, perlomeno, questi dati sono criptati con AES256 GCM (a partire dalla versione 0.39.2<\/a><\/noindex>). Ma sorge una domanda legittima: cosa c'\u00e8 di cos\u00ec speciale nella libreria VTE che richiede questo approccio non standard all'implementazione\u2026<\/p>\n
Conclusione<\/h4>\n
\nNella prima parte dell'articolo abbiamo scoperto che i terminali basati su VTE hanno un buon insieme di funzionalit\u00e0, ma ora vediamo che ci\u00f2 comporta alcuni costi per garantire le loro prestazioni. Ora la memoria non \u00e8 un problema, poich\u00e9 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\u00e0 di memoria RAM e sul buffer del kernel, potrebbero avere ancora bisogno di versioni precedenti dei terminali, poich\u00e9 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 \u00e8 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 \u00e8 inevitabile, potrebbero renderlo pi\u00f9 amichevole per l'utente. Per i geek esperti, passare dal terminale predefinito potrebbe anche significare una riduzione della tensione visiva e la possibilit\u00e0 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 \u00e8 inaccettabile.<\/p>\n
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\u00e9 offrono una significativa riduzione del ping. Purtroppo, non sono riuscito a misurare la latenza su Wayland: il programma Typometer, che ho utilizzato, \u00e8 stato creato per ci\u00f2 che Wayland cerca di evitare: la sorveglianza di altre finestre. Spero che il compositing di Wayland sia pi\u00f9 performante di X.org e anche che, in futuro, qualcuno trovi un modo per valutare il livello di latenza in questo ambiente.
\n
Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u041f\u0430\u0440\u0430 \u0441\u043b\u043e\u0432 \u043e\u0442 \u043d\u0430\u0448\u0435\u0433\u043e translate-\u0431\u044e\u0440\u043e: \u043e\u0431\u044b\u0447\u043d\u043e \u0432\u0441\u0435 \u0441\u0442\u0440\u0435\u043c\u044f\u0442\u0441\u044f \u043f\u0435\u0440\u0435\u0432\u043e\u0434\u0438\u0442\u044c \u0441\u0430\u043c\u044b\u0435 \u0441\u0432\u0435\u0436\u0438\u0435 \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u044b \u0438 \u043f\u0443\u0431\u043b\u0438\u043a\u0430\u0446\u0438\u0438, \u0438 \u043c\u044b \u043d\u0435 \u0438\u0441\u043a\u043b\u044e\u0447\u0435\u043d\u0438\u0435. \u041d\u043e \u0442\u0435\u0440\u043c\u0438\u043d\u0430\u043b\u044b \u2014 \u044d\u0442\u043e \u043d\u0435 \u0442\u043e, \u0447\u0442\u043e \u043e\u0431\u043d\u043e\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0440\u0430\u0437 \u0432 \u043d\u0435\u0434\u0435\u043b\u044e. \u041f\u043e\u044d\u0442\u043e\u043c\u0443 \u043c\u044b \u043f\u0435\u0440\u0435\u0432\u0435\u043b\u0438 \u0434\u043b\u044f \u0432\u0430\u0441 \u0441\u0442\u0430\u0442\u044c\u044e \u0410\u043d\u0442\u0443\u0430\u043d\u0430 \u0411\u043e\u043f\u0440\u0435, \u043e\u043f\u0443\u0431\u043b\u0438\u043a\u043e\u0432\u0430\u043d\u043d\u0443\u044e \u0432\u0435\u0441\u043d\u043e\u0439 2018 \u0433\u043e\u0434\u0430: \u043d\u0435\u0441\u043c\u043e\u0442\u0440\u044f \u043d\u0430 \u0441\u043e\u043b\u0438\u0434\u043d\u044b\u0439 \u043f\u043e \u0441\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u043c \u043c\u0435\u0440\u043a\u0430\u043c \u00ab\u0432\u043e\u0437\u0440\u0430\u0441\u0442\u00bb, \u043d\u0430 \u043d\u0430\u0448 \u0432\u0437\u0433\u043b\u044f\u0434, \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b \u0441\u043e\u0432\u0435\u0440\u0448\u0435\u043d\u043d\u043e \u043d\u0435 \u043f\u043e\u0442\u0435\u0440\u044f\u043b […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":27911,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-37222","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Recensione degli emulatori di terminale | ProHoster","description":"Due parole dal nostro ufficio traduzioni: di solito tutti cercano di tradurre i materiali e le pubblicazioni pi\u00f9 recenti, e noi non siamo un'eccezione. Ma i terminali non sono qualcosa che si aggiorna ogni settimana.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/obzor-emulyatorov-terminala","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041e\u0431\u0437\u043e\u0440 \u044d\u043c\u0443\u043b\u044f\u0442\u043e\u0440\u043e\u0432 \u0442\u0435\u0440\u043c\u0438\u043d\u0430\u043b\u0430 | ProHoster","og:description":"\u041f\u0430\u0440\u0430 \u0441\u043b\u043e\u0432 \u043e\u0442 \u043d\u0430\u0448\u0435\u0433\u043e translate-\u0431\u044e\u0440\u043e: \u043e\u0431\u044b\u0447\u043d\u043e \u0432\u0441\u0435 \u0441\u0442\u0440\u0435\u043c\u044f\u0442\u0441\u044f \u043f\u0435\u0440\u0435\u0432\u043e\u0434\u0438\u0442\u044c \u0441\u0430\u043c\u044b\u0435 \u0441\u0432\u0435\u0436\u0438\u0435 \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u044b \u0438 \u043f\u0443\u0431\u043b\u0438\u043a\u0430\u0446\u0438\u0438, \u0438 \u043c\u044b \u043d\u0435 \u0438\u0441\u043a\u043b\u044e\u0447\u0435\u043d\u0438\u0435. \u041d\u043e \u0442\u0435\u0440\u043c\u0438\u043d\u0430\u043b\u044b \u2014 \u044d\u0442\u043e \u043d\u0435 \u0442\u043e, \u0447\u0442\u043e \u043e\u0431\u043d\u043e\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0440\u0430\u0437 \u0432 \u043d\u0435\u0434\u0435\u043b\u044e.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/obzor-emulyatorov-terminala","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:16:26+00:00","article:modified_time":"2019-10-31T19:16:26+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"37222","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 16:48:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:31:24","updated":"2026-01-23 16:48:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/37222","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=37222"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/37222\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/27911"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=37222"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=37222"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=37222"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}