Par riječi iz naše prevodilačke agencije: obično svi teže prevesti najnovije materijale i objave, i mi nismo iznimka. Međutim, terminali nisu nešto što se ažurira svaka dva tjedna. Stoga smo za vas preveli članak Antoinea Boprea, objavljen u proljeće 2018. godine: unatoč solidnoj 'starosti' prema današnjim mjerilima, smatramo da materijal nije izgubio na relevantnosti. Osim toga, izvorno se radi o seriji od dva članka, no odlučili smo ih spojiti u jedan veliki post.
Terminali zauzimaju posebno mjesto u povijesti računalstva, ali su u posljednjim desetljećima bili 'prisiljeni' doslovno preživjeti uz naredbeni redak usred sveprisutnih grafičkih sučelja. zamijenili su hardverske kolege
, koji su, s druge strane, bili modifikacije sustava na perforiranim karticama i prekidačima. Moderni distribucije dolaze s mnoštvom emulatora terminala svih oblika i boja. Dok mnogi mirno koriste standardni terminal koji pruža njihovo radno okruženje, neki s ponosom koriste otvoreno egzotičan softver za pokretanje svoje omiljene ljuske ili uređivača teksta. No, kako ćemo vidjeti iz ovog članka, nisu svi terminali stvoreni jednaki: značajno se razlikuju po funkcionalnosti, veličini i performansama. razmatrali emulatore terminala u davnoj prošlosti
, ovaj članak predstavlja ažuriranje prethodnog materijala, koje će pomoći čitateljima da odaberu koji terminal koristiti u 2018. godini. U prvoj polovici članka uspoređuju se funkcije, a u drugoj se ocjenjuju performanse.
Možda ovo nisu najnovije verzije, budući da sam se oslanjao na stabilne verzije u trenutku pisanja, koje sam mogao instalirati na Debian 9 ili Fedora 27. Jedino isključenje je Alacritty. On je potomak terminala s GPU ubrzanjem i napisan je na neobičnom i novom jeziku za ovu svrhu — Rust. Isključio sam iz svog pregleda web terminale (uključujući i na ), budući da su preliminarni testovi pokazali njihovu izuzetno nisku izvedbu.
Podrška za unicode
Svoje testove sam započeo s podrškom za unicode. Prvi test terminala bio je prikazivanje Unicode stringa iz : «é, Δ, Й, ק, م, ๗, あ, 叶, 葉 и 말». Ovaj jednostavni test pokazuje može li terminal ispravno raditi s globalnim znakovima. Terminal xterm ne prikazuje arapski znak u zadnjem konfiguraciji:
Prema zadanim postavkama xterm koristi klasični „fiksni” font, koji, prema , ima „značajno pokrivanje unicode-a od 1997. godine”. U ovom fontu se događa nešto što uzrokuje da znak bude prikazan kao prazan okvir i tek pri povećanju fonta teksta na 20+ točaka znak konačno počinje ispravno prikazivati. Međutim, takvo „popravak” uništava prikaz drugih unicode znakova:
Ove snimke zaslona su napravljene na Fedora 27, jer je ona davala najbolje rezultate, za razliku od Debiana 9, gdje neki stari terminali (konkretno — mlterm) nisu mogli ispravno raditi s fontovima. Na sreću, to je ispravljeno u novijim verzijama.
Sada obratite pažnju na prikaz stringa u xterm. Ispostavlja se da znak Mem i onaj koji slijedi Semitic pripadaju skriptama za desno na lijevo (), pa bi ih tehnički trebalo prikazati s desna na lijevo. Web preglednici, poput Firefox 57, ispravno obrađuju navedeni string. Jednostavniji primjer RTL teksta je riječ «» na hebrejskom (). kaže sljedeće:
«Mnoge računalne programe ne mogu ispravno prikazati dvosmjerni tekst. Na primjer, hebrejsko ime „Sara” sastoji se od znakova sin (ש) (koji se pojavljuje s desne strane), zatim reš (ר) i konačno he (ה) (koji bi trebao biti s lijeve strane)».
Mnogi terminali ne prolaze ovu provjeru: Alacritty, VTE-derivativni terminali Gnome i XFCE, urxvt, st i xterm prikazuju "Saru" obrnutim redoslijedom, kao da smo to ime zapisali kao "Aras".
Drugi problem dvosmjernih tekstova je što ih treba nekako poravnati, osobito kada se radi o miješanju RTL i LTR tekstova. RTL skripte trebaju početi s desne strane prozora terminala, ali što bi trebalo biti s terminalima koji po zadano rade s LTR engleskim? Većina njih nema nikakve posebne mehanizme i poravnavaju sav tekst lijevo (uključujući i Konsole). Izuzetak su pterm i mlterm, koji se pridržavaju standarda i poravnavaju takve retke desno.
Zaštita od umetanja
Sljedeća kritična značajka koju sam za sebe odredio je zaštita od umetanja. Iako je široko poznato da su upute kao:
$ curl http://example.com/ | shpush komande za izvršavanje koda, malo tko zna da se skrivene naredbe mogu probiti u konzolu pri kopiranju-i-umetanju iz web preglednika, čak i nakon pažljivog pregleda. briljantno pokazuje kako bezazleno izgledajuća komanda:
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitizgleda pri umetnju sa stranice Horna u terminal ovako neugodna:
git clone /dev/null;
clear;
echo -n "Hello ";
whoami|tr -d 'n';
echo -e '!nTo je bila loša ideja. Ne kopirajte kod s web stranica kojima ne vjerujete!
Evo prve linije vašeg /etc/passwd: ';
head -n1 /etc/passwd
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitKako to funkcionira? Maliciozni kod je iznesen u blok , koji je pomaknut iz vidnog polja korisnika putem CSS-a.
jasno je namijenjen neutralizaciji sličnih napada. U ovom načinu, terminali okružuju umetnuti tekst parom posebnih escape sekvenci kako bi obavijestili ljusku o podrijetlu tog teksta. Tako ljuska dobiva signal da može ignorirati posebne simbole koje može sadržavati umetnuti tekst. Svi terminali, čak i cijenjeni xterm, podržavaju ovu funkciju, ali umetanje u Bracketed modu treba podršku ljuske ili aplikacije pokrenute na terminalu. Na primjer, softver koji koristi (isto Bash), treba datoteku ~/.inputrc:
set enable-bracketed-paste onNažalost, testna stranica Horna također pokazuje kako zaobići ovu zaštitu putem samog formatiranja teksta i prerano prekinuti primjenu Bracketed moda. To funkcioniše jer neki terminali pogrešno filtriraju escape sekvence prije nego što dodaju svoje. Na primjer, u mojim pokušajima nisam uspio uspješno završiti testove Konsole čak ni uz pravilnu konfiguraciju. .inputrc datoteke. To znači da lako možete dobiti oštećenja konfiguracije sistema zbog nepodržane aplikacije ili pogrešno podešenog shell-a. Ovo je posebno opasno prilikom ulaska na udaljene servere, gdje se pažljivo obrađivanje konfiguracije susreću rjeđe, pogotovo ako imate više takvih udaljenih mašina.
Dobar način za rešenje ovog problema je dodatak za potvrdu umetanja za terminal urxvt, koji jednostavno traži dozvolu za umetanje bilo kog teksta koji sadrži nove redove. Nije pronađena sigurnija opcija za opisani Horna napad tekstom.
Kartice i profili
Popularna funkcija danas je podrška za sučelje s karticama, koje ćemo definirati kao jedno terminalno prozori koje sadrži nekoliko terminala. Za različite terminale ova funkcija se razlikuje, i iako tradicionalni terminali poput xterm uopće ne podržavaju kartice, modernije inkarnacije terminala poput Xfce Terminal, GNOME Terminal i Konsole imaju ovu funkciju. Također, podrška za kartice postoji i u Urxvt-u, ali samo uz uslov korišćenja dodatka. Međutim, što se tiče podrške za kartice kao takve, neosporni lider je Terminator: ne samo da podržava kartice, već također može raspoređivati terminale u proizvoljnom redu (vidi sliku ispod).
Još jedna osobina Terminatora je mogućnost 'grupisanja' tih kartica zajedno i slanja istih pritisaka tastera na nekoliko terminala istovremeno, što omogućava grubo sredstvo za izvođenje masovnih operacija na nekoliko servera. Slična funkcija također je implementirana u Konsole-u. Za korišćenje ove funkcije u drugim terminalima potrebno je koristiti softver treće strane, kao što je , ili .
Osobito dobro kartice rade u kombinaciji s profilima: na primjer, možete imati jednu karticu za e-poštu, drugu za chat i tako dalje. To dobro podržava terminal Konsole i GNOME Terminal. Obojica omogućuju svakoj kartici da automatski pokrene svoj profil. Terminator također podržava profile, ali nisam uspio pronaći način da automatski pokrenem određene programe prilikom otvaranja određene kartice. Druge terminale uopće nemaju pojam 'profil'.
Ružice
Posljednje što ću razmotriti u prvom dijelu ovog članka je izgled terminala. Na primjer, GNOME, Xfce i urxvt podržavaju prozirnost, ali su nedavno ukinuli podršku za pozadinske slike, što je natjeralo neke korisnike da pređu na terminal. . Osobno me zadovoljava i jednostavno Xresources, koji postavlja osnovni set boja pozadine za urxvt. Međutim, neprilagođene boje mogu stvoriti i probleme. Na primjer, s aplikacijama i , budući da već koriste vlastite boje.
nije podržavao boje, a novi su često bili ograničeni na 256-bojnu paletu. Za iskusne korisnike koji stiliziraju svoje terminale, zahtjevi ljuske ili trake stanja na neki komplicirani način mogu postati neugodno ograničenje. prati koji terminali imaju podršku za 'True Color'. Moja testiranja potvrđuju da st, Alacritty i terminali temeljeni na VTE odlično podržavaju True Color. Ostali terminali u tom pogledu nisu dobro prošli i zapravo ne prikazuju čak ni 256 boja. Ispod možete vidjeti razliku između podrške True Color u terminalima GNOME, st i xterm, koji se dobro snalaze s ovom zadatkom pomoću svoje 256-bojne palete, i urxvt, koji ne samo da ne prolazi test, već čak pokazuje i neka trepćuća obilježja umjesto njih.
Neki terminali također analiziraju tekst u potrazi za URL obrazcima kako bi učinili linkove klikabilnima. To se odnosi na sve terminale izvedene iz VTE, dok urxvt zahtijeva poseban dodatni modul koji će transformirati URL adrese jednim klikom ili uz pomoć prečaca. Ostali terminali koje sam testirao prikazuju URL adrese drugim metodama.
Napokon, novi trend terminala je opcionalna traka za pomicanje. Na primjer, u st nema trake za pomicanje; pretpostavlja se da će korisnik koristiti terminalski multiplexer, poput tmux-a i .
U Alacritty također nedostaju povratne trake za pomicanje, ali njena podrška zbog "opširnog feedbacka" na ovu temu od strane korisnika. Osim tih izuzetak, svaki terminal koji sam provjerio podržava povratno pomicanje.
Međutim, rezultati
U drugom dijelu materijala (u originalu su to bile dvije različite članke, — napomena urednika.) usporedit ćemo performanse, potrošnju memorije i kašnjenje. No već vidimo da neki od pregledanih terminala imaju ozbiljne nedostatke. Na primjer, korisnici koji redovito rade s RTL skriptama mogli bi obratiti pažnju na mlterm i pterm, jer se oni bolje snalaze s takvim zadacima. Konsole se također dobro pokazao. Korisnici koji ne rade s RTL skriptama mogu birati nešto drugo.
S gledišta zaštite od umetanja zloćudnog koda, urxvt se izdvaja zbog svoje posebne implementacije zaštite od ovog tipa napada, koja mi se čini svakako korisnom. Onima koji traže neke dodatne mogućnosti, vrijedi pogledati Konsole. Na kraju, valja napomenuti da je VTE odlična osnova za terminale koja jamči podršku za boje, prepoznavanje URL-a i tako dalje. Na prvi pogled, zadani terminal koji dolazi s vašim omiljenim okruženjem može ispuniti sve zahtjeve, ali ostavimo ovo pitanje otvorenim dok ne razjasnimo performanse.
Nastavljamo razgovor
Uopće, performanse terminala same po sebi mogu izgledati kao izmišljeni problem, međutim, kako se ispostavilo, neki od njih pokazuju iznenađujuće veliku latenciju za softver ove osnovne vrste. Također ćemo dalje razmotriti ono što se tradicionalno naziva "brzinom" (u stvari, to je brzina pomicanja) i potrošnju memorije od strane terminala (s obzirom na to da danas to nije toliko kritično kao prije desetljeća).
Kašnjenje
Nakon temeljitog istraživanja performansi terminala, došao sam do zaključka da je najvažniji parametar u ovom pogledu veličina latencije (ping). U svom članku Pavel Fatin je ispitao kašnjenje različitih tekstualnih urednika i naglasio da terminali u tom smislu mogu raditi sporije od najbržih tekstualnih urednika. Ova naznaka na kraju me dovela do pokretanja vlastitih testova i pisanja ovog članka.
Ali što je to kašnjenje i zašto je to važno? U svom članku, Fatin ga definira kao "kašnjenje između pritiska tipke i odgovarajućeg ažuriranja ekrana" i citira , u kojem se kaže: "Kašnjenje u vizualnoj povratnoj informaciji na ekranu računala ima značajan utjecaj na ponašanje otkucavača i njihovo zadovoljstvo."
Fatin objašnjava da ta latencija ima dublje posljedice od samo zadovoljstva: "pisanje postaje sporije, dolazi do više grešaka, a napetost očiju i mišića se povećava." Drugim riječima, veće kašnjenje može dovesti do tipfelera, kao i smanjenja kvalitete koda, jer povećava dodatno kognitivno opterećenje na mozak. Ali što je još gore, latencija "povećava napetost očiju i mišića", što očito sugerira u budućnosti (očito autor misli na probleme s očnim mišićima, leđima, rukama i, naravno, vidom — nap. prev.) zbog ponavljajuće napetosti.
Neki od tih učinaka poznati su već dugo, a rezultati , objavljeni još 1976. u časopisu Ergonomics, govore da kašnjenje od 100 milisekundi "značajno pogoršava brzinu otkucavanja." Nedavno je u korisničkom priručniku GNOME dodano od 10 milisekundi, a ako se ode dalje, pokazuje da je ideal 1 milisekunda.
Fatin je svoje testove provodio na tekstualnim urednicima; stvorio je portabilni alat nazvan , koji sam koristio za testiranje pinga u terminalnim emulatorima. Imajte na umu da je test proveden u simulacijskom režimu: u stvarnosti moramo uzeti u obzir i kašnjenje unosa (tipkovnica, USB kontroler itd.) i izlaza (video memorija, monitor). Prema Fatinu, u tipičnim konfiguracijama to iznosi oko 20 ms. Uz gejmersku opremu, može se postići samo 3 milisekunde. Budući da već imamo takvu brzu opremu, aplikacija ne bi trebala dodavati dodatno kašnjenje. Fatinov cilj je smanjiti kašnjenje aplikacije na 1 milisekundu, ili čak postići set bez , poput .
Evo rezultata mojih mjerenja, kao i nekih rezultata Fatina kako bih pokazao da moj eksperiment korespondira s njegovim testovima:
Prvo što me iznenadilo su bolji odzivi starih programa, kao što su xterm i mlterm. Uz najgore kašnjenje registracije (2,4 ms) pokazali su bolje rezultate od najbržeg modernog terminala (10,6 ms za st). Nijedan moderni terminal ne prelazi ispod praga od 10 milisekundi. Konkretno, Alacritty ne ispunjava zahtjeve za „najbržim postojećim emulatorom terminala“, iako su njegovi rezultati poboljšani od prvih testova 2017. godine. Uistinu, autori projekta i rade na poboljšanju prikaza. Također, potrebno je napomenuti da je Vim, koji koristi GTK3, znatno sporiji od svog analoga GTK2. Iz ovoga se može zaključiti da GTK3 stvara dodatno kašnjenje, i to se odražava na svim ostalim terminalima koji ga koriste (Terminator, Xfce4 Terminal i GNOME Terminal).
Međutim, razlike mogu biti neprimjetne oku. Kako objašnjava Fatin: "nije nužno biti svjestan prisutnosti kašnjenja da bi ono imalo učinak na vas". Fatin također upozorava na standardnu devijaciju: "bilo kakva odstupanja u duljini kašnjenja (trešnja) stvaraju dodatno opterećenje zbog svoje nepredvidivosti."
Grafikon iznad dobiven je na čistom Debianu 9 (stretch) s . Ovo okruženje daje najbolje rezultate u testovima za identifikaciju kašnjenja. Kako se ispostavilo, GNOME generira dodatni ping od 20 ms za sve mjere. Moguće objašnjenje za to je postojanje programa sa sinkroniziranom obradom ulaznih događaja. Fatin navodi takav primjer. , koji dodaje kašnjenje obrađujući sve ulazne događaje sinkronizirano. Po zadanim postavkama, GNOME je također opremljen upraviteljem prozora , koji stvara dodatni sloj međuspremnika, što utječe na ping i dodaje minimalno 8 milisekundi kašnjenja.
Brzina skrolanja
Sljedeći test je tradicionalna provjera "brzine" ili "propusnosti", koja mjeri koliko brzo terminal može skrolati stranicu, prikazujući veliku količinu teksta na ekranu. Mehanika testa varira; originalni test se sastojao u jednostavnom generiranju iste tekstualne linije pomoću naredbe seq. Ostali testovi uključuju provjeru Thomasa E. Dicka (koji prati xterm), u kojem se više puta . U još jednom pregledu performansi terminala koristi niz nasumičnih bajtova u base32 kodiranju, koja se ispisuje u terminal pomoću cat. Luu smatra ovaj test "toliko beskorisnim benchmarkom koliko možeš zamisliti" i predlaže korištenje umjesto toga odziva terminala kao glavnog pokazatelja. Dick također smatra da je njegov test obmanjujući. Ipak, obojica autori priznaju da propusnost terminalnog prozora može biti problem. Luu je otkrio zamrzavanje Emacs Eshell pri prikazivanju velikih datoteka, dok je Dick optimizirao terminal kako bi eliminirao vizualnu tromost xterm-a. Stoga, u ovom testu još uvijek postoji neki smisao, no s obzirom na to da se proces renderiranja drastično razlikuje od terminala do terminala, može se koristiti i kao testna komponenta za provjeru drugih parametara.
Ovdje vidimo da rxvt i st napreduju u odnosu na konkurente, dok slijedi Alacritty, koji je mnogo noviji i razvija se s fokusom na brzinu. Zatim dolaze Xfce (obitelj VTE) i Konsole, koji rade gotovo dvostruko brže. Posljednji je xterm, koji je pet puta sporiji od rxvt-a. Tijekom testa, xterm je također imao ozbiljnih problema s prikazom, a bilo je teško razabrati prolazni tekst, čak i kad se radilo o istoj liniji. Konsole se pokazao brzim, ali je povremeno
Diki objašnjava da su razlike u performansama povezane s dizajnom spremnika za pomicanje u različitim terminalima. Konkretno, optužuje rxvt i druge terminale da "ne poštuju opća pravila":
"Za razliku od xterm-a, rxvt nije pokušavao prikazati sve promjene. Ako zakasni, odbacit će neke promjene kako bi nadoknadio izgubljeno. To je više utjecalo na prividnu brzinu pomicanja nego na organizaciju unutarnje memorije. Jedna od mana je što je ASCII animacija bila donekle netočna.
Kako bi ispravio ovu prividnu sporost xterm-a, Diki predlaže korištenje resursa , koji omogućava xterm-u da odbaci neke ažuriranja ekrana kako ne bi kasnio za tokom. Moji testovi potvrđuju da fastScroll poboljšava performanse i izjednačava xterm s rxvt-om. Ovo je, međutim, prilično grubo rješenje, kako sam Diki objašnjava: "ponekad xterm — poput konsole — izgleda kao da se zaustavlja, čekajući novi set ažuriranja ekrana nakon što su neka od njih već uklonjena". U ovom smislu, čini se da su drugi terminali našli najbolji kompromis između brzine i cjelovitosti prikaza.
Korištenje resursa
Bez obzira na to koliko je opravdano razmatrati brzinu pomicanja kao indikativ performansi, ovaj test omogućava simulaciju opterećenja na terminalima, što zauzvrat omogućava mjerenje drugih parametara, poput korištenja memorije ili diska. Metrički podaci su dobiveni pokretanjem navedenog testa seq pod nadzorom procesa Pythona. Prikupljao je podatke o brojačima za ru_maxrss, zbroj ru_oublock i ru_inblock i jednostavni mjerač vremena.
U ovom testu ST zauzima prvo mjesto s najmanjom prosječnom potrošnjom memorije od 8 MB, što nije iznenađujuće s obzirom na to da je osnovna ideja projekta jednostavnost. Malo više troše mlterm, xterm i rxvt - oko 12 MB. Još jedan značajan rezultat ima Alacritty, čija je potreba za radom 30 MB. Zatim dolaze terminali iz obitelji VTE s pokazateljima od 40 do 60 MB, što je prilično puno. Ova potrošnja može se objasniti time što ti terminali koriste biblioteke višeg nivoa, poput GTK. Konsole završava s kolosalnom potrošnjom od 65 MB memorije tijekom testova, iako se to može opravdati njegovim vrlo širokim skupom funkcija.
U usporedbi s prethodnim rezultatima iz pre deset godina, svi programi sada troše znatno više memorije. Prije je Xterm trebao 4 MB, a sada 15 MB samo za pokretanje. Sličan porast potrošnje ima i rxvt, koji sada iz kutije zahtijeva 16 MB. Terminal Xfce zauzima 34 MB, što je tri puta više nego ranije, dok GNOME Terminal traži samo 20 MB. Naravno, svi prethodni testovi provedeni su na 32-bitnoj arhitekturi. Na LCA 2012, Rusty Russell , postoje mnogi suptilniji razlozi koji mogu objasniti rast potrošnje memorije. Uz sve to, sada živimo u vremenima kada imamo cijele gigabajte memorije, pa ćemo se nekako snaći.
Ipak, ne mogu se oteti osjećaju da je dodjeljivanje veće količine memorije za tako temeljni softver kao što je terminal - rasipanje resursa. Ovi programi trebali bi biti najmanji i najminimalniji, sposobni raditi na bilo kojoj "kutiji", čak i na cipeli, ako ikada dođemo do toga da ih treba opskrbiti Linux sustavima (a znate da hoćemo). No, s ovim brojkama, potrošnja memorije postat će problem u budućnosti u bilo kojem okruženju prilikom pokretanja više terminala, osim u situaciji s nekoliko najsitnijih i ograničenih mogućnosti. Kako bi to nadoknadili, GNOME Terminal, Konsole, urxvt, Terminator i Xfce Terminal imaju Daemon način rada, koji omogućuje upravljanje više terminala putem jednog procesa, čime se ograničava njihova potrošnja memorije.
Tijekom svojih testova došao sam do još jednog neočekivanog zaključka o diskovnom čitanju i pisanju: očekivao sam da ovdje neću vidjeti ništa, ali se ispostavilo da neki terminali na disk zapisuju najobimnije podatke. Tako, knjižnica VTE zapravo drži u memoriji diskovni spremnik za pomicanje (ova osobina , i to se događa i dalje). No, za razliku od starih implementacija, sada su, barem, ti podaci šifrirani pomoću AES256 GCM (). No, nameće se razumno pitanje, što je to posebno u knjižnici VTE, da zahtijeva takav nesvakidašnji pristup implementaciji…
Zaključak
U prvom dijelu članka otkrili smo da terminali temeljeni na VTE imaju dobar skup funkcija, ali sada vidimo da je to povezano s nekim troškovima za održavanje njihove performanse. Trenutno, memorija nije problem, jer se svi VTE terminali mogu upravljati putem Daemon procesa, koji ograničava njihov apetit. Ipak, stare sustave s fizičkim ograničenjima u pogledu broja RAM-a i predmemorije jezgre možda i dalje trebaju ranije verzije terminala, jer troše znatno manje resursa. Iako su terminali VTE dobro pokazali u testovima propusnosti (pomičenje), njihovo kašnjenje prikazivanja podataka na ekranu je iznad postavljenog praga u priručniku korisnika GNOME. Vjerojatno bi se programerima VTE trebalo uzeti to u obzir. Ako se uzme u obzir da čak i za početnike Linux korisnike susret s terminalom je neizbježan, mogli bi ga učiniti prijateljskijim prema korisniku. Za iskusne „geekove“, prelazak s terminala po defaultu može značiti čak i smanjenje opterećenja na vid i mogućnost izbjegavanja profesionalnih ozljeda i bolesti u budućnosti zbog dugotrajnih radnih sesija. Nažalost, samo stari xterm i mlterm dovode nas do čarobnog praga pinga od 10 milisekundi, što je za mnoge neprihvatljivo.
Kontrolna mjerenja su također pokazala da su se zbog razvoja grafičkih okruženja Linux programeri morali suočiti s nizom kompromisa. Neki korisnici bi trebali razmotriti korištenje klasičnih upravitelja prozora, jer oni značajno smanjuju ping. Nažalost, za Wayland nije bilo moguće izmjeriti latenciju: program Typometer, koji sam koristio, bio je dizajniran da spriječi ono što Wayland nastoji spriječiti — špijuniranje drugih prozora. Nadam se da je performansa Wayland kompozitora bolja od one X.org i također se nadam da će netko u budućnosti pronaći način za procjenu razine latencije u ovom okruženju.
Izvor: habr.com
