Nekaj besed našega prevajalskega biroja: običajno si vsi prizadevajo prevajati najnovejša gradiva in publikacije in mi nismo izjema. Toda terminali niso nekaj, kar bi se posodabljalo enkrat na teden. Zato smo za vas prevedli članek Antoina Beaupréja, objavljenega spomladi 2018: kljub precejšnji "starosti" po sodobnih standardih gradivo po našem mnenju sploh ni izgubilo svoje pomembnosti. Poleg tega je bila to prvotno serija dveh člankov, vendar smo se odločili, da ju združimo v eno veliko objavo.
Terminali imajo posebno mesto v računalniški zgodovini, vendar so bili v zadnjih desetletjih prisiljeni preživeti poleg ukazne vrstice, saj so grafični vmesniki postali vseprisotni. zamenjali svoje , ki so bili posledično modifikacija sistemov, ki temeljijo na luknjanih karticah in preklopnih stikalih. Sodobne distribucije so opremljene z različnimi terminalskimi emulatorji vseh oblik in barv. In medtem ko so mnogi zadovoljni s standardnim terminalom, ki ga ponuja njihovo delovno okolje, nekateri ponosno uporabljajo naravnost eksotično programsko opremo za zagon svoje najljubše lupine ali urejevalnika besedil. Toda, kot bomo videli v tem članku, niso bili vsi terminali ustvarjeni po isti podobi: zelo se razlikujejo po funkcionalnosti, velikosti in zmogljivosti.
Nekateri terminali imajo naravnost presenetljive varnostne luknje, večina pa ima popolnoma drugačen nabor funkcij, od podpore za vmesnik z zavihki do skriptiranja. Čeprav mi , ta članek je posodobitev prejšnjega gradiva, ki bo bralcem pomagal določiti, kateri terminal uporabiti v letu 2018. Prva polovica članka primerja funkcije, druga polovica pa ocenjuje učinkovitost.
Tukaj so terminali, ki sem jih pregledal:
To morda niso najnovejše različice, saj sem bil v času pisanja omejen na stabilne različice, ki sem jih lahko uvedel v Debian 9 ali Fedora 27. Edina izjema je Alacritty. Je potomec GPE-pospešenih terminalov in je napisan v nenavadnem in novem jeziku za to nalogo – Rust. Iz pregleda sem izključil spletne terminale (vključno s tistimi na ), ker so preliminarni testi pokazali njihovo izjemno slabo delovanje.
Podpora Unicode
Svoje teste sem začel s podporo za Unicode. Prvi preizkus terminalov je bil prikaz niza Unicode iz : "é, Δ, И, ק, م, ๗, あ, 叶, 葉 in 말." Ta preprost test pokaže, ali lahko terminal pravilno deluje po vsem svetu. terminal xterm ne prikazuje arabskih znakov v privzeti konfiguraciji:
Xterm privzeto uporablja klasično "fiksno" pisavo, ki glede na , ima "znatno pokritost z Unicode od leta 1997". V tej pisavi se nekaj dogaja, zaradi česar je znak videti kot prazen okvir in šele ko se pisava besedila poveča na 20+ točk, se znak končno začne pravilno prikazovati. Vendar ta »popravek« prekine prikaz drugih znakov Unicode:
Ti posnetki zaslona so bili posneti v Fedori 27, saj je dala boljše rezultate kot Debian 9, kjer nekatere starejše različice terminalov (zlasti mlterm) niso mogle pravilno obravnavati pisav. Na srečo je bilo to popravljeno v kasnejših različicah.
Zdaj opazite, kako je črta prikazana v xterm. Izkazalo se je, da simbol Mem in naslednji semitski glejte skripte v slogu RTL (), zato bi morali biti tehnično prikazani od desne proti levi. Spletni brskalniki, kot je Firefox 57, pravilno obravnavajo zgornjo vrstico. Preprostejša različica besedila RTL je beseda "" v hebrejščini (). govori naslednje:
»Številni računalniški programi ne morejo pravilno prikazati dvosmernega besedila. Na primer, hebrejsko ime "Sarah" je sestavljeno iz znakov sin (ש) (ki se pojavi na desni), nato resh (ר) in nazadnje on (ה) (ki bi se moral pojaviti na levi).«
Številni terminali ne prestanejo tega preizkusa: terminali Alacritty, Gnome in XFCE, ki izvirajo iz VTE, urxvt, st in xterm prikazujejo "Sara" v obratnem vrstnem redu, kot da bi ime zapisali kot "Aras".
Druga težava z dvosmernimi besedili je, da jih je treba nekako poravnati, zlasti ko gre za mešanje besedil RTL in LTR. Skripti RTL bi se morali izvajati z desne strani terminalskega okna, toda kaj bi se moralo zgoditi s terminali, ki imajo privzeto LTR angleščino? Večina jih nima posebnih mehanizmov in celotno besedilo poravna v levo (tudi v Konsole). Izjema sta pterm in mlterm, ki se držita standardov in takšne vrstice poravnata desno.
Zaščita pred vstavljanjem
Naslednja kritična lastnost, ki sem jo ugotovil, je zaščita proti vstavljanju. Čeprav je splošno znano, da uroki, kot so:
$ curl http://example.com/ | shso potisni ukazi za izvajanje kode, malokdo ve, da se skriti ukazi lahko prikradejo v konzolo pri kopiranju in lepljenju iz spletnega brskalnika, tudi po natančnem pregledu. briljantno prikazuje, kako neškodljiv je ukaz:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitse spremeni v tako nadlogo, ko jo prilepite s Hornovega spletnega mesta v 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 deluje? Zlonamerna koda je vključena v blok , ki se premakne iz uporabnikovega pogleda s pomočjo CSS.
je jasno zasnovan za nevtralizacijo takšnih napadov. V tem načinu terminali zaprejo prilepljeno besedilo v par posebnih ubežnih zaporedij, da povedo lupini o izvoru besedila. To lupini pove, da lahko prezre posebne znake, ki jih lahko vsebuje prilepljeno besedilo. Vsi terminali nazaj do častitljivega xterm podpirajo to funkcijo, vendar lepljenje v načinu z oklepaji zahteva podporo lupine ali aplikacije, ki se izvaja na terminalu. Na primer, uporaba programske opreme (isti Bash), potrebuje datoteko ~/.inputrc:
set enable-bracketed-paste onNa žalost Hornovo testno mesto prikazuje tudi, kako zaobiti to zaščito prek samega oblikovanja besedila in zanj prezgodaj uporabiti način z oklepaji. To deluje, ker nekateri terminali ne filtrirajo pravilno ubežnih zaporedij, preden dodajo svoja. Na primer, v mojem nikoli nisem mogel uspešno dokončati testov Konsole, tudi s pravilno konfiguracijo .inputrc mapa. To pomeni, da lahko preprosto poškodujete sistemsko konfiguracijo zaradi nepodprte aplikacije ali nepravilno konfigurirane lupine. To je še posebej nevarno pri prijavi v oddaljene strežnike, kjer je skrbno konfiguriranje manj običajno, še posebej, če imate veliko takih oddaljenih strojev.
Dobra rešitev te težave je vtičnik za potrditev lepljenja za terminal urxvt, ki preprosto zahteva dovoljenje za vstavljanje besedila, ki vsebuje nove vrstice. Nisem našel bolj varne možnosti za besedilni napad, ki ga opisuje Horn.
Zavihki in profili
Trenutno priljubljena funkcija je podpora za vmesnik z zavihki, ki ga bomo definirali kot eno okno terminala, ki vsebuje več drugih terminalov. Ta funkcija se razlikuje za različne terminale in čeprav tradicionalni terminali xterm sploh ne podpirajo zavihkov, imajo sodobnejše inkarnacije terminalov, kot so terminal Xfce, terminal GNOME in Konsole, to funkcijo. Urxvt podpira tudi zavihke, vendar le, če uporabljate vtičnik. Toda kar zadeva samo podporo za zavihke, je Terminator nesporen vodja: ne podpira samo zavihkov, ampak lahko tudi razporedi terminale v poljubnem vrstnem redu (glejte sliko spodaj).
Druga značilnost Terminatorja je zmožnost "združevanja" teh zavihkov skupaj in pošiljanja istih pritiskov tipk na več terminalov hkrati, kar zagotavlja grobo orodje za izvajanje množičnih operacij na več strežnikih hkrati. Podobna funkcija je implementirana tudi v Konsole. Za uporabo te funkcije v drugih terminalih morate uporabiti programsko opremo tretjih oseb, kot je npr , ali .
Zavihki delujejo še posebej dobro, če so združeni s profili: en zavihek lahko imate na primer za e-pošto, drugega za klepet in tako naprej. To dobro podpirata terminal Konsole in terminal GNOME. Oba omogočata, da vsak zavihek samodejno zažene svoj profil. Terminator podpira tudi profile, vendar nisem našel načina za samodejni zagon določenih programov, ko odprete določen zavihek. Drugi terminali pojma "profil" sploh nimajo.
Naborki
Zadnja stvar, ki jo bom obravnaval v prvem delu tega članka, je videz terminalov. GNOME, Xfce in urxvt na primer podpirajo preglednost, vendar so pred kratkim opustili podporo za slike v ozadju, zaradi česar so morali nekateri uporabniki preklopiti na terminal . Osebno sem z njim zadovoljen in je preprost xresources, ki nastavi osnovni nabor barv ozadja za urxvt. Težave pa lahko povzročijo tudi nestandardne barvne teme. na primer z aplikacijami и , saj že uporabljajo svoje barve.
ni podpiral barv, nove pa so bile pogosto omejene na 256-barvno paleto. Za napredne uporabnike, ki oblikujejo svoje terminale, so pozivi lupine ali statusne vrstice lahko nadležna omejitev. spremlja, kateri terminali imajo podporo za "True Color". Moji testi potrjujejo, da terminali na osnovi st, Alacrity in VTE popolnoma podpirajo True Color. Drugi terminali se v tem pogledu ne odrežejo najbolje in pravzaprav ne prikazujejo niti 256 barv. Spodaj si lahko ogledate razliko med podporo za True Color v terminalih GNOME, st in xterm, ki to dobro opravita s svojo 256 barvno paleto, in urxvt, ki ne samo da ne prestane preizkusa, ampak namesto njih celo prikaže nekaj utripajočih znakov.
Nekateri terminali tudi analizirajo besedilo za vzorce URL, da omogočijo klikanje povezav. To velja za vse terminale, ki izvirajo iz VTE, medtem ko urxvt zahteva poseben vtičnik, ki bi pretvoril URL-je na klik ali z uporabo bližnjice na tipkovnici. Drugi terminali, ki sem jih preizkusil, prikazujejo URL-je na druge načine.
Nazadnje, nov trend v terminalih je izbirnost drsnega medpomnilnika. Na primer, st nima drsnega medpomnilnika; predpostavlja se, da bo uporabnik uporabljal terminalski multiplekser, kot sta tmux in .
Alacritty tudi nima povratnih medpomnilnikov, vendar svojo podporo zaradi "obsežnih povratnih informacij" uporabnikov o tej temi. Poleg teh nadobudnežev vsak terminal, ki sem ga preizkusil in ki sem ga našel, podpira obratno drsenje.
Vmesne seštevke
V drugem delu gradiva (v originalu sta bila to dva različna artikla - cca. vozni pas) bomo primerjali zmogljivost, porabo pomnilnika in zakasnitev. Toda že lahko vidimo, da imajo nekateri od zadevnih terminalov resne pomanjkljivosti. Na primer, uporabniki, ki redno delajo s skripti RTL, bodo morda želeli razmisliti o mlterm in pterm, saj sta boljša pri obravnavanju podobnih nalog kot drugi. Dobro se je izkazal tudi Konsole. Uporabniki, ki ne delajo s skriptami RTL, lahko izberejo kaj drugega.
Pri zaščiti pred vstavljanjem zlonamerne kode urxvt izstopa zaradi posebne izvedbe zaščite pred tovrstnimi napadi, kar se mi zdi vsekakor priročno. Za tiste, ki iščejo nekaj zvoncev in piščalk, je Konsole vreden ogleda. Na koncu velja omeniti, da je VTE odlična osnova za terminale, ki zagotavlja barvno podporo, prepoznavanje URL-jev ipd. Na prvi pogled lahko privzeti terminal, ki je priložen vašemu najljubšemu okolju, izpolnjuje vse zahteve, vendar pustimo to vprašanje odprto, dokler ne razumemo zmogljivosti.
Nadaljujva pogovor
Na splošno se lahko zmogljivost terminalov sama po sebi zdi namišljena težava, a kot se je izkazalo, imajo nekateri od njih presenetljivo visoko zakasnitev za programsko opremo tako osnovne vrste. V nadaljevanju si bomo ogledali tudi tisto, kar se tradicionalno imenuje "hitrost" (v resnici je to hitrost drsenja) in porabo pomnilnika terminala (z opozorilom, da to danes ni tako kritično kot pred desetletji).
Zamuda
Po temeljiti študiji zmogljivosti terminala sem prišel do zaključka, da je najpomembnejši parameter v zvezi s tem zakasnitev (ping). V svojem članku Pavel Fatin je pogledal zakasnitev različnih urejevalnikov besedila in namignil, da so lahko terminali v tem pogledu počasnejši od najhitrejših urejevalnikov besedil. Ta namig me je na koncu pripeljal do izvajanja lastnih testov in pisanja tega članka.
Toda kaj je zakasnitev in zakaj je tako pomembna? V svojem članku ga je Fatin opredelil kot "zamik med pritiskom na tipko in ustrezno posodobitvijo zaslona" in citiral , ki pravi: »Zakasnitev vizualnih povratnih informacij na računalniškem zaslonu pomembno vpliva na vedenje in zadovoljstvo tipkarjev.«
Fatin pojasnjuje, da ima to pinganje globlje posledice kot samo zadovoljstvo: "tipkanje postane počasnejše, pojavlja se več napak, poveča se napetost oči in mišic." Z drugimi besedami, velika zamuda lahko povzroči tipkarske napake in tudi nižjo kakovost kode, saj povzroči dodatno kognitivno obremenitev možganov. Še huje pa je, da ping "poveča obremenitev oči in mišic", kar nakazuje v prihodnosti (Očitno avtor misli na težave z mišicami oči, hrbta, rok in seveda vida – cca. vozni pas) zaradi ponavljajočega se stresa.
Nekateri od teh učinkov so znani že dolgo, rezultati pa , objavljen leta 1976 v reviji Ergonomics, je dejal, da zakasnitev 100 milisekund "znatno zmanjša hitrost tipkanja." Pred kratkim je bil predstavljen uporabniški priročnik za GNOME v 10 milisekundah, in če greš dlje, potem kaže, da je 1 milisekunda idealna.
Fatin je opravil svoje teste na urejevalnikih besedil; ustvaril je prenosni instrument, imenovan , ki sem ga uporabil za testiranje pinga v terminalskih emulatorjih. Ne pozabite, da je bil test izveden v simulacijskem načinu: v resnici moramo upoštevati tako vhodno (tipkovnica, krmilnik USB itd.) kot izhodno (medpomnilnik video kartice, monitor) zakasnitev. Po Fatinu je v tipičnih konfiguracijah približno 20 ms. Če imate igralno opremo, lahko to številko dosežete v samo 3 milisekundah. Ker že imamo tako hitro strojno opremo, aplikaciji ni treba dodajati lastne zakasnitve. Fatinov cilj je spraviti zakasnitev aplikacije na 1 milisekundo ali celo doseči klicanje brez , kako noter .
Tukaj so rezultati mojih meritev in nekateri Fatinovi rezultati, ki kažejo, da se moj poskus ujema z njegovimi testi:
Prva stvar, ki me je presenetila, je bil boljši odzivni čas starejših programov, kot sta xterm in mlterm. Z najslabšo zakasnitvijo registra (2,4 ms) so se izkazali bolje kot najhitrejši sodobni terminal (10,6 ms za st). Noben sodoben terminal ne pade pod prag 10 milisekund. Zlasti Alacritty ne izpolnjuje zahtevka o "najhitrejšem razpoložljivem terminalskem emulatorju", čeprav so se njegovi rezultati od prvega pregleda leta 2017 izboljšali. Avtorji projekta namreč in si prizadevajo izboljšati zaslon. Prav tako je treba opozoriti, da je Vim, ki uporablja GTK3, za red velikosti počasnejši od svojega dvojnika GTK2. Iz tega lahko sklepamo, da GTK3 ustvarja dodatno zakasnitev, kar se odraža v vseh drugih terminalih, ki ga uporabljajo (Terminator, Xfce4 Terminal in GNOME Terminal).
Vendar razlike morda niso opazne na oko. Kot pojasnjuje Fatin, "ni treba, da se zavedate zamude, da bi imela učinek na vas." Fatin opozarja tudi na standardno deviacijo: »kakršnekoli motnje v latenci (tresenje) ustvarjajo dodaten stres zaradi svoje nepredvidljivosti.«
Zgornji graf je vzet iz čistega Debiana 9 (stretch) z . To okolje daje najboljše rezultate pri testih zakasnitve. Izkazalo se je, da GNOME ustvari dodaten ping 20 ms za vse meritve. Možna razlaga za to je prisotnost programov s sinhrono obdelavo vhodnih dogodkov. Fatin daje primer za tak primer , ki doda zakasnitev s sinhrono obdelavo vseh vhodnih dogodkov. Privzeto ima GNOME tudi upravitelja oken , ki ustvari dodatno plast medpomnilnika, ki vpliva na ping in doda vsaj 8 milisekund zakasnitve.
Hitrost drsenja
Naslednji test je tradicionalni test "hitrosti" ali "pasovne širine", ki meri, kako hitro se lahko terminal pomika po strani, medtem ko na zaslonu prikazuje velike količine besedila. Mehanika preskusa se razlikuje; prvotni preizkus je bil preprosto generiranje istega besedilnega niza z uporabo ukaza seq. Drugi testi vključujejo test Thomasa E. Dickeyja (vzdrževalec xterm), ki ponavlja . V drugem pregledu delovanja terminala uporablja base32 kodiran niz naključnih bajtov, ki je izhod na terminal z uporabo cat. Luu meni, da je takšen test "tako neuporabno merilo uspešnosti, kot si lahko zamislite" in namesto tega predlaga uporabo odziva terminala kot primarne metrike. Dickey svoj test tudi imenuje zavajajočega. Vendar oba avtorja priznavata, da je pasovna širina terminalskega okna lahko težava. Luu je odkril, da Emacs Eshell zamrzne pri prikazovanju velikih datotek, Dickey pa je optimiziral terminal, da se znebi vizualne počasnosti xtrerma. Ta test ima torej še nekaj koristi, a ker se postopek upodabljanja od terminala do terminala zelo razlikuje, ga je mogoče uporabiti tudi kot testno komponento za testiranje drugih parametrov.
Tukaj vidimo, da rxvt in st prehitevata konkurenco, sledi pa ji veliko novejši Alacritty, ki je zasnovan s poudarkom na zmogljivosti. Sledita Xfce (družina VTE) in Konsole, ki sta skoraj dvakrat hitrejša. Zadnji je xterm, ki je petkrat počasnejši od rxvt. Med preizkusom je xterm tudi močno valovil, zaradi česar je bilo besedilo težko videti, tudi če je bila ista vrstica. Konsole je bil hiter, vendar je bil včasih zapleten: zaslon je občasno zamrznil in prikazal delno besedilo ali pa ga sploh ni bilo. Drugi terminali so jasno prikazovali nize, vključno s st, Alacritty in rxvt.
Dickey pojasnjuje, da so razlike v zmogljivosti posledica zasnove drsnih medpomnilnikov v različnih terminalih. Zlasti obtožuje rxvt in druge terminale, da "ne upoštevajo splošnih pravil":
»Za razliko od xterm, rxvt ni poskušal prikazati vseh posodobitev. Če zaostaja, bo zavrnil nekatere posodobitve, da jih dohiti. To je imelo večji vpliv na navidezno hitrost pomikanja kot na organizacijo notranjega pomnilnika. Ena pomanjkljivost je bila, da je bila animacija ASCII nekoliko nenatančna."
Da bi odpravili to zaznano počasnost xterm, Dickey predlaga uporabo vira , kar omogoča xtermu, da zavrže nekatere posodobitve zaslona, da bi sledil toku. Moji testi potrjujejo, da fastScroll izboljša zmogljivost in xterm izenači z rxvt. Vendar pa je to precej groba bergla, kot pojasnjuje sam Dickey: "včasih se zdi, da xterm - tako kot konzola - zastane, ko čaka na nov niz posodobitev zaslona, potem ko so bile nekatere odstranjene." V tem smislu se zdi, da so drugi terminali našli najboljši kompromis med hitrostjo in celovitostjo zaslona.
Poraba virov
Ne glede na to, ali je smiselno obravnavati hitrost drsenja kot metriko zmogljivosti, nam ta test omogoča simulacijo obremenitve terminalov, kar nam omogoča merjenje drugih parametrov, kot sta poraba pomnilnika ali diska. Meritve so bile pridobljene z izvedbo določenega testa nasl pod nadzorom procesa Python. Zbiral je podatke števcev za ru_maxrss, znesek ru_oublock и ru_inblock in preprost časovnik.
V tem testu ST zaseda prvo mesto z najnižjo povprečno porabo pomnilnika 8 MB, kar ni presenetljivo, če upoštevamo, da je glavna ideja zasnove preprostost. mlterm, xterm in rxvt porabijo malo več - približno 12 MB. Drug opazen rezultat je Alacritty, ki za delovanje potrebuje 30 MB. Potem so tu še terminali družine VTE s številkami od 40 do 60 MB, kar je precej. To porabo je mogoče pojasniti z dejstvom, da ti terminali uporabljajo knjižnice višje ravni, na primer GTK. Konsole je na zadnjem mestu z neverjetnimi 65 MB porabe pomnilnika med testi, čeprav je to mogoče upravičiti z zelo širokim naborom funkcij.
V primerjavi s prejšnjimi rezultati izpred desetih let so vsi programi začeli porabljati opazno več pomnilnika. Xterm je prej zahteval 4 MB, zdaj pa 15 MB samo ob zagonu. Podobno se je povečala poraba za rxvt, ki zdaj zahteva 16 MB takoj po namestitvi. Terminal Xfce zavzame 34 MB, kar je trikrat več kot prej, terminal GNOME pa potrebuje le 20 MB. Seveda so bili vsi prejšnji testi izvedeni na 32-bitni arhitekturi. Na LCA 2012 Rusty Russell , da obstaja veliko bolj subtilnih razlogov, ki bi lahko pojasnili povečanje porabe pomnilnika. Sedaj živimo v času, ko imamo gigabajte pomnilnika, tako da bomo že nekako zdržali.
Vendar si ne morem kaj, da ne bi menil, da je dodeljevanje več pomnilnika nečemu tako temeljnemu, kot je terminal, izguba virov. Ti programi bi morali biti najmanjši od najmanjših, morali bi delovati na kateri koli "škati", tudi škatli za čevlje, če bomo kdaj prišli do točke, ko jih bo treba opremiti z Linux sistemi (in veste, da bo tako). ) . Toda s temi številkami bo uporaba pomnilnika v prihodnosti postala težava v katerem koli okolju, v katerem se izvaja več terminalov, razen nekaj najlažjih in najbolj omejenih zmogljivosti. Da bi nadomestili to, imajo GNOME Terminal, Konsole, urxvt, Terminator in Xfce Terminal način Daemon, ki vam omogoča nadzor nad več terminali prek enega samega procesa, kar omejuje njihovo porabo pomnilnika.
Med mojimi testi sem prišel do še enega nepričakovanega rezultata glede branja in pisanja diska: pričakoval sem, da tukaj ne bom videl ničesar, vendar se je izkazalo, da nekateri terminali zapišejo največ podatkov na disk. Torej knjižnica VTE dejansko hrani drsni medpomnilnik na disku (ta funkcija , in to se še vedno dogaja). Toda za razliko od starejših izvedb so zdaj vsaj ti podatki šifrirani z uporabo AES256 GCM (). Postavlja pa se razumno vprašanje: kaj je v knjižnici VTE tako posebnega, da zahteva tako nestandarden pristop k implementaciji ...
Zaključek
V prvem delu članka smo ugotovili, da imajo terminali, ki temeljijo na VTE, dober nabor funkcij, zdaj pa vidimo, da to prinaša nekaj stroškov delovanja. Zdaj pomnilnik ni problem, ker je vse terminale VTE mogoče nadzorovati prek procesa Daemon, kar omejuje njihov apetit. Vendar pa starejši sistemi, ki imajo fizične omejitve glede količine RAM-a in medpomnilnikov jedra, morda še vedno potrebujejo starejše različice terminalov, saj porabijo bistveno manj virov. Čeprav so se terminali VTE dobro odrezali pri preizkusih prepustnosti (drsenje), je njihova zakasnitev prikaza nad pragom, določenim v uporabniškem priročniku GNOME. Razvijalci VTE bi verjetno morali to upoštevati. Če upoštevamo, da je tudi za začetnike v Linuxu srečanje s terminalom neizogibno, ga lahko naredijo uporabniku prijaznejšega. Za izkušene geeke lahko prehod s privzetega terminala celo pomeni manjšo obremenitev oči in možnost, da se izognejo prihodnjim delovnim poškodbam in boleznim zaradi dolgih delovnih sej. Na žalost nas le stara xterm in mlterm pripeljeta do magičnega praga pinga 10 milisekund, kar je za mnoge nesprejemljivo.
Primerjalne meritve so tudi pokazale, da so zaradi razvoja grafičnih okolij Linux morali razvijalci sprejemati številne kompromise. Nekateri uporabniki bodo morda želeli pogledati običajne upravitelje oken, saj zagotavljajo znatno zmanjšanje pinga. Na žalost ni bilo mogoče izmeriti zakasnitve za Wayland: program Typometer, ki sem ga uporabil, je bil ustvarjen za to, kar je Wayland zasnovan za preprečevanje: vohunjenje za drugimi okni. Upam, da Waylandovo sestavljanje deluje bolje kot X.org, in upam tudi, da bo v prihodnosti nekdo našel način za merjenje zakasnitve v tem okolju.
Vir: www.habr.com