Kilka słów od naszego biura tłumaczeń: zazwyczaj wszyscy starają się tłumaczyć najnowsze materiały i publikacje, i my nie jesteśmy wyjątkiem. Ale terminale to nie coś, co aktualizuje się co tydzień. Dlatego przetłumaczyliśmy artykuł Antoine’a Bopré, opublikowany wiosną 2018 roku: mimo solidnego jak na dzisiejsze czasy „wieku”, naszym zdaniem materiał wciąż ma aktualne znaczenie. Ponadto oryginał to seria dwóch artykułów, ale postanowiliśmy połączyć je w jeden duży post.
Terminale zajmują szczególne miejsce w historii komputerów, ale w ostatnich dziesięcioleciach były dosłownie zmuszone do przetrwania obok linii poleceń w erze powszechnie rozwijających się interfejsów graficznych. zastąpiły swoich , które z kolei były modyfikacją systemów opartych na kartach perforowanych i przekaźnikach. Nowoczesne dystrybucje dostarczane są z całą gamą emulatorów terminali w różnych kształtach i kolorach. I podczas gdy wielu zadowala się standardowym terminalem, który oferuje ich środowisko robocze, niektórzy z dumą korzystają z wyraźnie egzotycznego oprogramowania do uruchamiania swojej ulubionej powłoki lub edytora tekstu. Ale, jak zobaczymy w tym artykule, nie wszystkie terminale zostały stworzone na jedno podobieństwo: różnią się znacznie pod względem funkcjonalności, rozmiaru i wydajności.
Niektóre terminale mają wręcz zaskakujące luki w bezpieczeństwie, a większość z nich posiada zupełnie różny zestaw funkcji, od wsparcia dla interfejsu z zakładkami po skrypty. Chociaż my , ten artykuł jest aktualizacją poprzedniego materiału, który pomoże czytelnikom zdecydować, którego terminala używać w 2018 roku. W pierwszej części artykułu porównane są funkcje, a w drugiej oceniana jest wydajność.
Oto terminale, które rozważałem:
Możliwe, że to nie są najnowsze wersje, ponieważ opierałem się na stabilnych wydaniach w momencie pisania materiału, które udało mi się zainstalować na Debianie 9 lub Fedora 27. Jedynym wyjątkiem jest Alacritty. Jest to następca terminali z przyspieszeniem GPU i został napisany w nietypowym i nowym dla tego zadania języku – Rust. Wykluczyłem ze swojego przeglądu terminale webowe (w tym na ), ponieważ wstępne testy pokazały ich niezwykle niską wydajność.
Wsparcie dla Unicode
Swoje testy zaczynałem od wsparcia dla Unicode. Pierwszym testem terminali było wyświetlenie linii o Unicode z : „é, Δ, Й, ק, م, ๗, あ, 叶, 葉 i 말”. Ten prosty test pokazuje, czy terminal może poprawnie działać na całym świecie. Terminal xterm nie wyświetla arabskiego znaku w konfiguracji domyślnej:
Domyślnie xterm używa klasycznej „stałej” czcionki, która, według , ma „istotne wsparcie dla Unicode od 1997 roku”. W tej czcionce dzieje się coś, co powoduje, że znak wyświetla się jako pusta ramka, a dopiero po zwiększeniu rozmiaru tekstu do 20+ punktów, znak zaczyna prawidłowo się wyświetlać. Jednak taki „fix” psuje wyświetlanie innych znaków Unicode:
Te zrzuty ekranu zostały zrobione na Fedora 27, ponieważ to ona dawała lepsze wyniki niż Debian 9, gdzie niektóre starsze wersje terminali (konkretnie – mlterm) nie mogły działać poprawnie z czcionkami. Na szczęście to zostało naprawione w późniejszych wersjach.
Zwróć uwagę na wyświetlanie linii w xterm. Okazuje się, że znak Mem i następny po nim Semitic należą do skryptów rysowania RTL (), dlatego technicznie powinny być wyświetlane od prawej do lewej. Przeglądarki internetowe, takie jak Firefox 57, poprawnie obsługują powyższą linię. Prostszym przykładem tekstu RTL jest słowo „” po hebrajsku (). mówi następująco:
„Wiele programów komputerowych nie może poprawnie wyświetlać tekstu dwukierunkowego. Na przykład hebrajskie imię „Sara” składa się z liter syn (ש) (który pojawia się z prawej), następnie resz (ר) i w końcu che (ה) (który powinien pojawiać się z lewej)”.
Wiele terminali nie przechodzi tego testu: Alacritty, terminale oparte na VTE z Gnome i XFCE, urxvt, st oraz xterm wyświetlają „Sara” w odwrotnej kolejności, jakbyśmy zapisywali to imię jako „Aras”.
Innym problemem tekstów dwukierunkowych jest to, że trzeba je jakoś wyrównać, szczególnie w przypadku mieszania tekstów RTL i LTR. Scenariusze RTL powinny zaczynać z prawej strony okna terminala, ale co powinno się wydarzyć w terminalach, które domyślnie działają w LTR po angielsku? Większość z nich nie posiada specjalnych mechanizmów i wyrównuje cały tekst do lewej (w tym w Konsole). Wyjątkiem są pterm i mlterm, które przestrzegają standardów i wyrównują takie linie do prawej.
Ochrona przed wklejaniem
Następną krytyczną cechą, którą dla siebie określiłem, jest ochrona przed wklejaniem. Choć powszechnie wiadomo, że polecenia typu:
$ curl http://example.com/ | shsą komendami wykonawczymi, niewiele osób wie, że ukryte komendy mogą przedostać się do konsoli przy kopiowaniu-wklejaniu z przeglądarki, nawet po dokładnym sprawdzeniu. doskonale pokazuje, jak wyglądająca na pozór nieszkodliwa komenda:
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitprzekształca się podczas wklejania z strony Horna w coś tak nieprzyjemnego:
git clone /dev/null;
clear;
echo -n "Cześć ";
whoami|tr -d 'n';
echo -e '!nTo był zły pomysł. Nie kopiuj kodu z nieznanych stron!
Oto pierwsza linia twojego /etc/passwd: ';
head -n1 /etc/passwd
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitJak to działa? Złośliwy kod jest wydobyty z bloku , który jest przenoszony z pola widzenia użytkownika za pomocą CSS.
jest wyraźnie zaprojektowany w celu neutralizacji podobnych ataków. W tym trybie terminale otaczają wklejany tekst parą specjalnych sekwencji escape, aby poinformować powłokę o pochodzeniu tego tekstu. W ten sposób powłoka otrzymuje sygnał, że może zignorować specjalne znaki, które może zawierać wklejany tekst. Wszystkie terminale, aż po szanowanego xterm, obsługują tę funkcję, ale wklejanie w trybie w klamrach wymaga wsparcia powłoki lub aplikacji uruchomionej w terminalu. Na przykład, oprogramowanie używające (ten sam Bash), potrzebuje pliku ~ /.inputrc:
set enable-bracketed-paste onNiestety, testowa strona Horna również pokazuje, jak obejść tę ochronę poprzez samo formatowanie tekstu i przedwcześnie zakończyć stosowanie trybu Bracketed. Działa to, ponieważ niektóre terminale błędnie filtrują sekwencje escape przed dodaniem swoich własnych. Na przykład, w moich próbach nie udało mi się pomyślnie zakończyć testów Konsole, nawet przy poprawnej konfiguracji. .inputrc plik. Oznacza to, że z łatwością możesz uszkodzić konfigurację systemu z powodu nieobsługiwanej aplikacji lub źle skonfigurowanej powłoki. Jest to szczególnie niebezpieczne podczas logowania się do zdalnych serwerów, gdzie staranna obróbka konfiguracji zdarza się rzadziej, zwłaszcza jeśli masz wiele takich zdalnych maszyn.
Dobrym rozwiązaniem tego problemu jest wtyczka do potwierdzenia wklejania dla terminala urxvt, która po prostu prosi o zgodę na wklejenie dowolnego tekstu zawierającego nowe linie. Nie znalazłem bardziej zabezpieczonej opcji dla opisywanego przez Horna ataku tekstowego.
Karty i profile
Popularną funkcją obecnie jest wsparcie interfejsu z kartami, które definiujemy jako jedno okno terminala zawierające kilka terminali. Dla różnych terminali ta funkcja różni się, i chociaż tradycyjne terminale typu xterm w ogóle nie obsługują kart, bardziej nowoczesne wcielenia terminala w postaci Xfce Terminal, GNOME Terminal i Konsole tę funkcję mają. Wsparcie kart posiada również Urxvt, ale tylko pod warunkiem użycia wtyczki. Jednak z punktu widzenia wsparcia kart bezsprzecznym liderem jest Terminator: nie tylko obsługuje karty, ale także może układać terminale w dowolnej kolejności (patrz obrazek poniżej).
Kolejną cechą Terminatora jest możliwość „grupowania” tych kart razem i wysyłania tych samych naciśnięć klawiszy do kilku terminali jednocześnie, co zapewnia prosty instrument do wykonywania masowych operacji na kilku serwerach jednocześnie. Podobna funkcja jest również zrealizowana w Konsole. Aby skorzystać z tej funkcji w innych terminalach, należy użyć oprogramowania stron trzecich, takiego jak , lub .
Zakładki szczególnie dobrze działają w połączeniu z profilami: na przykład możesz mieć jedną zakładkę do poczty elektronicznej, drugą do czatu itd. Jest to dobrze wspierane przez terminale Konsole i GNOME Terminal. Oba pozwalają każdej zakładce na automatyczne uruchamianie swojego profilu. Terminator również wspiera profile, ale nie mogłem znaleźć sposobu na automatyczne uruchamianie określonych programów przy otwieraniu konkretnej zakładki. Inne terminale w ogóle nie mają pojęcia o '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 wspierają przezroczystość, ale ostatnio wycofano wsparcie dla obrazów tła, co spowodowało, że niektórzy użytkownicy przeszli na inny terminal. . Osobiście mi to odpowiada i jest po prostu Xresources, który ustawia podstawowy zestaw kolorów tła dla urxvt. Jednak niestandardowe motywy kolorów mogą powodować problemy. Na przykład, z aplikacjami i , ponieważ już używają swoich kolorów.
nie wspierał kolorów, a nowe często były ograniczone do palety 256 kolorów. Dla zaawansowanych użytkowników, którzy stylizują swoje terminale, prośby o powłokę lub linie stanu w sposób złożony mogą stać się nieprzyjemnym ograniczeniem. śledzi, które terminale mają wsparcie dla 'True Color'. Moje testy potwierdzają, że st, Alacritty i terminale oparte na VTE doskonale wspierają True Color. Inne terminale w tym zakresie wypadają dość słabo i w rzeczywistości nie wyświetlają nawet 256 kolorów. Poniżej możesz zobaczyć różnicę w wsparciu True Color w terminalach GNOME, st i xterm, które dobrze spełniają to zadanie za pomocą swojej 256-kolorowej palety, i urxvt, który nie tylko nie przechodzi testu, ale nawet pokazuje migające symbole zamiast nich.
Niektóre terminale również analizują tekst pod kątem wzorców URL, aby uczynić linki klikalnymi. Dotyczy to wszystkich terminali pochodnych od VTE, podczas gdy urxvt wymaga specjalnego modułu wtyczki, aby przekształcać adresy URL po kliknięciu lub za pomocą skrótu klawiaturowego. Inne terminale, które testowałem, wyświetlają adresy URL w inny sposób.
Wreszcie nowym trendem terminali jest opcjonalność bufora przewijania. Na przykład w st nie ma bufora przewijania; zakłada się, że użytkownik będzie korzystał z multiplexerów terminalowych, takich jak tmux i .
W Alacritty również brakuje buforów przewijania wstecz, ale jego obsługa z powodu «obszernej informacji zwrotnej» na ten temat od użytkowników. Oprócz tych nowości każdy terminal, który udało mi się znaleźć, obsługuje wsteczne przewijanie.
Podsumowanie pośrednie
W drugiej części materiału (w oryginale były to dwa różne artykuły, — przyp. red.) porównamy wydajność, zużycie pamięci i opóźnienie. Już teraz widzimy, że niektóre z omawianych terminali mają poważne wady. Na przykład, użytkownicy regularnie pracujący z skryptami RTL mogą zwrócić uwagę na mlterm i pterm, ponieważ lepiej radzą sobie z takimi zadaniami. Konsole również dobrze się spisuje. Użytkownicy, którzy nie pracują z skryptami RTL, mogą wybrać coś innego.
Z punktu widzenia ochrony przed wstawianiem złośliwego kodu urxvt wyróżnia się z powodu swojej szczególnej implementacji ochrony przed tym rodzajem ataków, co uważam za z pewnością wygodne. Osoby szukające jakichkolwiek udogodnień powinny spojrzeć na Konsole. Na koniec warto zauważyć, że VTE to doskonała baza dla terminali, która gwarantuje wsparcie dla kolorów, rozpoznawanie URL itd. Na pierwszy rzut oka domyślny terminal dostarczany z twoim ulubionym środowiskiem może spełniać wszystkie wymagania, ale pozostawimy to pytanie otwarte, dopóki nie przeanalizujemy wydajności.
Kontynuujemy rozmowę
Ogólnie wydajność terminali może wydawać się wymyślonym problemem, jednak jak się okazało, niektóre z nich wykazują zaskakująco dużą latencję dla oprogramowania tego podstawowego typu. Dalsze rozważania będą dotyczyć tego, co tradycyjnie nazywa się „szybkością” (w rzeczywistości chodzi o szybkość przewijania) oraz zużycia pamięci przez terminal (z uwagi na to, że obecnie nie jest to tak krytyczne jak dziesięciolecia temu).
Opóźnienie
Po dokładnym zbadaniu wydajności terminali doszedłem do wniosku, że najważniejszym parametrem w tej kwestii jest wielkość opóźnienia (ping). W swoim artykule Paweł Fatin przyjrzał się opóźnieniom różnych edytorów tekstu i zasugerował, że terminale w tym względzie mogą działać wolniej od najszybszych edytorów tekstu. To właśnie ta sugestia doprowadziła mnie ostatecznie do uruchomienia własnych testów i napisania tego artykułu.
Ale czym jest opóźnienie i dlaczego jest tak ważne? W swoim artykule Fatin zdefiniował je jako „opóźnienie między naciśnięciem klawisza a odpowiednim aktualizowaniem ekranu” i zacytował , w którym mówi się: „Opóźnienie w wizualnym sprzężeniu zwrotnym na ekranie komputera ma istotny wpływ na zachowanie operatora i jego satysfakcję”.
Fatin wyjaśnia, że to opóźnienie ma głębsze konsekwencje niż tylko satysfakcja: „pisanie staje się wolniejsze, pojawia się więcej błędów, rośnie napięcie oczu i mięśni”. Innymi słowy, większe opóźnienie może prowadzić do literówek oraz obniżenia jakości kodu, ponieważ zwiększa dodatkowe obciążenie poznawcze mózgu. Ale co gorsza, opóźnienie „zwiększa napięcie oczu i mięśni”, co najwyraźniej implikuje w przyszłości (najwyraźniej autor ma na myśli problemy z mięśniami oczu, plecami, rękami i, oczywiście, wzrokiem - przyp. red.) spowodowane powtarzającym się napięciem.
Niektóre z tych efektów są znane od dawna, a wyniki , opublikowanego już w 1976 roku w czasopiśmie Ergonomics, mówią, że opóźnienie wynoszące 100 milisekund „znacząco pogarsza prędkość pisania”. Całkiem niedawno w podręczniku użytkownika GNOME wprowadzono wynoszący 10 milisekund, a jeśli chodzi o ideały, to pokazuje, że ideałem jest 1 milisekunda.
Fatin przeprowadził swoje testy na edytorach tekstowych; stworzył przenośne narzędzie o nazwie , który używałem do testowania pingu w emulatorach terminala. Należy pamiętać, że test był przeprowadzany w trybie symulacji: w rzeczywistości musimy uwzględnić również opóźnienie wejścia (klawiatura, kontroler USB itd.) oraz wyjścia (bufor karty graficznej, monitor). Według Fatina w typowych konfiguracjach wynosi ono około 20 ms. Przy użyciu sprzętu gamingowego można osiągnąć wynik zaledwie 3 milisekund. Ponieważ już mamy taki szybki sprzęt, aplikacja nie powinna wprowadzać dodatkowego opóźnienia. Celem Fatina jest doprowadzenie opóźnienia aplikacji do 1 milisekundy lub wręcz osiągnięcie zestawu bez , jak w .
Poniżej wyniki moich pomiarów oraz niektóre wyniki Fatina, aby pokazać, że mój eksperyment jest zgodny z jego testami:
Pierwszą rzeczą, która mnie zaskoczyła, jest lepszy czas reakcji w starszych programach, takich jak xterm i mlterm. Przy najgorszym opóźnieniu rejestru (2,4 ms) osiągnęły one rezultat lepszy niż najszybszy nowoczesny terminal (10,6 ms dla st). Żaden nowoczesny terminal nie spada poniżej progu 10 milisekund. W szczególności Alacritty nie spełnia wymagań „najszybszego z istniejących emulatorów terminala”, chociaż jego wyniki poprawiły się od pierwszej kontroli w 2017 roku. Rzeczywiście, autorzy projektu i pracują nad poprawą wydajności. Należy również zauważyć, że Vim, używający GTK3, jest znacznie wolniejszy od swojego odpowiednika GTK2. Z tego można wywnioskować, że GTK3 wprowadza dodatkowe opóźnienie, a to wpływa na wszystkie inne terminale, które go używają (Terminator, Xfce4 Terminal i GNOME Terminal).
Jednak różnice mogą być niewidoczne dla oka. Jak tłumaczy Fatin: „niekoniecznie trzeba być świadomym opóźnienia, aby miało ono na ciebie wpływ”. Fatin ostrzega również przed odchyleniem standardowym: „jakiekolwiek zakłócenia w czasie opóźnienia (drganie) generują dodatkowe obciążenie z powodu ich nieprzewidywalności.”
Wykres powyżej został uzyskany na czystym Debianie 9 (stretch) z To środowisko zapewnia najlepsze wyniki w testach opóźnienia. Okazało się, że GNOME generuje dodatkowe opóźnienie wynoszące 20 ms we wszystkich pomiarach. Możliwe wyjaśnienie tego to obecność programów z synchronicznym przetwarzaniem zdarzeń wejściowych. Fatin przywołuje taki przypadek jako przykład , który dodaje opóźnienie, przetwarzając wszystkie zdarzenia wejściowe synchronicznie. Domyślnie GNOME wyposażony jest także w menedżera okien , który tworzy dodatkowy poziom buforowania, co wpływa na ping i dodaje co najmniej 8 milisekund opóźnienia.
Szybkość przewijania
Następnym testem jest tradycyjna kontrola »szybkości« lub »przepustowości«, która mierzy, jak szybko terminal może przewijać stronę, wyświetlając dużą ilość tekstu na ekranie. Mechanika testu różni się; oryginalny test polegał na prostym generowaniu tej samej linii tekstu za pomocą polecenia seq. Inne testy obejmują sprawdzenie Thomasa E. Dicka (towarzyszącego xterm), w ramach którego wielokrotnie . W jeszcze jednym przeglądzie wydajności terminali używa ciągu losowych bajtów w kodowaniu base32, który jest wyświetlany w terminalu za pomocą cat. Liu uważa ten test za »tak bezużyteczny wzorzec, jak to tylko możliwe« i proponuje zamiast tego użyć reakcji terminala jako głównego wskaźnika. Dick również określa swój test jako wprowadzający w błąd. Niemniej jednak obaj autorzy przyznają, że przepustowość okna terminala może być problemem. Liu odkrył zawieszanie się Emacs Eshell przy wyświetlaniu dużych plików, a Dick zoptymalizował terminal, aby pozbyć się wizualnego opóźnienia xterm. Dlatego ten test ma jeszcze pewien sens, ale ponieważ proces renderowania znacznie różni się w zależności od terminala, można go wykorzystać również jako komponent testowy do sprawdzania innych parametrów.
Tutaj widzimy, że rxvt i st przodują wśród konkurencji, a za nimi plasuje się znacznie nowszy Alacritty, opracowywany z myślą o wydajności. Dalej są Xfce (rodzina VTE) i Konsole, które działają prawie dwa razy szybciej. Na końcu jest xterm, który jest pięć razy wolniejszy niż rxvt. W trakcie testu xterm często migał, a przechodzący tekst był trudny do dostrzeżenia, nawet jeśli chodziło o tę samą linię. Konsole okazał się szybki, ale czasami „oszukiwał”: wyświetlacz od czasu do czasu zawieszał się, pokazując tekst częściowo lub w ogóle go nie wyświetlając. Inne terminale wyświetlały linie wyraźnie, w tym st, Alacritty i rxvt.
Diki wyjaśnia, że różnice w wydajności są związane z projektowaniem buforów przewijania w różnych terminalach. W szczególności obwinia rxvt i inne terminale o to, że „nie przestrzegają ogólnych zasad”:
„W przeciwieństwie do xterm, rxvt nie próbował wyświetlić wszystkich aktualizacji. Jeśli się spóźniał, rezygnował z niektórych aktualizacji, aby nadrobić zaległości. Miało to większy wpływ na pozorną szybkość przewijania, niż na organizację pamięci wewnętrznej. Jedną z wad było to, że animacja ASCII była nieco niedokładna”.
Aby naprawić tę pozorną wolność xterm, Diki sugeruje użycie zasobu , który pozwala xterm na pomijanie niektórych aktualizacji ekranu, aby nie pozostawał w tyle za strumieniem. Moje testy potwierdzają, że fastScroll zwiększa wydajność i sprawia, że xterm osiąga poziom z rxvt. Jest to jednak dość prymitywne obejście, jak sam wyjaśnia Diki: „czasami xterm — podobnie jak konsole — wydaje się zatrzymywać, ponieważ czeka na nowy zestaw aktualizacji ekranu po tym, jak niektóre z nich zostały usunięte”. W tym kontekście wydaje się, że inne terminale znalazły najlepszy kompromis między szybkością a integralnością wyświetlania.
Zużycie zasobów
Bez względu na to, na ile sensowne jest rozważanie prędkości przewijania jako wskaźnika wydajności, ten test pozwala na symulację obciążenia terminali, co z kolei pozwala nam mierzyć inne parametry, takie jak wykorzystanie pamięci lub dysku. Metryki uzyskano poprzez uruchomienie podanego testu seq pod monitorowaniem procesu Python. Zbierał dane liczników do ru_maxrss, sumy ru_oublock i ru_inblock i prosty timer czasu.
W teście ST zajmuje pierwsze miejsce z najmniejszym ś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. Nieco więcej pamięci konsumują mlterm, xterm i rxvt - około 12 MB. Kolejnym znaczącym wynikiem jest Alacritty, który do działania potrzebuje 30 MB. Następnie są terminale z rodziny VTE z wynikami od 40 do 60 MB, co jest stosunkowo dużo. Takie zużycie można wyjaśnić tym, że te terminale korzystają z bibliotek wyższego poziomu, takich jak GTK. Konsole zajmuje ostatnie miejsce z gigantycznym zużyciem 65 MB pamięci podczas testów, choć można to usprawiedliwić jej bardzo szerokim zestawem funkcji.
W porównaniu do wcześniejszych wyników uzyskanych dziesięć lat temu, wszystkie programy zaczęły zużywać zauważalnie więcej pamięci. Kiedyś Xterm wymagał 4 MB, a teraz - 15 MB tylko na uruchomienie. Podobny wzrost zużycia odnotowano w przypadku rxvt, który teraz z pudełka wymaga 16 MB. Terminal Xfce zajmuje 34 MB, co jest trzy razy więcej niż wcześniej, natomiast GNOME Terminal wymaga tylko 20 MB. Oczywiście, wszystkie poprzednie testy przeprowadzano na architekturze 32-bitowej. Na LCA 2012 Rasty Russell , że istnieje wiele bardziej subtelnych przyczyn, które mogą wyjaśnić wzrost zużycia pamięci. Mimo to żyjemy w czasach, gdy mamy całe gigabajty pamięci, więc jakoś sobie poradzimy.
Niemniej jednak nie mogę się pozbyć wrażenia, że przydzielenie większej ilości pamięci tak podstawowemu oprogramowaniu, jak terminal, to marnotrawstwo zasobów. Te programy powinny być najmniejsze z najmniejszych, powinny być w stanie działać na każdej „pudełku”, nawet na obuwiu, jeśli kiedykolwiek dojdziemy do tego, że będą musiały być wyposażone w systemy Linux (a wiecie, że tak będzie). Ale przy tych liczbach użycie pamięci stanie się w przyszłości problemem w każdej okolicy przy uruchamianiu kilku terminali, poza sytuacją, w której będą tylko kilka najlżejszych i ograniczonych w możliwości. Aby to zrekompensować, GNOME Terminal, Konsole, urxvt, Terminator i Xfce Terminal mają tryb Daemon, który pozwala zarządzać wieloma terminalami za pomocą jednego procesu, co ogranicza ich zużycie pamięci.
Podczas swoich testów doszedłem do kolejnego zaskakującego wniosku dotyczącego odczytu i zapisu na dysku: spodziewałem się, że nie zobaczę tutaj zupełnie nic, ale okazało się, że niektóre terminale zapisują na dysku największe dane. Biblioteka VTE faktycznie przechowuje na dysku bufor przewijania (ta cecha , i trwa to do dziś). Jednak w przeciwieństwie do wcześniejszych implementacji, obecnie przynajmniej te dane są szyfrowane przy użyciu AES256 GCM (). Ale rodzi się uzasadnione pytanie, co takiego wyjątkowego w bibliotece VTE, że wymaga ona tak niestandardowego podejścia do implementacji…
Podsumowanie
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 zapewnienia ich wydajności. Obecnie pamięć nie jest problemem, ponieważ wszystkie terminale VTE można zarządzać przez proces Daemon, który ogranicza ich apetyt. Niemniej jednak starsze systemy, mające fizyczne ograniczenia dotyczące ilości pamięci RAM i bufora jądra, mogą wciąż potrzebować wcześniejszych wersji terminali, ponieważ zużywają znacznie mniej zasobów. Chociaż terminale VTE dobrze spisały się w testach przepustowości (przewijanie), ich opóźnienie wyświetlania danych na ekranie przekracza ustalony próg w podręczniku użytkownika GNOME. Prawdopodobnie deweloperzy VTE powinni to uwzględnić. Biorąc pod uwagę, że nawet dla początkujących użytkowników Linuxa spotkanie z terminalem jest nieuniknione, mogą uczynić go bardziej przyjaznym dla użytkownika. Dla doświadczonych zapaleńców przejście z domyślnego terminala może oznaczać nawet zmniejszenie obciążenia wzroku i możliwość uniknięcia zawodowych urazów i chorób w przyszłości z powodu długotrwałych sesji pracy. Niestety, tylko stare xterm i mlterm prowadzą nas do magicznego progu pingu wynoszącego 10 milisekund, co dla wielu jest nie do przyjęcia.
Pomiar kontrolny również wykazał, że w wyniku rozwoju graficznych środowisk Linux programiści musieli pójść na szereg kompromisów. Niektórzy użytkownicy powinni spojrzeć na klasyczne menedżery okien, ponieważ zapewniają one znaczne obniżenie opóźnienia. Niestety, nie udało się zmierzyć opóźnienia w Waylandzie: program Typometer, którego używałem, został stworzony po to, aby to, co Wayland miał zapobiegać - szpiegostwu za innymi oknami. Mam nadzieję, że kompozycja w Waylandzie będzie lepsza wydajnościowo niż w X.org, a także mam nadzieję, że w przyszłości ktoś znajdzie sposób, aby ocenić poziom opóźnienia w tym środowisku.
Źródło: habr.com
