A few words from our translate bureau: usually everyone strives to translate the latest materials and publications, and we are no exception. But terminals are not something that is updated once a week. Therefore, we have translated for you an article by Antoine Beaupre, published in the spring of 2018: despite the “age” that is respectable by modern standards, in our opinion, the material has not lost its relevance at all. In addition, in the original this is a series of two articles, but we decided to combine them into one large post.
Terminals have a special place in computer history, but in recent decades they have been "forced" to literally survive along with the command line against the backdrop of ubiquitous graphical interfaces. replaced their , which, in turn, were a modification of systems on punched cards and toggle switches. Modern distributions come with a plethora of terminal emulators in all shapes and colors. And while many are content with the standard terminal that comes with their work environment, some are proud to use frankly exotic software to launch their favorite shell or text editor. But, as we will see from this article, not all terminals were created in the same way: they differ greatly in functionality, size and performance.
Some terminals have downright amazing security holes, plus most have a completely different set of features, from tabbed interface support to scripting. Although we , this article is an update of the previous material that will help readers determine which terminal to use in 2018. The first half of the article compares features, while the second half evaluates performance.
Here are the terminals I've reviewed:
These may not be the most recent versions, as I was limited to stable builds at the time of writing, which I managed to roll out on Debian 9 or Fedora 27. The only exception is Alacritty. It is a descendant of GPU-accelerated terminals and is written in an unusual and new language for this task - Rust. I excluded web terminals from my review (including those on ), because preliminary tests showed their extremely poor performance.
Unicode support
I started my tests with Unicode support. The first test of the terminals was to display them a string about unicode from : "é, Δ, й, ק, م, ๗, あ, 叶, 葉 and 말". This simple test shows if the terminal can work correctly around the world. xterm terminal not displaying arabic character in default configuration:
By default, xterm uses a classic "fixed" font, which, according to , has "substantial unicode coverage since 1997". There is something going on in this font that causes the character to appear as an empty frame, and only when the text font is increased to 20+ points does the character finally start to display correctly. However, such a "fix" breaks the display of other Unicode characters:
These screenshots were taken in Fedora 27, since it gave better results than Debian 9, where some older versions of terminals (specifically mlterm) could not work properly with fonts. Luckily this has been fixed in later versions.
Now pay attention to the display of the string in xterm. It turns out that the Mem symbol followed by the Semitic refer to RTL handwriting scripts (), so they should technically be rendered from right to left. Web browsers like Firefox 57 handle the above string correctly. A simpler version of the RTL text is the word "» in Hebrew (). says the following:
“Many computer programs cannot display bidirectional text correctly. For example, the Hebrew name Sarah consists of the characters sin (ש) (which appears on the right), then resh (ר), and finally heh (ה) (which must appear on the left).”
Many terminals fail this test: Alacritty, Gnome and XFCE's VTE-derived terminals, urxvt, st and xterm display "Sarah" in reverse order, as if we spelled the name as "Aras".
Another problem with bidirectional texts is that they need to be aligned somehow, especially when it comes to mixing RTL and LTR texts. RTL scripts should run from the right side of the terminal window, but what should happen for terminals that run LTR English by default? Most of them do not have any special mechanisms and align all text to the left (including in Konsole). The exceptions are pterm and mlterm, which adhere to the standards and right-align such lines.
Insert protection
The next critical feature that I have identified for myself is paste protection. Although it is widely known that spells like:
$ curl http://example.com/ | share code execution push commands, few people know that hidden commands can sneak into the console when copy-pasting from a web browser, even after close inspection. brilliantly shows how innocuous-looking command:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitturns into such a nuisance when pasting from Horn's website into the terminal:
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.gitHow it works? Malicious code moved to block , which is moved out of the user's view by means of CSS.
clearly designed to neutralize such attacks. In this mode, terminals wrap pasted text in a pair of special escape sequences to tell the shell the origin of the text. This signals to the shell that it can ignore special characters that the inserted text may contain. All terminals up to the venerable xterm support this feature, but inserting in Bracketed mode needs support from the shell or application running on the terminal. For example, software that uses (same Bash), needs a file ~/.inputrc:
set enable-bracketed-paste onUnfortunately, Horn's test site also shows how to bypass this protection through text formatting itself and prematurely end Bracketed mode on it. This works because some terminals don't properly filter escape sequences before adding their own. For example, in mine, I was never able to successfully complete the Konsole tests even with the correct configuration. .inputrc file. This means that you can easily get system configuration corruption due to an unsupported application or a misconfigured shell. This is especially dangerous when logging into remote servers, where careful configuration work is less common, especially if you have a lot of such remote machines.
A good solution to this problem is the Paste Confirmation Plugin for Terminal urxvt, which simply asks for permission to paste any text containing newlines. I did not find a more secure option for the text attack described by Horn.
Tabs and profiles
A popular feature right now is support for a tabbed interface, which we'll define as a single terminal window containing multiple terminals. This feature varies from terminal to terminal, and while traditional xterm terminals don't support tabs at all, more modern terminal incarnations like Xfce Terminal, GNOME Terminal, and Konsole do. Urxvt also has support for tabs, but only if the plugin is used. But in terms of tab support per se, Terminator is the undisputed leader: it not only supports tabs, but it can also place terminals in an arbitrary order (see image below).
Another feature of Terminator is the ability to "group" these tabs together and send the same keystrokes to multiple terminals at the same time, which provides a crude tool for performing bulk operations on multiple servers at the same time. A similar feature is also implemented in Konsole. To use this function in other terminals, you need to use third-party software such as , or .
Tabs work especially well with profiles: for example, you might have one tab for email, another for chat, and so on. This is well supported by Konsole and GNOME Terminal. Both allow each tab to automatically launch its own profile. Terminator also supports profiles, but I couldn't find a way to automatically launch certain programs when a certain tab is opened. Other terminals don't have the concept of a "profile" at all.
Ruffles
The last thing I will cover in the first part of this article is the appearance of the terminals. For example GNOME, Xfce and urxvt support transparency, but have recently dropped support for background images, forcing some users to switch to the terminal . Personally, I'm satisfied and just xresources, which sets the base set of background colors for urxvt. However, non-standard color themes can create problems. For example, with applications и , since they already use their own colors.
did not support colors, and new ones were often limited to a 256-color palette. For power users who style their terminals, shell prompts or status bars in some complicated way can be a nasty limitation. keeps track of which terminals have "True Color" support. My tests confirm that st, Alacritty and VTE based terminals support True Color perfectly. Other terminals don't do very well in this regard and in fact don't even display 256 colors. Below you can see the difference between True Color support in GNOME terminals, st and xterm, which do a pretty good job with their 256-color palette, and urxvt, which not only fails the test, but even shows some blinking characters instead. them.
Some terminals also parse text for URL patterns to make links clickable. This applies to all VTE-derived terminals, while urxvt requires a special plug-in that would transform URLs on click or with a keyboard shortcut. Other terminals I've tested display URLs differently.
Finally, a new trend in terminals is the optional scroll buffer. For example, st does not have a scroll buffer; the user is supposed to be using a terminal multiplexer like tmux and .
Alacritty also lacks backscroll buffers, but its support due to the "extensive feedback" on this topic from users. Apart from these upstarts, every terminal I have checked that I can find supports reverse scrolling.
Subtotals
In the second part of the material (in the original, these were two different articles, - approx. per.) we will compare performance, memory usage and latency. But we already see that some of the terminals in question have serious shortcomings. For example, users who work with RTL scripts on a regular basis may pay attention to mlterm and pterm, as they are better than others for such tasks. Konsole also performed well. Users who do not work with RTL scripts may choose something else.
From the point of view of protection against the insertion of malicious code, urxvt stands apart due to its special implementation of protection against this type of attack, which I find definitely convenient. Those looking for some bells and whistles should check out Konsole. Finally, it is worth noting that VTE is a great base for terminals, which guarantees color support, URL recognition, and so on. At first glance, the default terminal that comes with your favorite environment might fit the bill, but we'll leave that question open until we get to the bottom of performance.
We continue the conversation
In general, the performance of terminals in itself may seem like a far-fetched problem, however, as it turns out, some of them exhibit surprisingly high latency for software of this fundamental type. Also further we will look at what is traditionally called “speed” (in fact, this is scrolling speed) and the memory consumption of the terminal (with an eye to the fact that today this is not as critical as it was decades ago).
Delay
After a thorough study of the performance of terminals, I came to the conclusion that the most important parameter in this regard is the size of the delay (ping). In his article Pavel Fatin looked at the latency of various text editors and hinted that terminals might be slower in this regard than the fastest text editors. It was this hint that led me to eventually run my own tests and write this article.
But what is latency, and why is it so important? In his article, Fatin defined it as "the delay between pressing a key and the corresponding screen update" and quoted , which states: "Delay in visual feedback on a computer display has an important impact on typist behavior and satisfaction."
Fatin explains that such a ping has deeper consequences than just satisfaction: "typing becomes slower, more errors occur, eye and muscle strain increases." In other words, a large delay can lead to typos, as well as a decrease in the quality of the code, as it leads to an additional cognitive load on the brain. But to make matters worse, ping "increases eye and muscle strain," which seems to imply in future (apparently, the author means problems with the muscles of the eyes, back, arms and, of course, vision, - approx. per.) due to repetitive stress.
Some of these effects have been known for a long time, and the results , published back in 1976 in the journal Ergonomics, say that a delay of 100 milliseconds "significantly degrades the speed of typing." More recently, the GNOME User Guide has added in 10 milliseconds, and if you go further, then indicates that the ideal is 1 millisecond.
Fatin conducted his tests on text editors; he created a portable tool called which I used to test ping in terminal emulators. Keep in mind that the test was run in simulation mode: in reality, we need to take into account both input latency (keyboard, USB controller, and so on) and output latency (video card buffer, monitor). According to Fatin, in typical configurations, it is about 20 ms. With gaming equipment, you can achieve a figure of only 3 milliseconds. Since we already have such fast hardware, the application should not add any latency. Fatin's goal is to bring the application latency to 1 millisecond, or even achieve dialing without , how in .
And here are the results of my measurements, as well as some results of Fatin in order to show that my experiment is consistent with his tests:
The first thing that struck me was the better response times of older programs such as xterm and mlterm. With the worst register latency (2,4 ms) they performed better than the fastest modern terminal (10,6 ms for st). No modern terminal drops below the 10 millisecond threshold. In particular, Alacritty falls short of the "fastest terminal emulator in existence" claim, although its scores have improved since it was first reviewed in 2017. Indeed, the authors of the project and are working on improving the display. It should also be noted that Vim using GTK3 is an order of magnitude slower than its GTK2 counterpart. From this we can conclude that GTK3 creates additional latency, and this is reflected in all other terminals that use it (Terminator, Xfce4 Terminal and GNOME Terminal).
However, the differences may not be noticeable to the eye. As Fatin explains, "You don't have to be aware of a delay for it to have an effect on you." Fatin also warns about the standard deviation: "any irregularities in the duration of the delay (jitter) create additional burden due to their unpredictability."
The graph above is taken on a clean Debian 9 (stretch) with . This environment gives the best results in latency tests. As it turns out, GNOME generates an extra 20ms ping for all measurements. A possible explanation for this is the existence of programs with synchronous processing of input events. Fatin gives an example for such a case , which adds latency by processing all input events synchronously. GNOME also comes with a window manager by default. , which creates an extra layer of buffering that impacts ping and adds a minimum of 8 milliseconds of latency.
Scroll speed
The next test is the traditional "speed" or "bandwidth" test, which measures how quickly a terminal can scroll a page while displaying a large amount of text on the screen. The mechanics of the test varies; the original test was to just generate the same text string with the seq command. Other tests include a test by Thomas E. Dickey (the xterm maintainer) that repeatedly . In another review of terminal performance uses a base32 encoded string of random bytes that is output to the terminal with cat. Luu considers such a test "as useless as a benchmark as one can imagine" and suggests using terminal response as the main metric instead. Dickey also calls his test misleading. However, both authors acknowledge that terminal window bandwidth can be an issue. Luu found Emacs Eshell hanging when displaying large files, and Dickey optimized the terminal to get rid of xtrerm's visual sluggishness. Therefore, there is still some merit in this test, but since the rendering process is very different from terminal to terminal, it can also be used as a test component to check other parameters.
Here we see rxvt and st taking the lead over the competition, followed by the much newer Alacritty, which is being developed with a focus on performance. Next come Xfce (the VTE family) and Konsole, which are almost twice as fast. Last comes xterm, which is five times slower than rxvt. During the test, the xterm also rippled a lot, passing text was hard to see, even if it was the same line. Konsole was fast, but at times it was "cunning": the display hung from time to time, showing text partially or not displaying it at all. Other terminals displayed strings clearly, including st, Alacritty, and rxvt.
Dickey explains that the performance differences are due to the design of the scroll buffers in different terminals. In particular, he accuses rxvt and other terminals of not "following the general rules":
“Unlike xterm, rxvt didn't try to display all updates. If it falls behind, it will drop some upgrades to catch up. This had more of an effect on the apparent scrolling speed than on the organization of the internal memory. One drawback was that the ASCII animation was somewhat inaccurate."
To fix this seeming slowness of xterm, Dickey suggests using the resource , allowing xterm to discard some screen updates to keep up with the flow. My tests confirm that fastScroll improves performance and brings xterm on par with rxvt. This is, however, a rather crude hack, as Dickey himself explains: "Sometimes xterm - like konsole - seems to stall as it waits for a new set of screen updates after some of them have been removed." In this vein, other terminals seem to have found the best compromise between speed and display integrity.
Resource consumption
Regardless of the usefulness of considering scroll speed as a measure of performance, this test allows us to simulate the load on terminals, which in turn allows us to measure other parameters such as memory or disk usage. The metrics were obtained by running the specified test seq under Python process monitoring. He collected meter data for ru_maxrss, amount en_oublock и en_inblock and a simple timer.
In this test, the ST takes first place with the lowest average memory consumption of 8MB, which is not surprising given that the main idea of the project is simplicity. Slightly more consumes mlterm, xterm and rxvt - about 12 MB. Another notable result is Alacritty, which requires 30 MB to run. Then there are terminals of the VTE family with indicators from 40 to 60 MB, which is quite a lot. This consumption can be explained by the fact that these terminals use higher-level libraries, such as GTK. The Konsole comes last with a whopping 65MB of memory during benchmarks, although this can still be justified by its very wide feature set.
Compared to the previous results obtained ten years ago, all programs began to consume noticeably more memory. Xterm used to require 4 MB, but now it's 15 MB just at startup. There is a similar increase in consumption for rxvt, which now requires 16 MB out of the box. Xfce Terminal takes up 34 MB, which is three times as much as before, while GNOME Terminal requires only 20 MB. Of course, all previous tests were carried out on a 32-bit architecture. At LCA 2012 Rusty Russell that there are many more subtle reasons that can explain the increase in memory consumption. With all this, we now live in a time when we have whole gigabytes of memory, so somehow we can handle it.
However, I can't help feeling that allocating more memory to such fundamental software as a terminal is a waste of resources. These programs should be the smallest of the smallest, should be able to run on any "box", even a shoe box, if we ever come to the point that they need to be equipped with Linux systems (and you know that they will be) . But with these numbers, memory usage will become a problem in the future in any environment when running multiple terminals, except for a few of the lightest and most limited in capabilities. To compensate for this, GNOME Terminal, Konsole, urxvt, Terminator, and Xfce Terminal have a Daemon mode that allows you to control multiple terminals through a single process, which limits their memory consumption.
During my tests, I came up with another unexpected result regarding disk read-write: I expected to see nothing here at all, but it turned out that some terminals write the largest data to disk. So, the VTE library actually keeps a scroll buffer on disk (this feature and this is still happening). But unlike the old implementations, now at least this data is encrypted using AES256 GCM (). But a reasonable question arises, what is so special about the VTE library that it requires such a non-standard approach to implementation ...
Conclusion
In the first part of the article, we found that VTE-based terminals have a good feature set, but now we see that this comes with some performance overhead. Now memory is not a problem, because all VTEs can be controlled through a Daemon process that limits their appetite. However, older systems that are physically limited in terms of RAM and kernel buffer may still need older terminals as they consume significantly less resources. Although VTE terminals perform well in throughput (scrolling) tests, their display latency is above the threshold set in the GNOME User Guide. Perhaps the VTE developers should take this into account. If we take into account that even for novice Linux users encountering a terminal is inevitable, they can make it more user friendly. For experienced geeks, switching from the default terminal can even mean reduced eye strain and avoid future occupational injuries and illnesses due to long work sessions. Unfortunately, only the old xterm and mlterm bring us to the magical ping threshold of 10 milliseconds, which is unacceptable for many.
The benchmarks also showed that due to the development of Linux graphical environments, developers had to make a number of compromises. Some users should take a look at regular window managers as they provide significant ping reduction. Unfortunately, there was no latency measurement for Wayland: the Typometer program I used was designed to do what Wayland is designed to prevent - spying on other windows. I hope that Wayland's compositing performs better than X.org, and I also hope that in the future someone will find a way to estimate the level of latency in this environment.
Source: habr.com