{"id":37222,"date":"2019-10-31T22:16:26","date_gmt":"2019-10-31T19:16:26","guid":{"rendered":"https:\/\/prohoster.info\/blog\/obzor-emulyatorov-terminala\/"},"modified":"2019-10-31T22:16:26","modified_gmt":"2019-10-31T19:16:26","slug":"obzor-emulyatorov-terminala","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/obzor-emulyatorov-terminala","title":{"rendered":"Pregled emulatorjev terminalov","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Besede od na\u0161e prevajalske agencije: obi\u010dajno se vsi trudijo prevajati najnovej\u0161e vsebine in objave, in mi nismo nobena izjema. A terminali niso nekaj, kar se posodablja vsak teden. Zato smo za vas prevedli \u010dlanek Antoine Bopre, objavljen spomladi 2018: kljub svoji precej\u0161nji \u201estarosti\u201c v sodobnem \u043c\u0435\u0440ilu menimo, da material ni izgubil svoje aktualnosti. Poleg tega je bil v izvirniku to niz dveh \u010dlankov, vendar smo se odlo\u010dili, da ju zdru\u017eimo v en obse\u017een post.<\/i><\/p>\n

\"Pregled
\n
\nTerminali imajo posebno mesto v zgodovini ra\u010dunalni\u0161tva, vendar so bili v zadnjih desetletjih prisiljeni dobesedno pre\u017eiveti skupaj s ukazno vrstico ob ozadju vseprisotnih grafi\u010dnih vmesnikov. Emulatorji terminalov<\/a><\/noindex> so zamenjali svoje strojne bratrance<\/a><\/noindex>, ki so bili sami po sebi modifikacija sistemov na perforiranih karticah in preklopnikih. Sodobne distribucije prihajajo s celotno mno\u017eico emulatorjev terminalov vseh oblik in barv. In medtem ko so mnogi povsem zadovoljni s standardnim terminalom, ki ga nudi njihovo delovno okolje, nekateri s ponosom uporabljajo izrazito eksoti\u010dno programsko opremo za zagon svojih najljub\u0161ih lupin ali urejevalnikov besedil. Vendar, kot bomo videli v tem \u010dlanku, niso vsi terminali ustvarjeni po istem vzorcu: med seboj se mo\u010dno razlikujejo po funkcionalnosti, velikosti in zmogljivosti.
\n<\/a><\/noindex><\/p>\n

Nekateri terminali imajo presenetljive varnostne luknje, poleg tega pa ima ve\u010dina popolnoma razli\u010den nabor funkcij, od podpore za vmesnik s zavihki do skript. \u010ceprav smo v preteklosti obravnavali emulatorje terminalov<\/a><\/noindex>, je ta \u010dlanek posodobitev prej\u0161njega materiala, ki bo bralcem pomagal dolo\u010diti, kateri terminal uporabiti v letu 2018. V prvi polovici \u010dlanka se primerjajo funkcije, v drugi pa se ocenjuje zmogljivost.<\/p>\n

Tukaj so obravnavani terminali:<\/p>\n

\"Pregled
\n
\nMogo\u010de to niso najnovej\u0161e razli\u010dice, saj sem se omejil na stabilne razli\u010dice ob \u010dasu pisanja materiala, ki sem jih uspel namestiti na Debian 9 ali Fedora 27. Edina izjema je Alacritty. Ta je potomka terminalov z GPU pospe\u0161evanjem in napisan v nenavadnem in novem jeziku za to nalogo \u2014 Rust. V svojem pregledu sem izklju\u010dil spletne terminale (tudi na Electron<\/a><\/noindex>), ker so predhodni testi pokazali izjemno nizko zmogljivost.<\/p>\n

Podpora za unicode<\/h4>\n

\nSvoje teste sem za\u010del s podporo za unicode. Prvi test terminalov je bilo prikazovanje stringa o unicode iz \u010dlanka na Wikipediji<\/a><\/noindex>: \u201e\u00e9, \u0394, \u0419, \u05e7, \u0645, \u0e57, \u3042, \u53f6, \u8449 in \ub9d0\u201c. Ta enostaven test poka\u017ee, ali terminal pravilno deluje po vsem svetu. Terminal xterm ne prikazuje arabske znake Pomnilnik<\/a><\/noindex> v privzeti konfiguraciji:<\/p>\n

\"Pregled
\n
\nPrivzeto xterm uporablja klasi\u010dno \u201efiksno\u201c pisavo, ki ima, po besedah iste Wikipedije<\/a><\/noindex>, \u201eznaten pokritost unicode od leta 1997\u201c. V tej pisavi se zgodi nekaj, kar povzro\u010da, da se znak prika\u017ee kot prazna okvir, in \u0161ele ob pove\u010danju pisave na 20+ to\u010dk se znak kon\u010dno za\u010dne pravilno prikazovati. Vendar pa ta \u201epopravilo\u201c zru\u0161i prikazovanje drugih unicode znakov:<\/p>\n

\"Pregled
\n
\nTi posnetki zaslona so bili narejeni na Fedora 27, saj je ta dajala najbolj\u0161e rezultate, v primerjavi z Debian 9, kjer nekatere stare razli\u010dice terminalov (natan\u010dneje - mlterm) niso mogle pravilno delovati s pisavami. Na sre\u010do je to bilo popravljenih v novej\u0161ih razli\u010dicah.<\/p>\n

Zdaj pozornost na prikazovanje niza v xterm. Izkazalo se je, da znak Mem in naslednji Semiti\u010dni Qoph<\/a><\/noindex> spadajo v scenarije pisanja RTL (right-to-left<\/a><\/noindex>), zato bi se tehni\u010dno morali prikazovati z desne proti levi. Spletni brskalniki, na primer Firefox 57, pravilno obravnavajo zgornji niz. Enostavnej\u0161a razli\u010dica besedila RTL je beseda \u201eSara<\/a><\/noindex>\u201c v hebrej\u0161\u010dini (\u05e9\u05e8\u05d4<\/a><\/noindex>). Stran Wikia o dvosmernih besedilih<\/a><\/noindex> pravi naslednje:<\/p>\n

\u201eMnogi ra\u010dunalni\u0161ki programi ne morejo pravilno prikazati dvosmernega besedila. Na primer, hebrejsko ime \u201eSara\u201c je sestavljeno iz znakov sin (\u05e9) (ki se pojavi na desni), nato re\u0161 (\u05e8) in kon\u010dno he (\u05d4) (ki se mora pojaviti na levi)\u201c.<\/p><\/blockquote>\n

\nMnogi terminali ne uspejo prestati tega testa: Alacritty, VTE-izvedeni terminali Gnome in XFCE, urxvt, st in xterm prikazujejo 'Sara' v obratnem vrstnem redu, kot da bi to ime zapisali kot 'Aras'.<\/p>\n

\"Pregled
\n
\nDrug problem dvosmernih besedil je, da jih je treba nekako poravnati, \u0161e posebej, \u010de gre za me\u0161anje besedil RTL in LTR. RTL scenariji se morajo za\u010deti z desne strani okna terminala, toda kaj se mora zgoditi v terminalih, ki privzeto delujejo z LTR-angle\u0161\u010dino? Ve\u010dina jih nima posebnih mehanizmov in poravnava celotno besedilo na levo (tudi v Konsole). Izklju\u010ditev sta pterm in mlterm, ki upo\u0161tevata standarde in poravnata tak\u0161ne vrstice na desno.<\/p>\n

\"Pregled
\n<\/p>\n

Za\u0161\u010dita pred lepljenjem<\/h4>\n

\nNaslednja kriti\u010dna zna\u010dilnost, ki sem jo dolo\u010dil, je za\u0161\u010dita pred lepljenjem. \u010ceprav je splo\u0161no znano, da so ukazi, kot so:<\/p>\n

$ curl http:\/\/example.com\/ | sh<\/code><\/pre>\n
\npotisni ukazi za izvajanje kode, malo kdo ve, da lahko skriti ukazi vstopijo v konzolo pri kopiranju in lepljenju iz spletnega brskalnika, celo po natan\u010dnem pregledu. Preverjanja spletna stran Janna Horna<\/a><\/noindex> odli\u010dno prikazuje, kako videti nedol\u017een ukaz:<\/p>\n
git clone git:\/\/git.kernel.org\/pub\/scm\/utils\/kup\/kup.git<\/code><\/pre>\n
\nse pri lepljenju s Horneve spletne strani v terminal spremeni v tak\u0161no neprijetnost:<\/p>\n
git clone \/dev\/null;\n\tclear;\n\techo -n \"Hello \";\n\twhoami|tr -d 'n';\n\techo -e '!nTo je bila slaba ideja. Ne kopirajte kode s spletnih mest, ki jim ne zaupate! \n\tTukaj je prva vrstica va\u0161ega \/etc\/passwd: ';\n\thead -n1 \/etc\/passwd\n\tgit clone git:\/\/git.kernel.org\/pub\/scm\/utils\/kup\/kup.git<\/code><\/pre>\n
\nKako to deluje? Zlonamerna koda je prestavljena v blok <\/b>, ki je CSS sredstva premaknjena iz vidnega polja uporabnika.<\/p>\n
Na\u010din Bracketed paste<\/a><\/noindex> je zasnovan za nevtralizacijo podobnih napadov. V tem na\u010dinu terminali vstavljenemu besedilu prilo\u017eijo par posebnih escape-sekvenc, da obvestijo lupino o izvoru tega besedila. Tako lupina prejme signal, da lahko ignorira posebne znake, ki jih lahko vsebuje vstavljen tekst. Vse terminali, razen \u010dastitljivega xterm, podpirajo to funkcijo, vendar vstavljanje v Bracketed na\u010dinu zahteva podporo lupine ali aplikacije, ki te\u010de v terminalu. Na primer, programska oprema, ki uporablja GNU Readline<\/a><\/noindex> (ista Bash), potrebuje datoteko ~\/.inputrc<\/b>:<\/p>\n
set enable-bracketed-paste on<\/code><\/pre>\n
\n\u017dal se testna stran Horna prav tako izka\u017ee, kako zaobiti to za\u0161\u010dito preko samega formatiranja besedila in prezgodnjega prenehanja uporabe Bracketed na\u010dina. To deluje, ker nekateri terminali nepravilno filtrirajo escape zaporedja pred dodajanjem lastnih. Na primer, v mojih nisem uspel uspe\u0161no zaklju\u010diti testov Konsole, kljub pravilni konfiguraciji. .inputrc<\/b> datoteke. To pomeni, da lahko zlahka po\u0161kodujete konfiguracijo sistema zaradi nepodprte aplikacije ali nepravilno nastavljene lupine. \u0160e posebej nevarno je to pri vstopu na oddaljene stre\u017enike, kjer se skrbna obdelava konfiguracije redkeje sre\u010duje, \u0161e posebej, \u010de imate veliko tak\u0161nih oddaljenih strojev.<\/p>\n
Dober na\u010din re\u0161evanja tega problema je vti\u010dnik za potrditev lepljenja za terminal urxvt<\/b>, ki preprosto zahteva dovoljenje za lepljenje katere koli besedila, ki vsebuje nova vrstice. Bolj\u0161ega za\u0161\u010ditenega na\u010dina za opisani Hornov napad s tekstom nisem na\u0161el.<\/p>\n
Zavihki in profili<\/h4>\n
\nPriljubljena funkcija danes je podpora za vmesnik z zavihki, ki ga bomo opredelili kot eno okno terminala, ki vsebuje ve\u010d terminalov. Za razli\u010dne terminale se ta funkcija razlikuje, in \u010deprav tradicionalni terminali, kot je xterm, sploh ne podpirajo zavihkov, bolj sodobne inkarnacije terminala, kot so Xfce Terminal, GNOME Terminal in Konsole, to funkcijo omogo\u010dajo. Tudi Urxvt podpira zavihke, vendar le ob uporabi vti\u010dnika. Vendar je Terminator brezpogojni voditelj glede podpore zavihkom: ne le, da podpira zavihke, ampak prav tako lahko postavlja terminale v poljubnem vrstnem redu (glejte sliko spodaj).<\/p>\n
\"Pregled
\n
\n\u0160e ena zna\u010dilnost Terminatorja je mo\u017enost, da te zavihke \u00bbskupina\u00ab skupaj in po\u0161lje enake pritiske tipk na ve\u010d terminalov hkrati, kar zagotavlja grob instrument za izvajanje mno\u017ei\u010dnih operacij na ve\u010d stre\u017enikih hkrati. Podobna funkcija je prav tako implementirana v Konsole. Za uporabo te funkcije v drugih terminalih je potrebno uporabiti programsko opremo tretjih oseb, kot je Cluster SSH<\/a><\/noindex>, xlax<\/a><\/noindex> ili tmux<\/a><\/noindex>.<\/p>\n
\u0160e posebej dobro delujejo zavihki skupaj s profili: na primer, lahko imate en zavihek za e-po\u0161to, drugega za klepet in tako naprej. To dobro podpira terminal Konsole in GNOME Terminal. Obe omogo\u010data, da vsak zavihek samodejno za\u017eene svoj profil. Terminator prav tako podpira profile, vendar nisem mogel najti na\u010dina za samodejno zagon dolo\u010denih programov ob odpiranju dolo\u010denega zavihka. Drugi terminali sploh nimajo koncepta 'profil'.<\/p>\n
Volan\u010dki<\/h4>\n
\nZadnja stvar, ki jo bom obravnaval v prvem delu tega \u010dlanka, je videz terminalov. Na primer, GNOME, Xfce in urxvt podpirajo prosojnost, vendar so nedavno opustili podporo za ozadja, kar je nekaterim uporabnikom povzro\u010dilo prehod na terminal. Tilix<\/a><\/noindex>. Osebno me zadostuje in preprosto Xresources<\/b>, ki nastavi osnovni niz barv ozadja za urxvt. Vendar pa lahko nestandardne barvne teme prinesejo tudi te\u017eave. Na primer, Solarized<\/a><\/noindex> ne deluje<\/a><\/noindex> s aplikacijami htop<\/a><\/noindex> in IPTraf<\/a><\/noindex>, ker \u017ee uporabljajo svoje barve.<\/p>\n
Izvorni terminal VT100<\/a><\/noindex> ni podpiral barv, novosti pa so pogosto omejene na 256-barvno paleto. Za izku\u0161ene uporabnike, ki stilizirajo svoje terminale, lahko zahtevki lupine ali vrstic stanja na nekak\u0161ne zapletene na\u010dine postanejo neprijetna omejitev. Gist<\/a><\/noindex> sledi, kateri terminali podpirajo \u201eTrue Color\u201c. Moji testi potrjujejo, da st, Alacritty in terminali na osnovi VTE odli\u010dno podpirajo True Color. Drugi terminali se na tem podro\u010dju ne obnesejo najbolje in dejansko ne prika\u017eejo niti 256 barv. Spodaj lahko vidite razliko med podporo True Color v terminalih GNOME, st in xterm, ki se dobro spopadajo s to nalogo s svojo 256-barvno paleto, ter urxvt, ki ne samo, da ne prestane testa, temve\u010d tudi prikazuje nekaj utripajo\u010dih simbolov namesto njih.<\/p>\n
\"Pregled
\n
\nNekateri terminali tudi analizirajo besedilo za vzorce URL-jev, da bi naredili povezave klikabilne. To velja za vse razli\u010dice terminalov VTE, medtem ko urxvt zahteva poseben vti\u010dnik, ki bi URL-naslove pretvoril ob kliku ali s kombinacijo tipk. Drugi terminali, ki sem jih testiral, prikazujejo URL-naslove na druga\u010dne na\u010dine.<\/p>\n
Kon\u010dno, nov trend terminalov je opcionalnost pomi\u010dnega pomagalnika. Na primer, v st ni pomi\u010dnega pomagalnika; domneva se, da bo uporabnik uporabljal terminalski multiplexer, kot je tmux. GNU Screen<\/a><\/noindex>.<\/p>\n
V Alacritty prav tako ni pomi\u010dnih pomagalnikov, vendar bodo kmalu dodani.<\/a><\/noindex> Njihova podpora se bo pojavila zaradi \"obse\u017ene povratne informacije\" na to temo s strani uporabnikov. Poleg teh izjem je vsak terminal, ki sem ga preizkusil in na\u0161el, podpiral obratno pomikanje.<\/p>\n
Vmesni rezultati<\/h4>\n
\nV drugem delu gradiva (v izvirniku sta bili to dve lo\u010deni \u010dlanki, \u2014 op. red.<\/i>) bomo primerjali zmogljivost, uporabo pomnilnika in zakasnitve. Vendar pa \u017ee vidimo, da imajo nekateri od obravnavanih terminalov resne pomanjkljivosti. Na primer, uporabniki, ki redno delajo z RTL-skripti, lahko opazijo mlterm in pterm, saj se bolje spopadajo s tovrstnimi nalogami. Konsole se je prav tako dobro izkazal. Uporabniki, ki ne delajo z RTL-skripti, lahko izberejo kaj drugega.<\/p>\n
Z vidika za\u0161\u010dite pred vstavitvijo zlonamerne kode urxvt izstopa zaradi svoje posebne izvedbe za\u0161\u010dite pred tovrstnimi napadi, kar se mi zdi zagotovo koristno. Tistim, ki i\u0161\u010dejo kak\u0161ne posebne funkcije, naj pogledajo Konsole. Na koncu pa je vredno omeniti, da je VTE odli\u010dna osnova za terminale, ki zagotavlja podporo za barve, prepoznavanje URL-jev in tako naprej. Na prvi pogled se lahko privzeti terminal, ki ga ponuja va\u0161a najljub\u0161a okolica, zdi, da izpolnjuje vse zahteve, a pustimo to vpra\u0161anje odprto, dokler ne razjasnimo zmogljivosti.<\/p>\n
<\/p>\n
Nadaljujemo pogovor<\/h4>\n
<\/i>
\nNa splo\u0161no se lahko zmogljivost terminalov zdi umetno ustvarjen problem, vendar se je izkazalo, da nekateri med njimi ka\u017eejo izjemno velika zakasnitve za tako temeljno programsko opremo. Nadalje bomo pregledali tisto, kar tradicionalno imenujemo \"hitrost\" (pravzaprav gre za hitrost pomikanja) in porabo pomnilnika terminala (ob upo\u0161tevanju, da to danes ni tako kriti\u010dno, kot je bilo pred desetletji).<\/p>\n
Ka\u0161njenje<\/h4>\n
\nPo temeljitem raziskovanju zmogljivosti terminalov sem pri\u0161el do zaklju\u010dka, da je najpomembnej\u0161i parameter v tem smislu velikost zakasnitve (ping). V svojem \u010dlanku \u00bbTiskamo z veseljem\u00ab<\/a><\/noindex> Pavel Fatin je obravnaval zamudo razli\u010dnih urejevalnikov besedil in namignil, da terminali na tem podro\u010dju morda delujejo po\u010dasneje od najhitrej\u0161ih urejevalnikov besedil. Ta namig me je na koncu spodbudil, da sem za\u010del lastne teste in napisal ta \u010dlanek.<\/p>\n
Ampak kaj je zamuda in zakaj je tako pomembna? V svojem \u010dlanku je Fatin opredelil zamudo kot \u00bbzamudo med pritiskom na tipko in ustreznim posodobitvijo zaslona\u00ab in citiral \u00bbPriro\u010dnik za interakcijo \u010dloveka s ra\u010dunalnikom\u00ab<\/a><\/noindex>, v katerem pi\u0161e: \u00bbZamuda v vizualni povratni informaciji na ra\u010dunalni\u0161kem zaslonu pomembno vpliva na vedenje tipkovnice in njeno zadovoljstvo.\u00ab<\/p>\n
Fatin pojasnjuje, da ta ping ima globlje posledice od preproste zadovoljstva: \u00bbtipkanje postane po\u010dasnej\u0161e, napak je ve\u010d, pove\u010dana je napetost o\u010di in mi\u0161ic\u00ab. Z drugimi besedami, ve\u010dja zamuda lahko vodi do tipkarskih napak ter zmanj\u0161anja kakovosti kode, saj pove\u010duje dodatno kognitivno obremenitev mo\u017eganov. A kar je \u0161e huje, ping \u00bbpove\u010duje napetost o\u010di in mi\u0161ic\u00ab, kar o\u010ditno pomeni razvoj poklicnih po\u0161kodb<\/a><\/noindex> v prihodnosti (o\u010ditno avtor misli na te\u017eave z o\u010dmi, hrbtom, rokami in seveda vidom \u2014 op. prev.<\/i>) zaradi ponavljajo\u010de se napetosti.<\/p>\n
Nekateri od teh u\u010dinkov so znani \u017ee dolgo, rezultati \u0438\u0441\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u043d\u0438\u044f<\/a><\/noindex>, objavljeni \u017ee leta 1976 v reviji Ergonomics, pa trdijo, da zamuda 100 milisekund \u00bbznatno poslab\u0161a hitrost tipkanja\u00ab. Pred kratkim je bilo v uporabni\u0161kem priro\u010dniku GNOME dodano sprejemljivo \u010dasovno zamudo<\/a><\/noindex> v 10 milisekundah, in \u010de gremo \u0161e naprej, Microsoft Research<\/a><\/noindex> prikazuje, da je ideal 1 milisekunda.<\/p>\n
Fatin je izvajal svoje teste na urejevalnikih besedil; ustvaril je prenosno orodje z imenom Typometer<\/a><\/noindex>, ki sem ga uporabil za preverjanje pinga v emulatorskih terminalih. Upo\u0161tevajte, da je bil test izveden v simulacijskem na\u010dinu: v resnici je treba upo\u0161tevati tudi zamudo vnosa (tipkovnica, USB krmilnik itd.) in izpisa (pomnilni\u0161ki pomnilnik grafi\u010dne kartice, monitor). Po Fatinhovih besedah \u200b\u200bje pri tipi\u010dnih konfiguracijah pribli\u017eno 20 ms. Ob uporabi igralne opreme je mogo\u010de dose\u010di vrednost le 3 milisekunde. Ker \u017ee imamo tako hitro opremo, aplikacija ne sme dodati nobene dodatne zamude. Fatinov cilj je zmanj\u0161ati zamudo aplikacije na 1 milisekundo ali celo dose\u010di igro brez izmerljive zamude<\/a><\/noindex>, kot v IntelliJ IDEA 15<\/a><\/noindex>.<\/p>\n
Tukaj so rezultati mojih meritev in nekateri rezultati Fatina, da poka\u017eem, da se moj eksperiment strinja z njegovimi testi:<\/p>\n
\"Pregled
\n
\nPrva stvar, ki me je presenetila, je bila bolj\u0161a odzivnost starih programov, kot sta xterm in mlterm. Kljub najslab\u0161i zamudi registracije (2,4 ms) so dosegli bolj\u0161i rezultat kot najhitrej\u0161i sodobni terminal (10,6 ms za st). Noben sodoben terminal ne pade pod prag 10 milisekund. Zlasti Alacritty ne izpolnjuje zahtev po \u00bbnajhitrej\u0161em med obstoje\u010dimi emulatorji terminalov\u00ab, \u010deprav so se njegovi rezultati izbolj\u0161ali od prvega pregleda leta 2017. Resni\u010dno so avtorji projekta seznanjeni s situacijo<\/a><\/noindex> in delajo na izbolj\u0161anju prikazovanja. Prav tako je treba opozoriti, da je Vim, ki uporablja GTK3, precej po\u010dasnej\u0161i od svojega ustreznika GTK2. Iz tega lahko sklepamo, da GTK3 ustvarja dodatno zamudo, kar vpliva na vse druge termine, ki ga uporabljajo (Terminator, Xfce4 Terminal in GNOME Terminal).<\/p>\n
Vendar so lahko razlike za oko nevidne. Kot pojasnjuje Fatin: \u00bbni nujno biti zavedajo\u010d se prisotnosti zamude, da bi imela u\u010dinek name\u00ab. Fatin tudi opozarja na standardni odklon: \u00bbvsaka odstopanja v trajanju zamude (tre\u0161enje) ustvarjajo dodatno obremenitev zaradi svoje nepredvidljivosti\u00ab.<\/p>\n
\"Pregled
\n
\nGrafikon zgoraj je bil pridobljen iz \u010distih Debian 9 (stretch) z i3 upravljanjem oken<\/a><\/noindex>. To okolje daje najbolj\u0161e rezultate pri testih za dolo\u010ditev zakasnitve. Izkazalo se je, da GNOME ustvari dodatni ping 20 ms za vse meritve. Mo\u017eno razlago za to predstavlja prisotnost programov z sinhronim obdelovanjem vhodnih dogodkov. Fatin za ta primer navaja Workrave<\/a><\/noindex>, ki dodaja zakasnitev, ko obdeluje vse vhodne dogodke sinhrono. Privzeto je GNOME opremljen tudi z upraviteljem oken Mutter<\/a><\/noindex>, ki ustvarja dodatno raven predpomnjenja, kar vpliva na ping in doda vsaj 8 milisekund zakasnitve.<\/p>\n
\"Pregled
\n<\/p>\n
Hitrost pomikanja<\/h4>\n
\nNaslednji test je tradicionalni preizkus \u00bbhitrosti\u00ab ali \u00bbpasovne \u0161irine\u00ab, ki meri, kako hitro terminal lahko pomika stran, prikazuje veliko \u0161tevilo besedila na zaslonu. Mehanika testa se razlikuje; izvorni test je bil preprosto generirati isto besedilno vrstico z uporabo ukaza seq. Drugi testi vklju\u010dujejo preverjanje Thomasa E. Dicka (s spremljajo\u010dim xterm), v okviru katerega se ve\u010dkrat izva\u017ea datoteka terminfo.src<\/a><\/noindex>. V \u0161e enem pregledu zmogljivosti terminalov Den Luu<\/a><\/noindex> uporablja vrstico naklju\u010dnih bajtov v kodiranju base32, ki se izpi\u0161e v terminalu z uporabo cat. Luu \u0161teje ta test za \u00bbtoliko neuporabnega etalona, kolikor si ga lahko zamislite\u00ab in predlaga, da se namesto tega uporabi odziv terminala kot glavni kazalnik. Dick prav tako imenuje svoj test zavajajo\u010d. Kljub temu oba avtorja priznavajo, da je propustnost okna terminala lahko problem. Luu je opazil zamrznitev Emacs Eshell pri prikazovanju velikih datotek, Dick pa je optimiziral terminal, da se znebi vizualne po\u010dasnosti xterm. Zato ima ta test \u0161e vedno nekaj smisla, vendar ker se proces upodabljanja mo\u010dno razlikuje od terminala do terminala, ga je mogo\u010de uporabiti tudi kot testni komponent za preverjanje drugih parametrov.<\/p>\n
\"Pregled
\n
\nTukaj vidimo, da sta rxvt in st prehitela konkurenco, za njima pa sledi precej novej\u0161i Alacritty, razvijan z osredoto\u010denostjo na hitro delovanje. Naslednja sta Xfce (dru\u017eina VTE) in Konsole, ki delujeta skoraj dvakrat hitreje. Zadnji je xterm, ki je petkrat po\u010dasnej\u0161i od rxvt. Med testom je xterm tudi mo\u010dno migal, prehajajo\u010dega besedila ni bilo mogo\u010de dobro prebrati, tudi \u010de je bila to ista vrstica. Konsole se je izkazal za hitrega, vendar je v\u010dasih \u201eprevaral\u201c: zaslon se je ob\u010dasno ustavil, delno prikazoval besedilo ali ga sploh ni prikazoval. Drugi terminali, vklju\u010dno s st, Alacritty in rxvt, so prikazovali vrstice jasno.<\/p>\n
Diki pojasnjuje, da so razlike v zmogljivosti povezane z oblikovanjem pomnilnika za pomikanje v razli\u010dnih terminalih. \u0160 particularly, obto\u017euje rxvt in druge terminale, da \u201ene sledijo splo\u0161nim pravilom\u201c:<\/p>\n
\u201eZa razliko od xterm, rxvt ni posku\u0161al prikazati vseh posodobitev. \u010ce zaostaja, se odre\u010de nekaterim posodobitvam, da bi nadoknadil zamudo. To je imelo ve\u010dji vpliv na zaznano hitrost pomikanja, kot pa na organizacijo notranjega pomnilnika. Ena pomanjkljivost pa je bila, da je bila animacija ASCII nekoliko neto\u010dna.\u201c<\/p><\/blockquote>\n
\nZa odpravo te o\u010ditne po\u010dasnosti xterm Diki predlaga uporabo vira fastScroll<\/a><\/noindex>, ki omogo\u010da xterm, da zavr\u017ee nekatere posodobitve zaslona, da ne bi zaostal za tokom. Moji testi potrjujejo, da fastScroll pove\u010duje zmogljivost in izena\u010duje xterm z rxvt. Vendar pa je to precej grob popravek, kot sam Diki pojasnjuje: \u201ev\u010dasih se zdi, da xterm \u2014 kot tudi konsole \u2014 ustavi, ker \u010daka na nov sklop posodobitev zaslona, potem ko so nekateri od njih bili odstranjeni\u201c. V tej lu\u010di se zdi, da so drugi terminali na\u0161li najbolj\u0161i kompromis med hitrostjo in celovitostjo zaslona.<\/p>\n
Poraba virov<\/h4>\n
\nNe glede na to, ali je smiselno obravnavati hitrost pomikanja kot merilo zmogljivosti, ta test omogo\u010da simulacijo obremenitve terminalov, kar nam omogo\u010da merjenje drugih parametrov, kot so raba pomnilnika ali diska. Metri\u010dni podatki so bili pridobljeni z izvajanjem navedenega testa seq<\/b> pod nadzorom procesa Python. Zbiral je podatke \u0161tevcov getrusage ()<\/a><\/noindex> za ru_maxrss<\/b>, skupno ru_oublock<\/b> in ru_inblock<\/b> in preprost \u010dasomer.<\/p>\n
\"Pregled
\n
\nV tem testu ST zaseda prvo mesto z najni\u017ejo povpre\u010dno porabo pomnilnika, ki zna\u0161a 8 MB, kar ni presenetljivo, \u010de upo\u0161tevamo, da je osnovna ideja projekta preprostost. Mlterm, xterm in rxvt porabijo nekoliko ve\u010d \u2014 okoli 12 MB. Drugi opazni rezultati se pojavijo pri Alacritty, ki za delovanje potrebuje 30 MB. Nato so tu terminali dru\u017eine VTE z rezultati med 40 in 60 MB, kar je precej veliko. Tako visoka poraba je razlo\u017eena s tem, da ti terminali uporabljajo knji\u017enice vi\u0161je ravni, kot je GTK. Konsole je na koncu s kolosalno porabo 65 MB pomnilnika med testi, \u010deprav je to mogo\u010de opravi\u010diti z njegovim \u0161irokim naborom funkcij.<\/p>\n
V primerjavi s prej\u0161njimi rezultati, pridobljenimi pred desetimi leti, so vse aplikacije za\u010dele porabljati znatno ve\u010d pomnilnika. V preteklosti je Xterm potreboval 4 MB, zdaj pa 15 MB samo za zagon. Podobno pove\u010danje porabe je pri rxvt, ki zdaj iz \u0161katle potrebuje 16 MB. Terminal Xfce zavzema 34 MB, kar je trikrat ve\u010d kot prej, medtem ko GNOME Terminal potrebuje le 20 MB. Seveda so vsi prej\u0161nji testi potekali na 32-bitni arhitekturi. Na LCA 2012 Rasti Russell je povedal<\/a><\/noindex>, kar pomeni, da obstaja veliko bolj subtilnih razlogov, ki lahko razlo\u017eijo rast porabe pomnilnika. Kljub temu zdaj \u017eivimo v \u010dasu, ko imamo cele gigabajte pomnilnika, zato se bomo \u017ee nekako spoprijeli.<\/p>\n
Kljub temu ne morem znebiti ob\u010dutka, da je dodelitev ve\u010d pomnilnika za tako temeljno programsko opremo, kot je terminal, prazna izguba virov. Te aplikacije bi morale biti najmanj\u0161e med najmanj\u0161imi, zmo\u017ene delovati na vsakem '\u0161katlu', celo na \u010devljarski, \u010de kdaj pridemo do to\u010dke, ko jih bomo morali opremiti z Linux sistemi (in veste, da bo tako). Toda s temi \u0161tevilkami bo poraba pomnilnika v prihodnosti problem v kateremkoli okolju pri zagonu ve\u010d terminalov, razen v primerih z ve\u010dimi najla\u017ejimi in najbolj omejenimi mo\u017enostmi. Da bi to kompenzirali, imajo GNOME Terminal, Konsole, urxvt, Terminator in Xfce Terminal na\u010din Daemon, ki omogo\u010da upravljanje ve\u010d terminalov preko enega procesa, kar omejuje njihovo porabo pomnilnika.<\/p>\n
\"Pregled
\n
\nMed svojim testiranjem sem naletel na \u0161e en nepri\u010dakovan rezultat glede branja in pisanja podatkov na disk: pri\u010dakoval sem, da tukaj ne bom videl ni\u010desar, a se je izkazalo, da nekateri terminali zapisujejo najve\u010dje koli\u010dine podatkov na disk. Tako knji\u017enica VTE dejansko hran\u00ed v spominu pomnilni\u0161ki predpomnilnik (to lastnost smo opazili \u017ee leta 2010<\/a><\/noindex>, in to se dogaja \u0161e danes). Toda v nasprotju s starimi implementacijami, so zdaj vsaj ti podatki \u0161ifrirani z uporabo AES256 GCM (od razli\u010dice 0.39.2<\/a><\/noindex>). Vendar se postavlja razumen vpra\u0161anje, kaj je tako posebnega v knji\u017enici VTE, da zahteva tak\u0161en nestandarden pristop k implementaciji\u2026<\/p>\n
Zaklju\u010dek<\/h4>\n
\nV prvem delu \u010dlanka smo ugotovili, da terminali, zasnovani na VTE, ponujajo dober nabor funkcij, a zdaj vidimo, da je to povezano z nekaterimi stro\u0161ki za zagotavljanje njihove zmogljivosti. Trenutno spomin ni te\u017eava, ker vse VTE terminale nadzira Daemon proces, ki omejuje njihov apetit. Kljub temu pa lahko starej\u0161i sistemi, ki imajo fizi\u010dne omejitve glede koli\u010dine delovnega spomina in predpomnilnika jedra, \u0161e vedno potrebujejo zgodnej\u0161e razli\u010dice terminalov, saj porabijo bistveno manj virov. \u010ceprav so se terminali VTE dobro odrezali pri testih prepustnosti (pomikanje), je njihova zakasnitev pri prikazu podatkov na zaslonu nad dolo\u010denim pragom v uporabni\u0161kem priro\u010dniku GNOME. Verjetno bi si morali razvijalci VTE to zapomniti. \u010ce upo\u0161tevamo, da se tudi za\u010detniki v Linuxu ne morejo izogniti sre\u010danju s terminalom, bi lahko ta postal bolj prijazen do uporabnikov. Za izku\u0161ene geek-e pa bi prehod na privzeti terminal lahko pomenil tudi zmanj\u0161anje obremenitve za o\u010di in mo\u017enost izogibanja poklicnim po\u0161kodbam ter boleznim v prihodnosti zaradi dolgotrajnih delovnih sej. Na \u017ealost nas samo stari xterm in mlterm pripeljeta do \u010darobnega praga pinga pri 10 milisekundah, kar mnogim ni sprejemljivo.<\/p>\n
Kontrolne mere so prav tako pokazale, da so se zaradi razvoja grafi\u010dnih okolij Linux razvijalci morali odlo\u010diti za vrsto kompromisov. Nekaterim uporabnikom bi bilo smiselno pogledati obi\u010dajne upravljavce oken, saj zagotavljajo znatno zmanj\u0161anje pinga. Na \u017ealost ni bilo mogo\u010de izmeriti zakasnitve za Wayland: program Typometer, ki sem ga uporabljal, je bil ustvarjen za to, kar Wayland \u017eeli prepre\u010diti \u2014 vohunjenje za drugimi okni. Upam, da je kompozicija Waylanda bolj\u0161a glede zmogljivosti kot X.org, prav tako pa upam, da bo v prihodnosti nekdo na\u0161el na\u010din za oceno ravni zakasnitve v tem okolju.
\n
Izvor: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u041f\u0430\u0440\u0430 \u0441\u043b\u043e\u0432 \u043e\u0442 \u043d\u0430\u0448\u0435\u0433\u043e translate-\u0431\u044e\u0440\u043e: \u043e\u0431\u044b\u0447\u043d\u043e \u0432\u0441\u0435 \u0441\u0442\u0440\u0435\u043c\u044f\u0442\u0441\u044f \u043f\u0435\u0440\u0435\u0432\u043e\u0434\u0438\u0442\u044c \u0441\u0430\u043c\u044b\u0435 \u0441\u0432\u0435\u0436\u0438\u0435 \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u044b \u0438 \u043f\u0443\u0431\u043b\u0438\u043a\u0430\u0446\u0438\u0438, \u0438 \u043c\u044b \u043d\u0435 \u0438\u0441\u043a\u043b\u044e\u0447\u0435\u043d\u0438\u0435. \u041d\u043e \u0442\u0435\u0440\u043c\u0438\u043d\u0430\u043b\u044b \u2014 \u044d\u0442\u043e \u043d\u0435 \u0442\u043e, \u0447\u0442\u043e \u043e\u0431\u043d\u043e\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0440\u0430\u0437 \u0432 \u043d\u0435\u0434\u0435\u043b\u044e. \u041f\u043e\u044d\u0442\u043e\u043c\u0443 \u043c\u044b \u043f\u0435\u0440\u0435\u0432\u0435\u043b\u0438 \u0434\u043b\u044f \u0432\u0430\u0441 \u0441\u0442\u0430\u0442\u044c\u044e \u0410\u043d\u0442\u0443\u0430\u043d\u0430 \u0411\u043e\u043f\u0440\u0435, \u043e\u043f\u0443\u0431\u043b\u0438\u043a\u043e\u0432\u0430\u043d\u043d\u0443\u044e \u0432\u0435\u0441\u043d\u043e\u0439 2018 \u0433\u043e\u0434\u0430: \u043d\u0435\u0441\u043c\u043e\u0442\u0440\u044f \u043d\u0430 \u0441\u043e\u043b\u0438\u0434\u043d\u044b\u0439 \u043f\u043e \u0441\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u043c \u043c\u0435\u0440\u043a\u0430\u043c \u00ab\u0432\u043e\u0437\u0440\u0430\u0441\u0442\u00bb, \u043d\u0430 \u043d\u0430\u0448 \u0432\u0437\u0433\u043b\u044f\u0434, \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b \u0441\u043e\u0432\u0435\u0440\u0448\u0435\u043d\u043d\u043e \u043d\u0435 \u043f\u043e\u0442\u0435\u0440\u044f\u043b […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":27911,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-37222","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47PREGLED EMULATORJEV TERMINALOV | ProHoster","description":"Beseda od na\u0161e prevajalske agencije: obi\u010dajno si vsi prizadevamo prevajati najnovej\u0161e materiale in objave, in mi nismo izjema. A terminali niso nekaj, kar se posodablja enkrat na teden.","canonical_url":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/obzor-emulyatorov-terminala","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sl_SI","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041e\u0431\u0437\u043e\u0440 \u044d\u043c\u0443\u043b\u044f\u0442\u043e\u0440\u043e\u0432 \u0442\u0435\u0440\u043c\u0438\u043d\u0430\u043b\u0430 | ProHoster","og:description":"\u041f\u0430\u0440\u0430 \u0441\u043b\u043e\u0432 \u043e\u0442 \u043d\u0430\u0448\u0435\u0433\u043e translate-\u0431\u044e\u0440\u043e: \u043e\u0431\u044b\u0447\u043d\u043e \u0432\u0441\u0435 \u0441\u0442\u0440\u0435\u043c\u044f\u0442\u0441\u044f \u043f\u0435\u0440\u0435\u0432\u043e\u0434\u0438\u0442\u044c \u0441\u0430\u043c\u044b\u0435 \u0441\u0432\u0435\u0436\u0438\u0435 \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u044b \u0438 \u043f\u0443\u0431\u043b\u0438\u043a\u0430\u0446\u0438\u0438, \u0438 \u043c\u044b \u043d\u0435 \u0438\u0441\u043a\u043b\u044e\u0447\u0435\u043d\u0438\u0435. \u041d\u043e \u0442\u0435\u0440\u043c\u0438\u043d\u0430\u043b\u044b \u2014 \u044d\u0442\u043e \u043d\u0435 \u0442\u043e, \u0447\u0442\u043e \u043e\u0431\u043d\u043e\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0440\u0430\u0437 \u0432 \u043d\u0435\u0434\u0435\u043b\u044e.","og:url":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/obzor-emulyatorov-terminala","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:16:26+00:00","article:modified_time":"2019-10-31T19:16:26+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"37222","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 16:48:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:31:24","updated":"2026-01-23 16:48:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/37222","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/comments?post=37222"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/37222\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media\/27911"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media?parent=37222"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/categories?post=37222"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/tags?post=37222"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}