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:
Í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 számítógépes program nem tudja helyesen kezelni a kétirányú szöveget. Például a héber név „Sára” karaktereiből áll, ahol a sin (ש) (ami jobbra kerül), aztán a resh (ר) és végül a he (ה) (ami balra kell, hogy kerüljön).”
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 , 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
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish