Beberapa kata dari biro terjemahan kami: biasanya semua orang ingin menerjemahkan bahan dan publikasi terbaru, dan kami tidak terkecuali. Tetapi terminal bukanlah sesuatu yang diperbarui seminggu sekali. Oleh karena itu, kami menerjemahkan untuk Anda sebuah artikel oleh Antoine Bopre yang diterbitkan pada musim semi 2018: meskipun “zaman” yang solid menurut standar modern, menurut pendapat kami, materi tersebut belum sepenuhnya kehilangan relevansinya. Selain itu, yang asli adalah serangkaian dua artikel, tetapi kami memutuskan untuk menggabungkannya menjadi satu posting besar.
Terminal menempati tempat khusus dalam sejarah komputer, tetapi dalam beberapa dekade terakhir mereka telah "dipaksa" untuk benar-benar bertahan hidup bersama dengan baris perintah dengan latar belakang antarmuka grafis di mana-mana.
Terminal emulator menggantikan
perangkat kerasnya , yang, pada gilirannya, merupakan modifikasi sistem pada kartu punch dan sakelar sakelar. Distribusi modern hadir dengan sejumlah emulator terminal dari semua bentuk dan warna. Dan sementara banyak diam-diam puas dengan terminal standar yang disediakan oleh lingkungan kerja mereka, beberapa dengan bangga menggunakan perangkat lunak yang terus terang eksotis untuk meluncurkan shell atau editor teks favorit mereka. Tetapi, seperti yang akan kita lihat dari artikel ini, tidak semua terminal dibuat dalam satu gambar dan rupa: mereka sangat bervariasi dalam fungsi, ukuran dan kinerja.
Beberapa terminal memiliki lubang keamanan yang luar biasa, ditambah, sebagian besar memiliki serangkaian fungsi yang sama sekali berbeda, dari dukungan antarmuka tab hingga scripting. Meskipun kami
melihat emulator terminal di masa lalu , artikel ini adalah pembaruan untuk materi sebelumnya yang akan membantu pembaca menentukan terminal mana yang akan digunakan pada 2018. Paruh pertama artikel membandingkan fungsi, dan babak kedua mengevaluasi kinerja.
Berikut adalah terminal yang saya ulas:
Mungkin ini bukan versi terbaru, karena saya membatasi diri saya untuk membangun stabil pada saat penulisan, yang saya dapat meluncurkan di Debian 9 atau Fedora 27. Satu-satunya pengecualian adalah Alacritty. Dia adalah keturunan terminal dengan akselerasi GPU dan ditulis dalam bahasa yang tidak biasa dan baru untuk tugas ini - Rust. Saya mengecualikan terminal web dari ulasan saya (termasuk pada
Electron ), karena tes pendahuluan menunjukkan kinerjanya yang sangat buruk.
Dukungan Unicode
Saya memulai pengujian dengan dukungan Unicode. Tes terminal pertama adalah menampilkan string Unicode dari
artikel Wikipedia : "é, Δ ,,, ק, م, ๗, あ, 叶, 葉, 葉, dan 말." Tes sederhana ini menunjukkan apakah terminal dapat bekerja dengan benar di seluruh dunia. Terminal xterm tidak menampilkan simbol Arab
Mem dalam konfigurasi default:
Secara default, xterm menggunakan font "tetap" klasik, yang, menurut
Wiki , memiliki "cakupan Unicode yang signifikan sejak 1997." Sesuatu terjadi di font ini yang menyebabkan karakter muncul sebagai bingkai kosong dan hanya ketika font teks meningkat menjadi 20+ poin karakter akhirnya mulai ditampilkan dengan benar. Namun, "perbaikan" tersebut merusak tampilan karakter Unicode lainnya:
Tangkapan layar ini diambil di Fedora 27, karena memberikan hasil yang lebih baik daripada Debian 9, di mana beberapa terminal versi lama (khususnya mlterm) tidak dapat berfungsi dengan baik dengan font. Untungnya, ini telah diperbaiki di versi yang lebih baru.
Sekarang perhatikan pemetaan string di xterm. Ternyata simbol Mem dan
Qof Semit berikutnya milik
skrip RTL (
kanan-ke-kiri ), jadi secara teknis mereka harus ditampilkan dari kanan ke kiri. Browser web, seperti Firefox 57, menangani dengan benar baris di atas. Versi sederhana dari teks RTL adalah kata "
Sarah " dalam bahasa Ibrani (
שרה ).
Halaman wiki dua arah mengatakan yang berikut:
“Banyak program komputer tidak dapat menampilkan teks dua arah dengan benar. Misalnya, nama Ibrani "Sarah" terdiri dari simbol sin (ש) (yang muncul di sebelah kanan), kemudian resh (ר) dan, akhirnya, heh (ה) (yang seharusnya muncul di sebelah kiri). "
Banyak terminal gagal tes ini: Alacritty, terminal yang diturunkan VTE Gnome dan XFCE, urxvt, st dan xterm menampilkan "Sarah" dalam urutan terbalik, seolah-olah kita mengeja nama ini sebagai "Aras".
Masalah lain dengan teks dua arah adalah bahwa mereka perlu disejajarkan dengan cara tertentu, terutama ketika menyangkut pencampuran teks RTL dan LTR. Script RTL harus dijalankan di sisi kanan jendela terminal, tetapi apa yang seharusnya terjadi untuk terminal yang menggunakan bahasa Inggris LTR? Kebanyakan dari mereka tidak memiliki mekanisme khusus dan menyelaraskan seluruh teks ke kiri (termasuk Konsole). Pengecualiannya adalah pterm dan mlterm, yang mematuhi standar dan menyelaraskan garis-garis tersebut ke kanan.
Perlindungan penyisipan
Fitur penting berikutnya yang telah saya tentukan sendiri adalah perlindungan terhadap penyisipan. Meskipun secara luas diketahui bahwa mantra itu seperti:
$ curl http://example.com/ | sh
adalah perintah eksekusi kode push, beberapa orang tahu bahwa perintah tersembunyi dapat menembus konsol saat menyalin dan menempel dari browser web, bahkan setelah pemeriksaan menyeluruh.
Situs tes Gianna Horne dengan cemerlang menunjukkan betapa tidak berbahaya penampilan tim:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.git
itu berubah menjadi gangguan ketika menempelkan dari situs web Horn ke 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.git
Bagaimana cara kerjanya? Kode berbahaya ditempatkan di blok
<span> , yang dipindahkan dari bidang penglihatan pengguna menggunakan CSS.
Mode pasta braket jelas dirancang untuk menetralkan serangan tersebut. Dalam mode ini, terminal melampirkan teks yang disisipkan dalam sepasang urutan pelarian khusus untuk menginformasikan shell tentang asal usul teks ini. Jadi shell menerima sinyal bahwa ia dapat mengabaikan karakter khusus yang berisi teks yang dimasukkan. Semua terminal, hingga xterm terhormat, mendukung fungsi ini, tetapi penyisipan dalam mode Bracketed memerlukan dukungan untuk shell atau aplikasi yang berjalan di terminal. Misalnya, perangkat lunak yang menggunakan
GNU Readline (Bash yang sama) membutuhkan file
~ / .inputrc :
set enable-bracketed-paste on
Sayangnya, situs uji Horn juga menunjukkan cara mengatasi perlindungan ini dengan memformat teks itu sendiri dan secara prematur mengakhiri penerapan mode Bracketed untuk itu. Ini berfungsi karena beberapa terminal tidak dengan benar menyaring urutan keluar sebelum menambahkan mereka sendiri. Misalnya, di saya, saya tidak berhasil menyelesaikan tes Konsole, bahkan dengan mempertimbangkan konfigurasi yang benar dari file
.inputrc . Ini berarti Anda dapat dengan mudah mendapatkan kerusakan konfigurasi sistem karena aplikasi yang tidak didukung atau shell yang tidak dikonfigurasi dengan benar. Ini sangat berbahaya ketika memasuki server jauh, di mana studi konfigurasi yang cermat kurang umum, terutama jika Anda memiliki banyak mesin jarak jauh tersebut.
Solusi yang baik untuk masalah ini adalah plugin konfirmasi tempel untuk terminal
urxvt , yang hanya meminta izin untuk menempelkan teks yang berisi baris baru. Saya tidak menemukan opsi yang lebih aman untuk serangan teks yang dijelaskan oleh Horn.
Tab dan Profil
Fitur populer sekarang adalah untuk mendukung antarmuka tab, yang akan kita definisikan sebagai satu jendela terminal yang berisi beberapa terminal lagi. Untuk terminal yang berbeda, fungsi ini berbeda, dan meskipun terminal tradisional seperti xterm tidak mendukung tab sama sekali, inkarnasi terminal yang lebih modern diwakili oleh Terminal Xfce, Terminal GNOME dan Konsole memiliki fungsi ini. Urxvt juga memiliki dukungan tab, tetapi hanya jika plugin digunakan. Tetapi dalam hal tab pendukung seperti itu, Terminator adalah pemimpin yang tidak perlu dipersoalkan: ia tidak hanya mendukung tab, tetapi juga dapat mengatur terminal dalam urutan apa pun (lihat gambar di bawah).
Fitur lain dari Terminator adalah kemampuan untuk "mengelompokkan" tab-tab ini bersama-sama dan mengirim penekanan tombol yang sama ke beberapa terminal secara bersamaan, yang menyediakan alat kasar untuk melakukan operasi massal pada beberapa server secara bersamaan. Fitur serupa juga diterapkan di Konsole. Untuk menggunakan fungsi ini di terminal lain, Anda harus menggunakan perangkat lunak pihak ketiga seperti
Cluster SSH ,
xlax atau
tmux .
Tab bekerja sangat baik bersama dengan profil: misalnya, Anda dapat memiliki satu tab untuk email, lainnya untuk obrolan dan sebagainya. Ini didukung dengan baik oleh Konsole dan Terminal GNOME. Keduanya memungkinkan setiap tab untuk secara otomatis meluncurkan profilnya. Terminator juga mendukung profil, tetapi saya tidak dapat menemukan cara untuk secara otomatis meluncurkan program tertentu ketika saya membuka tab tertentu. Terminal lain tidak memiliki konsep profil sama sekali.
Ryushechki
Hal terakhir yang akan saya pertimbangkan di bagian pertama artikel ini adalah penampilan terminal. Misalnya, GNOME, Xfce, dan urxvt mendukung transparansi, tetapi baru-baru ini menghapus dukungan untuk gambar latar belakang, memaksa beberapa pengguna untuk beralih ke terminal
Tilix . Secara pribadi, saya senang hanya dengan
Xresources , yang menetapkan set dasar warna latar belakang untuk urxvt. Namun, tema warna khusus dapat menyebabkan masalah. Misalnya,
Solarized tidak berfungsi dengan
aplikasi htop dan
IPTraf , karena mereka sudah menggunakan warna mereka sendiri.
Terminal VT100 asli tidak mendukung warna, dan yang baru sering terbatas pada palet 256-warna. Untuk pengguna tingkat lanjut yang menata terminal mereka, permintaan shell atau bilah status dengan beberapa cara rumit bisa menjadi batasan yang tidak menyenangkan.
Gist melacak terminal mana yang memiliki dukungan True Color. Tes saya mengkonfirmasi bahwa terminal berbasis st, Alacritty, dan VTE sangat mendukung True Color. Terminal lain dalam hal ini tidak terasa sangat baik dan bahkan tidak menampilkan 256 warna. Di bawah ini Anda dapat melihat perbedaan antara dukungan True Color di terminal GNOME, st dan xterm, yang melakukan pekerjaan dengan baik dengan palet 256-warna, dan urxvt, yang tidak hanya gagal dalam tes, tetapi bahkan menunjukkan beberapa karakter yang berkedip sebagai gantinya mereka.
Beberapa terminal juga menganalisis teks untuk pola URL untuk membuat tautan dapat diklik. Ini berlaku untuk semua terminal yang diturunkan VTE, sementara urxvt memerlukan plug-in khusus yang mengubah URL dengan klik atau pintasan keyboard. Terminal lain saya menguji URL tayangan dengan cara lain.
Akhirnya, tren baru untuk terminal adalah opsi buffer gulir. Sebagai contoh, di st tidak ada buffer gulir; Diasumsikan bahwa pengguna akan menggunakan terminal multiplexer seperti tmux dan
Layar GNU .
Alacritty juga tidak memiliki buffer gulir terbalik, tetapi dukungan
akan segera ditambahkan karena "umpan balik yang luas" pada topik ini dari pengguna. Selain pemula ini, setiap terminal saya menguji bahwa saya dapat menemukan dukungan bergulir ke belakang.
Subtotal
Pada bagian kedua dari materi (
dalam aslinya, ini adalah dua artikel yang berbeda, - kira-kira Per. ) Kami akan membandingkan kinerja, penggunaan memori dan penundaan. Tetapi kita sudah melihat bahwa beberapa terminal yang dimaksud memiliki kekurangan yang serius. Sebagai contoh, pengguna yang secara teratur bekerja dengan skrip RTL dapat memperhatikan mlterm dan pterm, karena mereka mengatasi tugas-tugas seperti itu lebih baik daripada yang lain. Konsole juga tampil dengan baik. Pengguna yang tidak bekerja dengan skrip RTL dapat memilih sesuatu yang lain.
Dari sudut pandang keamanan terhadap penyisipan kode berbahaya, urxvt berdiri terpisah karena penerapan perlindungan khusus terhadap serangan jenis ini, yang menurut saya pasti nyaman. Mereka yang mencari lonceng dan peluit harus melihat Konsole. Akhirnya, perlu dicatat bahwa VTE adalah basis yang bagus untuk terminal, yang menjamin dukungan warna, pengenalan URL, dan sebagainya. Pada pandangan pertama, terminal default yang datang dengan lingkungan favorit Anda dapat memenuhi semua persyaratan, tetapi mari kita biarkan pertanyaan ini terbuka sampai kita mengetahui kinerja.
Lanjutkan pembicaraan
Secara umum, kinerja terminal itu sendiri mungkin tampak seperti masalah yang dibuat-buat, namun, ternyata, beberapa dari mereka menunjukkan penundaan yang sangat besar untuk perangkat lunak dari tipe fundamental ini. Kami juga akan melihat lebih jauh pada apa yang secara tradisional disebut "kecepatan" (pada kenyataannya, ini adalah kecepatan gulir) dan konsumsi memori oleh terminal (mengingat hari ini tidak sepenting beberapa dekade yang lalu).
Tunda
Setelah mempelajari secara menyeluruh kinerja terminal, saya sampai pada kesimpulan bahwa parameter yang paling penting dalam hal ini adalah ukuran delay (ping). Dalam artikelnya
“Kami mencetak dengan senang hati”, Pavel Fatin memeriksa keterlambatan berbagai editor teks dan mengisyaratkan bahwa terminal dalam hal ini dapat bekerja lebih lambat daripada editor teks tercepat. Petunjuk inilah yang membuat saya, pada akhirnya, meluncurkan tes saya sendiri dan menulis artikel ini.
Tapi apa itu penundaan, dan mengapa itu begitu penting? Dalam artikelnya, Fatin mendefinisikannya sebagai "penundaan antara menekan tombol dan pembaruan layar yang sesuai" dan mengutip
"Manual tentang interaksi manusia-komputer" yang mengatakan: "Keterlambatan umpan balik visual pada tampilan komputer memiliki efek penting pada perilaku juru ketik dan kepuasannya. ".
Fatin menjelaskan bahwa ping seperti itu memiliki konsekuensi yang lebih dalam dari sekadar kepuasan: "mengetik menjadi lebih lambat, lebih banyak kesalahan terjadi, ketegangan mata dan otot meningkat." Dengan kata lain, penundaan besar dapat menyebabkan kesalahan ketik, serta penurunan kualitas kode, karena mengarah pada beban kognitif tambahan pada otak. Tetapi yang lebih buruk, ping "meningkatkan ketegangan mata dan otot", yang, tampaknya, menyiratkan
perkembangan cedera profesional di masa depan (
tampaknya, penulis berarti masalah dengan otot mata, punggung, lengan dan, tentu saja, penglihatan, - sekitar Per. ) Karena stres berulang.
Beberapa dari efek ini telah dikenal sejak lama, dan hasil
penelitian yang diterbitkan kembali pada tahun 1976 dalam jurnal Ergonomics mengatakan bahwa penundaan 100 milidetik "secara signifikan memperburuk kecepatan panggilan." Baru-baru ini,
waktu respons 10 milidetik yang dapat diterima diperkenalkan dalam panduan pengguna GNOME, dan jika kita melangkah lebih jauh,
Microsoft Research menunjukkan bahwa 1 milidetik ideal.
Fatin melakukan tes pada editor teks; dia menciptakan alat portabel yang disebut
Typometer , yang saya gunakan untuk menguji ping di terminal emulator. Ingatlah bahwa pengujian dilakukan dalam mode simulasi: pada kenyataannya, kita juga perlu mempertimbangkan penundaan input (keyboard, pengontrol USB, dll.) Dan output (buffer kartu video, monitor). Menurut Fatin, dalam konfigurasi tipikal adalah sekitar 20 ms. Jika Anda memiliki peralatan game, Anda hanya dapat mencapai indikator 3 milidetik. Karena kita sudah memiliki peralatan yang begitu cepat, aplikasi seharusnya tidak memperkenalkan penundaannya juga. Tujuan Fatin adalah untuk menunda aplikasi hingga 1 milidetik, atau untuk mencapai panggilan tanpa
penundaan yang terukur , seperti dalam
IntelliJ IDEA 15 .
Dan berikut ini adalah hasil pengukuran saya, serta beberapa hasil Fatin untuk menunjukkan bahwa percobaan saya konsisten dengan tes-tesnya:
Hal pertama yang mengejutkan saya adalah waktu respons terbaik untuk program yang lebih lama seperti xterm dan mlterm. Dengan latensi register terburuk (2,4 ms), mereka menunjukkan hasil yang lebih baik daripada terminal modern tercepat (10,6 ms untuk st). Tidak ada terminal modern yang jatuh di bawah ambang 10 milidetik. Secara khusus, Alacritty tidak memenuhi persyaratan untuk "emulator terminal tercepat yang ada", meskipun hasilnya telah meningkat sejak pemeriksaan pertama pada tahun 2017. Memang, penulis proyek
menyadari situasi dan berupaya memperbaiki tampilan. Perlu juga dicatat bahwa Vim menggunakan GTK3 adalah urutan besarnya lebih lambat dari rekan GTK2-nya. Dari sini kita dapat menyimpulkan bahwa GTK3 menciptakan penundaan tambahan, dan ini tercermin di semua terminal lain yang menggunakannya (Terminator, Xfce4 Terminal dan Terminal GNOME).
Namun, perbedaan mungkin tidak terlihat oleh mata. Seperti yang dijelaskan Fatin: "Tidak perlu mewaspadai keterlambatan agar hal itu berdampak pada Anda." Fatin juga memperingatkan deviasi standar: "Setiap penyimpangan dalam jangka waktu keterlambatan (jitter) menciptakan beban tambahan karena tidak dapat diprediksi."
Grafik di atas diambil pada Debian 9 murni (stretch) dengan
manajer jendela i3 . Lingkungan ini memberikan hasil terbaik dalam tes penundaan. Ternyata, GNOME menciptakan ping tambahan 20 ms untuk semua dimensi. Penjelasan yang mungkin untuk ini adalah keberadaan program dengan pemrosesan peristiwa input secara sinkron. Fatin mengutip contoh
Workrave untuk kasus ini, yang menambahkan penundaan dengan memproses semua peristiwa input secara sinkron. Secara default, GNOME juga memiliki
Mutter window manager yang menciptakan level tambahan buffering, yang memengaruhi ping dan menambahkan penundaan minimal 8 milidetik.
Kecepatan gulir
Tes berikutnya adalah tes tradisional "kecepatan" atau "bandwidth", yang mengukur seberapa cepat terminal dapat menggulir halaman, menampilkan sejumlah besar teks pada layar. Mekanisme tes bervariasi; tes asli adalah hanya menghasilkan string teks yang sama dengan perintah seq. Tes lain termasuk tes oleh Thomas E. Dickey (pengelola xterm), yang berulang kali
mengunduh file terminfo.src . Dalam ulasan kinerja terminal lain,
Den Luu menggunakan string byte acak yang disandikan, yang di-output ke terminal menggunakan cat. Luu menganggap tes semacam itu sebagai "tidak berguna karena dapat dibayangkan" dan menyarankan menggunakan respons terminal sebagai indikator utama. Dickey juga menyebut tesnya menyesatkan. Namun, kedua penulis mengakui bahwa bandwidth jendela terminal dapat menjadi masalah. Luu menemukan Emacs Eshell membeku ketika menampilkan file-file besar, dan Dickie mengoptimalkan terminal untuk menghilangkan kelambatan visual xtrerm. Oleh karena itu, masih ada beberapa alasan untuk pengujian ini, tetapi karena proses rendering sangat berbeda dari terminal ke terminal, itu juga dapat digunakan sebagai komponen uji untuk memeriksa parameter lainnya.
Di sini kita melihat bahwa rxvt dan st berada di depan di depan kompetisi, diikuti oleh Alacritty yang jauh lebih baru, yang sedang dikembangkan dengan fokus pada kecepatan. Selanjutnya datang Xfce (keluarga VTE) dan Konsole, yang bekerja hampir dua kali lebih cepat. Yang terakhir adalah xterm dengan indeks lima kali lebih lambat dari rxvt. Selama pengujian, xterm juga berdesir, sulit untuk melihat teks yang lewat, bahkan jika itu adalah baris yang sama. Konsole ternyata cepat, tetapi kadang-kadang itu "rumit": layar tergantung dari waktu ke waktu, menunjukkan sebagian teks atau tidak menampilkannya sama sekali. Terminal lain menampilkan string dengan jelas, termasuk st, Alacritty, dan rxvt.
Dickie menjelaskan bahwa perbedaan kinerja terkait dengan desain buffer gulir di terminal yang berbeda. Secara khusus, ia menuduh rxvt dan terminal lainnya “tidak mengikuti aturan umum”:
“Tidak seperti xterm, rxvt tidak mencoba menampilkan semua pembaruan. Jika dia ketinggalan, dia akan membuang beberapa pembaruan untuk mengejar ketinggalan. Ini memiliki efek yang lebih besar pada kecepatan gulir imajiner daripada pada organisasi memori internal. Satu kekurangannya adalah bahwa animasi ASCII agak tidak akurat. ”
Untuk memperbaiki kelambatan xterm yang tampaknya ini, Dickey menyarankan untuk menggunakan sumber daya
fastScroll , yang memungkinkan xterm untuk membuang beberapa pembaruan layar untuk mengikuti arus. Pengujian saya mengonfirmasi bahwa fastScroll meningkatkan kinerja dan membawa xterm ke tingkat yang sama dengan rxvt. Namun, ini adalah penopang yang agak kasar, seperti yang dijelaskan Dickey sendiri: "kadang-kadang xterm - seperti konsole - tampaknya berhenti karena mengharapkan serangkaian pembaruan layar baru setelah beberapa dari mereka telah dihapus." Dalam nada ini, tampaknya terminal lain telah menemukan kompromi terbaik antara kecepatan dan integritas layar.
Konsumsi sumber daya
Terlepas dari kesesuaian mempertimbangkan kecepatan gulir sebagai indikator kinerja, tes ini memungkinkan Anda untuk mensimulasikan beban pada terminal, yang, pada gilirannya, memungkinkan kami untuk mengukur parameter lain, seperti memori atau penggunaan disk. Metrik diperoleh dengan menjalankan tes
seq yang ditentukan di bawah pemantauan proses Python. Dia mengumpulkan
getrusage () data penghitung untuk
ru_maxrss , jumlah
ru_oublock dan
ru_inblock, dan timer sederhana.
Dalam tes ini, ST mengambil tempat pertama dengan konsumsi memori rata-rata terkecil 8 MB, yang tidak mengejutkan ketika Anda menganggap bahwa ide utama dari proyek ini adalah kesederhanaan. Mlterm, xterm dan rxvt mengkonsumsi sedikit lebih banyak - sekitar 12 MB. Alacritty memiliki hasil penting lainnya, yang membutuhkan 30 MB untuk bekerja. Lalu ada terminal keluarga VTE dengan indikator dari 40 hingga 60 MB, yang cukup banyak. Konsumsi semacam itu dapat dijelaskan oleh fakta bahwa terminal ini menggunakan pustaka tingkat yang lebih tinggi, misalnya, GTK. Konsole hadir dengan konsumsi memori sebesar 65 MB selama pengujian, meskipun hal ini dapat dibenarkan dengan berbagai fungsinya yang sangat luas.
Dibandingkan dengan hasil sebelumnya yang diperoleh sepuluh tahun yang lalu, semua program mulai mengkonsumsi lebih banyak memori. Sebelumnya, Xterm membutuhkan 4 MB, tetapi sekarang - 15 MB hanya untuk dijalankan. Rxvt memiliki peningkatan konsumsi yang serupa, yang sekarang membutuhkan 16 MB di luar kotak. Terminal Xfce menempati 34 MB, yang tiga kali lebih banyak dari sebelumnya, tetapi Terminal GNOME hanya membutuhkan 20 MB. Tentu saja, semua tes sebelumnya dilakukan pada arsitektur 32-bit. Pada LCA 2012, Rusty Russell
mengatakan bahwa ada banyak alasan yang lebih halus yang dapat menjelaskan peningkatan konsumsi memori. Dengan semua ini, kita sekarang hidup di masa ketika kita memiliki seluruh memori gigabytes, sehingga kita dapat menanganinya.
Namun demikian, saya tidak dapat menahan perasaan bahwa mengalokasikan lebih banyak memori ke perangkat lunak mendasar seperti terminal adalah pemborosan sumber daya. , «», , - , Linux- ( , ). , . , GNOME Terminal, Konsole, urxvt, Terminator Xfce Terminal Daemon-, , .
-: , , . , VTE (
2010 , ). , , , AES256 GCM (
0.39.2 ). , VTE, …
Kesimpulan
, VTE , , . , VTE- Daemon-, . , , , - , . VTE (), GNOME. , VTE . , Linux , . - . , xterm mlterm 10 , .
, - Linux . , . , Wayland : Typometer, , , Wayland — . , Wayland , X.org, , - .