{"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":"

Una parola dal nostro ufficio di traduzione: di solito tutti cercano di tradurre i materiali e le pubblicazioni pi\u00f9 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\u00e0 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><\/p>\n

\"Panoramica
\n
\nI 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\u00f9 comuni interfacce grafiche. Emulatori di terminale<\/a><\/noindex> hanno sostituito i loro cugini hardware<\/a><\/noindex>, che, a loro volta, erano una modifica dei sistemi a schede perforate e rel\u00e8. 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\u00e0, dimensioni e prestazioni.
\n<\/a><\/noindex><\/p>\n

Alcuni terminali presentano falle di sicurezza davvero sorprendenti e, inoltre, la maggior parte ha un insieme di funzionalit\u00e0 completamente diverse, dal supporto per l'interfaccia con schede agli script. Anche se noi abbiamo esaminato gli emulatori di terminale in un passato remoto<\/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 performance.<\/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, che ho potuto installare su Debian 9 o Fedora 27. L'unica eccezione \u00e8 Alacritty. Questo terminale discende da quelli con accelerazione GPU ed \u00e8 scritto in un linguaggio insolito e nuovo per questo compito: Rust. Ho escluso dalla mia recensione i terminali web (inclusi quelli su Electron<\/a><\/noindex>), poich\u00e9 i test preliminari hanno mostrato le loro 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 una stringa di Unicode da un articolo di Wikipedia<\/a><\/noindex>: \u00ab\u00e9, \u0394, \u0419, \u05e7, \u0645, \u0e57, \u3042, \u53f6, \u8449 e \ub9d0\u00bb. Questo semplice test verifica 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
\nDi default, xterm utilizza un classico font \u00abfisso\u00bb, che, secondo la stessa Wiki<\/a><\/noindex>, ha un \u00abampio supporto Unicode dal 1997\u00bb. In questo font, succede qualcosa che fa s\u00ec 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 \u00abcorrezione\u00bb compromette la visualizzazione di altri simboli Unicode:<\/p>\n

\"Panoramica
\n
\nQueste schermate sono state catturate su Fedora 27, poich\u00e9 quest'ultima ha fornito i migliori risultati rispetto a Debian 9, dove alcune versioni pi\u00f9 vecchie dei terminali (e in particolare mlterm) non riuscivano a gestire i font in modo adeguato. Per fortuna, questo \u00e8 stato risolto in versioni successive.<\/p>\n

Ora notate la visualizzazione della linea in xterm. Si scopre che il simbolo Mem e quello successivo Semitic Qoph<\/a><\/noindex> appartengono agli scritture di orientamento RTL (right-to-left<\/a><\/noindex>), quindi tecnicamente dovrebbero essere visualizzati da destra a sinistra. I browser web, come Firefox 57, gestiscono correttamente la riga sopra riportata. Un esempio pi\u00f9 semplice di testo RTL \u00e8 la parola \u00ab\u05e9\u05e8\u05d4<\/a><\/noindex>\u00bb in ebraico (\u05e9\u05e8\u05d4<\/a><\/noindex>). Pagina Wiki sui testi bidirezionali<\/a><\/noindex> afferma quanto segue:<\/p>\n

\u00abMolti programmi informatici non riescono a visualizzare correttamente il testo bidirezionale. Ad esempio, il nome ebraico \u00abSara\u00bb \u00e8 composto dai caratteri sin (\u05e9) (che appare a destra), poi res (\u05e8) e infine he (\u05d4) (che deve apparire a sinistra)\u00bb.<\/p><\/blockquote>\n

\nMolti terminali non superano questo test: terminali derivati da Alacritty, VTE di Gnome e XFCE, urxvt, st e xterm visualizzano \u00abSara\u00bb al contrario, come se scrivessimo questo nome come \u00abAras\u00bb.<\/p>\n

\"Panoramica
\n
\nUn'altra problematica dei testi bidirezionali \u00e8 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.<\/p>\n

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

Protezione da inserimento<\/h4>\n

\nLa prossima caratteristica critica che ho identificato per me stesso \u00e8 la protezione da inserimento. Anche se \u00e8 ampiamente noto che incantesimi di tipo:<\/p>\n

$ curl http:\/\/example.com\/ | sh<\/code><\/pre>\n
\nsono 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. Sito di verifica di Gianna Horn<\/a><\/noindex> dimostra chiaramente come un comando apparentemente innocuo:<\/p>\n
git clone git: \/\/git.kernel.org\/pub\/scm\/utils\/kup\/kup.git<\/code><\/pre>\n
\nsi trasforma, incollando dal sito di Horn nel terminale, in questo sgradevole risultato:<\/p>\n
git clone \/dev\/null;\n    clear;\n\techo -n \"Ciao \";\n\twhoami|tr -d 'n';\n\techo -e '!nQuella \u00e8 stata una cattiva idea. Non copiare codice da siti web di cui 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 spostato 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 chiaramente progettato per neutralizzare tale attacco. In questa modalit\u00e0, 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\u00e0 Bracketed richiede il supporto della shell o dell'applicazione in esecuzione sul terminale. Ad esempio, i software che utilizzano GNU Readline<\/a><\/noindex> (lo stesso Bash) richiedono un file ~ \/ .inputrc<\/b>:<\/p>\n
set enable-bracketed-paste on<\/code><\/pre>\n
\nSfortunatamente, il sito di test di Horn mostra anche come eludere 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 proprie. Ad esempio, nei miei tentativi non sono riuscito a completare con successo i test di Konsole anche con una corretta configurazione .inputrc<\/b> 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 \u00e8 particolarmente pericoloso quando si accede a server remoti, dove una configurazione accurata \u00e8 meno comune, specialmente se hai molte di queste macchine remote.<\/p>\n
Una buona soluzione a questo problema \u00e8 il plugin di conferma dell'inserimento per il terminale urxvt<\/b>, che semplicemente chiede il permesso per inserire qualsiasi testo che contenga nuove righe. Non ho trovato una soluzione pi\u00f9 sicura per l'attacco testuale descritto da Horn.<\/p>\n
Schede e profili<\/h4>\n
\nUna funzionalit\u00e0 popolare al momento \u00e8 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\u00f9 moderne del terminale come Xfce Terminal, GNOME Terminal e Konsole offrono questa funzionalit\u00e0. Anche Urxvt supporta le schede, ma solo se si utilizza un plugin. Tuttavia, in termini di supporto per le schede, il leader indiscusso \u00e8 Terminator: non solo supporta le schede, ma pu\u00f2 anche disporre i terminali in ordine arbitrario (vedi immagine sotto).<\/p>\n
\"Panoramica
\n
\nUn'altra caratteristica di Terminator \u00e8 la possibilit\u00e0 di \"raggruppare\" queste schede insieme e inviare gli stessi comandi da tastiera a pi\u00f9 terminali contemporaneamente, fornendo uno strumento rudimentale per eseguire operazioni di massa su pi\u00f9 server. Una funzione 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 in combinazione con i profili: ad esempio, potresti avere una scheda per la posta elettronica, un'altra per la chat e cos\u00ec via. Questo \u00e8 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\".<\/p>\n
Ruches<\/h4>\n
\nL'ultimo argomento che tratter\u00f2 nella prima parte di questo articolo \u00e8 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. Tilix<\/a><\/noindex>. Personalmente, mi va bene anche utilizzare semplicemente Xresources<\/b>, che imposta un insieme di colori di sfondo base per urxvt. Tuttavia, i temi di colore 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 gi\u00e0 utilizzano i propri colori.<\/p>\n
Il terminale originale VT100<\/a><\/noindex> 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. Gist<\/a><\/noindex> 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.<\/p>\n
\"Panoramica
\n
\nAlcuni 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.<\/p>\n
Infine, 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 presuppone 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 sar\u00e0 presto aggiunta<\/a><\/noindex> la sua supporto a causa di \u00abun ampio feedback\u00bb degli utenti su questo tema. A parte queste eccezioni, ogni terminale che ho potuto trovare e che ho testato supporta lo scorrimento inverso.<\/p>\n
Risultati intermedi<\/h4>\n
\nNella seconda parte del materiale (nel originale erano due articoli distinti, \u2014 nota dell'autore.<\/i>) confronteremo le prestazioni, l'uso della memoria e la latenza. Ma possiamo gi\u00e0 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.<\/p>\n
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\u00e0 avanzate dovrebbe dare un'occhiata a Konsole. Infine, \u00e8 importante notare che VTE \u00e8 una base eccellente per i terminali, garantendo supporto per i colori, riconoscimento degli URL e cos\u00ec via. A prima vista, il terminale predefinito fornito con il proprio ambiente preferito potrebbe soddisfare tutte le esigenze, ma lasciamo questa questione aperta finch\u00e9 non approfondiamo le prestazioni.<\/p>\n
<\/p>\n
Continuiamo la conversazione<\/h4>\n
<\/i>
\nIn realt\u00e0, le prestazioni dei terminali possono sembrare un problema fittizio, tuttavia, come si \u00e8 rivelato, alcuni di essi mostrano una sorprendente latenza per un software di cos\u00ec fondamentale importanza. Inoltre, esamineremo ci\u00f2 che tradizionalmente viene chiamato \"velocit\u00e0\" (in realt\u00e0, si tratta della velocit\u00e0 di scorrimento) e il consumo di memoria del terminale (tenendo presente che oggi non \u00e8 cos\u00ec critico come decenni fa).<\/p>\n
Latenza<\/h4>\n
\nDopo un'attenta analisi delle prestazioni dei terminali, sono giunto alla conclusione che il parametro pi\u00f9 importante in questo contesto \u00e8 la dimensione del ritardo (ping). Nel mio articolo \u00abScrivere con piacere\u00bb<\/a><\/noindex> 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\u00f9 lentamente degli editor di testo pi\u00f9 veloci. \u00c8 stata proprio questa allusione a portarmi, infine, a condurre i miei test e scrivere questo articolo.<\/p>\n
Ma che cos'\u00e8 il ritardo e perch\u00e9 \u00e8 cos\u00ec importante? Nel suo articolo, Fatin lo ha definito come \u00abil ritardo tra la pressione del tasto e il corrispondente aggiornamento dello schermo\u00bb e ha citato \u00abGuida all'interazione uomo-computer\u00bb<\/a><\/noindex>, in cui si afferma: \u00abIl ritardo nel feedback visivo sullo schermo del computer ha un importante impatto sul comportamento della dattilografa e sulla sua soddisfazione\u00bb.<\/p>\n
Fatin spiega che un tale ping ha conseguenze pi\u00f9 profonde che semplicemente soddisfacenti: \u00abla digitazione diventa pi\u00f9 lenta, si verificano pi\u00f9 errori, aumenta la tensione degli occhi e dei muscoli\u00bb. In altre parole, una maggiore latenza pu\u00f2 portare a errori di battitura, oltre a una diminuzione della qualit\u00e0 del codice, poich\u00e9 comporta un'ulteriore carico cognitivo per il cervello. Ma ci\u00f2 che \u00e8 ancora peggio, 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 (a quanto pare, l'autore si riferisce a problemi con i muscoli oculari, la schiena, le mani e, naturalmente, la vista, \u2014 nota dell'autore.<\/i>) a causa di uno stress ripetitivo.<\/p>\n
Alcuni di questi effetti sono noti da tempo, e i risultati della ricerca<\/a><\/noindex>, pubblicati gi\u00e0 nel 1976 nella rivista Ergonomics, indicano che una latenza di 100 millisecondi \u00abdiminuisce significativamente la velocit\u00e0 di digitazione\u00bb. Recentemente, nel manuale dell'utente di GNOME, \u00e8 stata introdotta una latenza accettabile<\/a><\/noindex> di 10 millisecondi, e se si va oltre, Microsoft Research<\/a><\/noindex> dimostra che l'ideale \u00e8 1 millisecondo.<\/p>\n
Fatin ha effettuato i suoi test sui programmi di editing del 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 la latenza di input (tastiera, controller USB e cos\u00ec via) e di output (buffer della scheda video, monitor). Secondo Fatin, nelle configurazioni tipiche essa \u00e8 di circa 20 ms. Con attrezzature da gaming, \u00e8 possibile raggiungere un valore di soli 3 millisecondi. Dato che abbiamo gi\u00e0 un hardware cos\u00ec veloce, l'applicazione non dovrebbe aggiungere ulteriore latenza. L'obiettivo di Fatin \u00e8 portare la latenza dell'applicazione a 1 millisecondo, o addirittura raggiungere un insieme senza latenza misurabile<\/a><\/noindex>, come in IntelliJ IDEA 15<\/a><\/noindex>.<\/p>\n
Ecco i risultati delle mie misurazioni, insieme 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 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\u00f9 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\u00f9 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 sono a conoscenza della situazione<\/a><\/noindex> e stanno lavorando per migliorare le prestazioni. \u00c8 anche importante notare che Vim, utilizzando GTK3, \u00e8 notevolmente pi\u00f9 lento rispetto alla sua controparte GTK2. Da questo si pu\u00f2 dedurre che GTK3 crea una latenza aggiuntiva, e ci\u00f2 si riflette su tutti gli altri terminali che lo utilizzano (Terminator, Xfce4 Terminal e GNOME Terminal).<\/p>\n
Tuttavia, le differenze potrebbero non essere visibili all'occhio. Come spiega Fatin: \u00abnon \u00e8 necessario essere consapevoli della presenza di ritardi affinch\u00e9 questi abbiano un effetto su di voi\u00bb. Fatin avverte anche dello scarto standard: \u00abqualsiasi variazione nella durata del ritardo (tremolio) crea un'ulteriore pressione a causa della loro imprevedibilit\u00e0\u00bb.<\/p>\n
\"Panoramica
\n
\nIl grafico sopra \u00e8 stato ottenuto su una versione pulita di Debian 9 (stretch) con il gestore di finestre i3<\/a><\/noindex>. Questo ambiente produce i migliori risultati nei test di misurazione dei ritardi. Si \u00e8 scoperto che GNOME introduce 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 cita come esempio Workrave<\/a><\/noindex>, che introduce un ritardo elaborando tutti gli eventi di input in modo sincrono. Per impostazione predefinita, GNOME \u00e8 dotato anche di un manager di finestre Mutter<\/a><\/noindex>, che crea un ulteriore livello di buffer, influenzando il ping e aggiungendo almeno 8 millisecondi di ritardo.<\/p>\n
\"Panoramica
\n<\/p>\n
Velocit\u00e0 di scorrimento<\/h4>\n
\nIl test seguente \u00e8 una verifica 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 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 scaricato il file terminfo.src<\/a><\/noindex>. In un'altra revisione delle prestazioni dei terminali Den Liu<\/a><\/noindex> usa una stringa di byte casuali in codifica base32, che viene visualizzata nel terminale con il comando cat. Lu considera questo test \u00abun riferimento cos\u00ec inutile come \u00e8 possibile immaginare\u00bb 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\u00f2 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'\u00e8 ancora un certo senso, ma poich\u00e9 il processo di rendering varia notevolmente da terminale a terminale, pu\u00f2 essere utilizzato anche come componente di test per verificare altri parametri.<\/p>\n
\"Panoramica
\n
\nQui possiamo vedere che rxvt e st si distaccano rispetto ai concorrenti, seguito da Alacritty, molto pi\u00f9 recente e sviluppato con un focus sulle prestazioni. A seguire ci sono Xfce (famiglia VTE) e Konsole, che funzionano quasi il doppio pi\u00f9 velocemente. Ultimo \u00e8 xterm, che risulta cinque volte pi\u00f9 lento di rxvt. Durante il test, xterm mostrava anche forti disturbi, rendendo difficile leggere il testo, anche se si trattava della stessa riga. Konsole \u00e8 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.<\/p>\n
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':<\/p>\n
A differenza di xterm, rxvt non ha cercato di visualizzare tutti gli aggiornamenti. Se \u00e8 in ritardo, rinuncer\u00e0 ad alcuni aggiornamenti per recuperare il tempo perso. Questo ha avuto un impatto maggiore sulla velocit\u00e0 apparente di scorrimento rispetto all'organizzazione della memoria interna. Un difetto consisteva nel fatto che l'animazione ASCII era piuttosto imprecisa.<\/p><\/blockquote>\n
\nPer correggere questa apparente lentezza di xterm, Dick suggerisce di utilizzare la risorsa fastScroll<\/a><\/noindex>, 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, \u00e8 un rimedio piuttosto grossolano, come spiega lo stesso Dick: \"a volte xterm \u2014 come konsole \u2014 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\u00e0 e integrit\u00e0 del display.<\/p>\n
Consumo di risorse<\/h4>\n
\nIndipendentemente dalla pertinenza di considerare la velocit\u00e0 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<\/b> sotto il monitoraggio del processo Python. Raccoglieva dati dai contatori. getrusage ()<\/a><\/noindex> per ru_maxrss<\/b>, la somma ru_oublock<\/b> e ru_inblock<\/b> e un semplice timer per il tempo.<\/p>\n
\"Panoramica
\n
\nIn 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 \u00e8 la semplicit\u00e0. Consuma leggermente di pi\u00f9 mlterm, xterm e rxvt, circa 12 MB. Un altro risultato notevole \u00e8 Alacritty, che richiede 30 MB per funzionare. Seguono i terminali della famiglia VTE con valori che vanno da 40 a 60 MB, il che \u00e8 piuttosto elevato. Questo consumo pu\u00f2 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\u00f2 pu\u00f2 essere giustificato dal suo ampio set di funzionalit\u00e0.<\/p>\n
Rispetto ai risultati precedenti ottenuti dieci anni fa, tutti i programmi richiedono notevolmente pi\u00f9 memoria. Prima Xterm necessitava di 4 MB, ora ne richiede 15 MB solo per avviarsi. Un aumento simile \u00e8 presente anche in rxvt, che ora richiede di base 16 MB. Il terminale Xfce occupa 34 MB, tre volte di pi\u00f9 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 raccontato<\/a><\/noindex>, ha osservato che ci sono molte altre ragioni pi\u00f9 sottili che possono spiegare l'aumento del consumo di memoria. Detto ci\u00f2, viviamo in un'epoca in cui abbiamo interi gigabyte di memoria, quindi ci organizzeremo in qualche modo.<\/p>\n
Tuttavia, non riesco a scrollare via la sensazione che allocare pi\u00f9 memoria a un software fondamentale come un terminale sia uno spreco di risorse. Questi programmi dovrebbero essere tra i pi\u00f9 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\u00e0). Ma con queste cifre, l'uso della memoria diventer\u00e0 un problema in futuro in qualsiasi ambiente quando si avvieranno pi\u00f9 terminali, a parte i casi con i pi\u00f9 leggeri e limitati nelle funzionalit\u00e0. Per compensare questo, GNOME Terminal, Konsole, urxvt, Terminator e Xfce Terminal hanno una modalit\u00e0 Daemon che consente di gestire pi\u00f9 terminali attraverso un singolo 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: non mi aspettavo di vedere nulla qui, ma si \u00e8 scoperto che alcuni terminali scrivono i dati pi\u00f9 voluminosi su disco. In effetti, la libreria VTE tiene effettivamente su disco un buffer di scorrimento (questa caratteristica \u00e8 stata notata gi\u00e0 nel 2010<\/a><\/noindex>, e questo continua ancora oggi). Ma a differenza delle vecchie implementazioni, ora, perlomeno, questi dati sono criptati con AES256 GCM (dalla versione 0.39.2<\/a><\/noindex>). Ma sorge una domanda legittima, cosa c'\u00e8 di cos\u00ec speciale nella libreria VTE che richiede un approccio cos\u00ec non convenzionale all'implementazione\u2026<\/p>\n
Conclusione<\/h4>\n
\nNella prima parte dell'articolo abbiamo scoperto che i terminali basati su VTE dispongono di un buon insieme di funzionalit\u00e0, ma ora vediamo che ci\u00f2 comporta alcuni costi per garantire le loro prestazioni. Al momento, la memoria non \u00e8 un problema, poich\u00e9 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\u00e0 di RAM e di buffer del kernel, potrebbero ancora avere bisogno di versioni pi\u00f9 precedenti dei terminali, poich\u00e9 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. \u00c8 probabile che gli sviluppatori di VTE debbano tenere conto di questo. Considerando che anche per i nuovi utenti Linux l'incontro con il terminale \u00e8 inevitabile, potrebbero renderlo pi\u00f9 user-friendly. Per i geek esperti, passare dal terminale predefinito potrebbe significare anche una minore affaticamento visivo e la possibilit\u00e0 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 \u00e8 inaccettabile.<\/p>\n
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\u00e9 offrono una notevole diminuzione del ping. Sfortunatamente, non sono riuscito a misurare la latenza di Wayland: il programma Typometer, che ho utilizzato, \u00e8 stato creato per prevenire ci\u00f2 che Wayland \u00e8 progettato a proteggere: la sorveglianza su altre finestre. Spero che il compositing di Wayland sia pi\u00f9 performante di X.org e mi auguro che in futuro qualcuno trover\u00e0 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\udd47Panoramica degli emulatori di terminale | ProHoster","description":"Un paio di parole dal nostro ufficio di traduzione: di solito tutti tendono a 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.","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}]}}