Nekoliko riječi iz našeg prevodilačkog biroa: obično svi nastoje prevesti najnovije materijale i publikacije, i mi nismo izuzetak. Ali terminali nisu nešto što se ažurira jednom sedmično. Stoga smo za vas preveli članak Antoinea Beaupréa, objavljen u proljeće 2018.: unatoč svojoj značajnoj „starosti“ prema modernim standardima, po našem mišljenju, materijal nije nimalo izgubio na važnosti. Osim toga, ovo je prvobitno bila serija od dva članka, ali smo ih odlučili spojiti u jedan veliki post.
Terminali imaju posebno mjesto u istoriji računara, ali su poslednjih decenija bili primorani da opstanu uz komandnu liniju jer su grafički interfejsi postali sveprisutni. zamenili svoje , koji su zauzvrat bili modifikacija sistema baziranih na bušenim karticama i prekidačima. Moderne distribucije dolaze s raznim emulatorima terminala svih oblika i boja. I dok su mnogi zadovoljni standardnim terminalom koji im pruža njihovo radno okruženje, neki s ponosom koriste potpuno egzotičan softver za pokretanje svog omiljenog shell-a ili uređivača teksta. Ali, kao što ćemo vidjeti iz ovog članka, nisu svi terminali kreirani na istoj slici: oni se uvelike razlikuju po funkcionalnosti, veličini i performansama.
Neki terminali imaju potpuno iznenađujuće sigurnosne rupe, plus većina ima potpuno drugačiji skup funkcija, od podrške za interfejs sa karticama do skriptovanja. Iako mi , ovaj članak je ažuriranje prethodnog materijala koji će čitateljima pomoći da odrede koji terminal koristiti u 2018. Prva polovina članka poredi karakteristike, a druga polovina vrednuje performanse.
Evo terminala koje sam pregledao:
Ovo možda nisu najnovije verzije, budući da sam bio ograničen na stabilne verzije u vrijeme pisanja, koje sam mogao izbaciti na Debian 9 ili Fedora 27. Jedini izuzetak je Alacritty. Potomak je GPU-ubrzanih terminala i napisan je na neobičnom i novom jeziku za ovaj zadatak - Rust. Izuzeo sam web terminale iz svog pregleda (uključujući one na ), jer su preliminarna ispitivanja pokazala njihove izuzetno loše performanse.
Unicode podrška
Počeo sam svoje testove sa podrškom za Unicode. Prvi test terminala bio je da se prikaže Unicode string iz : "é, Δ, I, ק, م, ๗, あ, 叶, 葉 i 말." Ovaj jednostavan test pokazuje da li terminal može ispravno raditi širom svijeta. xterm terminal ne prikazuje arapski karakter u zadanoj konfiguraciji:
Podrazumevano, xterm koristi klasični "fiksni" font, koji, prema , ima "značajnu pokrivenost Unicode-om od 1997. godine". Nešto se dešava u ovom fontu što uzrokuje da se znak pojavljuje kao prazan okvir i tek kada se font teksta poveća na 20+ bodova, znak konačno počinje ispravno prikazivati. Međutim, ovaj "popravak" prekida prikaz drugih Unicode znakova:
Ovi snimci ekrana su napravljeni u Fedori 27, jer je dao bolje rezultate od Debiana 9, gdje neke starije verzije terminala (posebno mlterm) nisu mogle pravilno rukovati fontovima. Srećom, ovo je popravljeno u kasnijim verzijama.
Sada primijetite kako je linija prikazana u xtermu. Ispostavilo se da je simbol Mem i sljedeći semitski pogledajte skripte u stilu RTL (), tako da tehnički treba da budu prikazani s desna na lijevo. Web pretraživači kao što je Firefox 57 ispravno obrađuju gornju liniju. Jednostavnija verzija RTL teksta je riječ "" na hebrejskom (). kaže sljedeće:
“Mnogi kompjuterski programi ne mogu ispravno prikazati dvosmjerni tekst. Na primjer, hebrejsko ime "Sarah" sastoji se od znakova sin (ש) (koji se pojavljuje na desnoj strani), zatim resh (ר) i na kraju on (ה) (koji bi se trebao pojaviti na lijevoj strani)."
Mnogi terminali nisu uspjeli na ovom testu: Alacritty, VTE-izvedeni Gnome i XFCE terminali, urxvt, st i xterm prikazuju "Sara" obrnutim redoslijedom, kao da smo ime napisali kao "Aras".
Drugi problem sa dvosmjernim tekstovima je taj što ih je potrebno nekako uskladiti, posebno kada je u pitanju miješanje RTL i LTR tekstova. RTL skripte bi trebale da se pokreću sa desne strane prozora terminala, ali šta bi trebalo da se desi sa terminalima koji podrazumevano koriste LTR engleski? Većina njih nema nikakve posebne mehanizme i poravnavaju sav tekst na lijevo (uključujući i Konsole). Izuzetak su pterm i mlterm, koji se pridržavaju standarda i poravnavaju takve linije udesno.
Zaštita od umetanja
Sledeća kritična karakteristika koju sam identifikovao je zaštita od umetanja. Iako je opšte poznato da su čarolije kao:
$ curl http://example.com/ | shsu push komande za izvršavanje koda, malo ljudi zna da skrivene komande mogu da se ušunjaju u konzolu prilikom kopiranja i lijepljenja iz web pretraživača, čak i nakon pažljivog pregleda. sjajno pokazuje koliko je komanda bezazlena:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitpretvara se u takvu smetnju kada se zalijepi sa Hornove web stranice u 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.gitKako radi? Zlonamjerni kod je uključen u blok , koji se pomiče iz korisničkog pogleda pomoću CSS-a.
jasno je dizajniran da neutrališe takve napade. U ovom modu, terminali zatvaraju zalijepljeni tekst u par posebnih izlaznih sekvenci kako bi rekli ljusci o porijeklu teksta. Ovo govori ljusci da može zanemariti posebne znakove koje zalijepljeni tekst može sadržavati. Svi terminali nazad na časni xterm podržavaju ovu funkciju, ali lijepljenje u Bracketed modu zahtijeva podršku od ljuske ili aplikacije koja se izvodi na terminalu. Na primjer, korištenje softvera (isti Bash), potreban je fajl ~/.inputrc:
set enable-bracketed-paste onNažalost, Horn-ova testna stranica također pokazuje kako zaobići ovu zaštitu kroz samo formatiranje teksta i prerano završiti primjenom načina rada u zagradama na njega. Ovo funkcionira jer neki terminali ne filtriraju ispravno izlazne sekvence prije nego što dodaju svoje. Na primjer, kod mene nikad nisam uspio uspješno završiti Konsole testove čak ni uz ispravnu konfiguraciju .inputrc fajl. To znači da možete lako oštetiti konfiguraciju sistema zbog nepodržane aplikacije ili neispravno konfigurirane ljuske. Ovo je posebno opasno kada se prijavljujete na udaljene servere, gdje je pažljiv rad na konfiguraciji manje uobičajen, posebno ako imate mnogo takvih udaljenih strojeva.
Dobro rješenje za ovaj problem je dodatak za potvrdu lijepljenja za terminal urxvt, koji jednostavno traži dozvolu da ubaci bilo koji tekst koji sadrži nove redove. Nisam pronašao sigurniju opciju za tekstualni napad koji je opisao Horn.
Kartice i profili
Popularna karakteristika sada je podrška za interfejs sa karticama, koji ćemo definisati kao jedan prozor terminala koji sadrži još nekoliko terminala. Ova funkcija se razlikuje za različite terminale, i iako tradicionalni xterm terminali uopće ne podržavaju tabove, modernije inkarnacije terminala kao što su Xfce Terminal, GNOME Terminal i Konsole imaju ovu funkciju. Urxvt također podržava kartice, ali samo ako koristite dodatak. Ali u pogledu same podrške za kartice, Terminator je neprikosnoveni lider: ne samo da podržava tabove, već može i poredati terminale bilo kojim redosledom (pogledajte sliku ispod).
Još jedna karakteristika Terminatora je mogućnost "grupisanja" ovih kartica zajedno i slanja istih pritisaka na više terminala u isto vrijeme, pružajući grubi alat za izvođenje grupnih operacija na više servera istovremeno. Slična karakteristika je takođe implementirana u Konsole. Da biste koristili ovu funkciju na drugim terminalima, morate koristiti softver treće strane kao što je , ili .
Kartice rade posebno dobro kada su uparene sa profilima: na primjer, možete imati jednu karticu za e-poštu, drugu za ćaskanje i tako dalje. Ovo je dobro podržano Konsole terminalom i GNOME terminalom. Oba omogućavaju svakoj kartici da automatski pokrene svoj profil. Terminator takođe podržava profile, ali nisam mogao pronaći način da automatski pokrenem određene programe kada se otvori određena kartica. Drugi terminali uopće nemaju koncept "profila".
Ruffles
Posljednja stvar koju ću pokriti u prvom dijelu ovog članka je izgled terminala. Na primjer, GNOME, Xfce i urxvt podržavaju transparentnost, ali su nedavno odustali od podrške za pozadinske slike, prisiljavajući neke korisnike da se prebace na terminal . Lično sam zadovoljan i jednostavan je xresources, koji postavlja osnovni skup boja pozadine za urxvt. Međutim, nestandardne teme boja također mogu stvoriti probleme. Na primjer, sa aplikacijama и , jer već koriste svoje boje.
nisu podržavale boje, a nove su često bile ograničene na paletu od 256 boja. Za napredne korisnike koji stiliziraju svoje terminale, shell upiti ili statusne trake na složene načine mogu biti neugodno ograničenje. prati koji terminali imaju podršku za "True Color". Moji testovi potvrđuju da terminali bazirani na st, Alacritty i VTE savršeno podržavaju True Color. Ostali terminali ne prolaze baš najbolje u ovom pogledu i, u stvari, ne prikazuju čak ni 256 boja. Ispod možete vidjeti razliku između podrške za True Color u GNOME terminalima, st i xterm, koji to dobro rade sa svojom paletom boja od 256 boja, i urxvt, koji ne samo da pada na testu, već čak i prikazuje neke znakove koji trepću umjesto njih.
Neki terminali također analiziraju tekst za URL obrasce kako bi linkovi mogli kliknuti. Ovo se odnosi na sve terminale izvedene iz VTE, dok urxvt zahtijeva poseban dodatak koji bi transformirao URL-ove na klik ili korištenjem prečice na tipkovnici. Ostali terminali Testirao sam URL-ove za prikaz na druge načine.
Konačno, novi trend u terminalima je opcionalnost bafera za pomicanje. Na primjer, st nema bafer za pomicanje; pretpostavlja se da će korisnik koristiti terminalni multiplekser kao što je tmux i .
Alacrittyju također nedostaju baferi za pomicanje unazad, ali svoju podršku zbog “opsežnih povratnih informacija” korisnika o ovoj temi. Osim ovih početnika, svaki terminal koji sam testirao koji sam mogao pronaći podržava obrnuto skrolovanje.
Iznosi
U drugom dijelu materijala (u originalu su to bila dva različita članka - cca. lane) uporedićemo performanse, upotrebu memorije i kašnjenje. Ali već vidimo da neki od terminala u pitanju imaju ozbiljne nedostatke. Na primjer, korisnici koji redovno rade sa RTL skriptama možda će htjeti uzeti u obzir mlterm i pterm, jer su oni bolji u rukovanju sličnim zadacima od drugih. Konsole se također dobro pokazao. Korisnici koji ne rade sa RTL skriptama mogu izabrati nešto drugo.
Što se tiče zaštite od ubacivanja zlonamjernog koda, urxvt se izdvaja po posebnoj implementaciji zaštite od ove vrste napada, što mi se čini definitivno zgodnim. Za one koji traže nešto zvona i zviždaljki, Konsole vrijedi pogledati. Na kraju, vrijedno je napomenuti da je VTE odlična baza za terminale, koja garantuje podršku bojama, prepoznavanje URL-a i tako dalje. Na prvi pogled, podrazumevani terminal koji dolazi sa vašim omiljenim okruženjem može ispuniti sve zahteve, ali ostavimo ovo pitanje otvorenim dok ne razumemo performanse.
Nastavimo razgovor
Općenito, performanse terminala same po sebi mogu izgledati kao nategnuti problem, ali kako se ispostavilo, neki od njih pokazuju iznenađujuće veliko kašnjenje za softver tako fundamentalnog tipa. Također, sljedeće ćemo pogledati ono što se tradicionalno naziva "brzina" (u stvari, ovo je brzina skrolovanja) i potrošnju memorije terminala (uz napomenu da to danas nije toliko kritično kao prije nekoliko desetljeća).
Kašnjenje
Nakon detaljnog proučavanja performansi terminala, došao sam do zaključka da je najvažniji parametar u tom pogledu latencija (ping). U svom članku Pavel Fatin je osvrnuo se na kašnjenje raznih uređivača teksta i nagovijestio da terminali u tom pogledu mogu biti sporiji od najbržih uređivača teksta. Taj nagovještaj me je na kraju naveo da pokrenem vlastite testove i napišem ovaj članak.
Ali šta je latencija i zašto je toliko važna? U svom članku, Fatin je to definirao kao "kašnjenje između pritiskanja tipke i odgovarajućeg ažuriranja ekrana" i citirao , koji kaže: „Kašnjenje vizuelne povratne informacije na ekranu računara ima važan uticaj na ponašanje i zadovoljstvo daktilografa.”
Fatin objašnjava da ovaj ping ima dublje posljedice od samog zadovoljstva: "kucanje postaje sporije, javlja se više grešaka, a napetost očiju i mišića se povećava." Drugim riječima, veliko kašnjenje može dovesti do grešaka u kucanju i niže kvalitete koda, jer dovodi do dodatnog kognitivnog opterećenja na mozgu. Ali ono što je još gore je da ping "povećava naprezanje očiju i mišića", što izgleda implicira u budućnosti (Očigledno, autor misli na probleme s mišićima očiju, leđa, ruku i, naravno, vidom - cca. lane) zbog stresa koji se ponavlja.
Neki od ovih efekata su poznati već duže vreme, a rezultati , objavljen 1976. u časopisu Ergonomics, kaže da kašnjenje od 100 milisekundi "značajno umanjuje brzinu kucanja". Nedavno je predstavljen GNOME korisnički vodič za 10 milisekundi, a ako idete dalje, onda pokazuje da je 1 milisekunda idealna.
Fatin je proveo svoje testove na uređivačima teksta; stvorio je prenosivi instrument pod nazivom koji sam koristio za testiranje pinga u terminalskim emulatorima. Imajte na umu da je test proveden u simulacijskom modu: u stvarnosti, moramo uzeti u obzir i ulaznu (tastatura, USB kontroler, itd.) i izlaznu (bafer video kartice, monitor) kašnjenje. Prema Fatinu, u tipičnim konfiguracijama to je oko 20 ms. Ako imate opremu za igranje, ovu brojku možete postići za samo 3 milisekunde. Pošto već imamo tako brz hardver, aplikacija ne mora da dodaje sopstvenu latenciju. Fatinov cilj je dovesti kašnjenje aplikacije na 1 milisekundu, ili čak postići biranje bez , kako u .
Evo rezultata mojih mjerenja, kao i nekih Fatinovih rezultata, koji pokazuju da se moj eksperiment slaže s njegovim testovima:
Prva stvar koja me je pogodila je bolje vrijeme odziva starijih programa kao što su xterm i mlterm. Sa najgorom latencijom registra (2,4 ms), radili su bolje od najbržeg modernog terminala (10,6 ms za st). Nijedan moderni terminal ne pada ispod praga od 10 milisekundi. Konkretno, Alacritty ne ispunjava tvrdnju o "najbržem dostupnom emulatoru terminala", iako su se njegovi rezultati poboljšali od njegove prve revizije 2017. Zaista, autori projekta i rade na poboljšanju prikaza. Takođe treba napomenuti da je Vim koji koristi GTK3 za red veličine sporiji od svog GTK2 kolege. Iz ovoga možemo zaključiti da GTK3 stvara dodatno kašnjenje, a to se odražava na svim ostalim terminalima koji ga koriste (Terminator, Xfce4 Terminal i GNOME Terminal).
Međutim, razlike možda neće biti vidljive oku. Kako Fatin objašnjava, "ne morate biti svjesni kašnjenja da bi to utjecalo na vas." Fatin također upozorava na standardnu devijaciju: "svaka smetnja u latenciji (jitter) stvara dodatni stres zbog svoje nepredvidljivosti."
Gornji graf je preuzet na čistom Debianu 9 (stretch) sa . Ovo okruženje daje najbolje rezultate u testovima latencije. Kako se ispostavilo, GNOME kreira dodatni ping od 20 ms za sva mjerenja. Moguće objašnjenje za ovo je prisustvo programa sa sinhronom obradom ulaznih događaja. Fatin daje primjer za takav slučaj , što dodaje kašnjenje tako što sinhrono obrađuje sve ulazne događaje. Podrazumevano, GNOME takođe dolazi sa menadžerom prozora , koji stvara dodatni sloj baferovanja, koji utiče na ping i dodaje najmanje 8 milisekundi latencije.
Brzina skrolovanja
Sljedeći test je tradicionalni test "brzine" ili "propusnosti", koji mjeri koliko brzo terminal može pomicati stranicu dok prikazuje velike količine teksta na ekranu. Mehanika testa varira; originalni test je bio jednostavno generiranje istog tekstualnog niza pomoću naredbe seq. Ostali testovi uključuju Thomas E. Dickey-jev (xterm održavač) test, koji se ponavlja . U drugom pregledu performansi terminala koristi base32 kodiran niz nasumičnih bajtova, koji se izlazi na terminal pomoću kat. Luu smatra da je takav test "beskorisan mjerilo koliko se može zamisliti" i predlaže korištenje terminalnog odgovora kao primarne metrike. Dickey svoj test također naziva pogrešnim. Međutim, oba autora priznaju da propusnost prozora terminala može biti problem. Luu je otkrio da se Emacs Eshell smrzava prilikom prikazivanja velikih datoteka, a Dickey je optimizirao terminal da se riješi vizuelne tromosti xtrerma. Dakle, još uvijek postoje neke zasluge za ovaj test, ali budući da se proces renderiranja veoma razlikuje od terminala do terminala, može se koristiti i kao testna komponenta za testiranje drugih parametara.
Ovdje vidimo rxvt i st pull ispred konkurencije, a zatim slijedi mnogo noviji Alacritty, koji je dizajniran s fokusom na performanse. Slijede Xfce (VTE porodica) i Konsole, koji su skoro duplo brži. Poslednji je xterm, koji je pet puta sporiji od rxvt. Tokom testa, xterm je takođe dosta mreškao, što je otežavalo uočavanje teksta koji je prošao, čak i ako je u pitanju isti red. Konsole je bio brz, ali je ponekad bio težak: ekran bi se s vremena na vrijeme zamrznuo, pokazujući djelomični tekst ili ga uopće ne bi. Ostali terminali jasno su prikazivali nizove, uključujući st, Alacritty i rxvt.
Dickey objašnjava da su razlike u performansama posljedica dizajna scroll bafera u različitim terminalima. Konkretno, on optužuje rxvt i druge terminale da "ne slijede opšta pravila":
“Za razliku od xterm-a, rxvt nije pokušao prikazati sva ažuriranja. Ako zaostane, odbit će neka ažuriranja kako bi ih sustigla. Ovo je imalo veći uticaj na prividnu brzinu skrolovanja nego na organizaciju interne memorije. Jedan nedostatak je bio taj što je ASCII animacija bila pomalo neprecizna."
Da bi popravio ovu uočenu sporost xterm, Dickey predlaže korištenje resursa , omogućavajući xtermu da odbaci neka ažuriranja ekrana kako bi održao korak s tokom. Moji testovi potvrđuju da fastScroll poboljšava performanse i dovodi xterm u rang sa rxvt. Ovo je, međutim, prilično gruba štaka, kako sam Dickey objašnjava: "ponekad se čini da xterm - poput konsole - staje dok čeka na novi set ažuriranja ekrana nakon što su neka uklonjena." U tom smislu, čini se da su drugi terminali pronašli najbolji kompromis između brzine i integriteta ekrana.
Potrošnja resursa
Bez obzira na to da li ima smisla uzeti u obzir brzinu skrolovanja kao metriku performansi, ovaj test nam omogućava da simuliramo opterećenje terminala, što nam zauzvrat omogućava mjerenje drugih parametara kao što su memorija ili upotreba diska. Metrike su dobijene izvođenjem navedenog testa dalje pod nadzorom Python procesa. Prikupio je podatke o brojilima do ru_maxrss, iznos ru_oublock и ru_inblock i jednostavan tajmer.
U ovom testu, ST zauzima prvo mjesto sa najnižom prosječnom potrošnjom memorije od 8 MB, što nije iznenađujuće s obzirom da je glavna ideja jednostavnost. mlterm, xterm i rxvt troše malo više - oko 12 MB. Još jedan značajan rezultat je Alacritty, kojem je za pokretanje potrebno 30 MB. Zatim tu su terminali VTE porodice sa brojkama od 40 do 60 MB, što je dosta. Ova potrošnja se može objasniti činjenicom da ovi terminali koriste biblioteke višeg nivoa, na primjer, GTK. Konsole dolazi na posljednjem mjestu sa ogromnih 65MB potrošnje memorije tokom testova, iako se to može opravdati njegovim vrlo širokim spektrom funkcija.
U poređenju sa prethodnim rezultatima dobijenim pre deset godina, svi programi su počeli da troše primetno više memorije. Xterm je nekada zahtevao 4 MB, ali sada zahteva 15 MB samo pri pokretanju. Slično je povećanje potrošnje za rxvt, koji sada zahtijeva 16 MB iz kutije. Xfce Terminal zauzima 34 MB, što je tri puta više nego ranije, ali GNOME terminalu je potrebno samo 20 MB. Naravno, svi prethodni testovi su sprovedeni na 32-bitnoj arhitekturi. Na LCA 2012 Rusty Russell , da postoji mnogo suptilnijih razloga koji bi mogli objasniti povećanje potrošnje memorije. Uz to, sada živimo u vremenu u kojem imamo gigabajte memorije, pa ćemo se nekako snaći.
Međutim, ne mogu a da ne osjećam da je dodjela više memorije nečemu tako fundamentalnom kao što je terminal gubitak resursa. Ovi programi bi trebali biti najmanji od najmanjih, trebali bi se moći pokrenuti na bilo kojoj „kutiji“, čak i kutiji za cipele, ako ikada dođemo do tačke u kojoj treba da budu opremljeni Linux sistemima (a znate da će tako biti ) . Ali s ovim brojevima, korištenje memorije će postati problem u budućnosti u bilo kojem okruženju koje pokreće više terminala osim nekoliko najlakših i najograničenijih mogućnosti. Da bi to kompenzirali, GNOME Terminal, Konsole, urxvt, Terminator i Xfce Terminal imaju Daemon način rada koji vam omogućava da kontrolirate više terminala kroz jedan proces, ograničavajući njihovu potrošnju memorije.
Tokom testiranja, došao sam do još jednog neočekivanog rezultata u vezi čitanja i pisanja diska: očekivao sam da ovdje neću vidjeti ništa, ali se pokazalo da neki terminali zapisuju najobimnije podatke na disk. Dakle, VTE biblioteka zapravo drži bafer za pomicanje na disku (ova funkcija , a to se još uvijek dešava). Ali za razliku od starijih implementacija, sada su barem ovi podaci šifrirani pomoću AES256 GCM (). Ali postavlja se razumno pitanje: šta je toliko posebno u VTE biblioteci da zahtijeva tako nestandardan pristup implementaciji...
zaključak
U prvom dijelu članka otkrili smo da terminali bazirani na VTE-u imaju dobar skup funkcija, ali sada vidimo da to dolazi sa određenim troškovima performansi. Sada memorija nije problem jer se svi VTE terminali mogu kontrolisati kroz Daemon proces, koji ograničava njihov apetit. Međutim, stariji sistemi koji imaju fizička ograničenja na količinu RAM-a i bafera kernela možda će i dalje trebati starije verzije terminala, jer troše znatno manje resursa. Iako su VTE terminali imali dobre rezultate u testovima propusnosti (skrolovanja), njihovo kašnjenje prikaza je iznad praga postavljenog u GNOME korisničkom vodiču. VTE programeri bi to trebali uzeti u obzir. Ako uzmemo u obzir da je čak i za početnike Linux korisnike susret s terminalom neizbježan, oni ga mogu učiniti lakšim za korištenje. Za iskusne štreberke, prelazak sa standardnog terminala može čak značiti manje naprezanje očiju i mogućnost izbjegavanja budućih ozljeda i bolesti na poslu zbog dugih radnih sesija. Nažalost, samo stari xterm i mlterm dovode nas do magičnog praga pinga od 10 milisekundi, što je za mnoge neprihvatljivo.
Benchmark mjerenja su također pokazala da su programeri zbog razvoja Linux grafičkih okruženja morali napraviti niz kompromisa. Neki korisnici će možda htjeti pogledati obične upravitelje prozora jer oni pružaju značajno smanjenje pinga. Nažalost, nije bilo moguće izmjeriti kašnjenje za Wayland: program Typometer koji sam koristio kreiran je za ono što je Wayland dizajniran da spriječi: špijuniranje drugih prozora. Nadam se da Wayland compositing radi bolje od X.org-a, a također se nadam da će u budućnosti neko naći način da izmjeri kašnjenje u ovom okruženju.
izvor: www.habr.com