Today the default choice for a terminal program is Gnome Terminal

March 20, 2023

Recently over on the Fediverse, someone who's coming back to Linux asked what terminal program one should use these days. After thinking about it, I realized that my answer had to be Gnome Terminal (also), at least for the kind of person who's asking this question without any particular additional qualifiers.

I'm personally very attached to the venerable xterm, but xterm is an acquired taste with various issues in practice, so I can't recommend it to a new person. If you want xterm, you already know it (and you probably have several reasons why). Out of the various alternatives, I think Gnome Terminal is the default choice for two reasons.

First, Gnome Terminal is inoffensive and basically works. I believe that it has all of the features you'd expect from a modern terminal emulator, and if some aspect of its behavior or appearance isn't entirely to your liking, it supports a reasonable amount of customization. If I had to switch to Gnome Terminal for some reason I could probably get by reasonably well, even though various differences from xterm would irritate me for ages. Gnome Terminal is a perfectly reasonable and functional terminal program, which is the basic requirement.

Second, Gnome Terminal is pervasive; it's the default Gnome terminal program, and Gnome is more or less the default Linux desktop. Because of this, pretty much everyone is going to test things with it and make sure that they work okay, both in appearance and in performance. For example, a Linux distribution is certainly going to make sure that its choice of default monospace font works okay in Gnome Terminal; your mileage may vary in other terminal programs. Similarly, text colours vary between terminal programs but people are almost certainly going to make sure that their program's use of colours looks decent in Gnome Terminal. This means that you're less likely to run into irritations with Gnome Terminal. And if something does explode, if you're using Gnome Terminal in a standard environment (such as Gnome itself), then fixing it should be a high priority for your Linux distribution since a lot of people will be affected.

You can make a case for KDE's konsole on much the same reasons, but I think KDE and konsole are less widely used and so you're more likely to run into issues in distributions and with programs. You can get rid of the distribution issues by using a Linux distribution (not an alternate 'spin' of a distribution) that focuses on KDE, which will likely take care to make sure their choice of default fonts works well with konsole and so on. I'm not sure there are very many of these left, though.

(This elaborates on my Fediverse reply.)

Comments on this page:

I used to be the same many years ago, but then I discovered that some terms felt "faster" when typing and backspacing than others (frame/input lag). Gnome term was on the list of slow ones and using the faster ones (like urxvt/rxvt) felt nicer, so switching was a no-brainer.

Just as of writing this: I tried launching and using a term that used to feel slow (sakura, vte-based) and I can't feel or see any difference any more. Perhaps it's because of my newer processor, graphics card, graphics drivers, monitor refresh rate or just vsync/tearfree config changes? Maybe it was an illusion all along? Not sure.

... and I suddenly felt compelled to try and get some numbers to back this up.

The results are VERY surprising. I was not imagining things after all.

Time from key travel bottoming to LCD starting to change pixels on the terminal:

Terminal name Mean time (camera frames) (msec) Median time (camera frames) (msec)
Gnome terminal 14.3 59.6 14 58.3
urxvt 12.9 53.7 13 54.2
mlterm 7.7 31.9 8 33.3

Gnome term and urxvt seem to perform about the same, well within error if you consider the reliability of my finger poking and the 16.7msec monitor frametime.

mlterm is a whole monitor frame (or possibly more) faster than the others.

~~Chris~~: Just for fun would you mind trying mlterm and reporting back if you feel it's any "faster" or slower than your normal terms?

Overall: everyone scores disgustingly slow for the simple task of showing a letter on a screen. 2-4 monitor frames before my keypress even get seen is abysmal, but I guess all of the GHz of my CPU are about throughput not latency. This delay is a sum of contributions from the keyboard (key mechanism, scanning speed, usb buffering, etc) to PC (USB buffering, interrupts/polling, kernel buffering, task switching), userspace app (terminal and Xorg), graphics drivers and graphics firmware.


  • 60hz monitor (1 frame ~= 16.7msec)
  • 240hz camera (1 frame ~= 4.2msec) (very low res and grainy)
  • Monitor and keyboard both recorded. I whacked the same key over and over again, quickly downwards
  • Times measured from bottoming of key switch (frame 0) to first hint of any change on LCD (frame x = final count)
  • Drivers: amdgpu with tearfree enabled.
  • Hardware: AMD RX570, AMD Ryzen 5 5600
  • GNOME Terminal 3.46.7 using VTE 0.70.1 +BIDI +GNUTLS +ICU -SYSTEMD
  • rxvt-unicode (urxvt) v9.31 - released: 2023-01-02
  • mlterm version 3.9.2
  • Font set to Terminus with a dark background on all (this can affect pixel transition time)
From at 2023-03-21 06:08:29:

Yes, libvte-based terminals are already known for their relatively high latency – there even was an LWN article about it.

It's still within comfortable bounds, though – not enough to offset its good font rendering and other capabilities, so I don't feel the need to switch to one of those fancy "GPU-accelerated" terminal emulators. (And as mentioned in an earlier comment, on the machine where I did want to switch to xterm, gnome-terminal turned out to be somehow much faster at rendering OpenType fonts than xterm was…)

libvte also does frame-limiting as a trick to feel faster. If you have something that generates a lot of output, some terminals like xterm will try to faithfully render each and every line, which can take longer than actually outputting the text. In contrast, gnome-terminal will deliberately cap its FPS so that it's never "left behind".

From at 2023-03-21 06:36:41:

See also: this series of articles on latency by Dan Luu: terminals, keyboards, whole input pipelines and the hard parts of latency measurement.

By zaitcev at 2023-03-24 20:51:53:

I rejected rxvt because it cheated with its display, and I wanted all information (basically, the animations like rotating bar). Reading these comments I understand now that its developers probably chased metrics. At least someone is happy about that, diversity wins yet again. Fortunately, gnome-terminal displays what it's told to display.

Written on 20 March 2023.
« Easily adjusting the minimum interval on panels in Grafana dashboards
ZFS on Linux and NFS(v3) server filesystem IDs »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Mar 20 22:30:05 2023
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.