Nekoliko riječi iz našeg prevoditeljskog ureda: obično svi nastoje prevesti najnovije materijale i publikacije, a mi nismo iznimka. Ali terminali nisu nešto što se ažurira jednom tjedno. Stoga smo za vas preveli članak Antoinea Beaupréa, objavljen u proljeće 2018.: unatoč značajnoj „starosti“ prema modernim standardima, po našem mišljenju, materijal uopće nije izgubio na važnosti. Osim toga, ovo je izvorno bila serija od dva članka, ali smo ih odlučili spojiti u jedan veliki post.
Terminali imaju posebno mjesto u povijesti računala, no posljednjih su desetljeća bili prisiljeni preživjeti uz naredbeni redak jer su grafička sučelja postala sveprisutna. zamijenili svoje , koji su pak bili modifikacija sustava temeljenih na bušenim karticama i prekidačima. Moderne distribucije dolaze s nizom emulatora terminala svih oblika i boja. I dok su mnogi zadovoljni standardnim terminalom koji im pruža njihovo radno okruženje, neki ponosno koriste potpuno egzotičan softver za pokretanje svoje omiljene školjke ili uređivača teksta. No, kao što ćemo vidjeti iz ovog članka, nisu svi terminali stvoreni na istu sliku: oni se uvelike razlikuju u funkcionalnosti, veličini i izvedbi.
Neki terminali imaju potpuno iznenađujuće sigurnosne rupe, plus većina ima potpuno drugačiji skup funkcija, od podrške za sučelje s karticama do skriptiranja. Iako mi , ovaj je članak ažuriranje prethodnog materijala koji će pomoći čitateljima da odluče koji terminal koristiti u 2018. Prva polovica članka uspoređuje karakteristike, a druga polovica ocjenjuje izvedbu.
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 postaviti na Debian 9 ili Fedora 27. Jedina iznimka je Alacritty. Potomak je GPU-ubrzanih terminala i napisan je na neobičnom i novom jeziku za ovaj zadatak - Rust. Isključio sam web terminale iz svoje recenzije (uključujući one na ), jer su preliminarni testovi pokazali njihove izuzetno loše performanse.
Unicode podrška
Započeo sam svoje testove s podrškom za Unicode. Prvi test terminala bio je prikaz Unicode niza iz : "é, Δ, I, ק, م, ๗, あ, 叶, 葉 i 말." Ovaj jednostavan test pokazuje može li terminal ispravno raditi u cijelom svijetu. xterm terminal ne prikazuje arapski znak u zadanoj konfiguraciji:
Standardno xterm koristi klasični "fiksni" font, koji prema , ima "značajnu Unicode pokrivenost od 1997.". Nešto se događa u ovom fontu zbog čega se znak pojavljuje kao prazan okvir i tek kada se font teksta poveća na 20+ točaka, znak se konačno počinje ispravno prikazivati. Međutim, ovaj "popravak" kvari prikaz drugih Unicode znakova:
Ove snimke zaslona su snimljene u Fedori 27, jer je dala bolje rezultate od Debiana 9, gdje neke starije verzije terminala (posebno mlterm) nisu mogle pravilno rukovati fontovima. Srećom, to je popravljeno u kasnijim verzijama.
Sada primijetite kako je linija prikazana u xterm-u. Ispada da simbol Mem i sljedeći semitski pogledajte skripte RTL stila (), tako da bi tehnički trebali biti prikazani s desna na lijevo. Web preglednici kao što je Firefox 57 ispravno obrađuju gornji redak. Jednostavnija verzija RTL teksta je riječ "" na hebrejskom (). kaže sljedeće:
“Mnogi računalni programi ne mogu ispravno prikazati dvosmjerni tekst. Na primjer, hebrejsko ime "Sara" sastoji se od znakova sin (ש) (koji se pojavljuje s desne strane), zatim resh (ר) i na kraju on (ה) (koji bi se trebao pojaviti s lijeve strane)."
Mnogi terminali padaju na ovom testu: Alacritty, Gnome i XFCE terminali izvedeni iz VTE-a, urxvt, st i xterm prikazuju "Sara" obrnutim redoslijedom, kao da smo napisali ime kao "Aras".
Još jedan problem s dvosmjernim tekstovima je taj što ih je potrebno nekako uskladiti, posebno kada se radi o miješanju RTL i LTR tekstova. RTL skripte trebale bi se pokretati s desne strane prozora terminala, ali što bi se trebalo dogoditi za terminale koji zadano koriste LTR engleski? Većina njih nema nikakve posebne mehanizme i sav tekst poravnava ulijevo (uključujući i Konsole). Izuzetak su pterm i mlterm, koji se pridržavaju standarda i poravnavaju takve retke udesno.
Zaštita od umetanja
Sljedeća kritična značajka koju sam identificirao je zaštita od umetanja. Iako je opće poznato da čarolije poput:
$ curl http://example.com/ | shsu push naredbe za izvršavanje koda, malo ljudi zna da se skrivene naredbe mogu ušuljati u konzolu prilikom kopiranja i lijepljenja iz web preglednika, čak i nakon pažljivog pregleda. briljantno pokazuje kako naredba izgleda bezazleno:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitpretvara se u takvu smetnju kada se zalijepi s Hornove web stranice na 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 pomoću CSS-a pomiče izvan korisničkog prikaza.
jasno je osmišljen da neutralizira takve napade. U ovom načinu rada terminali zatvaraju zalijepljeni tekst u par posebnih izlaznih sekvenci kako bi ljusci rekli o podrijetlu teksta. Ovo govori ljusci da može zanemariti posebne znakove koje zalijepljeni tekst može sadržavati. Svi terminali unatrag do časnog xterm-a podržavaju ovu značajku, ali lijepljenje u načinu rada u zagradama zahtijeva podršku ljuske ili aplikacije koja se izvodi na terminalu. Na primjer, korištenje softvera (isti Bash), potrebna je datoteka ~/.unosrc:
set enable-bracketed-paste onNažalost, Hornova testna stranica također pokazuje kako zaobići ovu zaštitu kroz samo oblikovanje teksta i prerano završiti primjenom načina rada u zagradama. Ovo funkcionira jer neki terminali ne filtriraju ispravno izlazne sekvence prije dodavanja vlastitih. Na primjer, u svom nikad nisam uspio uspješno dovršiti testove Konsole čak ni s ispravnom konfiguracijom .unosrc datoteka. To znači da možete lako oštetiti konfiguraciju sustava zbog nepodržane aplikacije ili neispravno konfigurirane ljuske. Ovo je posebno opasno kada se prijavljujete na udaljene poslužitelje, gdje je pažljiva konfiguracija manje uobičajena, pogotovo ako imate mnogo takvih udaljenih strojeva.
Dobro rješenje za ovaj problem je dodatak za potvrdu lijepljenja za terminal urxvt, koji jednostavno traži dopuštenje za umetanje bilo kojeg teksta koji sadrži nove retke. Nisam pronašao sigurniju opciju za tekstualni napad koji je opisao Horn.
Kartice i profili
Trenutačno popularna značajka je podrška za sučelje s karticama, koje ćemo definirati kao jedan prozor terminala koji sadrži nekoliko drugih terminala. Ova se funkcija razlikuje za različite terminale i iako tradicionalni xterm terminali uopće ne podržavaju kartice, 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 neosporni lider: ne samo da podržava kartice, već također može rasporediti terminale bilo kojim redoslijedom (pogledajte sliku ispod).
Još jedna značajka Terminatora je mogućnost "grupiranja" ovih kartica zajedno i slanja istih pritisaka tipki na više terminala u isto vrijeme, pružajući sirovi alat za izvođenje skupnih operacija na više poslužitelja istovremeno. Slična značajka također je implementirana u Konsole. Za korištenje ove značajke na drugim terminalima, morate koristiti softver treće strane kao što je , ili .
Kartice posebno dobro funkcioniraju kada su uparene s profilima: na primjer, možete imati jednu karticu za e-poštu, drugu za chat i tako dalje. Ovo dobro podržavaju Konsole terminal i GNOME terminal. Obje omogućuju svakoj kartici da automatski pokrene vlastiti profil. Terminator također podržava profile, ali nisam mogao pronaći način za automatsko pokretanje određenih programa kada otvorite određenu karticu. Drugi terminali uopće nemaju koncept "profila".
Volani
Posljednja stvar koju ću obraditi u prvom dijelu ovog članka je izgled terminala. Na primjer, GNOME, Xfce i urxvt podržavaju transparentnost, ali su nedavno ukinuli podršku za pozadinske slike, prisiljavajući neke korisnike da prijeđu na terminal . Osobno sam zadovoljan i jednostavan je Xresursi, koji postavlja osnovni skup pozadinskih boja za urxvt. Međutim, nestandardne teme boja također mogu stvoriti probleme. Na primjer, s aplikacijama и , budući da već koriste vlastite boje.
nisu podržavale boje, a nove su često bile ograničene na paletu od 256 boja. Za napredne korisnike koji stiliziraju svoje terminale, upiti ljuske 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 st, Alacritty i terminali temeljeni na VTE savršeno podržavaju True Color. Drugi terminali ne prolaze baš najbolje u tom pogledu i, zapravo, ne prikazuju ni 256 boja. Ispod možete vidjeti razliku između podrške za True Color u GNOME terminalima, st i xterm, koji to rade dobro sa svojom paletom od 256 boja, i urxvt, koji ne samo da pada na testu, već čak prikazuje neke trepćuće znakove umjesto njih.
Neki terminali također analiziraju tekst u potrazi za URL uzorcima kako bi poveznice bile moguće kliknuti. Ovo se odnosi na sve terminale izvedene iz VTE-a, dok urxvt zahtijeva poseban dodatak koji bi transformirao URL-ove na klik ili korištenjem prečaca na tipkovnici. Ostali terminali koje sam testirao prikazuju URL-ove za prikaz na druge načine.
Naposljetku, novi trend u terminalima je opcija međuspremnika za pomicanje. Na primjer, st nema međuspremnik za pomicanje; pretpostavlja se da će korisnik koristiti terminalni multiplekser poput tmux i .
Alacritty također nema međuspremnike za pomicanje unazad, ali svoju podršku zbog "opsežnih povratnih informacija" o ovoj temi od korisnika. Osim ovih početnika, svaki terminal koji sam testirao i koji sam mogao pronaći podržava obrnuto pomicanje.
podzbrojeva
U drugom dijelu materijala (u originalu su to dva različita artikla - cca. traka) usporedit ćemo performanse, korištenje memorije i latenciju. Ali već sada možemo vidjeti da neki od dotičnih terminala imaju ozbiljne nedostatke. Na primjer, korisnici koji redovito rade s RTL skriptama možda će htjeti razmotriti mlterm i pterm, jer su oni bolji u rješavanju sličnih zadataka od drugih. Konsole se također dobro pokazao. Korisnici koji ne rade s RTL skriptama mogu odabrati nešto drugo.
Što se tiče zaštite od ubacivanja malicioznog koda, urxvt se ističe posebnom implementacijom zaštite od ove vrste napada, što mi se čini svakako zgodnim. Za one koji traže nešto posebno, Konsole vrijedi pogledati. Na kraju, vrijedi napomenuti da je VTE izvrsna baza 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 zadovoljiti sve zahtjeve, ali ostavimo ovo pitanje otvorenim dok ne shvatimo performanse.
Nastavimo razgovor
Općenito, izvedba terminala sama po sebi može izgledati kao nategnut problem, ali kako se pokazalo, neki od njih pokazuju iznenađujuće visoku latenciju za softver tako temeljne vrste. Zatim ćemo pogledati ono što se tradicionalno naziva "brzina" (zapravo, ovo je brzina pomicanja) i potrošnja memorije terminala (uz upozorenje da to danas nije tako kritično kao prije desetljeća).
kašnjenje
Nakon temeljitog proučavanja performansi terminala, došao sam do zaključka da je najvažniji parametar u tom smislu latencija (ping). U svom članku Pavel Fatin pogledao je kašnjenje raznih uređivača teksta i nagovijestio da bi terminali u tom pogledu mogli biti sporiji od najbržih uređivača teksta. Bio je to taj savjet koji me naposljetku naveo da pokrenem vlastite testove i napišem ovaj članak.
Ali što je latencija i zašto je toliko važna? U svom je članku Fatin to definirao kao "kašnjenje između pritiskanja tipke i odgovarajućeg ažuriranja zaslona" i citirao , koji kaže: "Kašnjenje vizualne povratne informacije na zaslonu računala ima važan utjecaj na ponašanje i zadovoljstvo daktilografa."
Fatin objašnjava da ovaj ping ima dublje posljedice od samog zadovoljstva: "tipkanje postaje sporije, pojavljuje se više pogrešaka, a napetost očiju i mišića raste." Drugim riječima, veliko kašnjenje može dovesti do pogrešaka pri upisu, a također i niže kvalitete koda, jer dovodi do dodatnog kognitivnog opterećenja mozga. Ali ono što je još gore je da ping "povećava naprezanje očiju i mišića", što izgleda implicira u budućnosti (Navodno, autor misli na probleme s mišićima očiju, leđa, ruku i, naravno, vida - cca. traka) zbog ponavljajućeg stresa.
Neki od tih učinaka poznati su već duže vrijeme, a rezultati , objavljen još 1976. godine u časopisu Ergonomics, rekao je da kašnjenje od 100 milisekundi "značajno narušava brzinu tipkanja". Nedavno je predstavljen GNOME korisnički priručnik za 10 milisekundi, a ako idete dalje, onda pokazuje da je 1 milisekunda idealna.
Fatin je svoje testove proveo na uređivačima teksta; stvorio je prijenosni instrument tzv , koji sam koristio za testiranje pinga u emulatorima terminala. Imajte na umu da je test proveden u simulacijskom načinu rada: u stvarnosti moramo uzeti u obzir i ulaznu (tipkovnica, USB kontroler, itd.) i izlaznu (međuspremnik 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. Budući da već imamo tako brz hardver, aplikacija ne mora dodavati vlastitu latenciju. Fatinov cilj je smanjiti kašnjenje aplikacije na 1 milisekundu ili čak postići biranje bez kao u .
Evo rezultata mojih mjerenja, kao i nekih Fatinovih rezultata, koji pokazuju da se moj eksperiment slaže s njegovim testovima:
Prvo što mi se dojmilo bilo je bolje vrijeme odziva starijih programa kao što su xterm i mlterm. Uz najgoru latenciju registra (2,4 ms), imali su bolje rezultate 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 mu se rezultati poboljšali od njegove prve recenzije 2017. godine. Dapače, autori projekta i rade na poboljšanju prikaza. Također treba napomenuti da je Vim koji koristi GTK3 za red veličine sporiji od svog GTK2 dvojnika. Iz ovoga možemo zaključiti da GTK3 stvara dodatnu latenciju, a to se odražava na sve ostale terminale koji ga koriste (Terminator, Xfce4 Terminal i GNOME Terminal).
Međutim, razlike možda neće biti uočljive oku. Kao što Fatin objašnjava, "ne morate biti svjesni odgode da bi ona imala učinak na vas." Fatin također upozorava na standardnu devijaciju: “svaki poremećaji u latenciji (jitter) stvaraju dodatni stres zbog svoje nepredvidljivosti.”
Gornji grafikon je uzet na čistom Debianu 9 (stretch) s . Ovo okruženje daje najbolje rezultate u testovima latencije. Kako se ispostavilo, GNOME stvara dodatni ping od 20 ms za sva mjerenja. Moguće objašnjenje za to je prisutnost programa sa sinkronom obradom ulaznih događaja. Fatin daje primjer za takav slučaj , koji dodaje odgodu sinkronom obradom svih ulaznih događaja. Prema zadanim postavkama, GNOME također dolazi s upraviteljem prozora , koji stvara dodatni sloj međuspremnika, koji utječe na ping i dodaje najmanje 8 milisekundi kašnjenja.
Brzina pomicanja
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 test Thomasa E. Dickeyja (xterm održavatelj), koji opetovano . U drugom pregledu performansi terminala koristi base32 kodiran niz slučajnih bajtova, koji se šalje na terminal pomoću cat. Luu smatra da je takav test "beskorisno mjerilo koliko se može zamisliti" i umjesto toga predlaže korištenje odziva terminala kao primarne metrike. Dickey također svoj test naziva pogrešnim. Međutim, oba autora priznaju da propusnost prozora terminala može biti problem. Luu je otkrio da se Emacs Eshell smrzava pri prikazivanju velikih datoteka, a Dickey je optimizirao terminal kako bi se riješio vizualne tromosti xtrerma. Dakle, ovaj test još uvijek ima neke prednosti, ali budući da se proces renderiranja vrlo razlikuje od terminala do terminala, može se koristiti i kao testna komponenta za testiranje drugih parametara.
Ovdje vidimo rxvt i st kako se povlače ispred konkurencije, nakon čega slijedi puno noviji Alacritty, koji je dizajniran s fokusom na performanse. Slijede Xfce (VTE obitelj) i Konsole, koji su gotovo dvostruko brži. Zadnji je xterm, koji je pet puta sporiji od rxvt-a. Tijekom testa, xterm se također dosta namreškao, čineći prolazni tekst teško vidljivim čak i ako je bio isti redak. Konsole je bio brz, ali ponekad je bio nezgodan: zaslon bi se s vremena na vrijeme zamrznuo, prikazujući djelomično tekst ili ga uopće ne prikazujući. Drugi terminali su jasno prikazivali nizove, uključujući st, Alacritty i rxvt.
Dickey objašnjava da su razlike u izvedbi posljedica dizajna međuspremnika za pomicanje u različitim terminalima. Konkretno, on optužuje rxvt i druge terminale da "ne poštuju opća pravila":
“Za razliku od xterm-a, rxvt nije pokušao prikazati sva ažuriranja. Ako zaostane, odbit će neka ažuriranja da ih sustigne. To je imalo veći utjecaj na prividnu brzinu pomicanja nego na organizaciju interne memorije. Jedan nedostatak je bio taj što je ASCII animacija bila donekle neprecizna."
Da bi se popravila ova uočena tromost xterm-a, Dickey predlaže korištenje resursa , dopuštajući xterm-u da odbaci neka ažuriranja zaslona kako bi držao korak s tijekom. Moji testovi potvrđuju da fastScroll poboljšava performanse i dovodi xterm u rang s rxvt-om. Ovo je, međutim, prilično gruba štaka, kao što sam Dickey objašnjava: "ponekad se čini da se xterm - poput konzole - zaustavlja dok čeka novi skup ažuriranja zaslona nakon što su neka uklonjena." U tom smislu, čini se da su drugi terminali pronašli najbolji kompromis između brzine i integriteta prikaza.
Potrošnja resursa
Bez obzira na to ima li smisla smatrati brzinu pomicanja metrikom performansi, ovaj nam test omogućuje simulaciju opterećenja na terminalima, što nam zauzvrat omogućuje mjerenje drugih parametara poput upotrebe memorije ili diska. Mjerni podaci su dobiveni izvođenjem navedenog testa dalje pod nadzorom Python procesa. Prikupio je podatke o brojilu za ru_maxrss, iznos ru_oublock и ru_inblock i jednostavan mjerač vremena.
U ovom testu ST zauzima prvo mjesto s najnižom prosječnom potrošnjom memorije od 8 MB, što i ne čudi s obzirom da je glavna ideja dizajna jednostavnost. mlterm, xterm i rxvt troše malo više - oko 12 MB. Još jedan značajan rezultat je Alacritty, koji zahtijeva 30 MB za rad. Tu su zatim terminali obitelji VTE s brojkama od 40 do 60 MB, što je prilično puno. Ova se potrošnja može objasniti činjenicom da ovi terminali koriste biblioteke više razine, na primjer, GTK. Konsole dolazi na posljednjem mjestu s nevjerojatnih 65 MB potrošnje memorije tijekom testova, iako se to može opravdati njegovim vrlo širokim rasponom značajki.
U usporedbi s prijašnjim rezultatima prije deset godina, svi programi počeli su trošiti osjetno više memorije. Xterm je prije zahtijevao 4 MB, ali sada zahtijeva 15 MB samo pri pokretanju. Slično je povećanje potrošnje za rxvt, koji sada zahtijeva 16 MB izvan kutije. Xfce terminal zauzima 34 MB, što je tri puta više nego prije, ali GNOME terminalu treba samo 20 MB. Naravno, svi prethodni testovi su provedeni na 32-bitnoj arhitekturi. Na LCA 2012 Rusty Russell , da postoji mnogo suptilnijih razloga koji bi mogli objasniti povećanje potrošnje memorije. No, sad ž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 dodjeljivanje više memorije nečemu tako osnovnom 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 točke da ih treba opremiti Linux sustavima (a znate da će tako biti) ) . Ali s ovim brojevima, upotreba memorije postat će problem u budućnosti u bilo kojem okruženju s više terminala osim nekoliko najlakših i najograničenijih mogućnosti. Kako bi to kompenzirali, GNOME Terminal, Konsole, urxvt, Terminator i Xfce Terminal imaju način Daemon koji vam omogućuje kontrolu više terminala kroz jedan proces, ograničavajući njihovu potrošnju memorije.
Tijekom mojih testova došao sam do još jednog neočekivanog rezultata u vezi s čitanjem i pisanjem diska: očekivao sam da ovdje neću vidjeti baš ništa, ali pokazalo se da neki terminali pišu najobimnije podatke na disk. Dakle, VTE biblioteka zapravo čuva međuspremnik za pomicanje na disku (ova značajka , a to se još uvijek događa). Ali za razliku od starijih implementacija, sada su barem ovi podaci šifrirani pomoću AES256 GCM (). Ali postavlja se razumno pitanje: što je toliko posebno u biblioteci VTE da zahtijeva tako nestandardni pristup implementaciji...
Zaključak
U prvom dijelu članka otkrili smo da terminali temeljeni na VTE-u imaju dobar skup značajki, ali sada vidimo da to dolazi s određenim troškovima performansi. Sada memorija nije problem jer se svim VTE terminalima može upravljati kroz proces Daemon, što ograničava njihov apetit. Međutim, stariji sustavi koji imaju fizička ograničenja količine RAM-a i međuspremnika jezgre možda će i dalje trebati starije verzije terminala, budući da troše znatno manje resursa. Iako su VTE terminali imali dobre rezultate u testovima propusnosti (klizanja), njihova latencija prikaza je iznad praga postavljenog u korisničkom priručniku za GNOME. VTE programeri bi to vjerojatno trebali uzeti u obzir. Ako uzmemo u obzir da je čak i za početnike Linux korisnike susret s terminalom neizbježan, mogu ga učiniti lakšim za korištenje. Za iskusne štrebere prelazak sa zadanog terminala može čak značiti manje naprezanja očiju i mogućnost izbjegavanja budućih ozljeda i bolesti povezanih s radom 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.
Mjerenja benchmarka također su pokazala da su zbog razvoja Linux grafičkih okruženja programeri morali napraviti brojne kompromise. Neki korisnici možda će 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 stvoren je za ono za što je Wayland dizajniran da spriječi: špijuniranje drugih prozora. Nadam se da Wayland compositing radi bolje od X.org, a također se nadam da će u budućnosti netko pronaći način za mjerenje latencije u ovom okruženju.
Izvor: www.habr.com