Néhány szó fordítóirodánktól: általában mindenki a legújabb anyagok és kiadványok fordítására törekszik, ez alól mi sem vagyunk kivételek. De a terminálokat nem hetente egyszer frissítik. Ezért lefordítottuk Önöknek Antoine Beaupré 2018 tavaszán megjelent cikkét: a mai mércével mérve jelentős „kora” ellenére véleményünk szerint az anyag egyáltalán nem veszített aktualitásából. Ráadásul ez eredetileg egy két cikkből álló sorozat volt, de úgy döntöttünk, hogy ezeket egy nagy bejegyzésben egyesítjük.
A terminálok különleges helyet foglalnak el a számítógépek történetében, de az elmúlt évtizedekben a grafikus felületek mindenütt elterjedtsége miatt kénytelenek voltak túlélni a parancssor mellett. lecserélték a sajátjukat , amelyek viszont lyukkártyákon és váltókapcsolókon alapuló rendszerek módosításai voltak. A modern disztribúciókhoz különféle formájú és színű terminálemulátorok tartoznak. És bár sokan elégedettek a munkakörnyezetük által biztosított szabványos terminállal, néhányan büszkén használnak kifejezetten egzotikus szoftvereket kedvenc shell- vagy szövegszerkesztőjük futtatásához. De amint ebből a cikkből látni fogjuk, nem minden terminál ugyanabban a képben készült: funkcionalitásukban, méretükben és teljesítményükben nagyon különböznek egymástól.
Egyes terminálokon egészen meglepő biztonsági lyukak vannak, ráadásul a legtöbb teljesen más funkciókészlettel rendelkezik, a füles felület támogatásától a szkriptelésig. Bár mi , ez a cikk az előző anyag frissítése, amely segít az olvasóknak eldönteni, hogy melyik terminált használják 2018-ban. A cikk első fele összehasonlítja a jellemzőket, a második fele pedig a teljesítményt értékeli.
Íme az általam felülvizsgált terminálok:
Lehet, hogy ezek nem a legfrissebb verziók, mivel az írás idején a stabil buildekre korlátozódtam, amelyeket Debian 9-re vagy Fedora 27-re tudtam kiadni. Az egyetlen kivétel az Alacritty. Ez a GPU-gyorsítású terminálok leszármazottja, és ehhez a feladathoz egy szokatlan és új nyelven íródott - Rust. Kizártam a webterminálokat a felülvizsgálatomból (beleértve a ), mert az előzetes tesztek rendkívül gyenge teljesítményt mutattak.
Unicode támogatás
A teszteket Unicode támogatással kezdtem. A terminálok első tesztje a Unicode karakterlánc megjelenítése volt : „é, Δ, И, ק, م, ๗, あ, 叶, 葉 és 말.” Ez az egyszerű teszt megmutatja, hogy a terminál megfelelően működik-e világszerte. Az xterm terminál nem jelenít meg arab karaktert alapértelmezett konfigurációban:
Alapértelmezés szerint az xterm a klasszikus "fix" betűtípust használja, amely szerint , "1997 óta jelentős Unicode-lefedettséggel rendelkezik". Valami történik ebben a betűtípusban, ami miatt a karakter üres keretként jelenik meg, és csak akkor kezd el helyesen megjelenni a karakter, ha a betűtípust 20+ pontra növelik. Ez a „javítás” azonban megszakítja a többi Unicode-karakter megjelenítését:
Ezek a képernyőképek a Fedora 27-ben készültek, mivel az jobb eredményeket adott, mint a Debian 9, ahol a terminálok néhány régebbi verziója (különösen az mlterm) nem tudta megfelelően kezelni a betűtípusokat. Szerencsére ezt javították a későbbi verziókban.
Most figyelje meg, hogyan jelenik meg a sor az xtermben. Kiderül, hogy a szimbólum Mem és a következő szemita hivatkozzon az RTL stílusú szkriptekre (), tehát technikailag jobbról balra kell őket megjeleníteni. Az olyan webböngészők, mint a Firefox 57, megfelelően kezelik a fenti sort. Az RTL szöveg egyszerűbb változata a ""héberül (). a következőket mondja:
„Sok számítógépes program nem tudja helyesen megjeleníteni a kétirányú szöveget. Például a héber "Sarah" név a sin (ש) karakterekből áll (amely a jobb oldalon jelenik meg), majd a resh (ר) és végül a he (ה) karakterekből (melynek a bal oldalon kell megjelennie)."
Sok terminál megbukik ezen a teszten: Alacrity, VTE-eredetű Gnome és XFCE terminálok, urxvt, st és xterm fordított sorrendben jelenítik meg a "Sara"-t, mintha a nevet "Aras"-ként írtuk volna le.
Egy másik probléma a kétirányú szövegekkel, hogy valahogyan össze kell őket igazítani, különösen, ha RTL és LTR szövegek keveréséről van szó. Az RTL-szkripteknek a terminálablak jobb oldaláról kell futniuk, de mi történjen azokkal a terminálokkal, amelyek alapértelmezés szerint LTR angol nyelvet használnak? A legtöbbjük nem rendelkezik speciális mechanizmusokkal, és az összes szöveget balra igazítja (a Konsole-ban is). Ez alól kivétel a pterm és az mlterm, amelyek betartják a szabványokat, és jobbra igazítják az ilyen sorokat.
Behelyezés elleni védelem
A következő kritikus tulajdonság, amelyet azonosítottam, a beillesztés elleni védelem. Bár széles körben ismert, hogy az olyan varázslatok, mint:
$ curl http://example.com/ | shkódvégrehajtási push parancsok, kevesen tudják, hogy a webböngészőből való másolás és beillesztés során a rejtett parancsok még alapos ellenőrzés után is besurranhatnak a konzolba. ragyogóan mutatja, hogy milyen ártalmatlannak tűnik a parancs:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitakkora kellemetlenséggé válik, ha Horn webhelyéről beillesztik a terminálba:
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.gitHogyan működik? A blokk rosszindulatú kódot tartalmaz , amely CSS használatával kikerül a felhasználó nézetéből.
egyértelműen az ilyen támadások semlegesítésére szolgál. Ebben a módban a terminálok egy pár speciális escape szekvenciába zárják a beillesztett szöveget, hogy közöljék a héjjal a szöveg eredetét. Ez közli a héjjal, hogy figyelmen kívül hagyhatja azokat a speciális karaktereket, amelyeket a beillesztett szöveg tartalmazhat. A tiszteletreméltó xtermhez visszamenő összes terminál támogatja ezt a funkciót, de a zárójeles módban történő beillesztéshez a terminálon futó rendszerhéj vagy alkalmazás támogatása szükséges. Például szoftver használata (ugyanaz a Bash), szüksége van egy fájlra ~/.inputrc:
set enable-bracketed-paste onSajnos a Horn tesztoldala azt is megmutatja, hogyan lehet megkerülni ezt a védelmet magán a szövegformázáson keresztül, és idő előtt a Bracketed módot alkalmazni rá. Ez azért működik, mert egyes terminálok nem szűrik megfelelően az escape szekvenciákat, mielőtt hozzáadnák a sajátjukat. Például az enyémben soha nem tudtam sikeresen befejezni a Konsole teszteket még a megfelelő konfiguráció mellett sem .inputrc fájlt. Ez azt jelenti, hogy könnyen megsérülhet a rendszerkonfiguráció egy nem támogatott alkalmazás vagy egy helytelenül konfigurált shell miatt. Ez különösen veszélyes távoli szerverekre való bejelentkezéskor, ahol kevésbé gyakori a gondos konfigurációs munka, különösen akkor, ha sok ilyen távoli gépünk van.
Erre a problémára jó megoldás a terminál beillesztés-megerősítő bővítménye urxvt, amely egyszerűen engedélyt kér bármilyen új sorokat tartalmazó szöveg beszúrására. Nem találtam biztonságosabb lehetőséget a Horn által leírt szöveges támadásra.
Lapok és profilok
Jelenleg egy népszerű szolgáltatás a füles felület támogatása, amelyet úgy fogunk meghatározni, mint egy terminálablak, amely több más terminált tartalmaz. Ez a funkció a különböző termináloknál eltérő, és bár a hagyományos xterm terminálok egyáltalán nem támogatják a lapokat, a modernebb terminálok, például az Xfce Terminal, a GNOME Terminal és a Konsole rendelkezik ezzel a funkcióval. Az Urxvt a lapokat is támogatja, de csak akkor, ha bővítményt használ. De magát a laptámogatást tekintve a Terminator vitathatatlanul vezető szerepet tölt be: nem csak a füleket támogatja, hanem a terminálokat is tetszőleges sorrendbe tudja rendezni (lásd az alábbi képet).
A Terminator másik jellemzője, hogy ezeket a lapokat "csoportosíthatja", és ugyanazokat a billentyűleütéseket egyszerre több terminálra is elküldheti, így nyers eszközt biztosít több szerveren végzett tömeges műveletek egyidejű végrehajtásához. Hasonló funkciót a Konsole is megvalósított. Ennek a funkciónak más terminálokon való használatához harmadik féltől származó szoftvert kell használnia, mint pl , vagy .
A lapok különösen jól működnek, ha profilokkal párosítják: például lehet, hogy az egyik lap az e-mailekhez, a másik a csevegéshez stb. Ezt jól támogatja a Konsole Terminal és a GNOME Terminal. Mindkettő lehetővé teszi, hogy minden lap automatikusan elindítsa saját profilját. A Terminator támogatja a profilokat is, de nem találtam módot arra, hogy bizonyos programok automatikusan elinduljanak egy adott lap megnyitásakor. Más terminálokon egyáltalán nem szerepel a „profil” fogalma.
Fodor
Az utolsó dolog, amit a cikk első részében kitérek, a terminálok megjelenése. Például a GNOME, az Xfce és az urxvt támogatja az átláthatóságot, de a közelmúltban megszüntették a háttérképek támogatását, így néhány felhasználó terminálra vált. . Én személy szerint elégedett vagyok vele és egyszerű Xforrások, amely beállítja az urxvt háttérszíneinek alapkészletét. Azonban a nem szabványos színtémák is problémákat okozhatnak. Például, alkalmazásokkal и , hiszen már saját színeket használnak.
nem támogatta a színeket, és az újak gyakran 256 színpalettára korlátozódtak. Azok a haladó felhasználók számára, akik termináljaikat összetett módon alakítják ki, a shell promptok vagy állapotsorok bosszantó korlátozást jelenthetnek. nyomon követi, hogy mely terminálok rendelkeznek "True Color" támogatással. Tesztjeim megerősítik, hogy az st, Alacrity és VTE alapú terminálok tökéletesen támogatják a True Color-t. Más terminálok ebből a szempontból nem járnak túl jól, sőt, nem is jelenítenek meg 256 színt. Alább láthatja a különbséget a GNOME terminálok True Color támogatása, az st és az xterm között, amelyek 256-os színpalettájukkal ezt jól teljesítik, és az urxvt között, amely nem csak a teszten bukik meg, de még néhány villogó karaktert is mutat helyettük.
Egyes terminálok az URL-minták szövegét is elemzik, hogy a hivatkozásokat kattinthatóvá tegyék. Ez az összes VTE-eredetű terminálra vonatkozik, míg az urxvt speciális bővítményt igényel, amely egy kattintással vagy egy billentyűparancs használatával átalakítja az URL-eket. Egyéb terminálok A megjelenített URL-eket más módon teszteltem.
Végül a terminálok új trendje a scroll puffer opcionális lehetősége. Például az st-nek nincs görgetési puffere; feltételezzük, hogy a felhasználó terminál multiplexert fog használni, mint például a tmux és .
Az Alacrittyból szintén hiányoznak a backscroll pufferek, de támogatását a felhasználók e témával kapcsolatos „széles körű visszajelzései” miatt. Ezeken az újdonságokon kívül minden általam tesztelt terminál, amelyet találtam, támogatja a fordított görgetést.
részösszegek
Az anyag második részében (az eredetiben ez két különböző cikk volt - kb. sáv) összehasonlítjuk a teljesítményt, a memóriahasználatot és a késleltetést. De már most láthatjuk, hogy a szóban forgó terminálok egy része komoly hiányosságokkal rendelkezik. Például azoknak a felhasználóknak, akik rendszeresen dolgoznak RTL-szkriptekkel, érdemes megfontolni az mlterm és a pterm használatát, mivel ők jobban tudnak hasonló feladatokat kezelni, mint mások. A Konsole is jól teljesített. Azok a felhasználók, akik nem dolgoznak RTL-szkriptekkel, választhatnak mást.
A rosszindulatú kód beillesztése elleni védelem szempontjából az urxvt az ilyen típusú támadások elleni védelem speciális megvalósítása miatt tűnik ki, ami számomra határozottan kényelmesnek tűnik. Azok számára, akik harangokat és sípot keresnek, érdemes megnézni a Konsole-t. Végül érdemes megjegyezni, hogy a VTE kiváló alap a terminálokhoz, amely garantálja a színtámogatást, az URL felismerést stb. Első pillantásra a kedvenc környezetéhez tartozó alapértelmezett terminál minden követelménynek megfelelhet, de hagyjuk ezt a kérdést nyitva, amíg meg nem értjük a teljesítményt.
Folytatjuk a beszélgetést
Általánosságban elmondható, hogy a terminálok teljesítménye önmagában is messziről jövő problémának tűnhet, de mint kiderült, némelyikük meglepően magas késleltetést mutat az ilyen alapvető típusú szoftvereknél. Szintén a következőkben megvizsgáljuk a hagyományosan „sebességnek” nevezett (valójában ez a görgetési sebesség) és a terminál memóriafogyasztását (azzal a megkötéssel, hogy ez ma már nem olyan kritikus, mint évtizedekkel ezelőtt).
Késleltetés
A terminál teljesítményének alapos tanulmányozása után arra a következtetésre jutottam, hogy a legfontosabb paraméter ebből a szempontból a késleltetés (ping). cikkében Pavel Fatin megvizsgálta a különböző szövegszerkesztők késleltetését, és utalt arra, hogy a terminálok ebben a tekintetben lassabbak lehetnek, mint a leggyorsabb szövegszerkesztők. Ez volt az a tipp, ami végül arra késztetett, hogy lefuttassam a saját tesztjeimet és megírjam ezt a cikket.
De mi a látencia, és miért olyan fontos? Cikkében Fatin úgy határozta meg, mint „a billentyű lenyomása és a megfelelő képernyőfrissítés közötti késés”, és idézte , amely kijelenti: "A számítógépes kijelzőn megjelenő vizuális visszajelzés késése fontos hatással van a gépíró viselkedésére és elégedettségére."
Fatin elmagyarázza, hogy ennek a pingnek mélyebb következményei vannak, mint az elégedettség: „a gépelés lassabb lesz, több hiba történik, és nő a szem- és izomfeszültség.” Más szóval, a nagy késés elírási hibákhoz és alacsonyabb kódminőséghez vezethet, mivel további kognitív terheléshez vezet az agyban. De ami még rosszabb, az az, hogy a ping "növeli a szem és az izomfeszültséget", ami úgy tűnik, hogy azt sugallja a jövőben (A szerző nyilvánvalóan a szem, a hát, a kar izomzatának és természetesen a látással kapcsolatos problémákra gondol - kb. sáv) ismétlődő stressz miatt.
Ezen hatások némelyike már régóta ismert, és az eredmények is Az Ergonomics folyóiratban 1976-ban megjelent cikk szerint a 100 ezredmásodperces késleltetés "jelentősen rontja a gépelési sebességet". Nemrég bemutatták a GNOME felhasználói kézikönyvet 10 ezredmásodperc alatt, és ha tovább megy, akkor azt mutatja, hogy 1 ezredmásodperc az ideális.
Fatin szövegszerkesztőkkel végezte tesztjeit; nevű hordozható hangszert alkotott , amit a terminálemulátorokban a ping tesztelésére használtam. Ne feledje, hogy a teszt szimulációs módban történt: a valóságban a bemeneti (billentyűzet, USB-vezérlő stb.) és a kimeneti (videokártya puffer, monitor) késleltetését is figyelembe kell vennünk. Fatin szerint tipikus konfigurációkban körülbelül 20 ms. Ha rendelkezik játékfelszereléssel, ezt a számot mindössze 3 ezredmásodperc alatt érheti el. Mivel már van ilyen gyors hardverünk, az alkalmazásnak nem kell saját késleltetést hozzáadnia. Fatin célja, hogy az alkalmazás késleltetését 1 ezredmásodpercre csökkentse, vagy akár anélkül is tárcsázzon , hogyan be .
Íme a méréseim eredményei, valamint Fatin néhány eredménye annak bizonyítására, hogy a kísérletem megegyezik az ő tesztjeivel:
Az első dolog, ami megdöbbentett, az a régebbi programok, például az xterm és az mlterm jobb válaszideje. A legrosszabb regiszter késleltetéssel (2,4 ms) jobban teljesítettek, mint a leggyorsabb modern terminál (10,6 ms az st esetében). Egyetlen modern terminál sem esik a 10 ezredmásodperces küszöb alá. Az Alacrtty különösen nem teljesíti a „leggyorsabb elérhető terminálemulátor” állítást, bár pontszámai javultak a 2017-es első felülvizsgálat óta. Valóban, a projekt szerzői és a kijelző javításán dolgoznak. Azt is meg kell jegyezni, hogy a GTK3-at használó Vim egy nagyságrenddel lassabb, mint a GTK2 megfelelője. Ebből arra következtethetünk, hogy a GTK3 további késleltetést hoz létre, és ez az összes többi terminálon is megjelenik, amely ezt használja (Terminator, Xfce4 Terminal és GNOME terminál).
A különbségek azonban szemmel nem észrevehetők. Ahogy Fatin elmagyarázza, „nem kell tudatában lennie a késleltetésnek, hogy az hatással legyen rád”. Fatin a szórásra is figyelmeztet: „a látenciabeli zavarok (jitter) további stresszt okoznak a kiszámíthatatlanságuk miatt”.
A fenti grafikon tiszta Debian 9-re (nyúlás) készült . Ez a környezet produkálja a legjobb eredményeket a késleltetési tesztekben. Mint kiderült, a GNOME további 20 ms-os pinget hoz létre minden méréshez. Ennek lehetséges magyarázata a bemeneti események szinkron feldolgozásával rendelkező programok jelenléte. Fatin példát hoz egy ilyen esetre , amely késleltetést ad az összes bemeneti esemény szinkron feldolgozásával. Alapértelmezés szerint a GNOME-hoz tartozik egy ablakkezelő is , amely egy további pufferréteget hoz létre, amely hatással van a ping-re, és legalább 8 ezredmásodperces késleltetést ad hozzá.
Görgetési sebesség
A következő teszt egy hagyományos "sebesség" vagy "sávszélesség" teszt, amely azt méri, hogy a terminál milyen gyorsan tud görgetni egy oldalt, miközben nagy mennyiségű szöveget jelenít meg a képernyőn. A teszt mechanikája változó; az eredeti teszt az volt, hogy egyszerűen generálják ugyanazt a szöveges karakterláncot a seq paranccsal. További tesztek közé tartozik Thomas E. Dickey (xterm karbantartó) tesztje, amely ismételten . Egy másik áttekintésben a terminál teljesítményéről véletlen bájtokból álló base32 kódolású sztringet használ, amelyet a cat segítségével ad ki a terminálra. Luu úgy véli, hogy egy ilyen teszt „olyan haszontalan viszonyítási alap, amennyire csak elképzelhető”, és azt javasolja, hogy inkább a terminális választ használják elsődleges mérőszámként. Dickey a tesztjét is félrevezetőnek nevezi. Mindazonáltal mindkét szerző elismeri, hogy a terminálablak sávszélessége problémát jelenthet. Luu felfedezte, hogy az Emacs Eshell lefagy nagy fájlok megjelenítésekor, Dickey pedig optimalizálta a terminált, hogy megszabaduljon az xtrerm vizuális lassúságától. Tehát még mindig van némi érdeme ennek a tesztnek, de mivel a renderelési folyamat terminálonként nagyon eltérő, ezért tesztkomponensként is használható más paraméterek tesztelésére.
Itt azt látjuk, hogy az rxvt és az st előrébb húzzák a versenyt, ezt követi a sokkal újabb Alacrity, amelyet a teljesítményre összpontosítottak. Következik az Xfce (VTE család) és a Konsole, amelyek majdnem kétszer gyorsabbak. Az utolsó az xterm, ami ötször lassabb, mint az rxvt. A teszt során az xterm is sokat hullámzott, így az átadott szöveg nehezen látható még akkor is, ha ugyanaz a sor. A Konsole gyors volt, de időnként trükkös volt: a kijelző időnként lefagyott, részben vagy egyáltalán nem mutatott szöveget. Más terminálok egyértelműen megjelenítették a karakterláncokat, beleértve a st, Alacrtty és rxvt.
Dickey elmagyarázza, hogy a teljesítménybeli különbségek a különböző terminálokon található görgető pufferek kialakításából adódnak. Különösen azzal vádolja az rxvt-t és más terminálokat, hogy "nem tartják be az általános szabályokat":
„Az xterm-mel ellentétben az rxvt nem kísérelte meg megjeleníteni az összes frissítést. Ha lemarad, megtagad néhány frissítést, hogy utolérje. Ez nagyobb hatással volt a látszólagos görgetési sebességre, mint a belső memória szervezésére. Az egyik hátrány az volt, hogy az ASCII-animáció kissé pontatlan volt."
Az észlelt xterm lassúság kijavításához Dickey az erőforrás használatát javasolja , lehetővé téve az xterm számára, hogy elvetjen néhány képernyőfrissítést, hogy lépést tartson az áramlással. Tesztjeim megerősítik, hogy a fastScroll javítja a teljesítményt, és az xtermet az rxvt-vel egyenrangúvá teszi. Ez azonban meglehetősen durva mankó, ahogy Dickey maga magyarázza: "néha az xterm - mint a konzol - úgy tűnik, hogy leáll, amikor új képernyőfrissítésekre vár, miután néhányat eltávolítottak." Ebben a szellemben úgy tűnik, hogy más terminálok megtalálták a legjobb kompromisszumot a sebesség és a kijelző integritása között.
Erőforrás felhasználás
Függetlenül attól, hogy van-e értelme a görgetési sebességet teljesítménymutatónak tekinteni, ez a teszt lehetővé teszi számunkra, hogy szimuláljuk a terminálok terhelését, ami viszont lehetővé teszi más paraméterek, például memória- vagy lemezhasználat mérését. A mutatókat a megadott teszt futtatásával kaptuk meg seq Python folyamatfigyelés alatt. Mérőadatokat gyűjtött a ru_maxrss, összeg ru_oublock и ru_inblock és egy egyszerű időzítő.
Ebben a tesztben az ST az első helyet foglalja el a legalacsonyabb, 8 MB átlagos memóriafogyasztással, ami nem meglepő, ha figyelembe vesszük, hogy a tervezés fő gondolata az egyszerűség. Az mlterm, xterm és rxvt valamivel többet fogyaszt – körülbelül 12 MB. Egy másik figyelemre méltó eredmény az Alacrity, amelynek futtatásához 30 MB-ra van szükség. Aztán ott vannak a VTE család termináljai 40 és 60 MB között, ami elég sok. Ez a fogyasztás azzal magyarázható, hogy ezek a terminálok magasabb szintű könyvtárakat használnak, például GTK-t. A Konsole az utolsó helyen áll, a tesztek során bő 65 MB-os memóriafogyasztással, bár ezt a szolgáltatásai igen széles skálája indokolhatja.
A tíz évvel ezelőtti korábbi eredményekhez képest minden program észrevehetően több memóriát kezdett fogyasztani. Az Xterm korábban 4 MB-ot igényelt, de most 15 MB-ot igényel csak az indításkor. Hasonlóan nőtt a fogyasztás az rxvt esetében is, amelyhez most 16 MB kell a dobozból. Az Xfce Terminal 34 MB-ot foglal el, ami háromszor nagyobb, mint korábban, de a GNOME Terminal csak 20 MB-ot igényel. Természetesen az összes korábbi tesztet 32 bites architektúrán végezték el. A 2012-es LCA-n Rusty Russell , hogy sokkal finomabb okok magyarázhatják a memóriafelhasználás növekedését. Ennek ellenére most olyan időket élünk, amikor gigabájt memóriánk van, úgyhogy megoldjuk valahogy.
Mindazonáltal nem tehetek róla, de úgy érzem, hogy több memória lefoglalása olyan alapvető dolgokhoz, mint a terminál, erőforrások pazarlása. Ezeknek a programoknak a legkisebbeknek kell lenniük, bármilyen „dobozon”, akár cipősdobozon is futniuk kell, ha valaha is eljutunk odáig, hogy fel kell őket szerelni Linux rendszerekkel (és tudod, hogy így lesz ) . De ezekkel a számokkal a memóriahasználat problémát jelent a jövőben minden olyan környezetben, ahol több terminál fut, kivéve néhányat a legkönnyebb és legkorlátozottabb képességűek közül. Ennek kompenzálására a GNOME Terminal, a Konsole, az urxvt, a Terminator és az Xfce Terminal rendelkezik egy démon móddal, amely lehetővé teszi több terminál vezérlését egyetlen folyamaton keresztül, korlátozva a memóriafelhasználásukat.
Teszteléseim során újabb váratlan eredményre jutottam a lemez olvasása-írása kapcsán: arra számítottam, hogy itt semmit sem fogok látni, de kiderült, hogy egyes terminálok a legterjedelmesebb adatokat írják a lemezre. Tehát a VTE könyvtár valójában egy görgetőpuffert tart a lemezen (ez a funkció , és ez még mindig megtörténik). De a régebbi implementációkkal ellentétben most legalább ezek az adatok titkosítva vannak az AES256 GCM segítségével (). Felmerül azonban egy jogos kérdés: mi olyan különleges a VTE könyvtárában, hogy ilyen nem szabványos megközelítést igényel a megvalósítás...
Következtetés
A cikk első részében azt találtuk, hogy a VTE-alapú terminálok jó szolgáltatáskészlettel rendelkeznek, de most azt látjuk, hogy ez bizonyos teljesítményköltségekkel jár. A memória most nem probléma, mert az összes VTE terminál vezérelhető egy démon folyamaton keresztül, ami korlátozza az étvágyukat. Azonban a régebbi rendszereknek, amelyek fizikai korlátai vannak a RAM és a kernelpufferek mennyiségét illetően, továbbra is szükségük lehet a terminálok korábbi verzióira, mivel azok lényegesen kevesebb erőforrást fogyasztanak. Bár a VTE terminálok jól teljesítettek az átviteli (görgetési) tesztekben, megjelenítési késleltetésük meghaladja a GNOME felhasználói kézikönyvben meghatározott küszöbértéket. A VTE fejlesztőinek ezt valószínűleg figyelembe kell venniük. Ha figyelembe vesszük, hogy még a kezdő Linux felhasználók számára is elkerülhetetlen a terminál találkozása, felhasználóbarátabbá tehetik azt. A tapasztalt geekek számára az alapértelmezett terminálról való váltás még azt is jelentheti, hogy kevesebb szem megerőltetése és elkerülhető a jövőbeni, a hosszú munkavégzés miatti munkahelyi sérülések és betegségek. Sajnos csak a régi xterm és mlterm hoz el minket a 10 ezredmásodperces mágikus ping küszöbhöz, ami sokak számára elfogadhatatlan.
A benchmark mérések azt is kimutatták, hogy a Linux grafikus környezetek fejlesztése miatt a fejlesztőknek számos kompromisszumot kellett kötniük. Egyes felhasználók a szokásos ablakkezelőket szeretnék nézni, mivel jelentős ping-csökkentést biztosítanak. Sajnos a Wayland késleltetését nem lehetett mérni: az általam használt Typometer programot arra hozták létre, hogy a Wayland megakadályozza: más ablakok kémkedését. Remélem, hogy a Wayland-kompozíció jobban teljesít, mint az X.org, és azt is remélem, hogy a jövőben valaki talál módot a késleltetés mérésére ebben a környezetben.
Forrás: will.com