Câteva cuvinte de la biroul nostru de traduceri: de obicei, toată lumea își propune să traducă cele mai recente materiale și publicații, și noi nu facem excepție. Însă terminalele nu sunt ceva ce se actualizează săptămânal. De aceea, am tradus pentru voi articolul lui Antoine Beaupré, publicat în primăvara anului 2018: în ciuda „vârstei” sale considerabile din perspectiva actuală, din punctul nostru de vedere, materialul nu a pierdut deloc din relevanță. În plus, în original este o serie de două articole, dar am decis să le combinăm într-o singură postare mare.
Terminalele ocupă un loc special în istoria computerelor, însă în ultimele decenii au fost «nevoite» să supraviețuiească alături de linia de comandă în fața răspândirii tot mai mari a interfețelor grafice. au înlocuit rudele lor , care, la rândul lor, erau o modificare a sistemelor cu perforație și comutatoare. Distribuțiile moderne vin cu o mulțime de emulatoare de terminal în toate formele și culorile. Și, deși mulți se mulțumesc cu terminalul standard furnizat de mediul lor de lucru, unii folosesc cu mândrie software-ul evident exotic pentru a-și rula shell-ul preferat sau editorul de text. Dar, așa cum vom vedea din acest articol, nu toate terminalele au fost create după același model: ele diferă semnificativ între ele în funcționalitate, dimensiune și performanță.
Unele terminale au adevărate lacune de securitate, iar majoritatea au seturi de funcții complet diferite, de la suport pentru interfețe cu taburi la scripturi. Deși noi , acest articol reprezintă o actualizare a materialului anterior care va ajuta cititorii să decidă ce terminal să folosească în 2018. În prima jumătate a articolului se compară funcțiile, iar în a doua se evaluează performanța.
Iată terminalele pe care le-am examinat:
Este posibil ca acestea să nu fie cele mai recente versiuni, deoarece m-am limitat la versiuni stabile în momentul scrierii materialului, pe care am reușit să le rulez pe Debian 9 sau Fedora 27. Singura excepție este Alacritty. Este un descendent al terminalelor cu accelerare GPU și este scris într-o limbaj neobișnuit și nou pentru această sarcină — Rust. Am exclus din recenzia mea terminalele web (inclusiv și la ), deoarece testele preliminare au arătat o performanță extrem de scăzută.
Suport pentru unicode
Mi-am început testele cu suportul unicode. Primul test al terminalelor a fost afișarea unui șir de caractere unicode din : „é, Δ, Й, ק, م, ๗, あ, 叶, 葉 și 말”. Acest test simplu arată dacă terminalul poate funcționa corect în întreaga lume. Terminalul xterm nu afișează simbolul arab în configurația implicită:
Implicit, xterm folosește o font „fixă” clasică, care, conform , are „coborâre substanțială a unicode-ului din 1997”. În această font apare ceva ce face ca simbolul să fie afișat sub formă de un cadru gol și doar când dimensiunea fontului este mărită la 20 puncte sau mai mult simbolul începe în sfârșit să fie afișat corect. Cu toate acestea, acest „fix” strică afișarea altor simboluri unicode:
Aceste capturi de ecran au fost realizate în Fedora 27, deoarece aceasta a oferit cele mai bune rezultate, spre deosebire de Debian 9, unde unele versiuni vechi de terminale (în special — mlterm) nu puteau funcționa corect cu fonturile. Din fericire, aceasta a fost corectată în versiunile ulterioare.
Acum, observați afișarea șirului în xterm. Se pare că simbolul Mem și următorul său Semitic aparțin scenariilor de scriere RTL (), așa că tehnic ar trebui să fie afișate de la dreapta la stânga. Programele de navigare web, cum ar fi Firefox 57, gestionează corect șirul de mai sus. O variantă mai simplă de text RTL este cuvântul „” în ebraică (). spune următoarele:
„Multe programe de calculator nu pot afișa corect text bidirecțional. De exemplu, numele evreiesc „Sara” este format din simboluri sin (ש) (care apare la dreapta), apoi resh (ר) și, în final, he (ה) (care ar trebui să apară la stânga)”.
Multe terminale nu trec acest test: terminalele Alacritty, cele derivate VTE din Gnome și XFCE, urxvt, st și xterm afișează „Sara” în ordinea inversă, ca și cum am scrie acest nume ca „Aras”.
O altă problemă a textelor bidirecționale este că trebuie cumva aliniate, mai ales când este vorba de amestecarea textelor RTL și LTR. Scripturile RTL ar trebui să înceapă din partea dreaptă a ferestrei terminalului, dar ce ar trebui să se întâmple pentru terminalele care, în mod implicit, funcționează cu engleză LTR? Majoritatea dintre ele nu au mecanisme speciale și aliniază tot textul la stânga (inclusiv, și în Konsole). Excepțiile sunt pterm și mlterm, care respectă standardele și aliniază astfel de linii la dreapta.
Protecție împotriva inserției
Următoarea caracteristică critică pe care am identificat-o pentru mine este protecția împotriva inserției. Deși este bine cunoscut faptul că vrăjile de tip:
$ curl http://example.com/ | shsunt comenzi de execuție a codului, puțini știu că comenzile ascunse pot pătrunde în consola atunci când sunt copiate și lipite dintr-un browser web, chiar și după o inspecție atentă. arată strălucit cum o comandă care pare inofensivă:
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitse transformă, atunci când este lipită de pe site-ul lui Horne în terminal, într-o problemă neplăcută:
git clone /dev/null;
clear;
echo -n "Hello ";
whoami|tr -d 'n';
echo -e '!nA fost o idee proastă. Nu copiați cod de pe site-uri în care nu aveți încredere!
Iată prima linie din /etc/passwd: ';
head -n1 /etc/passwd
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitCum funcționează asta? Codul dăunător este scos într-un bloc <spаn>, care este mutat din câmpul vizual al utilizatorului prin mijloace CSS.
este destinat în mod special neutralizării unor astfel de atacuri. În acest mod, terminalele încadrează textul lipit într-o pereche de secvențe de escape speciale, pentru a informa shell-ul despre proveniența acestui text. Astfel, shell-ul primește semnalul că poate ignora caracterele speciale pe care le poate conține textul lipit. Toate terminalele, până la venerabilul xterm, suportă această funcție, dar lipirea în modul Bracketed necesită suport din partea shell-ului sau aplicației care rulează pe terminal. De exemplu, software-ul care folosește (același Bash), necesită un fișier ~/ .inputrc:
set enable-bracketed-paste onDin păcate, site-ul de testare Horn arată, de asemenea, cum să ocoliți această protecție prin auto-formatizarea textului și a încheia prematur aplicarea modului Bracketed. Acest lucru funcționează pentru că unele terminale filtrează incorect secvențele escape înainte de a adăuga propriile lor. De exemplu, în cazul meu, nu am reușit să finalizez cu succes testele Konsole, chiar și având în vedere configurația corectă. .inputrc fișier. Aceasta înseamnă că puteți suferi daune ale configurației sistemului din cauza unei aplicații neacceptate sau a unei consolă configurate incorect. Acest lucru este deosebit de periculos atunci când vă conectați la servere remote, unde o configurare atentă este mai rar întâlnită, mai ales dacă aveți multe dintre aceste mașini remote.
O soluție bună pentru această problemă este pluginul de confirmare a inserției pentru terminal urxvt, care pur și simplu solicită permisiunea de a insera orice text care conține noi linii. Nu am găsit o variantă mai sigură pentru atacul textului descris de Horn.
Tab-uri și profilu
O funcție populară în acest moment este suportul pentru interfața cu tab-uri, pe care o vom defini ca o fereastră de terminal care conține mai multe terminale. Pentru diferite terminale, această funcție diferă, și deși terminalele tradiționale de tip xterm nici măcar nu suportă tab-uri, incarnările moderne ale terminalului, cum ar fi Xfce Terminal, GNOME Terminal și Konsole, au această funcție. De asemenea, urxvt are suport pentru tab-uri, dar doar cu condiția utilizării unui plugin. Însă, din perspectiva suportului pentru tab-uri, Terminator este liderul incontestabil: nu numai că suportă tab-uri, dar poate de asemenea plasa terminalele într-o ordine aleatorie (vezi imaginea de mai jos).
O altă caracteristică a Terminator este posibilitatea de a „grupa” aceste tab-uri împreună și de a trimite aceleași apăsări de taste către mai multe terminale simultan, oferind un instrument simplu pentru a efectua operațiuni în masă pe mai multe servere simultan. O funcție similară este implementată și în Konsole. Pentru a folosi această funcție în alte terminale, este necesar să utilizați software terț, cum ar fi , sau .
În special, taburile funcționează bine împreună cu profilele: de exemplu, puteți avea o tab pentru e-mail, alta pentru chat și așa mai departe. Acest lucru este bine susținut de terminalul Konsole și GNOME Terminal. Ambele permit fiecărei tab să pornească automat propriul profil. Terminator suportă de asemenea profile, dar nu am reușit să găsesc o modalitate de a lansa automat anumite programe când se deschide o tab specifică. Alte terminale nu au deloc noțiunea de „profil”.
Volan
Ultimul lucru pe care îl voi analiza în prima parte a acestui articol este aspectul terminalelor. De exemplu, GNOME, Xfce și urxvt suportă transparența, dar recent au renunțat la suportul pentru imagini de fundal, ceea ce a determinat unii utilizatori să treacă la un terminal. . Personal, mă mulțumesc și simplu. Xresources, care stabilește setul de culori de bază pentru fundal pentru urxvt. Cu toate acestea, temele de culori personalizate pot crea și probleme. De exemplu, cu aplicațiile și , deoarece ele utilizează deja propriile sale culori.
nu suporta culori, iar cele moderne sunt adesea limitate la o paletă de 256 de culori. Pentru utilizatorii avansați, care își personalizează terminalele, cererile shell-ului sau liniile de stare în moduri complicate pot deveni o limitare neplăcută. urmărește ce terminale au suport pentru „True Color”. Testele mele confirmă că st, Alacritty și terminalele bazate pe VTE suportă excelent True Color. Alte terminale se descurcă mai puțin bine și de fapt nu afișează nici măcar 256 de culori. Mai jos puteți vedea diferența dintre suportul True Color în terminalele GNOME, st și xterm, care se descurcă destul de bine cu această sarcină folosind paleta sa de 256 de culori, și urxvt, care nu doar că nu trece testul, dar arată chiar și anumite simboluri care clipesc în locul lor.
Unele terminale analizează, de asemenea, textul pentru șabloane URL, pentru a face linkurile clicabile. Acest lucru se aplică tuturor terminalelor derivate din VTE, în timp ce urxvt necesită un modul plug-in special care să transforme adresele URL prin clic sau printr-o combinație de taste. Alte terminale pe care le-am testat afișează adresele URL în alte moduri.
În sfârșit, noul trend al terminalelor este opționalitatea bufferului de derulare. De exemplu, în st nu există buffer de derulare; se presupune că utilizatorul va folosi un multiplexor de terminal, cum ar fi tmux și .
În Alacritty, de asemenea, lipsesc buffer-ele de scroll invers, dar susținerea acestuia datorită "feedback-ului extins" pe această temă din partea utilizatorilor. În afară de aceste excepții, fiecare terminal pe care l-am verificat, pe care am reușit să-l găsesc, suportă derularea inversă.
Concluzii intermediare
În partea a doua a materialului (în original au fost două articole diferite, — nota editorului.) vom compara performanța, utilizarea memoriei și întârzierea. Dar vedem deja că unele dintre terminalele examinate au deficiențe serioase. De exemplu, utilizatorii care lucrează regulat cu scripturi RTL pot observa mlterm și pterm, deoarece acestea fac față mai bine unor astfel de sarcini. Konsole s-a dovedit de asemenea a fi performant. Utilizatorii care nu lucrează cu scripturi RTL pot alege altceva.
Din punct de vedere al protecției împotriva inserției de coduri dăunătoare, urxvt se distinge datorită implementării sale speciale de protecție împotriva acestui tip de atacuri, pe care o consider în mod cert convenabilă. Cei care caută diverse funcții avansate ar trebui să se uite la Konsole. În cele din urmă, merită menționat că VTE este o bază excelentă pentru terminale, care garantează suport pentru culori, recunoașterea URL-urilor și așa mai departe. La prima vedere, terminalul implicit livrat cu mediul tău preferat ar putea să îndeplinească toate cerințele, dar să lăsăm această întrebare deschisă până când ne ocupăm de performanță.
Continuăm discuția
În general, performanța terminalelor poate părea o problemă exagerată, totuși, așa cum s-a dovedit, unele dintre ele demonstrează o întârziere surprinzător de mare pentru un software de un asemenea tip fundamental. De asemenea, nu vom analiza ceea ce se numește în mod tradițional „viteză” (de fapt, este vorba despre viteza de derulare) și consumul de memorie al terminalului (având în vedere că astăzi acest lucru nu mai este atât de critic ca în trecut).
Întârziere
După o cercetare amănunțită a performanței terminalelor, am ajuns la concluzia că cel mai important parametru în acest sens este dimensiunea întârzierei (ping-ului). În articolul meu Pavel Fatin a analizat întârzierile diverselor editoare de text și a sugerat că terminalele pot funcționa, în acest caz, mai lent decât cele mai rapide editoare de text. Această sugestie m-a condus, în cele din urmă, să lansez propriile teste și să scriu acest articol.
Dar ce este o întârziere și de ce este atât de importantă? În articolul său, Fatin a definit-o ca „întârzierea dintre apăsarea unei taste și actualizarea corespunzătoare a ecranului” și a citat , în care se spune: „Întârzierea în feedback-ul vizual pe ecranul computerului are un impact semnificativ asupra comportamentului operatorului și satisfacției sale”.
Fatin explică faptul că un astfel de ping are consecințe mai profunde decât simpla satisfacție: „tastarea devine mai lentă, se produc mai multe erori, iar tensiunea oculară și musculară crește”. Cu alte cuvinte, o întârziere mai mare poate duce la greșeli de tipar și la o calitate mai scăzută a codului, deoarece generează o sarcină cognitivă suplimentară pentru creier. Dar, mai grav, ping-ul „crește tensiunea oculară și musculară”, ceea ce sugerează, evident, în viitor (aparent, autorul se referă la problemele cu mușchii oculari, spatele, mâinile și, bineînțeles, vederea - n.r.) din cauza tensiunii repetitive.
Unele dintre aceste efecte sunt cunoscute de mult timp, iar rezultatele , publicate încă din 1976 în revista Ergonomics, arată că o întârziere de 100 de milisecunde „împiedică semnificativ viteza de tastare”. Recent, a fost introdus în ghidul utilizatorului GNOME de 10 milisecunde și, dacă mergem mai departe, arată că idealul este de 1 milisecundă.
Fatin și-a desfășurat testele pe editoare de text; el a creat un instrument portabil numit , pe care l-am folosit pentru a verifica pingul în emulatorul de terminale. Rețineți că testul a fost efectuat în modul de simulare: în realitate, trebuie să luăm în considerare și întârzierea de intrare (tastatură, controler USB etc.) și de ieșire (bufferul plăcii video, monitor). Conform lui Fatin, în configurații tipice, aceasta este de aproximativ 20 ms. Cu echipamente de gaming, se poate ajunge la un indicator de doar 3 milisecunde. Având deja astfel de echipamente rapide, aplicația nu ar trebui să introducă și ea o întârziere. Scopul lui Fatin este să reducă întârzierea aplicației la 1 milisecundă sau chiar să ajungă la un set fără , ca în .
Iată rezultatele măsurătorilor mele, precum și unele rezultate ale lui Fatin pentru a arăta că experimentul meu este în concordanță cu testele sale:
Primul lucru care m-a surprins a fost timpul de răspuns mai bun al programelor mai vechi, cum ar fi xterm și mlterm. Cu o întârziere de înregistrare mai mare (2,4 ms), acestea au arătat rezultate mai bune decât cel mai rapid terminal modern (10,6 ms pentru st). Niciun terminal modern nu scade sub pragul de 10 milisecunde. În special, Alacritty nu corespunde cerințelor de „cel mai rapid dintre emulatorii de terminal care există”, deși rezultatele sale s-au îmbunătățit de la prima verificare din 2017. De fapt, autorii proiectului și lucrează la îmbunătățirea afișării. De asemenea, este important de menționat că Vim, care folosește GTK3, este cu mult mai lent decât omologul său GTK2. Din aceasta se poate concluziona că GTK3 introduce o întârziere suplimentară, iar acest lucru se reflectă asupra tuturor celorlalte terminale care îl utilizează (Terminator, Xfce4 Terminal și GNOME Terminal).
Totuși, pentru ochi, diferențele pot fi neobservabile. Așa cum explică Fatin: „nu este necesar să conștientizezi prezența unei întârziere pentru ca aceasta să aibă un efect asupra ta”. Fatin de asemenea avertizează asupra abaterii standard: „orice variații în durata întârzierii (tremur) creează o sarcină suplimentară din cauza imprevizibilității lor”.
Graficul de mai sus a fost obținut pe un sistem Debian 9 (stretch) curat, cu . Această mediu oferă cele mai bune rezultate în teste de latență. Se pare că GNOME introduce un ping suplimentar de 20 ms pentru toate măsurătorile. O explicație posibilă pentru acest lucru este existența programelor care procesează sincronizat evenimentele de intrare. Fatin dă ca exemplu în acest caz , care adaugă întârziere procesând toate evenimentele de intrare sincronizat. Implicit, GNOME este dotat de asemenea cu un manager de feronerie , care creează un nivel suplimentar de buffering, ceea ce influențează ping-ul și adaugă un minim de 8 milisecunde întârziere.
Viteza de derulare
Următorul test este o verificare tradițională a „vitezei” sau a „lățimii de bandă”, care măsoară cât de repede terminalul poate derula pagina, afișând o cantitate mare de text pe ecran. Mecânica testului variază; testul original consta în generarea aceleași linii de text folosind comanda seq. Alte teste includ verificarea lui Thomas E. Dick (asociat cu xterm), în cadrul căruia se descarcă repetat . Într-o altă revizuire a performanței terminalelor folosește o linie de byte aleatorii în codificarea base32, care este afișată în terminal folosind cat. Luu consideră că un astfel de test este „atât de inutil pe cât se poate imagina” și propune utilizarea în schimb a răspunsului terminalului ca principal indicator. Dick de asemenea numește testul său înșelător. Totuși, ambii autori recunosc că lățimea de bandă a feronerie terminalului poate fi o problemă. Luu a descoperit că Emacs Eshell se blochează la afișarea fișierelor mari, iar Dick a optimizat terminalul pentru a elimina lentorile vizuale din xterm. Prin urmare, în acest test există încă un anumit sens, dar deoarece procesul de redare variază semnificativ de la un terminal la altul, poate fi folosit și ca un component de testare pentru verificarea altor parametri.
Aici putem observa că rxvt și st își iau avans față de concurenți, urmat de mult mai noul Alacritty, dezvoltat cu accent pe performanță. Apoi urmează Xfce (familia VTE) și Konsole, care funcționează aproape de două ori mai repede. Ultimul este xterm cu un indice de cinci ori mai lent decât rxvt. În timpul testului, xterm a avut, de asemenea, un tremur puternic, textul care trecea fiind greu de distins, chiar dacă era aceeași linie. Konsole s-a dovedit rapid, dar a avut momente de „șmecherie”: display-ul se bloca din când în când, arătând textul parțial sau nereprezentându-l deloc. Alte terminale au afișat liniile clar, inclusiv st, Alacritty și rxvt.
Diki explică că diferențele de performanță sunt legate de designul bufetelor de derulare din diferitele terminale. În special, el acuză rxvt și alte terminale că „nu respectă reguli generale”:
„Spre deosebire de xterm, rxvt nu a încercat să afișeze toate actualizările. Dacă rămâne în urmă, el va renunța la unele actualizări pentru a recupera întârzierile. Acest lucru a avut un impact mai mare asupra vitezei percepute de derulare decât asupra organizării memoriei interne. Un dezavantaj a fost că animația ASCII a fost oarecum inexactă.”
Pentru a corecta această aparentă lentitudine a xterm, Diki sugerează utilizarea resursei , permițând xterm să elimine unele actualizări ale ecranului pentru a nu rămâne în urmă față de flux. Testele mele confirmă că fastScroll îmbunătățește performanța și trage xterm pe același nivel cu rxvt. Acesta este, totuși, un workaround destul de grosier, așa cum explică Diki: „uneori xterm — la fel ca și konsole — pare să se oprească, așteptând un nou set de actualizări ale ecranului după ce unele dintre acestea au fost eliminate”. În această privință, pare că alte terminale au găsit cel mai bun compromis între viteză și integritatea display-ului.
Consumul de resurse
Indiferent de oportunitatea de a lua în considerare viteza de derulare ca un indicator de performanță, acest test permite simularea încărcărilor pe terminale, ceea ce, la rândul său, ne permite să măsurăm alte parametrii, cum ar fi utilizarea memoriei sau a discului. Metricile au fost obținute prin rularea testului specificat seq sub monitorizarea procesului Python. Acesta a colectat datele contorului pentru ru_maxrss, suma ru_oublock și ru_inblock și un temporizator simplu de timp.
În acest test, ST ocupă primul loc cu cel mai mic consum mediu de memorie, de 8 MB, ceea ce nu este surprinzător, având în vedere că ideea principală a proiectului este simplitatea. Următoarele sunt mlterm, xterm și rxvt, care consumă aproximativ 12 MB. Un rezultat notabil este Alacritty, care necesită 30 MB pentru funcționare. Apoi urmează terminalele din familia VTE, cu consumuri între 40 și 60 MB, ceea ce este destul de mult. Acest consum poate fi explicat prin faptul că aceste terminale utilizează biblioteci de nivel mai înalt, precum GTK. Konsole se află pe ultimul loc, cu un consum uriaș de 65 MB de memorie în timpul testelor, deși acest lucru poate fi justificat de gama sa foarte largă de funcționalități.
Comparativ cu rezultatele anterioare, obținute acum zece ani, toate programele au început să consume semnificativ mai multă memorie. Acum, Xterm necesită 15 MB doar pentru a porni, față de 4 MB anterior. O creștere similară a consumului se observă și la rxvt, care acum necesită din start 16 MB. Terminalul Xfce consumă 34 MB, de trei ori mai mult decât înainte, în timp ce GNOME Terminal necesită doar 20 MB. Desigur, toate testele anterioare au fost efectuate pe arhitecturi de 32 de biți. La LCA 2012, Rusty Russell , sunt multe motive subtile care pot explica creșterea consumului de memorie. Cu toate acestea, trăim acum într-o eră în care avem gigabytes întregi de memorie, așa că ne putem descurca cumva.
Cu toate acestea, nu pot scăpa de senzația că alocarea unei cantități mai mari de memorie pentru un software atât de fundamental, precum terminalul, este o risipă de resurse. Aceste programe ar trebui să fie cele mai mici dintre cele mici, având capacitatea de a funcționa pe orice "cutie", chiar și pe o cutie de pantofi, dacă vreodată va fi necesar să le dotăm cu sisteme Linux (și știți că așa va fi). Dar cu aceste cifre, utilizarea memoriei va deveni o problemă în viitor în orice mediu la deschiderea mai multor terminale, cu excepția cazurilor cu cele mai ușoare și limitate funcționalități. Pentru a compensa acest lucru, GNOME Terminal, Konsole, urxvt, Terminator și Xfce Terminal au un mod Daemon, care permite gestionarea mai multor terminale printr-un singur proces, limitând astfel consumul de memorie.
În timpul testelor mele, am ajuns la un rezultat neașteptat în ceea ce privește citirea și scrierea pe disc: mă așteptam să nu văd nimic aici, dar s-a dovedit că unele terminale scriu cele mai voluminoase date pe disc. Astfel, biblioteca VTE stochează, de fapt, un buffer de derulare pe disc (această caracteristică , și acesta se întâmplă și acum). Dar, spre deosebire de vechile implementări, acum, cel puțin, aceste date sunt criptate folosind AES256 GCM (). Însă apare o întrebare legitimă, ce este atât de special în biblioteca VTE, încât necesită o abordare atât de neconvențională în implementare…
Concluzie
În prima parte a articolului, am descoperit că terminalele bazate pe VTE au un set bun de funcții, dar acum vedem că acest lucru se leagă de anumite costuri pentru asigurarea performanței lor. În prezent, memoria nu este o problemă, deoarece toate terminalele VTE pot fi gestionate printr-un proces Daemon care le limitează apetitul. Cu toate acestea, vechile sisteme, care au constrângeri fizice privind cantitatea de memorie RAM și buffer-ul nucleei, pot avea în continuare nevoie de versiuni anterioare ale terminalelor, deoarece acestea consumă semnificativ mai puține resurse. Deși terminalele VTE s-au comportat bine în teste de lățime de bandă (derulare), întârzierea afișării datelor pe ecranul este peste limita stabilită în manualul utilizatorului GNOME. Probabil că dezvoltatorii VTE ar trebui să ia în considerare acest aspect. Având în vedere că, chiar și pentru utilizatorii începători de Linux, întâlnirea cu terminalul este inevitabilă, ei ar putea face asta mai prietenos în raport cu utilizatorul. Pentru geekii experimentați, trecerea de la terminalul implicit ar putea însemna chiar o reducere a oboselii vizuale și posibilitatea de a evita traumatismele profesionale și bolile în viitor din cauza sesiunilor de lucru prelungite. Din păcate, doar vechile xterm și mlterm ne conduc către pragul magic de ping de 10 milisecunde, ceea ce pentru mulți este inacceptabil.
Măsurătorile de control au arătat, de asemenea, că, datorită dezvoltării mediilor grafice Linux, dezvoltatorii au fost nevoiți să facă o serie de compromisuri. Unora dintre utilizatori le-ar trebui să ia în considerare gestionarii de feronerie standard, deoarece ei asigură o reducere semnificativă a ping-ului. Din păcate, pentru Wayland nu am reușit să măsor întârzierea: programul Typometer pe care l-am folosit a fost creat pentru a preveni exact ceea ce Wayland este destinat - spionajul asupra altor feronierii. Sper că compozitul Wayland va performa mai bine decât X.org și, de asemenea, sper că în viitor cineva va găsi o modalitate de a evalua nivelul întârzierei în acest mediu.
Sursa: habr.com
