Néhány szó a fordítóirodánktól: általában mindenki a legújabb anyagok és publikációk fordítására törekszik, és mi sem vagyunk kivételek. De a terminálok nem olyanok, amik hetente frissülnek. Ezért lefordítottuk Antoine Bopre 2018 tavaszán közzétett cikkét: a szerződéses életkorához képest teljesen aktuálisnak tartjuk az anyagot. Ezen kívül az eredeti cikk egy két részes sorozat, de úgy döntöttünk, hogy egy nagy posztba foglaljuk őket.
A terminálok különleges helyet foglalnak el a számítástechnika történetében, de az elmúlt évtizedekben szó szerint együtt kellett élniük a parancssorral a grafikusan elterjedt felületek hátterében. helyettesítették hardveres megfelelőiket Néhány terminálban meglepő biztonsági réseket találhatunk, ráadásul a legtöbbjük nagyon eltérő funkciókkal rendelkezik, a tabbed felület támogatásától a szkriptekig. Bár mi
régen foglalkoztunk terminálemulátorokkal Íme az általam megvizsgált terminálok:
Вот рассмотренные мной терминалы:
Lehetséges, hogy ezek nem a legfrissebb verziók, mivel a megírás időpontjában a stabil kiadásokra korlátozódtam, amelyeket Debian 9-en vagy Fedora 27-en tudtam telepíteni. Az egyetlen kivétel az Alacritty. Ez egy GPU-gyorsítással rendelkező terminálok utódja, és egy szokatlan, új nyelven íródott ehhez a feladathoz — Rust. Kizártam a web-terminálokat a bemutatómból (így a ), mert a kezdeti tesztek rendkívül alacsony teljesítményt mutattak.
Unicode támogatás
A tesztjeimet a Unicode támogatással kezdtem. Az első terminálteszt a Unicode-ról a következő szöveg megjelenítése volt : „é, Δ, Й, ק, م, ๗, あ, 叶, 葉 és 말”. Ez az egyszerű teszt megmutatja, hogy a terminál képes-e helyesen működni világszerte. Az xterm terminál nem jeleníti meg az arab karaktert alapértelmezett konfigurációban:
Alapértelmezés szerint az xterm a klasszikus „fix” betűtípust használja, amely szerint , „jelentős Unicode-támogatása 1997 óta van”. Ebben a betűtípusban valami történik, ami üres keretként jeleníti meg a karaktert, és csak akkor kezd el helyesen megjelenni, amikor a szöveg betűméretét 20+ pontra növelem. Azonban ez a „javítás” megszakítja más Unicode karakterek megjelenítését:
Ezek a képernyőképek a Fedora 27-en készültek, mivel ez adta a legjobb eredményeket a Debian 9-hez képest, ahol néhány régi terminálverzió (nevezetesen — mlterm) nem tudta megfelelően kezelni a betűtípusokat. Szerencsére ezt későbbi verziókban javították.
Most nézzük meg az xterm-ben a sor megjelenítését. Kiderül, hogy a Mem karakter és a mögötte álló szemita karakterek a RTL () írási irányhoz tartoznak, így technikailag jobbról balra kellene megjelenniük. A webböngészők, például a Firefox 57, helyesen kezelik a fent említett szöveget. Az RTL szöveg egyszerűbb változata a „” szó héberül (). „Sok számítógépes program nem tudja helyesen megjeleníteni a kétnyelvű szöveget. Például a héber név „Sara” a sin (ש) (ami jobbról áll), majd a resh (ר) és végül a he (ה) (ami balról kellene, hogy álljon) karaktereiből áll.”
«Многие компьютерные программы не могут правильно отображать двунаправленный текст. Например, еврейское имя «Сара» состоит из символов син (ש) (который появляется справа), затем реш (ר) и, наконец, хе (ה) (который должен появляться слева)».
Sok terminál nem teljesíti ezt a tesztet: Alacritty, Gnome és XFCE VTE-terminálok, urxvt, st és xterm az „Sara” szót fordítva jeleníti meg, mintha a nevet „Aras”-nak írnánk le.
A kétnyelvű szövegek másik problémája, hogy valahogy össze kell őket hangolni, különösen ha RTL és LTR szövegek keverednek. Az RTL szkripteknek a terminál ablakának jobb oldalán kell megjelenniük, de mi történik azokkal a terminálokkal, amelyek alapértelmezetten LTR angolul működnek? A legtöbbjük nem rendelkezik különleges mechanizmusokkal, és minden szöveget balra igazítanak (beleértve a Konsole-t is). Kivételt képez a pterm és mlterm, amelyek betartják a szabványokat és az ilyen sorokat jobbra igazítják.
Beillesztés elleni védelem
A következő kritikus jellemző, amelyet kijelöltem, a beillesztés elleni védelem. Bár széles körben ismert, hogy az olyan parancsok, mint:
$ curl http://example.com/ | shkódvégrehajtó push-parancsok, kevesen tudják, hogy rejtett parancsok is bejuthatnak a konzolba, ha másolják-beillesztik őket egy webböngészőből, még alapos ellenőrzés után is. kiválóan bemutatja, hogy a látszólag ártalmatlan parancsból:
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gita Horn webhelyről való beillesztés után a terminálban így néz ki:
git clone /dev/null;
clear;
echo -n "Hello ";
whoami|tr -d 'n';
echo -e '!nAz rossz ötlet volt. Ne másolj kódot olyan webhelyekről, amikben nem bízol!
Itt a /etc/passwd első sora: ';
head -n1 /etc/passwd
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitHogyan működik ez? A kártékony kód a <spаn>, blokkba kerül, amely CSS segítségével nem látható a felhasználó számára.
kifejezetten az ilyen támadások semlegesítésére lett kifejlesztve. Ebben a módban a terminálok beillesztett szöveget záró speciális escape-sorozatokkal keretezik, hogy tájékoztassák a shellt a szöveg eredetéről. Így a shell jelet kap, hogy elhanyagolhatja a beillesztett szöveget esetleg tartalmazó speciális karaktereket. Minden terminál, beleértve a tiszteletbeli xterm-et is, támogatja ezt a funkciót, azonban a Bracketed módban való beillesztés támogatást igényel a shelltől vagy az alkalmazástól, amely a terminálon fut. Például a (ugyanaz, mint Bash) szüksége van egy fájlra ~ /.inputrc:
set enable-bracketed-paste onSajnos, a Horn tesztoldala is megmutatja, hogyan kerülhető meg ez a védelem a szöveg önálló formázásán keresztül, és hogyan lehet előre befejezni a Bracketed mód alkalmazását. Ez azért működik, mert egyes terminálok helytelenül szűrik a menekülési szekvenciákat, mielőtt hozzáadnák a sajátjukat. Például az én gépemen nem tudtam sikeresen befejezni a Konsole tesztjeit, még a helyes konfiguráció figyelembevételével sem. .inputrc fájl. Ez azt jelenti, hogy könnyen kaphat sérült rendszerkonfigurációt nem támogatott alkalmazás vagy rosszul beállított shell miatt. Különösen veszélyes ez távoli szerverekre való belépéskor, ahol a konfiguráció gondos kidolgozása ritkább, főleg ha sok ilyen távoli gép van.
A probléma jó megoldása a terminálhoz készült beillesztési megerősítő bővítmény urxvt, amely egyszerűen engedélyt kér minden, új sorokat tartalmazó szöveg beillesztésére. Erősebb megoldást a Hornt által leírt szöveges támadásra nem találtam.
Fülek és profilok
Jelenleg népszerű funkció a fülkezelő felület támogatása, amelyet úgy definiálunk, mint egy terminálablakot, amely több terminált tartalmaz. Különböző terminálok esetén ez a funkció eltérő, és bár a hagyományos xterm típusú terminálok egyáltalán nem támogatják a füleket, a modernebb terminálok, mint az Xfce Terminal, GNOME Terminal és Konsole, rendelkeznek ezzel a funkcióval. Az Urxvt is támogatja a füleket, de csak bővítmény használata esetén. De fül támogatás szempontjából a Terminator kétségtelenül az élen jár: nemcsak a füleket támogatja, hanem a terminálokat is tetszőleges sorrendbe tudja helyezni (lásd az alábbi képet).
A Terminator egy másik jellemzője, hogy lehetővé teszi a fülek „csoportosítását”, és ugyanazokat a billentyűleütéseket több terminálba egyszerre küldheti, ami egy durva eszközt biztosít tömeges műveletek végrehajtására több szerveren egyidejűleg. Hasonló funkciót a Konsole is megvalósít. E funkció használatához más terminálokon külső szoftverre van szükség, mint például , vagy .
Különösen jól működnek a fülkék a profilokkal együtt: például lehet egy fül az e-mailhez, egy másik a csevegéshez, és így tovább. Ezt jól támogatja a Konsole és a GNOME Terminal. Mindkettő lehetővé teszi, hogy minden fül automatikusan elindítja a saját profilját. A Terminátor szintén támogatja a profilokat, de nem találtam módot arra, hogy automatikusan elindítsam a meghatározott programokat egy adott fül megnyitásakor. Más terminálok egyáltalán nem ismerik a „profil” fogalmát.
Frufru
Az utolsó dolog, amit az article első részében megvizsgálok, a terminálok megjelenése. Például a GNOME, Xfce és urxvt támogatják az átlátszóságot, de nemrégiben megszüntették a háttérképek támogatását, ami arra kényszerítette egyes felhasználókat, hogy átálljanak más terminálokra. . Személy szerint nekem ez is megfelel, egyszerűen Xresources, amely alapértelmezett háttérszín-készletet állít be az urxvt számára. Azonban a nem szabványos színsémák problémákat okozhatnak. Például, alkalmazásokkal és , mivel már saját színeiket használják.
nem támogatta a színeket, míg az újabbak gyakran 256 színű palettára korlátozódtak. A tapasztalt felhasználók, akik bonyolult módon stilizálják a termináljaikat, kellemetlen korlátozásokat tapasztalhatnak a parancssori kérések vagy állapotsorok formázásakor. nyomon követi, hogy mely terminálok támogatják a „True Color” funkciót. A tesztjeim megerősítik, hogy az st, Alacritty és a VTE alapú terminálok remekül támogatják a True Color-t. Más terminálok ebben a tekintetben nem teljesítenek jól, és valójában még 256 színt sem jelenítenek meg. Az alábbiakban láthatja a különbséget a True Color támogatásban a GNOME, st és xterm terminálok között, amelyek elég jól teljesítenek a 256 színű palettájukkal, és az urxvt, amely nemcsak hogy nem teljesíti a tesztet, hanem valamilyen villogó szimbólumokat is mutat helyettük.
Néhány terminál szintén elemzi a szöveget URL-minták alapján, hogy kattintható linkeket hozzon létre. Ez minden VTE-ből származó terminálra vonatkozik, míg az urxvt speciális bővítményt igényel, amely átalakítja az URL-címeket kattintásra vagy billentyűparancs segítségével. Más tesztelt terminálok eltérő módon jelenítik meg az URL-címeket.
Végre, az új termináltrendi választási lehetőség a görgetési puffernél. Például az st terminálban nincs görgetési puffer, azt feltételezik, hogy a felhasználó terminálmultiplexert, mint a tmux-ot fog használni, és .
Az Alacritty-ben szintén nincsenek visszagörgetési pufferek, de a támogatása a felhasználók számára érkezett "széleskörű visszajelzések" miatt erről a témáról. Ezeken a kivételeken kívül minden általam ellenőrzött terminál, amit megtaláltam, támogatja a visszagörgetést.
Közbenső eredmények
A cikk második részében (eredetileg ez két külön cikk volt — a fordító megjegyzése.) összehasonlítjuk a teljesítményt, a memóriahasználatot és a késleltetést. De már látjuk, hogy néhány vizsgált terminálnak komoly hátrányai vannak. Például a RTL-skriptekkel rendszeresen dolgozó felhasználók figyelmét a mlterm és pterm vonzza, mivel ezek jobban kezelik az ilyen feladatokat. A Konsole szintén jól teljesített. Az RTL-skriptekkel nem foglalkozó felhasználók választhatnak valami mást.
A rosszindulatú kódbeillesztés elleni védelmet nézve az urxvt különálló helyet foglal el a támadásokkal szembeni védelem sajátos megvalósítása miatt, amely számomra határozottan kényelmes. Aki valami extrát keres, nézzen meg a Konsole-t. Végül meg kell említeni, hogy a VTE nagyszerű alapként szolgál a terminálok számára, amely garantálja a szín támogatását, az URL-ek felismerését és így tovább. Első pillantásra a kedvenc környezettel szállított alapértelmezett terminál minden igénynek megfelelhet, de ezt a kérdést nyitva hagyjuk, amíg a teljesítményével nem fogunk foglalkozni.
Folytassuk a beszélgetést
Valójában a terminálok teljesítménye önmagában álproblémának tűnhet, de kiderült, hogy közülük néhány meglepően nagy késleltetést mutat az ilyen alapvető típusú szoftverek esetében. Továbbá megvizsgáljuk azt, amit hagyományosan "sebességnek" neveznek (valójában ez a görgetés sebessége) és a terminál memóriahasználatát (figyelembe véve, hogy ma már ez nem olyan kritikus, mint évtizedekkel ezelőtt).
Késleltetés
A terminálok teljesítményének alapos vizsgálata után arra a következtetésre jutottam, hogy ebben a tekintetben a legfontosabb paraméter a késleltetés mértéke (ping). Az írásomban Pavel Fatin megvizsgálta a különböző szövegszerkesztők késlekedését, és arra utalt, hogy a terminálok ebben a tekintetben lassabban működhetnek, mint a leggyorsabb szövegszerkesztők. Ez az utalás vezetett végül saját tesztjeim elindításához és ennek a cikknek a megírásához.
De mi is az a késlekedés, és miért olyan fontos? Fatin a cikkében „a billentyű lenyomása és a képernyő megfelelő frissítése közötti késlekedésként“ határozta meg, és idézte , amelyben azt állítják: „A késlekedés a számítógép kijelzőjén a vizuális visszajelzésben jelentős hatással van a gépíró viselkedésére és elégedettségére.“
Fatin magyarázza, hogy ez a ping egy mélyebb következményekkel jár, mint egyszerűen a kényelmesség: „a gépelés lassabbá válik, több hiba történik, nő a szem- és izomfeszültség.” Más szóval, a nagyobb késlekedés gépelési hibákhoz vezethet, és csökkentheti a kód minőségét, mivel extra kognitív terhet ró az agyra. De ami még rosszabb, a ping „növeli a szem- és izomfeszültséget“, ami nyilvánvalóan utal (úgy tűnik, hogy a szerző a szem, hát, kéz és természetesen a látás problémáira utal - a fordító megj.) a folyamatos feszültség miatt.
Ezek közül néhány hatás régóta ismert, és az , amelyeket már 1976-ban tettek közzé az Ergonomics folyóiratban, azt mutatják, hogy a 100 milliszekundumos késlekedés „jelentősen rontja a gépelési sebességet“. Nemrégiben a GNOME felhasználói kézikönyvébe bekerült 10 milliszekundumra, és ha tovább megyünk, akkor megmutatja, hogy az ideális 1 milliszekundum.
Fatin a szövegszerkesztőken végezte a tesztjeit; létrehozott egy hordozható eszközt, amelyet , amelyet a ping ellenőrzésére használtam terminálemulátorokban. Ne feledje, hogy a teszt szimulációs módban zajlott: valójában figyelembe kell venni a bemeneti (billentyűzet, USB-vezérlő stb.) és a kimeneti (videokártya puffere, monitor) késleltetést. Fatinj szerint a tipikus konfigurációkban ez körülbelül 20 ms. Játékberendezéssel 3 milliszekundumos eredmény is elérhető. Mivel már van ilyen gyors berendezésünk, az alkalmazásnak nem szabad további késleltetést okoznia. Fatinj célja, hogy az alkalmazás késleltetését 1 milliszekundumra csökkentse, vagy akár elérje a késleltetés nélküli bevitelt. , mint a .
Ezek a méréseim eredményei, valamint Fatinj néhány mérése, hogy megmutassam, hogy kísérletem összhangban van az ő tesztjeivel:
Elsőként lenyűgözött, hogy a régi programok, mint az xterm és mlterm, jobb válaszidőt mutattak. A legrosszabb regisztrációs késleltetéssel (2,4 ms) jobb eredményt értek el, mint a leggyorsabb modern terminál (10,6 ms az st esetében). Egy modern terminál sem esik 10 milliszekundum alá. Különösen az Alacritty nem felel meg a „leggyorsabb terminálemulátor” követelményeinek, bár az eredményei javultak az első ellenőrzés óta 2017-ben. Valóban, a projekt szerzői és dolgoznak a megjelenés javításán. Meg kell említeni, hogy a GTK3-at használó Vim lényegesen lassabb, mint GTK2-es megfelelője. Ez arra utal, hogy a GTK3 további késleltetést okoz, ami tükröződik az összes többi terminálban is, amelyek ezt használják (Terminator, Xfce4 Terminal és GNOME Terminal).
Azonban a szem számára a különbségek észrevétlenek lehetnek. Ahogy Fatinj magyarázza: „nem feltétlenül szükséges tudomásul venni a késleltetés jelenlétét ahhoz, hogy hatással legyen rád”. Fatinj a normál eloszlásra is figyelmeztet: „bármilyen zavar a késleltetés tartamában (rezgés) további terhet jelent az előrejelezhetetlenség miatt”.
A fenti grafikon egy tiszta Debian 9 (stretch) rendszerből származik, . Ez a környezet a legjobb eredményeket nyújtja a késleltetés meghatározására szolgáló tesztekben. Kiderült, hogy a GNOME 20 ms extra pinget generál minden méréshez. A lehetséges magyarázat ennek az, hogy vannak olyan programok, amelyek szinkron módon dolgozzák fel a bejövő eseményeket. Fatin példaként említi ezt az esetet. , amely késleltetést ad, mivel az összes beviteli eseményt szinkron módon dolgozza fel. Alapértelmezés szerint a GNOME ablakkezelője is rendelkezik. , amely további puffereket hoz létre, ami befolyásolja a pinget, és legalább 8 milliszekundumos késleltetést ad hozzá.
Görgetési sebesség
A következő teszt a hagyományos „sebesség” vagy „sávszélesség” vizsgálata, amely azt méri, hogy a terminál milyen gyorsan tudja görgetni az oldalt, miközben nagy mennyiségű szöveget jelenít meg a képernyőn. A teszt mechanikája változó; az eredeti teszt abból állt, hogy egyszerűen ugyanazon szövegsort generáltuk a seq parancs segítségével. Más tesztek között szerepel Thomas E. Dick tesztje (amely kíséri az xtermet), amely során többször。 . Egy másik teljesítményértékelésben véletlenszerű bájtok sorozatát használja base32 kódolásban, amelyet a terminálba a cat parancs segítségével küld be. Luu ezt a tesztet „annyira haszontalan mérőszámnak tartja, amennyire csak lehet” és azt javasolja, hogy inkább a terminál válaszát használjuk fő mutatóként. Dick is félrevezetőnek tartja a saját tesztjét. Mindazonáltal mindkét szerző elismeri, hogy a terminálablak sávszélessége problémát jelenthet. Luu észlelte az Emacs Eshell akadozását, miközben nagy fájlokat jelenített meg, míg Dick optimalizálta a terminált, hogy megszabaduljon az xterm vizuális lassúságától. Ezért ebben a tesztben még mindig van némi érvényesség, de mivel a renderelési folyamat terminálról terminálra jelentősen eltér, tesztkomponensként is felhasználható más paraméterek ellenőrzésére.
Itt láthatjuk, hogy az rxvt és az st előtérbe kerülnek a versenytársakkal szemben, mögöttük következik a sokkal újabb Alacritty, amely a teljesítményre összpontosít. A következő helyen áll a Xfce (VTE család) és a Konsole, amelyek szinte kétszer gyorsabbak. Utolsóként az xterm szerepel, amely ötödször lassabb, mint az rxvt. A teszt során az xterm is erősen rezgett, a futó szöveget nehéz volt észrevenni, még ha ugyanarról a sorral volt is szó. A Konsole gyorsnak bizonyult, de időnként „trükközött”: a kijelző néha megakadt, a szöveget részben mutatta, vagy egyáltalán nem jelenítette meg. Más terminálok éles vonalakat mutattak, beleértve az st, Alacritty és rxvt terminálokat.
Diki elmagyarázza, hogy a teljesítménybeli különbségeket a különböző terminálok görgetési pufferei közötti tervezési eltérések okozzák. Különösen az rxvt-t és más terminálokat hibáztatja, hogy "nem követik az általános szabályokat":
"Ellenkezőleg, az xtermhez képest az rxvt nem próbálta megjeleníteni az összes frissítést. Ha lemarad, lemond néhány frissítésről, hogy utolérje magát. Ez nagyobb hatással volt a látszólagos görgetési sebességre, mint a belső memória elrendezésére. Az egyik hátránya az volt, hogy az ASCII animációk kissé pontosatlanok voltak."
Az xterm látszólagos lassulásának orvoslására Diki azt javasolja, hogy használjunk egy erőforrást , amely lehetővé teszi, hogy az xterm eldobja néhány képernyőfrissítést, hogy ne maradjon le az áramlásról. A tesztjeim megerősítik, hogy a fastScroll javítja a teljesítményt és az xterm-t az rxvt szintjére emeli. Ez azonban egy meglehetősen durva megoldás, ahogy Diki is magyarázza: "néha az xterm - akárcsak a konsole - azt a benyomást kelti, hogy megállt, mivel új képernyőfrissítésekre vár, miután néhányat eltávolították." Ebben a tekintetben úgy tűnik, hogy más terminálok a legjobb kompromisszumot találták meg a sebesség és a kijelző épsége között.
Erőforrás-felhasználás
Függetlenül attól, hogy érdemes-e a görgetési sebességet a teljesítmény mutatójának tekinteni, ez a teszt lehetővé teszi a terminálok terhelésének szimulálását, ami lehetővé teszi számunkra más paraméterek, például a memória- vagy lemezhasználat mérését. A metrikákat a megadott teszt futtatásával nyertük seq , a Python folyamat figyelemmel kísérésével. Az adatgyűjtést a következő számlálók adatok gyűjtése végezte: a ru_maxrss, a ru_oublock és ru_inblock és egy egyszerű időmérő.
A teszt során az ST az átlagos memóriafogyasztás 8 MB-jával az első helyen áll, ami nem meglepő, figyelembe véve, hogy a projekt alapgondolata a egyszerűség. Az mlterm, xterm és rxvt kicsit többet fogyaszt — körülbelül 12 MB. Az Alacritty pedig 30 MB-ot igényel a működéshez. Ezt követik a VTE család termináljai, melyek fogyasztása 40-60 MB között mozog, ami viszonylag sok. Ez a fogyasztás a magasabb szintű könyvtárak használatával magyarázható, például a GTK. A Konsole 65 MB-os hatalmas memóriafogyasztásával zárja a sort a tesztek során, bár ezt a széles funkciókészlete is indokolja.
A korábbi, tíz évvel ezelőtt végzett eredményekhez képest minden program lényegesen több memóriát igényel. Régen az Xterm 4 MB-ot kért, most pedig 15 MB szükséges ahhoz, hogy elinduljon. Az rxvt esetében hasonló növekedés figyelhető meg, ami most alapértelmezetten 16 MB-ot igényel. Az Xfce terminál 34 MB-ot foglal el, ami háromszoros növekedés a korábbihoz képest, míg a GNOME Terminal mindössze 20 MB-ot igényel. Természetesen az összes korábbi teszt 32 bites architektúrán zajlott. A LCA 2012-n Rásti Russell , számos finomabb ok is lehet, ami a memóriafogyasztás növekedését magyarázza. Mindettől függetlenül mostanság gigabájtos memóriáink vannak, így valahogy megbirkózunk vele.
Mindazonáltal nem tudom kiűzni magamból azt az érzést, hogy az ilyen alapvető szoftverek, mint a terminál, számára a több memória allokációja értelmetlen erőforrás-pazarlás. Ezeknek a programoknak a legkisebbeknek kell lenniük, képesnek kell lenniük bármilyen "dobozon" működni, még cipős dobozokon is, ha valaha arra a pontra jutunk, hogy Linux rendszerekkel kell őket felszerelni (mert tudjátok, hogy ez fog történni). De ezekkel a számokkal a memóriahasználat a jövőben problémát jelent majd bármilyen környezetben, amikor több terminált indítunk, kivéve a legkönnyebb és legkorlátozottabb funkciókkal rendelkező eseteket. Ennek kompenzálására a GNOME Terminal, a Konsole, az urxvt, a Terminator és az Xfce Terminal rendelkezik Daemon üzemmóddal, amely lehetővé teszi több terminál kezelését egyetlen folyamat révén, ezáltal korlátozva a memóriafogyasztásukat.
Tesztjeim során egy másik váratlan eredményre jutottam a lemez írás-olvasásával kapcsolatban: azt hittem, itt nem fogok semmit látni, de kiderült, hogy egyes terminálok a legnagyobb adatokat írják a lemezre. A VTE könyvtár gyakorlatilag egy görgető puffert tart a lemezen (ez a jellemző , és ez azóta is így van). De a régi megoldásokkal ellentétben most, legalábbis, ezek az adatok AES256 GCM titkosítással védettek (). De felmerül a jogos kérdés, hogy mi olyan különleges a VTE könyvtárban, ami ilyen szokatlan megközelítést igényel a megvalósításhoz…
Zárás
A ciklus első részében felfedeztük, hogy a VTE alapú terminálok jó funkciókkal rendelkeznek, de most látjuk, hogy ez némi költséggel jár a teljesítményük biztosítása érdekében. Jelenleg a memória nem jelent problémát, mivel az összes VTE-terminált egy Daemon folyamat kezel, amely korlátozza az étvágyukat. Ennek ellenére a régi rendszerek, amelyeknek fizikai korlátai vannak a RAM és a kernel puffere kapacitására, továbbra is igényelhetik a korábbi verziókat, mivel ezek jelentősen kevesebb erőforrást fogyasztanak. Bár a VTE terminálok jól teljesítettek a sávszélesség-tesztek során (görgetés), az adatok képernyőn való megjelenítésének késése meghaladja a GNOME felhasználói kézikönyvében megadott határértéket. Valószínűleg a VTE fejlesztőinek figyelembe kellene venniük ezt. Figyelembe véve, hogy még a Linux kezdő felhasználói számára is elkerülhetetlen a terminál használata, barátságosabbá tehetnék azt a felhasználó számára. A tapasztalt geekek számára az alapértelmezett terminálról való áttérés még a szem terhelésének csökkenését is jelentheti, és lehetőséget adhat a hosszan tartó munkamenetekből adódó jövőbeli szakmai sérülések és betegségek elkerülésére. Sajnos csak a régi xterm és mlterm juttat el minket a 10 milliszekundumos ping varázslatos küszöbéhez, ami sokak számára elfogadhatatlan.
A mérések azt is kimutatták, hogy a Linux grafikus környezetek fejlődése miatt a fejlesztőknek számos kompromisszumot kellett kötniük. Egyes felhasználóknak érdemes megnézniük a hagyományos ablakkezelőket, mivel ezek jelentősen csökkentik a pinget. Sajnos a Wayland esetében nem sikerült mérni a késleltetést: a Typometer programot, amelyet használtam, kifejezetten azért hozták létre, hogy megakadályozza a más ablakok megfigyelését. Remélem, hogy a Wayland kompozitálás teljesítménye jobb, mint az X.org-é, és azt is remélem, hogy a jövőben valaki megtalálja a módját, hogy értékelje ennek a környezetnek a késleltetési szintjét.
Forrás: habr.com
