Câteva cuvinte de la biroul nostru de traduceri: de obicei toată lumea se străduiește să traducă cele mai recente materiale și publicații, iar noi nu facem excepție. Dar terminalele nu sunt ceva care se actualizează o dată pe săptămână. Prin urmare, am tradus pentru voi un articol de Antoine Beaupré, publicat în primăvara lui 2018: în ciuda „vechilor” considerabile la standardele moderne, în opinia noastră, materialul nu și-a pierdut deloc relevanța. În plus, aceasta a fost inițial o serie de două articole, dar am decis să le combinăm într-o singură postare mare.
Terminalele au un loc special în istoria computerelor, dar în ultimele decenii au fost forțate să supraviețuiască alături de linia de comandă, pe măsură ce interfețele grafice devin omniprezente. le-au înlocuit pe ale lor , care, la rândul lor, au fost o modificare a sistemelor bazate pe carduri perforate și comutatoare. Distribuțiile moderne vin cu o varietate de emulatori de terminale de toate formele și culorile. Și în timp ce mulți sunt mulțumiți de terminalul standard oferit de mediul lor de lucru, unii folosesc cu mândrie software-ul de-a dreptul exotic pentru a rula shell-ul sau editorul de text preferat. Dar, așa cum vom vedea din acest articol, nu toate terminalele au fost create în aceeași imagine: diferă foarte mult în funcție de funcționalitate, dimensiune și performanță.
Unele terminale au găuri de securitate de-a dreptul surprinzătoare, plus cele mai multe au un set complet diferit de funcții, de la suport pentru o interfață cu file la scripting. Deși noi , acest articol este o actualizare a materialului anterior care va ajuta cititorii să determine ce terminal să folosească în 2018. Prima jumătate a articolului compară caracteristicile, iar a doua jumătate evaluează performanța.
Iată terminalele pe care le-am revizuit:
Este posibil să nu fie cele mai recente versiuni, deoarece eram limitat la versiuni stabile în momentul scrierii, pe care le-am putut lansa pe Debian 9 sau Fedora 27. Singura excepție este Alacritty. Este un descendent al terminalelor accelerate de GPU și este scris într-o limbă neobișnuită și nouă pentru această sarcină - Rust. Am exclus terminalele web din recenzia mea (inclusiv cele de pe ), deoarece testele preliminare au arătat performanța lor extrem de slabă.
Suport Unicode
Mi-am început testele cu suport Unicode. Primul test al terminalelor a fost afișarea șirului Unicode de la : „é, Δ, И, ק, م, ๗, あ, 叶, 葉 și 말.” Acest test simplu arată dacă terminalul poate funcționa corect în întreaga lume. Terminalul xterm nu afișează caracterul arab în configurația implicită:
Implicit, xterm folosește fontul clasic „fix”, care, conform , are „acoperire substanțială Unicode din 1997”. Se întâmplă ceva în acest font care face ca caracterul să apară ca un cadru gol și doar atunci când fontul textului este crescut la peste 20 de puncte caracterul începe în sfârșit să fie afișat corect. Cu toate acestea, această „remediere” întrerupe afișarea altor caractere Unicode:
Aceste capturi de ecran au fost făcute în Fedora 27, deoarece a dat rezultate mai bune decât Debian 9, unde unele versiuni mai vechi de terminale (în special mlterm) nu puteau gestiona fonturile corect. Din fericire, acest lucru a fost rezolvat în versiunile ulterioare.
Acum observați cum este afișată linia în xterm. Se dovedește că simbolul Mem și următorul semitic consultați scripturile în stil RTL (), așa că din punct de vedere tehnic ar trebui să fie afișate de la dreapta la stânga. Browserele web precum Firefox 57 gestionează corect linia de mai sus. O versiune mai simplă a textului RTL este cuvântul „" în ebraică (). spune urmatoarele:
„Multe programe de calculator nu pot afișa corect textul bidirecțional. De exemplu, numele ebraic „Sarah” constă din caracterele sin (ש) (care apare în dreapta), apoi resh (ר) și în final he (ה) (care ar trebui să apară în stânga)."
Multe terminale nu reușesc acest test: terminalele Alacritty, Gnome și XFCE derivate din VTE, urxvt, st și xterm afișează „Sara” în ordine inversă, de parcă am fi scris numele ca „Aras”.
O altă problemă cu textele bidirecționale este că acestea trebuie aliniate cumva, mai ales când vine vorba de amestecarea textelor RTL și LTR. Scripturile RTL ar trebui să ruleze din partea dreaptă a ferestrei terminalului, dar ce ar trebui să se întâmple cu terminalele care implicit la LTR engleză? Majoritatea nu au mecanisme speciale și aliniază tot textul la stânga (inclusiv în Konsole). Excepțiile sunt pterm și mlterm, care aderă la standarde și aliniază la dreapta astfel de linii.
Protecție la inserție
Următoarea caracteristică critică pe care am identificat-o este protecția anti-inserție. Deși este larg cunoscut faptul că se vorbește ca:
$ curl http://example.com/ | shsunt comenzi push de execuție a codului, puțini oameni știu că comenzile ascunse se pot strecura în consolă atunci când copiați și lipiți dintr-un browser web, chiar și după o inspecție atentă. arată în mod strălucit cât de inofensiv este comanda:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitse transformă într-o astfel de pacoste atunci când este lipit de pe site-ul lui Horn în terminal:
git clone /dev/null;
clear;
echo -n "Hello ";
whoami|tr -d 'n';
echo -e '!nThat was a bad idea. Don'"'"'t copy code from websites you don'"'"'t trust!
Here'"'"'s the first line of your /etc/passwd: ';
head -n1 /etc/passwd
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitCum functioneaza? Codul rău intenționat este inclus în bloc , care este mutat din vizualizarea utilizatorului folosind CSS.
este în mod clar conceput pentru a neutraliza astfel de atacuri. În acest mod, terminalele includ textul lipit într-o pereche de secvențe speciale de evadare pentru a spune shell-ului despre originea textului. Aceasta îi spune shell-ului că poate ignora caracterele speciale pe care le poate conține textul lipit. Toate terminalele înapoi la venerabilul xterm acceptă această caracteristică, dar lipirea în modul Bracketed necesită suport din partea shell-ului sau a aplicației care rulează pe terminal. De exemplu, utilizarea software-ului (același Bash), are nevoie de un fișier ~/.inputrc:
set enable-bracketed-paste onDin păcate, site-ul de testare al lui Horn arată, de asemenea, cum să ocoliți această protecție prin formatarea textului în sine și să ajungeți prematur să-i aplice modul Bracketed. Acest lucru funcționează deoarece unele terminale nu filtrează corect secvențele de evadare înainte de a le adăuga pe ale lor. De exemplu, în al meu nu am reușit niciodată să finalizez cu succes testele Konsole chiar și cu configurația corectă .inputrc fişier. Aceasta înseamnă că vă puteți deteriora cu ușurință configurația sistemului din cauza unei aplicații neacceptate sau a unui shell configurat incorect. Acest lucru este deosebit de periculos atunci când vă conectați la servere la distanță, unde munca de configurare atentă este mai puțin obișnuită, mai ales dacă aveți multe astfel de mașini la distanță.
O soluție bună la această problemă este pluginul de confirmare a lipirii pentru terminal urxvt, care cere pur și simplu permisiunea de a introduce orice text care conține linii noi. Nu am găsit o opțiune mai sigură pentru atacul text descris de Horn.
File și profile
O caracteristică populară în acest moment este suportul pentru o interfață cu file, pe care o vom defini ca o fereastră de terminal care conține mai multe alte terminale. Această funcție diferă pentru diferite terminale și, deși terminalele tradiționale xterm nu acceptă deloc file, încarnările terminale mai moderne, cum ar fi Xfce Terminal, GNOME Terminal și Konsole, au această funcție. Urxvt acceptă și file, dar numai dacă utilizați un plugin. Dar în ceea ce privește suportul pentru file în sine, Terminator este liderul incontestabil: nu numai că acceptă file, dar poate și aranja terminale în orice ordine (vezi imaginea de mai jos).
O altă caracteristică a Terminator este capacitatea de a „grupa” aceste file împreună și de a trimite aceleași apăsări de taste către mai multe terminale în același timp, oferind un instrument brut pentru a efectua operațiuni în bloc pe mai multe servere simultan. O caracteristică similară este implementată și în Konsole. Pentru a utiliza această caracteristică în alte terminale, trebuie să utilizați software terță parte, cum ar fi , sau .
Filele funcționează mai ales bine atunci când sunt asociate cu profiluri: de exemplu, puteți avea o filă pentru e-mail, alta pentru chat și așa mai departe. Acest lucru este bine susținut de Terminalul Konsole și Terminalul GNOME. Ambele permit fiecărei file să lanseze automat propriul profil. Terminator acceptă și profiluri, dar nu am putut găsi o modalitate de a lansa automat anumite programe atunci când deschideți o anumită filă. Alte terminale nu au deloc conceptul de „profil”.
Volane
Ultimul lucru pe care îl voi aborda în prima parte a acestui articol este aspectul terminalelor. De exemplu, GNOME, Xfce și urxvt acceptă transparența, dar recent au renunțat la suportul pentru imaginile de fundal, forțând unii utilizatori să treacă la terminal . Personal, sunt multumit de el si este simplu Xresurse, care stabilește setul de bază de culori de fundal pentru urxvt. Cu toate acestea, temele de culoare non-standard pot crea și probleme. De exemplu, cu aplicatii и , deoarece își folosesc deja propriile culori.
nu acceptau culori, iar cele noi erau adesea limitate la o paletă de 256 de culori. Pentru utilizatorii avansați care își modelează terminalele, prompturile shell sau barele de stare în moduri complexe pot fi o limitare enervantă. urmărește care terminale au suport „True Color”. Testele mele confirmă că terminalele st, Alacritty și VTE acceptă perfect True Color. Alte terminale nu se descurcă prea bine în acest sens și, de fapt, nici măcar nu afișează 256 de culori. Mai jos puteți vedea diferența dintre suportul True Color în terminalele GNOME, st și xterm, care fac o treabă bună cu paleta lor de 256 de culori, și urxvt, care nu numai că eșuează testul, dar chiar arată câteva caractere intermitente în locul lor.
Unele terminale analizează, de asemenea, textul pentru modele URL pentru a face clic pe linkuri. Acest lucru se aplică tuturor terminalelor derivate din VTE, în timp ce urxvt necesită un plugin special care ar transforma adresele URL la un clic sau folosind o comandă rapidă de la tastatură. Alte terminale Am testat adrese URL afișate în alte moduri.
În cele din urmă, o nouă tendință în terminale este opționalitatea tamponului de defilare. De exemplu, st nu are tampon de defilare; se presupune că utilizatorul va folosi un multiplexor terminal precum tmux și .
Alacritty nu are, de asemenea, buffer-uri de derulare înapoi, dar sprijinul său datorită „feedback-ului extins” pe acest subiect din partea utilizatorilor. În afară de acești parveniți, fiecare terminal pe care l-am testat pe care l-am găsit acceptă derularea inversă.
subtotaluri
În a doua parte a materialului (în original acestea erau două articole diferite - cca. BANDĂ) vom compara performanța, utilizarea memoriei și latența. Dar putem observa deja că unele dintre terminalele în cauză au neajunsuri serioase. De exemplu, utilizatorii care lucrează în mod regulat cu scripturi RTL ar putea dori să ia în considerare mlterm și pterm, deoarece sunt mai buni în a gestiona sarcini similare decât alții. De asemenea, Konsole a avut rezultate bune. Utilizatorii care nu lucrează cu scripturi RTL pot alege altceva.
În ceea ce privește protecția împotriva inserției de cod rău intenționat, urxvt se remarcă prin implementarea specială a protecției împotriva acestui tip de atac, ceea ce mi se pare cu siguranță convenabil. Pentru cei care caută niște clopote și fluiere, Konsole merită o privire. În cele din urmă, este de remarcat faptul că VTE este o bază excelentă pentru terminale, care garantează suport de culoare, recunoaștere URL și așa mai departe. La prima vedere, terminalul implicit care vine cu mediul tău preferat poate îndeplini toate cerințele, dar să lăsăm această întrebare deschisă până când înțelegem performanța.
Continuăm conversația
În general, performanța terminalelor în sine poate părea o problemă exagerată, dar, după cum se dovedește, unele dintre ele prezintă o latență surprinzător de mare pentru software-ul de un tip atât de fundamental. De asemenea, în continuare ne vom uita la ceea ce se numește în mod tradițional „viteză” (de fapt, aceasta este viteza de defilare) și consumul de memorie al terminalului (cu avertismentul că acest lucru nu este atât de critic astăzi ca acum zeci de ani).
Întârziere
După un studiu amănunțit al performanței terminalului, am ajuns la concluzia că cel mai important parametru în acest sens este latența (ping). În articolul său Pavel Fatin s-a uitat la latența diferitelor editori de text și a sugerat că terminalele în acest sens pot fi mai lente decât cele mai rapide editoare de text. Acest indiciu m-a determinat în cele din urmă să-mi fac propriile teste și să scriu acest articol.
Dar ce este latența și de ce este atât de importantă? În articolul său, Fatin a definit-o drept „întârzierea dintre apăsarea unei taste și actualizarea corespunzătoare a ecranului” și a citat , care afirmă: „Întârzierea feedback-ului vizual pe afișajul unui computer are un impact important asupra comportamentului și satisfacției dactilografului”.
Fatin explică că acest ping are consecințe mai profunde decât doar satisfacția: „tastarea devine mai lentă, apar mai multe erori și tensiunea oculară și musculară crește”. Cu alte cuvinte, o întârziere mare poate duce la greșeli de scriere și, de asemenea, la o calitate mai scăzută a codului, deoarece duce la o încărcare cognitivă suplimentară asupra creierului. Dar ceea ce este mai rău este că ping-ul „crește tensiunea oculară și musculară”, ceea ce pare să implice in viitor (Aparent, autorul înseamnă probleme cu mușchii ochilor, spatelui, brațelor și, bineînțeles, vederii - cca. BANDĂ) din cauza stresului repetitiv.
Unele dintre aceste efecte sunt cunoscute de mult timp, iar rezultatele , publicat în 1976 în jurnalul Ergonomics, spunea că o întârziere de 100 de milisecunde „deteriorează în mod semnificativ viteza de tastare”. Mai recent, a fost introdus Ghidul utilizatorului GNOME în 10 milisecunde, iar dacă mergi mai departe, atunci arată că 1 milisecundă este ideală.
Fatin și-a efectuat testele pe editori de text; a creat un instrument portabil numit , pe care l-am folosit pentru a testa ping-ul în emulatoarele de terminale. Rețineți că testul a fost efectuat în modul de simulare: în realitate, trebuie să ținem cont atât de latența de intrare (tastatură, controler USB, etc.), cât și de latența de ieșire (bufferul plăcii video, monitor). Potrivit lui Fatin, în configurațiile tipice este de aproximativ 20 ms. Dacă aveți echipament de gaming, puteți obține această cifră în doar 3 milisecunde. Deoarece avem deja un hardware atât de rapid, aplicația nu trebuie să-și adauge propria latență. Scopul lui Fatin este de a aduce latența aplicației la 1 milisecundă sau chiar de a realiza apelarea fără ca în .
Iată rezultatele măsurătorilor mele, precum și unele dintre rezultatele lui Fatin, pentru a arăta că experimentul meu este de acord cu testele sale:
Primul lucru care m-a frapat a fost timpul de răspuns mai bun al programelor mai vechi precum xterm și mlterm. Cu cea mai proastă latență a registrului (2,4 ms), au funcționat mai bine 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 reușește să îndeplinească afirmația „cel mai rapid emulator de terminal disponibil”, deși scorurile sale s-au îmbunătățit de la prima sa revizuire din 2017. Într-adevăr, autorii proiectului și lucrează la îmbunătățirea afișajului. De asemenea, trebuie remarcat faptul că Vim folosind GTK3 este cu un ordin de mărime mai lent decât omologul său GTK2. Din aceasta putem concluziona că GTK3 creează o latență suplimentară, iar acest lucru se reflectă în toate celelalte terminale care îl folosesc (Terminator, Xfce4 Terminal și GNOME Terminal).
Cu toate acestea, diferențele pot să nu fie vizibile pentru ochi. După cum explică Fatin, „nu trebuie să fii conștient de întârziere pentru ca aceasta să aibă un efect asupra ta”. Fatin avertizează, de asemenea, despre abaterea standard: „orice perturbări ale latenței (jitter) creează stres suplimentar din cauza impredictibilității lor”.
Graficul de mai sus este luat pe Debian 9 pur (stretch) cu . Acest mediu produce cele mai bune rezultate la testele de latență. După cum se dovedește, GNOME creează un ping suplimentar de 20 ms pentru toate măsurătorile. O posibilă explicație pentru aceasta este prezența programelor cu procesare sincronă a evenimentelor de intrare. Fatin dă un exemplu pentru un astfel de caz , care adaugă o întârziere prin procesarea sincronă a tuturor evenimentelor de intrare. Implicit, GNOME vine și cu un manager de ferestre , care creează un strat suplimentar de buffering, care afectează ping-ul și adaugă cel puțin 8 milisecunde de latență.
Viteza de defilare
Următorul test este un test tradițional de „viteză” sau „lățime de bandă”, care măsoară cât de repede terminalul poate derula o pagină în timp ce afișează cantități mari de text pe ecran. Mecanica testului variază; testul inițial a fost să genereze pur și simplu același șir de text folosind comanda seq. Alte teste includ testul lui Thomas E. Dickey (menținătorul xterm), care în mod repetat . Într-o altă revizuire a performanței terminalului folosește un șir codificat în bază32 de octeți aleatori, care este scos la terminal folosind cat. Luu consideră că un astfel de test este „un punct de referință atât de inutil pe cât se poate imagina” și sugerează utilizarea răspunsului terminalului ca măsură principală. De asemenea, Dickey numește testul său înșelător. Cu toate acestea, ambii autori recunosc că lățimea de bandă a ferestrei terminalului poate fi o problemă. Luu a descoperit că Emacs Eshell se blochează atunci când afișează fișiere mari, iar Dickey a optimizat terminalul pentru a scăpa de lentul vizual al xtrerm. Deci, există încă un merit pentru acest test, dar deoarece procesul de randare este foarte diferit de la terminal la terminal, poate fi folosit și ca componentă de testare pentru a testa alți parametri.
Aici vedem rxvt și st trag înaintea concurenței, urmate de mult mai nou Alacritty, care este conceput cu accent pe performanță. Urmează Xfce (familia VTE) și Konsole, care sunt aproape de două ori mai rapide. Ultimul este xterm, care este de cinci ori mai lent decât rxvt. În timpul testului, xterm s-a ondulat foarte mult, făcând trecerea textului dificil de văzut, chiar dacă era aceeași linie. Konsole a fost rapid, dar a fost dificil uneori: afișajul se bloca din când în când, afișând text parțial sau nu îl afișa deloc. Alte terminale au afișat clar șiruri de caractere, inclusiv st, Alacritty și rxvt.
Dickey explică faptul că diferențele de performanță se datorează designului bufferelor de defilare în diferite terminale. În special, el acuză rxvt și alte terminale că „nu respectă regulile generale”:
„Spre deosebire de xterm, rxvt nu a încercat să afișeze toate actualizările. Dacă rămâne în urmă, va refuza unele actualizări pentru a ajunge din urmă. Acest lucru a avut un impact mai mare asupra vitezei aparente de defilare decât asupra organizării memoriei interne. Un dezavantaj a fost că animația ASCII era oarecum imprecisă.”
Pentru a remedia această încetinire percepută a xterm, Dickey sugerează utilizarea resursei , permițând xterm să renunțe la unele actualizări de ecran pentru a ține pasul cu fluxul. Testele mele confirmă că fastScroll îmbunătățește performanța și aduce xterm la egalitate cu rxvt. Aceasta este, totuși, o cârjă destul de dură, așa cum explică însuși Dickey: „uneori, xterm - ca și konsole - pare să se blocheze în timp ce așteaptă un nou set de actualizări de ecran după ce unele au fost eliminate". În acest sens, se pare că alte terminale au găsit cel mai bun compromis între viteză și integritatea afișajului.
Consumul de resurse
Indiferent dacă are sens să luăm în considerare viteza de derulare ca măsură de performanță, acest test ne permite să simulăm sarcina pe terminale, ceea ce, la rândul său, ne permite să măsurăm alți parametri, cum ar fi utilizarea memoriei sau a discului. Valorile au fost obținute prin rularea testului specificat urm sub monitorizarea procesului Python. El a colectat datele contorului pentru ru_maxrss, Cantitate ru_oublock и ru_inblock și un simplu cronometru.
Î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 designului este simplitatea. mlterm, xterm și rxvt consumă puțin mai mult - aproximativ 12 MB. Un alt rezultat notabil este Alacritty, care necesită 30 MB pentru a rula. Apoi există terminale din familia VTE cu cifre de la 40 la 60 MB, ceea ce este destul de mult. Acest consum poate fi explicat prin faptul că aceste terminale folosesc biblioteci de nivel superior, de exemplu, GTK. Konsole vine pe ultimul loc cu un consum uriaș de 65 MB de memorie în timpul testelor, deși acest lucru poate fi justificat prin gama sa foarte largă de caracteristici.
În comparație cu rezultatele anterioare obținute în urmă cu zece ani, toate programele au început să consume mult mai multă memorie. Xterm avea nevoie de 4 MB, dar acum necesită 15 MB doar la pornire. Există o creștere similară a consumului pentru rxvt, care necesită acum 16 MB din cutie. Terminalul Xfce ocupă 34 MB, ceea ce este de trei ori mai mare decât înainte, dar Terminalul GNOME necesită doar 20 MB. Desigur, toate testele anterioare au fost efectuate pe arhitectura pe 32 de biți. La LCA 2012 Rusty Russell , că există multe motive mai subtile care ar putea explica creșterea consumului de memorie. Acestea fiind spuse, acum trăim într-o perioadă în care avem gigaocteți de memorie, așa că ne vom descurca cumva.
Cu toate acestea, nu pot să nu simt că alocarea mai multă memorie pentru ceva la fel de fundamental precum terminalul este o risipă de resurse. Aceste programe ar trebui să fie cele mai mici dintre cele mai mici, ar trebui să poată rula pe orice „cutie”, chiar și pe o cutie de pantofi, dacă ajungem vreodată în punctul în care trebuie să fie echipate cu sisteme Linux (și știi că așa va fi ). Dar, cu aceste numere, utilizarea memoriei va deveni o problemă în viitor în orice mediu care rulează mai multe terminale, altele decât câteva dintre cele mai ușoare și mai limitate ca capabilități. Pentru a compensa acest lucru, GNOME Terminal, Konsole, urxvt, Terminator și Xfce Terminal au un mod Daemon care vă permite să controlați mai multe terminale printr-un singur proces, limitându-le consumul de memorie.
În timpul testelor mele, am ajuns la un alt rezultat neașteptat în ceea ce privește citirea-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. Deci, biblioteca VTE păstrează de fapt un tampon de defilare pe disc (această caracteristică , iar asta se mai întâmplă). Dar, spre deosebire de implementările mai vechi, acum cel puțin aceste date sunt criptate folosind AES256 GCM (). Dar apare o întrebare rezonabilă: ce este atât de special la biblioteca VTE încât necesită o abordare atât de nestandardă a implementării...
Concluzie
În prima parte a articolului, am constatat că terminalele bazate pe VTE au un set bun de caracteristici, dar acum vedem că acest lucru vine cu unele costuri de performanță. Acum memoria nu este o problemă, deoarece toate terminalele VTE pot fi controlate printr-un proces Daemon, care le limitează apetitul. Cu toate acestea, sistemele mai vechi care au limitări fizice în ceea ce privește cantitatea de memorie RAM și buffer-uri de kernel pot avea nevoie în continuare de versiuni anterioare de terminale, deoarece consumă mult mai puține resurse. Deși terminalele VTE au avut rezultate bune la testele de derulare (defilare), latența lor de afișare este peste pragul stabilit în Ghidul utilizatorului GNOME. Dezvoltatorii VTE ar trebui probabil să țină cont de acest lucru. Dacă luăm în considerare faptul că, chiar și pentru utilizatorii Linux începători, întâlnirea cu un terminal este inevitabil, ei îl pot face mai ușor de utilizat. Pentru tociștii cu experiență, trecerea de la terminalul implicit poate însemna chiar mai puțin oboseala ochilor și capacitatea de a evita rănile și bolile viitoare legate de muncă din cauza sesiunilor lungi de lucru. Din păcate, doar vechile xterm și mlterm ne aduc la pragul magic ping de 10 milisecunde, ceea ce este inacceptabil pentru mulți.
Măsurătorile de referință au arătat, de asemenea, că, datorită dezvoltării mediilor grafice Linux, dezvoltatorii au fost nevoiți să facă o serie de compromisuri. Unii utilizatori ar putea dori să se uite la managerii obișnuiți de ferestre, deoarece oferă o reducere semnificativă a ping-ului. Din păcate, nu a fost posibilă măsurarea latenței pentru Wayland: programul Typometer pe care l-am folosit a fost creat pentru ceea ce Wayland a fost conceput pentru a preveni: spionarea altor ferestre. Sper că Wayland compositing are performanțe mai bune decât X.org și, de asemenea, sper că în viitor cineva va găsi o modalitate de a măsura latența în acest mediu.
Sursa: www.habr.com